We aren't getting any warnings when running our test suite, which means
that gems that depended on this method (like graphql [1]) have already
added compatibility for this case.
[1] Pull request 3774 in https://github.com/rmosolgo/graphql-ruby/
This is similar to what we did in commit 00a5dc921 when upgrading to
Rails 5.2. Quoting from that commit:
> Note this change will cause all fragment caching to expire. We
> consider it acceptable considering the page where caching is most
> important (stats) is barely affected by this change, since this change
> only affects the view, and the time-consuming operations are cached in
> the model.
>
> Comments are actually affected, though, and pages with thousands of
> comments might take a few extra seconds to load the first time they're
> accessed after this change. We don't think this is going to be an
> issue on existing CONSUL installations.
Note that enabling this options means all encrypted messages and cookies
generated the application become invalid, so we're adding a cookie
rotator in order to keep sessions from expiring when upgrading the
application, as recommended in the "Upgrading Ruby on Rails" guideline
[1].
Since we haven't seen any Consul Democracy applications using encrypted
messages and these messages become invalid with this change, we're also
removing the pre-Rails 5.2 encryption to authenticate messages
(AES-256-CBC) and switching to the default one since Rails 5.2
(AES-256-GCM). Since the configured encryption is used by the cookie
rotator initializer (through the ActiveSupport::MessageEncryptor.key_len
method), at first I thought this might affect the cookie rotator, but it
doesn't: upgrading works as expected, and existing sessions are still
active.
I'm adding a comment to remove the initializer once all cookies have
been migrated. I've added "Rails 7.1" in the comment because we usually
check for these comments when upgrading Rails, but we rarely check for
them when after releasing new versions of Consul Democracy.
[1] https://guides.rubyonrails.org/v7.0/upgrading_ruby_on_rails.html#key-generator-digest-class-changing-to-use-sha256
In Rails 6.1 and earlier, `button_to` generated a <button> tag when it
received the content as a block, but an <input> tag when receiving
the content as the first parameter.
That's why we were using blocks with `button_to` most of the time; for
starters, <button> tags accept pseudocontent and so are easier to style.
In Rails 7.0, `button_to` always generates a <button> tag [1], so we're
simplifying the code what uses `button_to`, passing the content as a
first parameter instead of passing it as a block.
[1] https://guides.rubyonrails.org/v7.1/configuring.html#config-action-view-button-to-generates-button-tag
The config.file_watcher option still exists but it's no longer included
in the default environtment file. Since we don't use it, we're removing
it.
The config.assets.assets.debug option is no longer true by default [1],
so it isn't included anymore.
The config.active_support.deprecation option is now omitted on
production in favor of config.active_support.report_deprecations, which
is false by default. I think it's OK to keep it this way, since we check
deprecations in the development and test environments but never on
production environments.
As mentioned in the Rails upgrade guide, sprockets-rails is no longer a
rails dependency and we need to explicitly include it in our Gemfile.
The behavior of queries trying to find an invalid enum value has changed
[2], so we're updating the tests accordingly.
The `favicon_link_tag` method has removed the deprecated `shortcut`
link type [3], so we're updating the tests accordingly.
The method `raw_filter` in ActiveSupport callbacks has been renamed to
`filter` [4], so we're updating the code accordingly.
[1] https://github.com/rails/rails/commit/adec7e7ba87e3
[2] https://github.com/rails/rails/commit/b68f0954
[3] Pull request 43850 in https://github.com/rails/rails
[4] Pull request 41598 in https://github.com/rails/rails
This task was necessary when updating to version 2.1.0, when we
integrated Puma with Systemd. Now that all Consul Democracy
installations are using Systemd, we no longer need it.
The `database:` argument from the `connected_to` method was deprecated
in Rails 6.1 [1] and removed in Rails 7.0 [2]. The ros-apartement gem
has already introduced fixes for this issue [3][4], but there has been
no release including these fixes.
So we're applying the fix in our code.
Note that, since Apartment already overwrites the `connected_to` method
by creating a `connected_to_with_tenant` method, we're calling the
`connected_to_without_tenant` method inside the patch, which is
equivalent to ActiveRecord's original `connected_to`.
[1] Pull request 37874 in https://github.com/rails/rails
[2] Pull request 40530 in https://github.com/rails/rails/pull
[3] Pull request 194 in https://github.com/rails-on-services/apartment
[4] Pull request 243 in https://github.com/rails-on-services/apartment
These warnings appear in the logs in the development environment, and,
with Rails 7, the application will crash. When running the tests, they
would appear in the standard error ouput if we set `config.cache_classes
= false` in the test environment but, since that isn't the case, they
don't.
To reproduce these warnings (or the lack of them), start a Rails console
in development and check the log/development.log file.
Quoting from pull request 43508 in the Rails repository [1]:
> When you are running test locally, most of the time you run only a
> subset, so it's better to load as little code as possible to have a
> faster time to first test result.
>
> But when you are on CI, it's usually much preferable to eager load the
> whole application because you will likely need all the code anyway,
> and even if the test suite is split across runners, it's preferable to
> load all the code to ensure any codefile that may have side effects is
> loaded.
>
> This also ensure that if some autoloaded constants are not properly
> tested on CI, at least they'll be loaded and obvious errors (e.g.
> SyntaxError) will be caught on CI rather than during deploy.
[1] https://github.com/rails/rails/commit/db0ee287eed
In Rails 6.1, the classic autoloader is deprecated.
We were getting an error because we were using `autoload` in the
ActiveStorage plugin for CKEditor:
expected file app/lib/ckeditor/backend/active_storage.rb to define
constant Ckeditor::Backend::ActiveStorage
So we're removing the line causing the error.
Finally, we can now restore all the tests that that failed sometimes
with the classic autoloader and that we modified in commits 2af1fc72f
and 8ba37b295.
Since we're already setting `wordpress_oauth2` using the `option :name`
command in the `OmniAuth::Strategies::Wordpress` class, Devise can
automatically find the strategy. However, it wasn't working because we
were passing a string instead of a symbol.
Even though we don't load this file with Zeitwerk, we're doing it for
consistency.
If we tried to load this file using Zeitwerk, without this change we'd
get an error:
```
NameError: uninitialized constant OmniauthWordpress
```
We were getting a few errors when trying out Zeitwerk:
```
expected file lib/sms_api.rb to define constant SmsApi
expected file app/components/layout/common_html_attributes_component.rb
to define constant Layout::CommonHtmlAttributesComponent
```
In these cases, we aren't using an inflection because we also define the
`Verification::SmsController` and a few migrations containing `Html` in
their class name, and none of them would work if we defined the
inflection.
We were also getting an error regarding classes containing WYSIWYG in
its name:
```
NameError: uninitialized constant WYSIWYGSanitizer
Did you mean? WysiwygSanitizer
```
In this case, adding the acronym is easier, since we never use "Wysiwyg"
in the code but we use "WYSIWYG" in many places.
The purpose of the lib folder is to have code that doesn't necessary
belong in the application but can be shared with other applications.
However, we don't have other applications and, if we did, the way to
share code between them would be using a gem or even a git submodule.
So having both the `app/` and the `lib/` folders is confusing IMHO, and
it causes unnecessary problems with autoloading.
So we're moving the `lib/` folder to `app/lib/`. Originally, some of
these files were in the `app/services/` folder and then they were moved
to the `lib/` folder. We're using `app/lib/` instead of `app/services/`
so the upgrade is less confusing.
There's an exception, though. The `OmniAuth::Strategies::Wordpress`
class needs to be available in the Devise initializer. Since this is an
initializer and trying to autoload a class here will be problematic when
switching to Zeitwerk, we'll keep the `require` clause on top of the
Devise initializer in order to load the file and so it will be loaded
even if it isn't in the autoload paths anymore.
We're getting one warning when compiling the assets due to the code we
use from font-awesome-sass, and a lot of warnings due to the code we use
from foundation.
Since these warnings are very annoying, and we get them both when
deploying and every time we change an SCSS file in development, we're
silencing them.
I haven't found the way to pass the `quiet_deps` option to the Sprockets
processor, so I'm monkey-patching the Sass engine instead.
SassC/Libsass has been deprecated for years and has been replaced by
Dart Sass. However, the dartsass-rails gem, maintained by the Rails
team, doesn't support sprockets integration and doesn't allow glob
imports (using `@import something/**/*` or similar). In particular,
dartsass-rails needs to start a separate browser that makes it less
straightforward to change a file and reload the browser.
So we're using sassc-embedded, which provides Dart Sass integration with
sprockets. While there's no guarantee this gem will be maintained a few
years from now, we know for sure that SassC/Libsass won't be maintained
at all, so using sassc-embedded is an improvement over our current
situation.
On my machine, this change reduces compilation times by about 35%.
Note we still depend on the `sassc-rails` gem, for two reasons.
First, we're still importing CSS/Sass content from a couple of gems
(mainly, social-share-button and font-awesome) and we don't know how to
import this content without the `sassc-rails` gem.
And, second, it provides support for glob imports. Without it, we'd have
to manually add every single (S)CSS file we import to the
`application.scss` file instead of being able to write things like
`@import admin/**/*";`.
Note we're removing the `sass` gem from `Gemfile.lock`. We should have
done it as part of e210682ac, but when we developed that branch, it
didn't contain the changes where we removed another gem depending on the
`sass` gem (which we removed in commit 2fa713c64), so Bundler didn't
delete it. However, now that we're changing the Gemfile, Bundler is
finally removing the no-longer-needed `sass` gem and its dependencies.
The Bing sitemap submission was removed in sitemap_generator 6.3.0 [1],
and Google has also deprecated the ping and we're getting an error when
deploying:
```
Ping failed for Google: #<OpenURI::HTTPError: 404 Sitemaps ping is
deprecated.
```
Since those were the only two search engines we were pinging in the
past, we're removing the code that did so.
[1] Pull request 408 in https://github.com/kjvarga/sitemap_generator
There was only one different line between these two lines, and we really
want these two files to be as similar as possible, so testing on a
staging server we get the same results we'll get on production.
This duplication made it easy to forget to update the staging.rb file
when updating the production.rb, particularly when upgrading to a new
version of Rails, which automatically changes the production.rb file but
not the staging.rb one.
So, now that we're getting ready to upgrade to Rails 7.0, we're basing
the staging configuration on the production one, just like we based the
preproduction configuration on the staging one in commit 7b91adb16.
This is possible since audited 5.4.3, and IMHO it's useful because
audited has added a callback on touch, which could result in strange
behavior since we might use the `touch` method to expire the cache
without doing any changes.
While this doesn't affect our application because we're using the `on:`
option of the `audited` method in the budget investment model, it'll
make it easier to enable audited for other classes in custom
installations without having to worry about the (usually undesired)
touch callbacks.
We haven't updated this initializer for years, so here's the updated
version. The `expire_auth_token_on_timeout` doesn't seem to exist
anymore, and a few more options have been added.
Note that the default Devise initializer configures
`config.responder.error_status` and `config.responder.redirect_status`
so they follow Hotwire/Turbo conventions. For now, I'm commenting these
lines because we currently don't use Hotwire/Turbo.
While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
We are ensuring that only position field is rendered only on
non-header cards.
Note that we have 3 sections that use widget cards:
- Homepage (cards and header cards)
- Custompages (only have cards)
- Sdg Homepage (cards and header cards)
We haven't been updating this file for a long time so, and this version
uses the `configure` method instead of the `config` hash.
We're also adding a few comments already included in previous versions
of wicked pdf that we hadn't copied to our initializer.
By default, when starting a Rails application, ExecJS checks whether there's
a runtime available in the system. Since on production we now use FNM to
manage node versions, this meant that we had to run Puma using the
`fnm exec bundle exec puma` command.
However, this causes issues when integrating Puma with Systemd. For instance,
when using `fnm exec`, the PID for the main process is no longer the Puma
process but the FNM process, meaning that stopping and restarting Puma will
no longer behave as expected and might last 90 seconds (Systemd's timeout to
stop a service). Furthermore, using a Puma Systemd socket in order to
implement hot or phased restarts won't work either, and so we'll get 502
errors while restarting the service.
So we're using the `EXECJS_RUNTIME=Disabled` environment variable in the
Systemd service, which means we can remove the `fnm exec` prefix in the
ExecStart command (which starts Puma) and now the PID for the main process
is the Puma process, stopping/restarting the service no longer times out,
and we'll be able to implement Puma socket activation and hot restarts.
However, removing `bundle` from the list of commands which use `fnm exec`
(the `fnm_map_bins`) meant that we got a `RuntimeUnavailable` exception when
running `bundle exec bin/delayed_job`. We tried to add `delayed_job` to the
`fnm_map_bins` variable but couldn't make it work.
Since we only need the ExecJs runtime when precompiling the assets but we
don't need it in order to start Puma or Delayed Job, we're adding
`{ EXECJS_RUNTIME: "Disabled" }` to Capistrano's default environment and
we're only using the default Runtime when `fnm exec` is used, which we've
done by setting the environment variable in the prefix of the fnm command.
This way, when running `EXECJS_RUNTIME='' fnm exec bundle exec rake assets:precompile`,
the right ExecJS Runtime will be loaded, but it won't be loaded (since it
isn't needed) when starting Puma or Delayed Job.
We moved the "Custom content blocks" menu entry from "Settings" to "Site
content" in commit a902f9e11, but we forgot to update a description
referencing the old location..
This will allow us to keep using the timezone used when running
the installer.
We keep using Madrid as default timezone in the installer and in
the application.
