Its value is difficult to read due to the low contrast between the color
of the field and the color of the placeholder text, and we already have
the same information in the hint above it.
Since targets didn't have a title but only a long description, every
form allowing to select targets was pretty much unusable: we either
displayed just the code or the whole description.
Now, with a concise title, it's easier to find and select the desired
target.
The titles have been copied from The Global Goals page [1].
Note we're using the `short_title` I18n key for the `title` method and
the `long_title` I18n key for the `long_title` method. We can't use
`title` as I18n key instead of `short_title` because it would affect
existing translations.
[1] https://www.globalgoals.org/
The same way we don't render empty regular tags since commit 4d27bbeba.
This way we avoid adding an empty `<div class="sdg-tag-list">` tag,
which might have associated styles (in custom CONSUL installation
styles, for instance) and thus break the layout
The icons were a bit hard to click on small screens, even for people
without any motion disabilities.
We might increase the size or the space between icons again in the
future; right now it's hard for users with certain motion disabilities
to click on the right icon.
Coincidentally, the minimum size of the icon is now barely over the 44px
established as minimum required size by the WCAG guideline 2.5.5 (level
AAA) [1].
Also coincidentally, at a screen 320px wide (the minimum screen size we
support), six icons appear on each row, just like in the UN logo.
[1] https://www.w3.org/TR/WCAG21/#target-size
These icons have been converted from EPS pages found at their respective
language UNRIC sites [1, 2, 3].
Since SVG icons are smaller and can be compressed, users browsing the
page in these languages will have to download way less data for the SDG
icons than when using PNGs. Users browsing the web in Italian will have
to download about 70KB for the SDG icons instead of the 575KB. Users
browsing the page in Greek will have to download about 75KB for the SDG
icons instead of 720KB. And users browsing the web in Dutch will have to
download about 115KB for the SDG icons instead of 230KB.
[1] https://unric.org/it/agenda-2030/
[2] https://unric.org/el/17-στοχοι-βιωσιμησ-αναπτυξησ/
[3] https://unric.org/nl/duurzame-ontwikkelingsdoelstellingen/
Based on an EPS file downloaded from The Global Goals page [1].
We didn't have Indonesian SDG icons in any format.
[1] https://www.globalgoals.org/resources
Based on an EPS file downloaded from The Global Goals page [1].
Although in that page there are icons for other languages we support and
that we've only got in PNG format, the Spanish ones are the only ones
which are similar to the official PNG ones provided by the UN or
UN-related organizations like UNRIC. Icons in other languages (like
Chinese, French or Russian) are not that similar to the official PNG
icons and their quality is (in my humble opinion) lower.
Since SVG icons are smaller and can be compressed, users browsing the
page in Spanish will have to download about 80KB for the SDG icons,
instead of the 240KB they needed to download when using PNGs.
[1] https://www.globalgoals.org/resources
These icons have been downloaded from The Global Goals page [1]. English
is the official language of this page and the only one containing all
the information.
Since SVG icons are smaller and can be compressed, users browsing the
page in English will have to download about 45KB for the SDG icons,
instead of the 250KB they needed to download when using PNGs.
[1] https://globalgoals.org
SVG files are smaller than PNG files, can be compressed, and are
scalable.
We're choosing to render SVG files as images instead of inline because
inline SVGs aren't cached nor compressed, and they might appear several
times on the same page, making the generated HTML much larger.
We could also load them with an SVG sprite, using `<use>`, which would
reduce the number of HTTP requests when several icons are present on the
page (like in the index of most sections). However, using SVG inside an
`<img>` tag is universally supported, while the `<use>` tag doesn't
work in Internet Explorer when using an external URI and support in
Opera Mini and UC Browser is unknown.
We didn't enable it by default in commit 676adfcb3 so existing
installations didn't suddenly get a new section without expecting it.
But since the setting already exists for installations using version
CONSUL 1.3, now it will only be enabled for new installations.
On very large screens, the admin menu had a lot of blank space for
languages where all sections had short names (like English). This was
inconvenient because the icon to open a submenu was far from its
associated menu item.
Using the `max-content` value for the `max-width` property, we reduce
the amount of blank space in these cases.
Since the icon was absolutely positioned, in some languages it
overlapped with the text.
Using a flex layout solves this issue. It also improves the appearance
of elements whose text spans over multiple lines; previously the second
line would go under their section icon.
We're also using the `$global-left` variable so the icon is properly
displayed in languages written from right to left. We could use the
`margin-inline-start` property instead, but it isn't universally
supported in every browser yet.
Since the layout is now incompatible with the old (and obsolete) way to
add icons to the menu (using classes which would use the
`[class^="icon-"]` selector), we're removing this code.
When items went over multiple lines, the distance between their lines
was the same as the distance between one element and another one. This
made it hard to differentiate how many elements there were.
Using a padding to separate the contents of one element and the contents
of the next one solves the issue.
These tests were checking the URLs of documents and images pointed to
the URL generated by the `attachment.url` method. In order to do so, we
were running database queries after starting the process running the
browser, which is sometimes causing database inconsistencies when
running the tests.
So I'm simply removing the URL check. The tests are slightly less useful
now, but it isn't like they were 100% right in the first place. After
all, if the `attachment.url` method wasn't working properly, the tests
were still passing.
We were testing the URL of the image changes to `missing.png`, but
actually that's confusing because the image record is now invalid and so
its changes can't be saved. That means that, when rendered in the
browser, the image won't render the `missing.png` image but will try to
render the destroyed one.
If we want to render the `missing.png` image when the attachment has
been destroyed, we need to remove the attachment presence validation or
change the `url` method so it detects when an attachment is missing.
We're already using a custom controller to handle direct uploads.
Besides, as mentioned by one of Active Storage co-authors [1], the
Active Storage DirectUploadsController doesn't provide any
authentication or validation at all, meaning anyone could create blobs
in our database by posting to `/rails/active_storage/direct_uploads`.
The response there could be then used to upload any file (again, without
validation) to `/rails/active_storage/disk/`.
For now, we're monkey-patching the controllers in order to send
unauthorized responses, since we aren't using these routes. If we ever
enable direct uploads with Active Storage, we'll have to add some sort
of authentication.
Similar upload solutions like CKEditor don't have this issue since their
controllers inherit from `ApplicationController` (which includes
authorization rules), while Active Storage controllers inherit from
`ActionController::Base`.
[1] https://discuss.rubyonrails.org/t/activestorage-direct-uploads-safe-by-default-how-to-make-it-safe/74863/2
We were having issues with cached attachments and external services.
A `Tempfile` is returned by `URI.open` when using S3, so we're dealing
with this case as well.
There could be inconsistencies in the database and an attachment might
have a `record_id` pointing to a record which no longer exist. We were
getting an exception in this case.
We were getting a duplicate prepared statement error when trying to
execute more than one test using this task. So we're checking whether
the prepared statement exists before defining it.
Just like we add the `storage_` prefix for new records so we can use
both Active Storage and Paperclip at the same time.
Now the migration actually works, at least for basic cases.
This model is added by the devise-security gem, but we don't use it. We
were getting an error while migrating:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "old_passwords" does not exist
LINE 8: WHERE a.attrelid = '"old_passwords"'::regclas...
^
SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod,
c.collname, col_description(a.attrelid, a.attnum) AS comment
FROM pg_attribute a
LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum
LEFT JOIN pg_type t ON a.atttypid = t.oid
LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation
WHERE a.attrelid = '"old_passwords"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
lib/tasks/active_storage.rake:27:in `block (4 levels) in <top (required)>'
lib/tasks/active_storage.rake:26:in `each'
lib/tasks/active_storage.rake:26:in `block (3 levels) in <top (required)>'
lib/tasks/active_storage.rake:25:in `block (2 levels) in <top (required)>'
Caused by:
PG::UndefinedTable: ERROR: relation "old_passwords" does not exist
We can use the `ActiveStorage::Blob` class to find where the file is
supposed to be stored instead of manually setting the path. This is also
more robust because it works with Active Storage configurations which
don't store files in the default folder.
In order to migrate existing files from Paperclip to ActiveStorage, we
need Paperclip to find out the files associated to existing database
records. So we can't simply replace Paperclip with ActiveStorage.
That's why it's usually recommended [1] to first run the migration and
then replace Paperclip with ActiveStorage using two consecutive
deployments.
However, in our case we can't rely on two consecutive deployments
because we have to make an easy process so existing CONSUL installations
don't run into any issues. We can't just release version 1.4.0 and 1.5.0
and day and ask everyone to upgrade twice on the same day.
Instead, we're following a different plan:
* We're going to provide a Rake task (which will require Paperclip) to
migrate existing files
* We still use Paperclip to generate link and image tags
* New files are handled using both Paperclip and ActiveStorage; that
way, when we make the switch, we won't have to migrate them, and in
the meantime they'll be accessible thanks to Paperclip
* After we make the switch, we'll update the `name` column in the active
storage attachments tables in order to remove the `storage_` prefix
Regarding our handling of new files, the exception are cached
attachments. Since those attachments are temporary files used while
submitting a form and we have to delete them afterwards, we're only
handling them with Paperclip. We'll handle these ones in version 1.5.0.
Note the task creating the dev seeds was failing after these changes
with an `ActiveStorage::IntegrityError` exception because we were
opening some files without closing them. If the same file was attached
twice, it failed the second time.
We're solving it by closing the files with `File.open` and a block. Even
though we didn't get any errors, we're doing the same thing in the
`Attachable` concern because it's a good practice to close files after
we're done with them.
Also note we have to change the CKEditor Active Storage code so it's
compatible with Paperclip. In this case, I haven't been able to write a
test to confirm the attachment exists; I was getting the same
`ActiveStorage::IntegrityError` mentioned above.
Finally, we're updating the site customization image controller to use
`update` so the image and the attachment are updated within the same
transaction. This is also what we do in most controllers.
[1] https://www.youtube.com/watch?v=tZ_WNUytO9o
ActiveStorage support was added to CKEditor in version 5.1.0. However,
we can't upgrade to version 5.0.0 or later because it only supports
loading CKEditor via CDN.
So we're copying the code related to ActiveStorage instead. I tried to
move it to the `vendor/` folder, but couldn't find a way to load it from
there and if I found one I wouldn't be sure it'd work on production
environments.
