So it's similar to the other custom page 404 tests.
Note we're explicitely marking the page as a draft so it's more obvious
what's going on in the test.
We were getting a deprecation message in Rails 5.2:
The missing? predicate is deprecated and will be removed in Rails 6.0.
Please use not_found? as provided by Rack::Response::Helpers
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
When requesting files like `/hackattempt.js`, the pages controller was
responding with 404 status code.
However, since the request was considered a JavaScript request (because
of the `.js` extension), the response was also considered to be a
JavaScript one, and since the request wasn't an AJAX request, our
protection from forgery was preventing a potential security issue by
raising an InvalidCrossOriginRequest exception.
By setting HTML as content type, we correctly respond with a 404 status
code.
More info:
https://die-antwort.eu/techblog/2018-08-avoid-invalid-cross-origin-request-with-catch-all-route/
From now on these static pages:
`/privacy'
`/conditions'
`/accesibility'
`/help/faq'
`/welcome'
have been moved to the DB and can be modified easily by any
administrator in `/admin/site_customization/pages'
Normalize page paths so they can be accessed by `page_path(:id)`.
The benefit of this is that we can add any arbitrary amount of pages
without affecting the routing layer.
