search

quellenform / t3x-iconpack

This extension provides an iconpack registry for custom iconpacks which can be used in backend and frontend and are rendered according to the configuration of the installed iconpacks.
GNU General Public License v3.0
10 stars 4 forks source link

Compatibility with TYPO3 v12 - RTE Transform #6

Closed stephankellermayr closed 1 year ago

stephankellermayr commented 1 year ago

Note: Basically, the output of icons previously stored in RTE fields in the database in v11 works, but...

As of TYPO3 v12 the following has changed regarding this task:

This means that it is no longer possible to load and save icons in v12 in the RTE. It therefore needs two modifications to enable the transformation of the icons when editing and saving in the backend:

  1. An alternative to transformRte is needed to transform the iconfig string of the icons into a valid HTML markup when loading from the database, and to display the icons in the RTE.
  2. An alternative to transformDb is needed to transform the HTML markup from the RTE into an iconfig string for storage in the database.

The following transformation would have to be achieved (DB <> RTE)

Content to be stored in the database:

<p><icon data-iconfig="fa6:solid,eye"></icon></p>

Content to be displayed in the RTE:

<p><span class="fa-eye fas" data-iconfig="fa6:solid,eye" role="img"> </span></p>

The following classes/files are affected:

Any help on this topic is greatly appreciated!

SicorDev commented 1 year ago

Hi, just curious: Why can't you just use the span or the icon everywhere? What is the forward and backward transformation good for?

stephankellermayr commented 1 year ago

Hi, just curious: Why can't you just use the span or the icon everywhere? What is the forward and backward transformation good for?

Thanks for your interesting question and your interest in this extension!

I try an explanation....

The transformation in this case has the following background:

When editing a record, an icon is to be added via a plugin in the RTE. Due to the restrictive limitations in the CKEditor, this can only be done using valid HTML code and a tag such as <span class="fas fa-star" /> or similar must be added to enable the display in the RTE in the first place. To do this, the appropriate webfont must be loaded in the background. However, depending on what assets the icon pack can provide at all. A representation with SVG is only partly possible in the RTE.

In the end, however, exactly this content is NOT to be stored in the database, but a separate tag is to be used (in this case <icon iconfig="fa6:solid,star" />), so that this icon can be rendered in the frontend at any time in any format defined by the configuration.

For this reason, two transformations are necessary:

  1. when saving the record, the HTML code valid for the RTE is transformed into an iconfig tag.
  2. when rendering in the frontend, this tag is transformed into HTML code corresponding to the configuration (e.g. webfont, or directly as SVG, or SVG-inline, etc. depending on what the iconpack provides and depending on how it was individually configured in typoscript).

Only in this way the flexibility regarding the rendering of icons in the RTE is possible at all.

With all other database fields this is no problem, because there only the iconfig-string is stored directly and can be rendered via ViewHelper in any HTML code.

If you have another (better) idea how to display an icon in the RTE, which can be rendered later in the frontend in a different format (Inline-SVG, SVG, WebFont, etc.) at any time, then I'm looking forward to your suggestions and your help!

SicorDev commented 1 year ago

Well, if you use this in the RTE as you do now: <span class="fa-eye fas" data-iconfig="fa6:solid,eye" role="img">

And store it just like that in DB, you basically have to adjust your frontend handling to look for the "data-iconfig" attribute within <span> instead of <icon>, no?

stephankellermayr commented 1 year ago

Hm, you're right of course, that would be a workaround.

However, then the rendering in the backend/RTE can no longer be selected individually (which is currently also the case, ...at least theoretically).

My idea (or hope) was originally that in upcoming EXT:iconpack versions also the rendering in the backend/CKEditor (if that can be implemented solidly in the CKEditor at all) can be chosen individually.

Currently it can be displayed in version 10/11 only because I inject the necessary CSS files in the background when opening the modal. And the consideration was, whether this can not be changed somehow in the CKEditor completely to inline SVG (or SVG).

If I would solve this as you suggest, then this plan should no longer work, right?

SicorDev commented 1 year ago

It seems what can be done and what not is getting more and more restrictive in the core RTE, so instead of opening a way for SVG I think they would rather close it if there was any ;-)

And I don't know, if you can ever replace <icon> with an SVG, you can probably do it with <span> just as well, why differentiate between back- and frontend here?

stephankellermayr commented 1 year ago

It seems what can be done and what not is getting more and more restrictive in the core RTE, so instead of opening a way for SVG I think they would rather close it if there was any ;-)

Yes, you might be right, I already had this worry ;-)

And I don't know, if you can ever replace <icon> with an SVG, you can probably do it with <span> just as well, why differentiate between back- and frontend here?

I had implemented the differentiation because possibly not all iconpacks are always available in all variations (webfont, SVG, SVG sprites, etc.).

As currently thought, the backend should always generate the "optimal" rendering for a TYPO3 backend (depending on current standards and the CKEditor) and the frontend should of course always be free to decide which rendering to use. So the separation had technical reasons:

In CKEditor 4, I basically succeeded in rendering as SVG and the functionality exists in principle, but I could not test it extensively, so I did not use it. In CKEditor 5, however, this is even more restrictive, and for these reasons I decided to use web fonts in CKEditor.

However, in all other native backend fields and in the modal window, using SVG (not inline SVG!) seemed the best/most performant to me, so I implemented SVGs there exclusively.

The webfont is therefore used by default only in the CKEditor.

All in all, it boils down to the fact that an iconpack can optimally offer the formats Webfont and SVG. If the CKEditor could be taught to use SVG as well, it would be possible to do without Webfont completely ....therefore these considerations.

stephankellermayr commented 1 year ago

Well, if you use this in the RTE as you do now: <span class="fa-eye fas" data-iconfig="fa6:solid,eye" role="img">

And store it just like that in DB, you basically have to adjust your frontend handling to look for the "data-iconfig" attribute within <span> instead of <icon>, no?

But you might really be right that you could store the content in the RTE in a <span> tag. Maybe I've approached the problem in too roundabout a way. In theory, it should come down to the same thing, since, as you correctly say, the final rendering in the frontend would just have to process those RTE fields accordingly.

...Good suggestion. I'll give it some thought.

Have you tested this yet or looked at it in more detail?

SicorDev commented 1 year ago

Right now in TYPO3 12 I don't even get <span>Katze</span> into the DB... No idea what they did to the RTE this time again... :)

stephankellermayr commented 1 year ago

Right now in TYPO3 12 I don't even get <span>Katze</span> into the DB... No idea what they did to the RTE this time again... :)

...maybe try <span>Hund</span> instead? :D

I understand exactly what you mean. That's why I need help here too. I'm sure there is a simple solution here, and probably it has to do with the YAML configuration (allowedTags?), but I don't know version 5 of CKEditor enough either. ...so far.

stephankellermayr commented 1 year ago

Well, if you use this in the RTE as you do now: <span class="fa-eye fas" data-iconfig="fa6:solid,eye" role="img">

And store it just like that in DB, you basically have to adjust your frontend handling to look for the "data-iconfig" attribute within <span> instead of <icon>, no?

@SicorDev I have now found a solution for the transformation problem (TYPO3 v10-12), but there is no way around using XLCASS directly on the \TYPO3\CMS\Core\Html\RteHtmlParser, because this is the only way that a transformation is possible at all when saving RTE content and converting the data back from the database to the RTE.

I also thought about your suggestion to swap the <icon> element for a <span> element (possibly this was a bad idea of mine from the beginning). According to my tests, this should at least work equally well and cause less problems for future versions. In the course of this, I will provide an upgrade wizard in the coming versions.

Thanks for your helpful feedback!

SicorDev commented 1 year ago

Great to see you're making some progress here. Still struggling on a few things LTS 12 myself. Keep Up the good work! 👍

stephankellermayr commented 1 year ago

Solved with version 1.0.0.

PS: Sorry, unfortunately no upgrade wizard, but there is a backward compatibility in the frontend and by saving a record again the new tag is applied.