Project

General

Profile

Actions

Feature #72016

closed

Autoregistration for Custom Content Element icons

Added by Jan Mueller over 8 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2015-12-02
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

At the moment icons for custom content elements have to be registered in
different places (like TCA, ext_tables) which makes registration very unconvenient

it would be nice if we could define a new convention for the autoregistration
of icons like a new path in the resources folder like:
/Resources/Private/Icons/

once the custom extension gets installed that folder will be looked up and
autoregisters all the icons belonging to the specific content element,
same goes with when the system cache gets cleared

In that folder there have to be the icons for the different views of each CE element like:
slider_wizard.svg (display in content clement wizard)
slider_column.svg (display in listview)
(maybe anyone has an better idea how to define them?)

thanks for reading

Actions #1

Updated by Tobias Wollender over 8 years ago

I think you can't define the icons for different "views" just with the filename. In the first step, only the registration of the files should be automated. Currently you have to register your icons in ext_tables.php of your extension.

// Register own icons
$iconRegistry = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Imaging\IconRegistry::class);
$iconRegistry->registerIcon(
    'basetemplate-carousel-image',
    \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
    ['source' => 'EXT:base_template/Resources/Public/Icons/ContentElementWizard/Carousel-Image.svg']
);

It would be nice, if this step isn't needed but could be done by TYPO3 when installing an extension or clearing some caches (sytem cache?). I suggest the folder for icons to be /Resources/Public/Icons (not /Private) and create the identifier out of the file/folder they are placed (lowercaseExtensionkey-filename or lowercaseExtensionkey-folder-filename).

Examples:

File: /Resources/Public/Icons/Carousel-Image.svg
IconIdentifier: lowercaseExtensionkey-carousel-image

File: /Resources/Public/Icons/ContentElementWizard/Carousel-Image.svg
IconIdentifier: lowercaseExtensionkey-contentelementwizard-carousel-image

Then you can use the files with this identifier for the wizards you like (tca select, newcontentelementwizard, page module, etc..). Allowed files should probably be GIF, PNG and SVG.

Actions #2

Updated by Mathias Brodala over 8 years ago

I don't think this is something for the core but maybe for EXT:autoloader.

Actions #3

Updated by Tobias Wollender over 8 years ago

But it makes the life of integrators, which want to add new content elements "the core way" a little easier, as they don't have to remember those core functions and where to put them. "Just" to use some icons in the TYPO3 backend. You don't want an additional extension just for that. So for me this is definitely a feature for the core.

Actions #4

Updated by Jan Mueller over 8 years ago

i agree with Tobias here, this is something the core should provide, not another extension

Actions #5

Updated by Tim Lochmüller over 8 years ago

Hey Mathias,

great idea ;) I add this feature to the next EXT:autoloader release:
https://github.com/lochmueller/autoloader/commit/88fa2cbb9c1b99907783f7447c46fabb3ac750c9

Regards,
Tim

Actions #6

Updated by Markus Klein over 8 years ago

The main issue here is that this is (again) magic, which is generally not that good.
We try to get as much magic out of the Core as possible and especially those magic name conversions are really PITA for non-pros.

Moreover you have to consider that magic implies implicit configuration, thus, "if a file is there I'll configure/register something".
Implicit configuration has one major drawback compared to explicit configuration (writing down somewhere which file/icon/etc I want to load): Aweful debugging.

Imagine implicit configuration and your icon is not loaded and you have no clue why and you also don't get any error message. Maybe you made a naming mistake (remember those complicated naming schemes, which nobody knows by heart), of course the Core wouldn't consider your file. Happy searching....
Now imagine explicit configuration, so you wrote down you want my-icon.png and accidentally named the file myicon.png. Now the Core knows about your intention and will shout out loud that it's unable to find what you told it to search for. Easy to solve.
This saves you hours of development time.

This is the reason why I would not recommend implementing such a feature.

Actions #7

Updated by Mathias Brodala over 8 years ago

Tim Lochmüller wrote:

great idea ;) I add this feature to the next EXT:autoloader release:
https://github.com/lochmueller/autoloader/commit/88fa2cbb9c1b99907783f7447c46fabb3ac750c9

Dude, you are a machine. :-) This is great for people who know what they do.

And again, especially for reasons outlined by Markus, this is not something for the core.

Actions #8

Updated by Riccardo De Contardi about 8 years ago

  • Status changed from New to Rejected

See previous comments and please use ext:autoloader for this feature.

If you think that this is the wrong decision, please open a new feature and add this one as reference. Thank you.

Actions

Also available in: Atom PDF