* Add a comment, and a safe default value for cloudinary
When moving a site from imgproxy to cloudinary, we observed that
wrapping the cloud name in quotes caused off-looking urls (with the
user name in %22 escaped quotes).
Additionally, if cloudinary is enabled, cloudinary secure should
be set to true. We leave the others blank to prevent conditionally enabling this
service (we check for ENV var presence) mistakenly, but the secure
flag won't turn it on or off and is safe to keep a default value.
* remove unnecessary comment
quoting the env vars had no effect when tested.
* 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
* Remove Connect
* Remove more Connect specs
* Remove a lot more Connect code
* 🚮
* It all has to go
* Explicitly add httpclient
* Update application layout
* Remove messages association from User
* Start fixing specs
* reintroduce util function and refactor references
* Remove Connect Cypress test
* Fix more specs
* Remove Connect from listings
* Ignore contact_via_connect column on listings
* Remove contact_via_connect usages
* Ignore mod_chat_channel_id on tags
* Drop Connect tables
* Remove email_connect_messages from user notification settings
* Re-add httpclient 2.8.3
This was mistakenly removed as a merge conflict
* Don't need to exclude removed chat channel file
* Remove unneeded style for chat channels
* Remove unneeded channel list prop type
* Remove chat channels index/connect-link from getPageEntries
* Re-add comment from httpclient in Gemfile
* Remove connect references from mailers
Tag Moderators no longer have a chat channel
No longer will users be notified about new messages (there won't be
any)
No longer will users be notified about channel invites (you can't
invite anyone anymore)
* Don't configure Pusher and remove PUSHER_* from .env_sample
since it's removed from gemfile, the Pusher constant will not resolve, if this is
configured in the environment variables we'll fail to boot.
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Dan Uber <dan@forem.com>
* When AWS_ID is the placeholder value, act as though AWS not setup
We have "Optional" as the placeholder in the .env_sample
When that's the "final" value in the .env file, assume we're actually
going to use local storage instead.
* Clear placeholder AWS values from env_sample
Revert the change to the carrierwave initializer (don't hardcode the
placeholder value).
Mimics choices we made for Cloudinary in #13767
* Fallback to the image URL if neither Cloudinary nor Imgproxy are configured
* Fix specs
* Cloudinary api_secret is required
* Update spec/models/message_spec.rb
Co-authored-by: Michael Kohl <citizen428@dev.to>
Co-authored-by: Michael Kohl <citizen428@dev.to>
Running coverage is great, but it's definitely something I don't want
to do when interactively using the test suite (running a single file
or single example, this adds 20+ seconds for me).
* WIP: release footprint in the admin UI
* feat: show the commit ID and the date
* chore: change env optional to empty string
* fix: change the FOREM_BUILD_DATE to RELEASE_FOOTPRINT
* feat: add Not Available as a last option
* test: last deployed time and latest commit id
* feat: update the way we change the env variable!
* fix: we need to set the RELEASE FOOTPRINT so that this clause is not hit - `return path if release_footprint.blank?`
* Disable Google reCAPTCHA in env file sample
* Update .env_sample
Co-authored-by: Jacob Herrington <jacobherringtondeveloper@gmail.com>
Co-authored-by: Jacob Herrington <jacobherringtondeveloper@gmail.com>
* Use APP_NAME rather than APP_DOMAIN in chat channels
APP_NAME may not always be set (it is not "required" per se), which can
cause issues while deriving the pusher_channels. We should use APP_DOMAIN,
which is more common and always has a default value.
* Add TODO to make pusher channels more unique
* Only bust_fastly_cache if fastly is enabled
* Conditionally bust nginx cache from CacheBuster#bust
* Don't _actually_ call out to openresty
* Remove redundant check for FASTLY_API_KEY in CacheBuster
* Clean up and add a spec
* Do not call .purge_ methods if fastly is not configured
* Add OPENRESTY_ ENV vars to .env_sample
* Remove extra / prepending path
* Remove ConfigurationError, clean up Purgeable concern
* Use raise instead of fail like fastly-ruby
* No longer check for Rails.env.production?
* Use let! to create article in BustMultipleCachesWorker spec
The `.env` file shouldn't live in the `/config` directory when it is created, but
currently, the `.env_sample` file lives within `/config`. This can be confusing and
cause ENV var issues if someone duplicates `.env_sample` and renames it to `.env`,
because none of their ENV variables will get picked up, since their `.env` file will
mistakenly end up in `/config`.
This change moves `.env_sample` out of `/config`, and updates the documentation/relevant
.yml files accordingly.
