Rails 5 changed the initialization order, and now our initializers were
running before the `append_assets_path` initializer for each engine,
which prepended application assets to the custom assets we prepended in
the initializer.
Moving the code to the `config.after_initialize` code didn't work
either, since the paths added there were ignored by the application.
Adding another initializer to the Rails Engine is a hack, but solves the
problem.
spec/lib/tasks/dev_seed_spec.rb:8
This test was failing and we could see messages like:
db/dev_seeds/polls.rb:147:
warning: toplevel constant Answer referenced by Poll::Answer
Resulting in the error:
rake db:dev_seed seeds the database without errors
Failure/Error: expect { run_rake_task }.not_to raise_error
expected no Exception, got #<ActiveModel::UnknownAttributeError:
unknown attribute 'question_id' for Answer
Apparently the lookup was not correclty being performed, due to
conflicting names.
"Naming conflicts of this kind are rare in practice, but if one
occurs, require_dependency provides a solution by ensuring that
the constant needed to trigger the heuristic is defined in the
conflicting place."
https://guides.rubyonrails.org/v5.0/autoloading_and_reloading_constants.html
New version of globalize uses RequestStore gem to store I18n.locale and
Globalize.fallbacks in a per request basis to avoid collissions between
different requests. This gem update broke Globalize.fallback results
because it tries to fetch fallbacks from RequestStore, where there is no
locale fallbacks definition.
For some reason the paperclip method `attachment.exists?' was
returning nil even when `attachment.url(style)' was correctly
returning the url/path of the attachment.
Therefore returning `nil' was causing to raise an error in the
method `image_tag'.
With this change we make sure we return the image url it it's
available, or an empty string if it's not, but never a null value.
DEPRECATION WARNING: [Devise] `DeviseHelper.devise_error_messages!`
is deprecated and it will be removed in the next major version.
To customize the errors styles please run `rails g devise:views` and
modify the `devise/shared/error_messages` partial.
We will render the resource errors instead fo calling the deprecated method.
DEPRECATION WARNING: Directly inheriting from ActiveRecord::Migration
is deprecated. Please specify the Rails release the migration was
written for:
class MigrationClass < ActiveRecord::Migration[4.2]
(called from require at bin/rails:4)
This patch adds 2 missing colons (:) for 2 migrations that are failing when
the `rake db:migrate` task is ran. Whilst already-committed-to-source-control-
and-ran-on-production-environments migrations shouldn't be modified whatsoever,
this change does not modify in any way the current database schema so, technically,
it shouldn't affect forks that might have ran these migrations already and those
CONSUL installations that haven't done so should be able to without problems
Metrics/LineLength: Line is too long.
RSpec/InstanceVariable: Use let instead of an instance variable.
Layout/TrailingBlankLines: Final newline missing.
Style/StringLiterals: Prefer double-quoted strings.
If tests run very fast all votes are created within the last 24
hours, so hot_score has the same value if the creation date for the
votes is Time.current or 1.day.ago.
Creating the votes 48 hours ago we make sure hot_score has the
correct value and the tests pass correctly.
Maintain the method for models that are still translatable. This help
me to pass the CI build. In later PR's this method will be eliminated
as no one will invoke it.
Move method from sanitizable to globalizable concern because
globalize_accessors were overiding sanitizable method and was never
called. Another solution to this could be to load sanitizable
always after globalizable concern.
Old method implementation was not working well with globalize_accessors,
it was returning nil always.
Some queries were accessing original column instead of the new translatable one. This should have been causing unexpected behavior for requests maded in a different locale than the application default.
Some queries were accessing original column instead of the new
translatable one. This should have been causing unexpected behavior
for requests maded in a different locale than the application default.
Some queries were accessing original column instead of the new
translatable one. This should have been causing unexpected behavior
for requests maded in a different locale than the application default.
