Language flags (css classes and sprites) got removed in 7.6.0
According to the commit message of issue 70477 some deprecations take place for v7 LTS via 7.6.0
But this commit does more than a deprecation because it also removes files
And it also removes a bugfix which was merged with 7.4.0
I'd be happy to still be able to support 6.2 with metaseo extension and move to IconRegistry as soon as we drop support for 6.2.
Our old 6.2-style code is missing css classes for language flags and therefore only displays a red X icon.
We're using the css classes for flags in the backend.
I guess 58c46d75099acd8449aded959efe8f031cec13d0 must at least be considered as a breaking change the way it was done. Is that intended or is it a bug or was there a breaking change in the past (pre-6.2) which allows for the removal of the files?
Removal of flags.css and flags.png was suggested by Wouter Wolters (with a question mark).
A breaking change was suggested by Christian Kuhn (with a question mark) for Patch set 7 of https://review.typo3.org/#/c/43897/ But no breaking change was communicated.
I'm not sure if that was a breaking change, a bug or totally fine. Please give some feedback which was the intention here. For the moment it looks more like a bug to me, while I'm aware that there is a modern alternative in 7.6.x.
Suggested fix would be to give back the dropped files, css classes and bugfix 68217 for 7.6.x only.
[BUGFIX] Fix broken language flags via IconUtility::getSpriteIcon
With #70477 the SpriteIcon stuff has been marked as deprecated.
The patch removed the flags support. This patch fix the problem by checking
the IconRegisty and return the icon by using the IconFactory.
Reviewed-by: Thomas Mayer <email@example.com>
Tested-by: Thomas Mayer <firstname.lastname@example.org>
Reviewed-by: Wouter Wolters <email@example.com>
Reviewed-by: Christian Kuhn <firstname.lastname@example.org>
Tested-by: Christian Kuhn <email@example.com>
#1 Updated by Thomas Mayer about 2 years ago
Calling deprecated function in 7.6.10-dev
is broken in 7.6. I get a red cross for that while the HTML output is
<span class="t3-icon t3-icon-status t3-icon-status-status t3-icon-status-icon-missing"> </span>
It could fall back to
/** @var \TYPO3\CMS\Core\Imaging\IconFactory $iconFactory */ $iconFactory = Typo3GeneralUtility::makeInstance('TYPO3\CMS\Core\Imaging\IconFactory'); $iconFactory->getIcon('flags-de', Icon::SIZE_SMALL);
Which gives me the HTML output
<span class="t3js-icon icon icon-size-small icon-state-default icon-flags-de" data-identifier="flags-de"> <span class="icon-markup"> <img src="/typo3/sysext/core/Resources/Public/Icons/Flags/SVG/DE.svg" height="16" width="16"> </span> </span>
So the suggested fix could be to let IconUtility::getSpriteIcon() call $iconFactory->getIcon().
That would result in SVG output (consistent with other SVG flags).
Note that 7.6.10-dev code documentation still suggests the use of IconUtility in respect to flags, e.g.
typo3/sysext/backend/Classes/Configuration/TranslationConfigurationProvider.php Line 47: The calling party should call * \TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIcon(<flags-xx>) to get an HTML * which will represent the flag of this language.
Additionally, old css and .PNG flags and bugfix 68217 could be of use when used directly without using IconUtility::getSpriteIcon() or $iconFactory->getIcon() to make mitigate the breaking change.
#2 Updated by Thomas Mayer about 2 years ago
Another option would be to implement issue 77048, which embeds all the SVG files into few css files. 77048 also allows to use simple CSS classes again while the same class names could be used as in 6.2, at least for a transition/deprecation concept.
If backported to 7.6, 77048 could even potentially mitigate the breaking change (which occured via 70477), still giving all the benefits of SVG, plus improving backend's performance in 7.6 and beyond.