Prior to this commit, we had two places that need to know the nuances
ofquerying for tag flares and what we should include in our queries for
serialization.
With this commit, we're factoring towards a common source of knowledge
and providing a much needed test for the expected output of this
serialization.
Loosely related to #15916, #15983, #15994, and #16032.
Below are the grep results of searching for ArticleSerializer (note
there are no remaining `Search::ArticleSerializer' references).
Using `ripgrep` (e.g., `rg`), I have the following from the `main`
branch.
```log
> rg ArticleSerializer
app/services/search/reading_list.rb:
Search::ReadingListArticleSerializer
app/services/search/article.rb:
Homepage::ArticleSerializer
app/services/homepage/fetch_articles.rb:
Homepage::ArticleSerializer
spec/serializers/search/reading_list_article_serializer_spec.rb:
RSpec.describe Search::ReadingListArticleSerializer do
app/serializers/search/reading_list_article_serializer.rb:
class ReadingListArticleSerializer < ApplicationSerializer
app/serializers/homepage/article_serializer.rb:
class ArticleSerializer < ApplicationSerializer
```
Definitely want to keep pruning unused code.
This relates to exploration around #15916 and the attempted solutions in
While working on #15916 (via #15983 and later #15994) I was exploring if
we needed to stringify JSON values. I also injected a few `try, catch,
debug` areas.
Consolidating the parsing does not appear to adversely affect things.
* Remove all references to VerifySetupCompleted to remove setup banner
* Removes setup banner-related specs
* Adjusts the title in activateMissingKeysModal
* Adds the show expand classes to getStartedBodyContainer in show.html.erb
* feat: add a section id to the images section
* feat: update the images section
* chore: add some space
* chore: update the descriptiion text for logos
* feat/WIP: first version of the svg logo to png logo DUS
* feat: logoSVG Uploader
* refactor: remove the if original_filename
* feat: add a test for the logo_svg_uploader
* feat: update the test and dus
* add soem error handling
* updae the rails spec helper
* feat: provide a content type
* feat: add content type
* Try https://travis-ci.community/t/build-times-out-with-no-apparent-reason/5083/4
* chore: try this suggestion https://stackoverflow.com/questions/41138404/how-to-install-newer-imagemagick-with-webp-support-in-travis-ci-container
* chore: remove libweb adn fix = in the travis.yml
* chore: undo the changes to attempt to update the version for image magick
* feat: install gsfonts for convert
* chore: add a comment for svg
* feat: use the good practices for tempfile, update error handling and update the tests
* chore: update the timestamp on the DUS
* feat: convert to png with a transparent background using Image Magick
* feat: substitute some css variables with real css colors
* chore: revert the path
* fix: set content type
* Update lib/data_update_scripts/20220105112823_migrate_logo_svg_data.rb
Co-authored-by: Jamie Gaskins <jamie@forem.com>
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Tidying up and documenting Tag model
Prior to this commit we had a custom `where(alias_for: [nil, ""])`
call. That call highlighted that we lacked a term for a Tag that was
not an alias. As part of this commit, I named that a "concrete" tag.
Further, I added scopes to assist in helping "name" those concepts.
This commit also adds a data migration and utilization of
StringAttributeCleaner to hopefully get away from `alias_for == ""`
situations.
As of writing this commit <2022-01-04 Tue 17:22 UTC>, in DEV.to we had 5
tags with `alias_for == ""`:
- actionshackathon21
- regex
- atlashackathon
- hotwire
- foremfest
In https://dev.to/admin/blazer I ran the following:
```sql
SELECT name FROM tags WHERE alias_for = ''
```
* Renaming concrete to direct
* We no longer need to manually install faraday 1.8.0 as a work-around
Faraday 2.0.1 re-introduces the default adapter (net_http), which
makes the prior work around (installing faraday 1.8 prior to
installing dpl, preventing it from bringing in 2.0.0 as the current
release).
There's currently a related dependency issue where a circular
dependency between dpl, faraday, and faraday-patron was causing deploy
failures (faraday-patron requiring faraday 2.0.x but we had
specified otherwise).
Remove the temporary shim to enable travis heroku deploys, and let
their team manage that.
* No longer require faraday before install
This was a first attempt to address the deploy issue, but failed. It
installed faraday in the target ruby version 3, while travis was
installing the conflicting package dpl in their travis internal ruby
version.
Safe to remove.
* Skip google analytics when ga_tracking_id is nil
This commit involves short-circuiting Google Analytics calls when the
Forem has not configured a `Settings::General.ga_tracking_id`. Note,
depending on your local `.env` file (or configured ENV variables) you
may have a `GA_TRACKING_ID` value set; I did, it was set to "Optional"
which overrode the database setting.
We set the HTML data properites in two places: [admin.html.erb][1] and
[application.html.erb][2].
In addition, I'm short-circuiting the local fallback analytics call (via
[Stacato][https://github.com/tpitale/staccato]). My understanding of
Stacato, based on a cursory read, requires a Google Analytics Tracking
ID to work.
And last, we have a one off of javascript for Google Analytics tracking.
This closes#15962.
[1]:528bd2baa6/app/views/layouts/admin.html.erb (L31)
[2]:528bd2baa6/app/views/layouts/application.html.erb (L55)
How to test?
- Check your .env file to see if you have set GA_TRACKING_ID. If so,
unset it.
- Start with a fresh Forem instance.
- Open your browser and open the developer tools to inspect the Network
activity.
- Open the homepage of your local Forem instance (http://localhost:3000)
- Filter your Network results for analytics. You shouldn't see any.
Also, make sure you're disabling any blockers you might have as that
influences things.
* Commenting out GA_TRACKING_ID
Related to https://github.com/forem/forem/pull/15967
* Favor empty GA_TRACKING_ID env variable
Faraday 2.0.1 re-introduces the default adapter (net_http), which
makes the prior work around (installing faraday 1.8 prior to
installing dpl, preventing it from bringing in 2.0.0 as the current
release).
There's currently a related dependency issue where a circular
dependency between dpl, faraday, and faraday-patron was causing deploy
failures (faraday-patron requiring faraday 2.0.x but we had
specified otherwise).
Remove the temporary shim to enable travis heroku deploys, and let
their team manage that.
