images are not processed

[navaki]

A few images inserted via the RTE are not displayed in the frontend, it seems that the path is not resolved correctly, because in the src part a URL like "typo3/image/process?token=1a372fa4f26ec25d0b49ef1317e04233eab325fb&id=28234" is displayed. Looks like that in the frontend, of course:

However, a few images are displayed correctly - what could be the reason?

Also, in the backend, when uploading, the message "The validation of the security token of this form has failed. Please reload the form and submit it again." - is this possibly related?

Edit: This occurs with Typo3 Version 11.5.15 and rte_ckeditor_image in Version 11.0.5 (PHP 8.0)

[cschnell]

I can confirm this Issue. To me it seems as if this only happens to editors, not to admins. The tag that I can see when switching the RTE to source code mode looks like this: <img alt="" data-alt-override="true" data-htmlarea-file-table="sys_file" data-htmlarea-file-uid="16188" data-title-override="true" height="750" src="https://<mydomain>/typo3/image/process?token=4c12de5113a30c7c5dc33e4af404c25ba8746317&amp;id=32133" title="" width="1000" />

The currently installed version is 11.0.5 with TYPO3 11.5.15 and PHP 8.0

[navaki]

Problem occurs in Typo3 Version 11.5.16, too. Replacing lost images with new reference fixes this Problem temporarly, but after saving the container a second time they disappear again.

[jpmschuler]

Same on PHP 7.4

[jpmschuler]

Ok, did my best for a proposal #194 that doesn't need to re-save each an every "contaminated" RTE field. Perhaps this might help you too. I don't have much insight into RTE post processors, but the solution seems plausible

[cschnell]

I have added the patch to my system and will provide feedback, when tested.

[navaki]

I tested the bugfix on my local system - unfortunately it did not solve the problem for me. @cschnell is your problem fixed?

[jpmschuler]

n.b.:

1. To be fair I also added #197 to my installs before running all tests, but that is rather for really legacy RTE content and shouldn't affect this.
2. I didn't see any change at all for multiple scenarios as this seemed to be cached on different levels. I really need to force-clear the whole cache and then use a different browser with incognito mode to reliably see the new stuff.

[cschnell]

I tested the bugfix on my local system - unfortunately it did not solve the problem for me. @cschnell is your problem fixed?

sorry for my late reply. As this seems to only affect my editors (I can't reproduce, I can only see the result), I have to wait until they report back to me. So far, none has.

[cschnell]

Today, I had the possibility to check: The bugfix of @jpmschuler works half. In the frontend, the image is processed and rendered, as it should. In the RTE however, the image is not shown, because the source is something like <img alt="" data-alt-override="true" data-htmlarea-file-table="sys_file" data-htmlarea-file-uid="16561" data-title-override="true" height="750" src="https://www.mydomain.com/typo3/image/process?token=149f699b330312ff519c0fa3af2b6dd99658cd4b&amp;id=35214" title="" width="1000" />

[jpmschuler]

Interesting, I dug deeper into it: https://www.mydomain.com/typo3/image/process?token=149f699b330312ff519c0fa3af2b6dd99658cd4b&id=35214 gives a 404, while with a not-encoded & https://www.mydomain.com/typo3/image/process?token=149f699b330312ff519c0fa3af2b6dd99658cd4b&id=35214 redirects to a proper /fileadmin/_processed_/c/0/csm_RTEmagicC_.... and shows the image

This sounds like we need to call the url and get its redirect target instead of using the url as-is. Or at least if+str_replace the ampersand.

[sgalinski]

I guess there is some debug code in the RTE processing class that prevents resolving the current newly added images. I always get process URLs instead of the fileadmin ones. The process URLs can not be processed outside of the backend context. So if anyone has this problem and wants fileadmin URLs back, just implement the following patch.

diff -urNw rte-ckeditor-image.old/Classes/Database/RteImagesDbHook.php rte-ckeditor-image/Classes/Database/RteImagesDbHook.php
--- rte-ckeditor-image.old/Classes/Database/RteImagesDbHook.php	2023-02-03 14:02:02.000000000 +0100
+++ rte-ckeditor-image/Classes/Database/RteImagesDbHook.php	2023-02-07 16:28:12.125681023 +0100
@@ -247,7 +247,7 @@
                         // An original image file uid is available
                         try {
                             $originalImageFile = $resourceFactory
-                                ->getFileObject((int) $attribArray['data-htmlarea-file-uid'] . '0');
+                                ->getFileObject((int) $attribArray['data-htmlarea-file-uid']);
                         } catch (FileDoesNotExistException $exception) {
                             if ($this->logger !== null) {
                                 // Log the fact the file could not be retrieved.

[jpmschuler]

probably fixed by #218 as #220 was a duplicate of that

[comeleleu]

I have the same issue using TYPO3 11.5.26 and rte_ckeditor_image v11.0.9.

I've fixed it by creating an XClass in my website extension:

return new JsonResponse([
    ...
    'processed' => [
        ...
        'url'    => $processedFile->getOriginalFile()->getPublicUrl(),
    ],
    ...
]);

[MIchelHolz]

same for TYPO3 11.5.26, solved by manually setting the target redirect url in my custom sanitizer extension with curl in BackendOnSave hook

[mohammed-bens]

same for TYPO3 11.5.26, solved by manually setting the target redirect url in my custom sanitizer extension with curl in BackendOnSave hook

Hello MichelHolz; Can you tell us how you solved the problem?

[stephangrass]

I am also unable to get it working after updating to TYPO3 11. The images are being output with a URL like 'typo3/image/process?token=324234234'. rte_ckeditor_image in version 11.0.8 is installed ...

[bigahuna]

I am also unable to get it working after updating to TYPO3 11. The images are being output with a URL like 'typo3/image/process?token=324234234'. rte_ckeditor_image in version 11.0.8 is installed ...

Try including the extension in the template.

[stephangrass]

@bigahuna Including the extension in the template?

[bigahuna]

Edit the template for the site and add the "CKEditor Image Support" item to the "Selected Items" list.

[stephangrass]

@bigahuna The static template is included. That's not the problem ...

[franhida]

@bigahuna The static template is included. That's not the problem ...

Hi. I found out that adding the template actually makes a difference because it activates "Netresearch\RteCKEditorImage\Controller\ImageRenderingController" which preproess the image link and in case it has a "/typo3/image/process"-like URL.

However, as you posted, it will not suffice. You will have to add the following code in your extension package (or an extension that loads the TypoScript after rte_ckeditor_image's TypoScript):

lib.parseFunc_RTE.tags.img < lib.parseFunc.tags.img

This line will enable the rendering of the image in the Frontend.

Cheers.

[Patta]

If you use fluid_styled_content, include the ckeditor_image static template/setup before FSC. Or copy lib.parseFunc to lib.parseFunc_RTE

[Gitsko]

@navaki, @stephangrass is the problem solved for you with the above solutions or are there still problems? Does the problem still exist?

[stephangrass]

@navaki, @stephangrass is the problem solved for you with the above solutions or are there still problems? Does the problem still exist?

I think so ...

[arunspt]

Hi All,

Do we've any permanent solution for this issue? Sometimes it works and it returns URLS with /fileadmin and sometimes like "typo3/image/process?token=". The "typo3/image/process?token=" code returns broken images in the frontend and backend. I have this issue for both admin and editor users.

Any updates would be really appreciated.

Thank you.

[muelli1000]

Hi All,

in Typo3 11.5.36 this issue still exist. Is there a solution? I have included the static Template before the fsc. Some Images in the RTE are still like https://www.domain.com/typo3/image/process?token=2fe79893bacb46f9710caacc82f7fb2c952d985b&id=145439

Does have anybody any ideas?

Thank you.

[Gitsko]

Hi @muelli1000,

Is the problem still there? Unfortunately I can't reproduce it, the images are output correctly for me, with and without adding static templates.

<img alt="" data-alt-override="true" data-htmlarea-file-table="sys_file" data-htmlarea-file-uid="166" data-title-override="true" src="/fileadmin/_processed_/6/d/csm_picard_s1_brd_front_stlbk-pc-games6_2625a161fb.jpg" style="" title="" width="100" height="56">

[Ceremony64]

I believe I finally found the cause of the issue!

First of all: Not all images are affected, only those where the new processed-URL differs from the one stored in the textarea. Example: The original file /fileadmin/image.jpg gets added to a textarea. Typo3 v10 stores the processed file under /fileadmin/_processed_/d/3/csm_image_7e60d10e17.jpg. After switching to Typo3 v11 and clearing these temporary generated images, the file no longer exists. This is where the typoscript hook of EXT:rte_ckeditor_image/Configuration/TypoScript/ImageRendering/setup.typoscript kicks in and recreates the missing file. Successfully I might add. However, the new file might may get stored under a different path+name, such as /fileadmin/_processed_/b/c/csm_image_c7b7480c66.jpg. Now the hook in TypoScript rte_ckeditor_image/Configuration/TypoScript/ImageRendering/setup.txt calls ImageRenderingController.php#L88-L98 and generates a new file, in case it doesn't exist. The new URL is set in the $additionalAttributes.

Unfortunately, this attribute gets overwritten in ImageRenderingController.php#L139-L147 again by the old, invalid URL.

Looking at the current version, after the image generation, it also sets $imageSource to the new path. This is what is missing in the package for Typo3 v11.

Thus, the fix is adding $imageSource = $processedFile->getPublicUrl(); after $processedFile in ImageRenderingController.php#L88-L89

EDIT: Commit 1cfe7a7 that fixed it originally was v12 only