Breaking: Icons are renamed and follow the colour scheme 

Description 

The record icons of this extension were registered with the core provider \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider , which renders the default markup - the markup a typeicon_classes entry reaches - as an <img> tag. An image is opaque to CSS, so the icon kept the ink of its file whatever the backend colour scheme said, and a dark drawing stayed dark on the dark cards of the record list.

They are now registered with \FGTCLB\AcademicBase\Imaging\IconProvider\CurrentColorSvgIconProvider , which inlines the file in both markups, and the files themselves are drawn in currentColor with no colour of their own.

Every icon of this extension is now a Font Awesome Free solid drawing, and every icon identifier of this extension follows the scheme tx-<extension key without underscores>-<group>-<name>. The group decides the registry: doktype, plugin and record icons are shown by the backend and live in Configuration/Icons.php only. The identifiers of 2.x are removed without an alias:

The page type and the Partners Linked content element share one drawing, Resources/Public/Icons/plugin/partners.svg, but no longer one identifier, so a site can replace either one alone. The other three content elements are drawn from plugin/list.svg, plugin/map.svg and plugin/partnerships-teaser.svg. The two record icons are drawn from the shared files info/partnership.svg and info/role.svg of academic_base. The partner select of a partnership showed the partnership icon for every partner page it offers, it now shows the page type icon of the page.

The four category type icons and the group icon keep their identifiers, category_types.partners.* and category_types_group.partners , which category_types registers in the icon registry of the backend and in the frontend icon registry of academic_base. Their files moved:

Paths without an extension prefix are below EXT:academic_partners/Resources/Public/Icons/. The files Partnership.svg, Role.svg and the folders CategoryTypes/ and CategoryGroups/ are removed. Extension.svg stays the extension icon and is no longer registered as an icon. The four category types and the group ask for the inlining provider with inlineIcon: true in Configuration/CategoryTypes.yaml. Without that flag a category type icon keeps the core provider.

Impact 

The four category type icons reach the frontend, through the icon ViewHelper of academic_base, <ab:icon identifier="category_types.partners.{type}" /> , in Partials/Partner/Page/Categories.html, Partials/Partnerships/List/Item.html and Partials/Partnerships/Teaser/Item.html, and through category_types.partners.{category} in Partials/Partner/Item.html. category_types registers them in the frontend icon registry as well, with the same provider, see Important: Category type icons come from the frontend icon registry. None of those calls asks for the inline markup, so their rendered markup changes: an <img> of a fixed pixel size becomes an inlined <svg> with width="1em" height="1em" , which follows the font size and the colour of the text around it. Every frontend icon of this extension renders inline in currentColor, and every site using the partner or partnership plugins sees those icons resize, recolour and change their drawing.

Site CSS or JavaScript that sized, coloured or addressed the <img> has to address the <svg> instead.

In the backend, the academic partner page type icon, the content element icons, the two record icons and the four category type icons take the text colour around them, so they stay legible in a dark backend colour scheme, and all of them show their new drawing.

A site package that registered one of the 2.x identifiers in its own Configuration/Icons.php to replace the shipped drawing replaces nothing any more: the backend shows the new shipped icon. Backend code, TCA or page TSconfig of a site that names a 2.x identifier, for example a iconIdentifier of a wizard entry, shows TYPO3's not-found icon. A site package that pointed at one of the removed files, in its own icon registration or in a CategoryTypes.yaml that declares a type or the group again, shows no icon.

Affected Installations 

Every installation of this extension. Installations that render the partner or partnership plugins in the frontend are affected visibly. Installations whose site package replaces an icon of this extension, names one of its 2.x identifiers or points at one of its removed files have to migrate.

Migration 

Replace an image selector with an element selector in the site CSS, for example

/* before */
.partner-attributes .icon img { width: 32px; }

/* after */
.partner-attributes .icon svg { width: 1.25em; }

The icon element keeps the surrounding <span class="t3js-icon icon" data-identifier="…"> wrapper, so a selector written against the wrapper of a category type icon needs no change. A selector written against the identifier of a page type, content element or record icon names the 3.0 identifier from the table above.

Replace every 2.x identifier the site names, in TCA, page TSconfig, templates or code, with its 3.0 identifier. The 2.x academic-partners became five identifiers, pick the one of the page type or of the content element it is shown for.

A site package that replaces a page type, content element or record icon registers the 3.0 identifier in its own Configuration/Icons.php, for the backend:

use FGTCLB\AcademicBase\Imaging\IconProvider\CurrentColorSvgIconProvider;

return [
    'tx-academicpartners-plugin-partners' => [
        'provider' => CurrentColorSvgIconProvider::class,
        'source' => 'EXT:my_site/Resources/Public/Icons/Partners.svg',
    ],
];

A site package that replaces a category type icon keeps the identifier: it declares the type again in its Configuration/CategoryTypes.yaml with its own icon , for both registries, or registers the identifier in its own Configuration/FrontendIcons.php, for the frontend only, see Important: Category type icons come from the frontend icon registry. A file path of this extension it names has to be the 3.0 path from the table above.