Skip to content

WIP: Allow Thumbnail Choice Blocks To Use All Icons In A Directory#1240

Draft
dchukhin wants to merge 134 commits into
mainfrom
icon-directory-for-thumbnails
Draft

WIP: Allow Thumbnail Choice Blocks To Use All Icons In A Directory#1240
dchukhin wants to merge 134 commits into
mainfrom
icon-directory-for-thumbnails

Conversation

@dchukhin
Copy link
Copy Markdown
Collaborator

@dchukhin dchukhin commented Apr 8, 2026

One-line summary

This pull request updates our IconChoiceBlock to use all icons in a directory.

Significant changes and points to review

More specifically, the changes are:

  • the most recent changes in wagtail_thumbnail_choice_block support pointing a ThumbnailChoiceBlock at a directory, and Wagtail users being able to choose any of the icons from that directory.
  • IconListItemBlock now uses a ThumbnailChoiceBlock, setting the thumbnail_directory to img/firefox/flare/2026/icons, which makes all icons in that directory (and all of its subdirectories) choices for the block
  • springfield may require CSS classes for the icons in the directory, so a new springfield/cms/management/commands/generate_flare_icon_css.py management command allows creating a file of CSS rules, setting the --icon-src for each of the files in the directory (and all of its subdirectories). I ran this command for the files in media/img/firefox/flare/2026/icons/desktop-16, and added CSS rules for them to media/css/cms/flare26-icon.css.
  • some helper function have been added in a springfield/cms/icon_utils.py file. For example, icon_value_fn() takes a relative path to a file, and returns an icon name (given "desktop-16/arrows-and-chevrons/forward-16", it returns "forward"). This function is used by the ThumbnailChoiceBlock to determine which value to save in the database when a user chooses an icon. Since a number of icon paths would result in identical values ("mobile-24/arrows-chevrons/forward-24.svg" would also want to be "forward"), any value collisions are handled explicitly in the icon_value_fn.

TODO:

  • improve styling for the block in Wagtail

Issue / Bugzilla link

Testing

  1. install the most recent (unreleased) wagtail_thumbnail_choice_block changes: pip uninstall wagtail-thumbnail-choice-block and pip install wagtail-thumbnail-choice-block@git+https://github.com/lincolnloop/wagtail-thumbnail-choice-block.git@main
  2. run the migrations on this branch
  3. go through the pages that already use the icon choice block, like what's new pages, and make sure that the icons show up in the template, and Wagtail users can change them successfully
  4. find an article detail page that has an icon set, and make sure that it is still set and shows up as expected in article cards list blocks
  5. try to create a new page with icon choice blocs, and verify that the icons show up as expected
  6. create a new page that uses an article cards list block. For example, create a free form 2026 page, add a section to the content, and add an article cards list block to the section, and choose an article and set the card type to be "Icon Card". Verify that the article detail page's icon shows up in the article card on the new free form 2026 page.

dchukhin added 30 commits March 3, 2026 10:10
…ocale when the requested locale page is not found
Note: this logic shouldn't be needed, since all of
the locales should be present in the database, but
in case one of the locale records is removed from
the database, but the locale is still referenced
in the code (for example, in the settings), this
logic will handle it.
CANONICAL_LANG matches LANG, unless a page is served
for a fallback locale. In this case, the template
can determine which context variable (LANG or
CANONICAL_LANG) to use in each relevant place.
when a user requests a page and is given content
for a fallback locale, the page links in the
content should match the requested URL's locale.
…ent from alias locale URL when alias locale has no content
… alias Locale does not exist in the database
…when alias Locale does not exist in the database
this fixes an error where translating a page into
the new Locales was causing a server error,
because wagtail-localize was not able to correctly
find the root page in the new Locale.
do not show hreflang alternates for alias locales
that don't have their own content
Base automatically changed from WT-961-programmatically-make-cms-compare-and-more-pages to main May 13, 2026 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants