This plugin provides more control over tables and solves a JS error thrown
when user clicks on "Cell properties" ckeditor feature.
https://ckeditor.com/cke4/addon/tabletools
All of these plugins are not used anywhere.
Change introduced at ckeditor initializer will ommit unneeded
precompilation of plugins assets on production environments.
Change introduced at ckeditor config file adresses the problem with assets
pipeline fallback on testing environments described here: #2711. Now plugins
that are explicitly disabled will not be precomiled when running ckeditor
javascript enabled feature specs.
This filter was added in commit 4285ba4b, it was changed in commit
002d8688, and most of the code from the original commit has disappeared
without a trace (maybe due to a merge conflict?).
This filter could actually be useful if we started using it when users
click on a tag. Since we don't, I'm removing it. We might add it back if
we decide to actually use it.
We're now using the same version we used to generate our Gemfile.lock.
Using the latest bundler we got a deprecation warning, which might turn
into an error in the future:
[DEPRECATED] The `--deployment` flag is deprecated because it relies on
being remembered across bundler invocations, which bundler will no
longer do in future versions.
We could also upgrade to bundler 2.x, but since we're using Ruby 2.4 and
Ruby 2.6 comes with bundler 1.17, we've decided to keep this version.
- Validate that locale is a valid locale for RemoteTranslation Client.
- RemoteTranslation can only be created for resources that do not have the requested
language translated
The old Setting["dashboard.emails"] is a Feature Setting, but appeared as
Configuration Setting without button for enable/disable.
In this commit, we update the old setting to behave like a Feature Setting.
Too we rename setting to clarify what emails are blocked with this feature.
The test environment was using the file in `config/puma.rb`, meaning it
wouldn't work with Rails 5.1, which uses a different setup for Puma.
I've decided to create a new file called `defaults.rb`, which will be
used in every environment but development and test. We could also add an
empty file in `config/puma/test.rb`; I think that's less intuitive, but
it's a subjective opinion.
The task `deploy:restart` was doing nothing since we moved from unicorn
to puma.
Now we're also restarting delayed jobs on `deploy:restart`, which is
probably what's expected in most cases.
So now the way to restart the application does not depend on whether we
use puma or passenger.
What this plugin actually does is restarting puma when we touch the
`tmp/restart.txt` file, which is what `rails restart` does.
This way we don't have to start it manually every time the server is
restarted.
Note if we start the application with `bin/rails s start -e production`,
as we'd probably want to do so this task doesn't depend on the server we
use, the application will crash when we restart it because it will be
restarted in the development environment. Maybe this issue will be fixed
in future versions of Rails and/or Puma.
Also note we're passing `2` workers to delayed job, and this number must
be the same number we use for the `delayed_job_workers` variable in
capistrano. I haven't found a way to share this variable between
whenever and capistrano.
We need to download the most recent CONSUL and check its `.ruby-version`
file before installing Ruby.
The `rvm1-capistrano` gem knows it and was invoking the `updating` task
before installing Ruby. So we were getting a warning in Capistrano about
the `updating` task being executed twice.
New CONSUL instances who didn't use the newest installer and haven't
done any deployments with capistrano would get an exception because the
`current` capistrano folder doesn't exist yet.
We were using Capistrano's shared folder because it was the default
folder used by the capistrano-puma gem. However, it's easier to manage
it if it's under version control.
So we're moving the old `puma.rb` to `puma/development.rb`, and we use
the new `puma.rb` file for all environments except development. Anyone
installing CONSUL can change these files at will or change the specific
files for preproduction, production and staging environments.
Deploy environment files were loaded after config/deploy.rb was loaded,
meaning if we used settings like `deploy_to` or `current_path` to set
variables inside the config/deploy.rb file, we'd be using the default
settings instead of the ones dictated by the deploy environment files.
These files are only loaded when the stage already has the value set
inside them, so we don't need to set it again.
On the other hand, the `rails_env` setting is configured in the
`config/deploy.rb` file.
This is the same configuration we had with unicorn.
With several workers, we've got two basic configuration options:
* Preload the application and use a hot restart
* Don't preload the application and use a phased restart
I've decided to preload the application because using a hot restart
changes are available immediately, while with a phased restart there are
a few seconds when both workers for the old code and workers for the new
code exist.
Using a phased restart also has advantages, so some forks might want to
disable the `puma_preload_app` setting in order to use it.
