TYPO3 Core

Regenerate Processed file...

Upon rendering
---------------

+ is transparent

- consume a more resources because it must be checked whether Processed File exists or not. (cache could compensate the cons)

Scheduler Task
---------------

+ does not take time from the rendering process

- must be configured and specifically created
- will not work well if the image is replaced

As additional information, the processed file images are regenerated when the RTE is saved -> yes (and good). However this can not be the final solution IMHO because it forces the User to open up the content element and save it again. For big websites... well not the most adequate.

Fabien Udriot wrote:

Regenerate Processed file...

Upon rendering
---------------

+ is transparent

- consume a more resources because it must be checked whether Processed File exists or not. (cache could compensate the cons)

This must be the way to go. ProcessedFiles already includes a caching layer and regenerates the file only if needed.

In case it is not clear enough, a small step-by-step procedure for reproducing the issue (it does not hurt):

1. Insert a Magic Image in the RTE
2. Look how nicely it is rendered on the FE
3. Delete the image in _processed_ directory
4. Reload the FE. Oh, a 404 image!

There could be 3 tests to lead for testing and verifying the patch. Open a Text Content Element.

1. External Image

Copy / paste in body text:

Flag RTE disable: "on" 

<img src="http://government.typo3cms.demo.typo3.org/fileadmin/_processed_/csm_IMG_1400_7d600da0db.jpg" title="2012-05-29_13.43.19-1.jpg" width="265" height="177" alt="baz" style="foo: bar" class="foo"/>

2. MagicImage

-> Insert the image with the MagickImage wizard which is the default use case

What actually has happend to this issues? It only says resolved but not if anything has changed.

I still have this issues with a current 6.2.12 version.

1. Add a magic image,
2. then change the image on the storage,
3. let the scheduler task for indexing the storage notice the change.
4. As a result the processed image is deleted, but calling the page does not generate a new image.

Any updates on that?

For the record: The click-enlarge functionality is ok.

This is not related to click enlarge. The issue that is ticket was initially written for is still present.

Can anybody please change the status of the ticket and plan it for next patch level.

This is a serious issue that removes pictures from websites frequently. Everytime you have to deleted the processed images (e.g. changed settings in image generation) you have to go all magic images, open and save the cElements manually.

What about this? I have this issue, a lot of thumbnails disappeared on a live site. I don't see if the issue is solved, or not, or?... wtf? I even tried to apply this patch: https://review.typo3.org/#/c/27884/
No success with this, images will not be regenerated.
It looks that I have to replace all the images by hand, one by one.. is this possible for a very serious issue that has been tracked for over a year?? Am I missing something?

For me it looks like the images will be regenerated, but the new filename (different postfix) will not be updated in the content (for magic RTE images).
e.g. the file in the output source code is "fileadmin/_processed_/csm_cd15_f54430da3a.jpg", the new generated one "fileadmin/_processed_/csm_cd15_726f19803a.jpg"

To avoid replacing all images by hand (> 200!) I wrote a script that reads the DB and makes copies of the file with the wrong postfix for all the other src-tags found.

I have a guess what the matter is: if an image is used several times (maybe with the same scaling) in RTE-generated content, all the src-attributes point to different filenames. But the regenerating of the thumbnails cleans up all redundant files. Just one src-tag will point to an existing file at the end.

So one way would be to consolidate the html-code to make all src-attributes point to the same file if the same source and scaling is involved, or just allow multiple copies of the file. Or (best) not let the html-code in the DB point to a real file (post processing).

I will upload the script I used to my GIT-repo and post the link here for any other victims of this behaviour

Hi Matthias,

i can confirm this bug - i can tell that all the images that were linked in the bodytext of HTMLArea are affected.

Since i have a whole lot of missing images due to that behaviour, can you post your script ASAP! Beer or wine preferred? ;-)

Christoph

Here is the script I created and used to fix the issue. It will copy existing files in processed with matching filename for each appearance of the same filename (with different postfix) found in any tt_content.bodytext.
The script does not change anything in the database, it just copies existing files. You have to request the page with the missign thumbnails in the browser to let typo3 generate the thumbnails (with postfix in the filename), so that they can be copied by the script.

Additional description in the script-file:
[[https://bitbucket.org/snippets/thismaechler/j8Bj9]]

The same issue in TYPO3 6.2.15. In tt_news RTE images are added as magic images. When I updated the typo3 version to 6.2.13 the images of news are now generated in FE. If I edit the news entry and save it the images are generated in the processed folder. After that If I rename the processed folder the images are generated only for the newly updated or saved news item. Other news items still shows 404 error. No idea how to resolve this. In my site there are 1800+ news entries are there. So editing and saving entries one by one is not a practical approach.

I tried @Matthias script with tt_news table instead of tt_content. This didn’t work !.

Hello,

I added this to my TS:
// TS setup for TYPO3 image rendering
// Needed to resolve this bug: https://forge.typo3.org/issues/56147
// Found here: https://github.com/TYPO3/TYPO3.CMS/tree/master/typo3/sysext/rtehtmlarea/Configuration/TypoScript/ImageRendering
// **********************************************
// Including library for processing of magic images and file abstraction attributes on img tag
// **********************************************

lib.parseFunc_RTE {
tags.img = TEXT
tags.img {
current = 1
preUserFunc = TYPO3\CMS\Rtehtmlarea\Controller\ImageRenderingController->renderImageAttributes
}
nonTypoTagStdWrap.HTMLparser.tags.img.fixAttrib {
allparams.unset = 1
data-htmlarea-file-uid.unset = 1
data-htmlarea-file-table.unset = 1
}
}

Cheers!
Bert

Bert Hiddink wrote:

Hello,

I added this to my TS:

When does this get triggered?
I have this problem on one of my installations and the images get regenerated when I open the content element and click on save.

But the site is big (>100000 CEs) and complex and only a part of the Images are missing. So how can I trigger this open&save-Action for all pages?
I'm on 6.2.26 (LTS)

Any news on this? I ran into the same problem :/

Julian Stock wrote:

Any news on this? I ran into the same problem :/

Nothing new here, still having this Problem producing a lot of work for the editors :(

In TYPO3 7 I've got the same problem after clearing the processed directory.
RTE-Images are generated, but not if they are placed inside of a link.

Following typoscript helped me:

Edit: Changed code, previous one caused links to vanish

lib.parseFunc_RTE {
    tags.link {
        orderedStdWrap.10.parseFunc {
            tags.img = TEXT
            tags.img {
                current = 1
                preUserFunc = TYPO3\CMS\Rtehtmlarea\Controller\ImageRenderingController->renderImageAttributes
            }
        }
    }
}

Related: https://github.com/netresearch/t3x-rte_ckeditor_image/issues/25