Task #56147

Epic #55070: Workpackages

Epic #54260: WP: FAL Missing Issues / Features / API

Story #54272: As an Editor I expect FAL to work with the RTE

Regenerate missing RTE magic image on rendering

Added by Fabien Udriot over 5 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2014-02-20
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
medium
Sprint Focus:

Description

RTE now handles Magic images as Processed File and generate a new CSM image (Crop Scale Mask) upon "importation" in the RTE.

What is currently lacking is a way to regenerate this image in case the file is missing for instance after flushing the _processed_ directory.

It must be decided what is the best approach:

  • The image is regenerated on the fly when rendering the FE.
  • Via a scheduler task.
  • ...

Feedback welcome.

rte_custom_file_processing.zip (2.69 KB) Fabien Udriot, 2014-03-17 14:48


Related issues

Related to TYPO3 Core - Feature #56133: Replace file feature for fal file list Closed 2014-02-19
Related to TYPO3 Core - Bug #56077: Blocking errors if files deleted Closed 2014-02-18
Related to TYPO3 Core - Bug #73239: Clear processed files leads to 404 errors Closed 2016-02-11

History

#1 Updated by Fabien Udriot over 5 years ago

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

#2 Updated by Fabien Udriot over 5 years ago

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.

#3 Updated by Helmut Hummel over 5 years ago

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.

#4 Updated by Helmut Hummel over 5 years ago

  • Parent task set to #54272

#5 Updated by Fabien Udriot over 5 years ago

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!

#6 Updated by Stanislas Rolland over 5 years ago

  • Assignee set to Stanislas Rolland

#7 Updated by Stanislas Rolland over 5 years ago

  • Subject changed from RTE - regenerate Processed File if missing to Regenerate missing RTE magic image on rendering

#8 Updated by Stanislas Rolland over 5 years ago

  • % Done changed from 0 to 90

#9 Updated by Stanislas Rolland over 5 years ago

  • Status changed from New to Under Review

#10 Updated by Fabien Udriot over 5 years ago

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

#12 Updated by Stanislas Rolland over 5 years ago

  • % Done changed from 90 to 100

#13 Updated by Wouter Wolters over 5 years ago

  • Status changed from Under Review to Resolved

#14 Updated by Martin R. Krause over 4 years ago

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?

#15 Updated by Markus Klein over 4 years ago

  • Status changed from Resolved to Accepted
  • Assignee deleted (Stanislas Rolland)
  • Target version changed from 6.2.0 to next-patchlevel
  • % Done changed from 100 to 0
  • Complexity set to medium

I remember now having had a similar issue.
If a processed file is deleted, it is not properly regenerated for some reason.

Easily reproducable by setting config.noScaleUp = 0 in TS.
This triggers FAL to throw away (due to config change; more details in #66614) an existing processed file (from preview in RTE) when generating the image for FE, but the file is never regenerated.

#16 Updated by Markus Klein about 4 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (next-patchlevel)

In conjunction with with #66614 I know discovered that the RTE Click-Enlarge rendering (the static template) is buggy somehow.
Removing the static template, fixes the issue in FE and the proper image is generated.

I'm not sure, hence, how this is related to this ticket.

#17 Updated by Markus Klein about 4 years ago

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

#18 Updated by Martin R. Krause about 4 years ago

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.

#19 Updated by Alexander Opitz about 4 years ago

  • Status changed from Needs Feedback to New

#20 Updated by This Mächler almost 4 years ago

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?

#21 Updated by This Mächler almost 4 years ago

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"

#22 Updated by This Mächler almost 4 years ago

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

#23 Updated by Christoph RUnkel almost 4 years ago

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

#24 Updated by This Mächler almost 4 years ago

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]]

#25 Updated by HOJA M A over 3 years ago

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 !.

#26 Updated by Bert Hiddink about 3 years ago

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

#27 Updated by Thomas Oliver Moll about 3 years ago

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)

#28 Updated by Julian Stock almost 3 years ago

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

#29 Updated by Thomas Oliver Moll almost 3 years ago

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 :(

#30 Updated by Riccardo De Contardi almost 2 years ago

  • Status changed from New to Closed

We are sorry, but we close this issue as now TYPO3 uses CKEditor and RTEHtmlarea is no more supported by TYPO3 .

RTEHtmlarea development has stopped - it has been decoupled from the core and its code is available on GitHub:
https://github.com/FriendsOfTYPO3/rtehtmlarea

If you still need this fixed please create a PR on GitHub

If you think that this is the wrong decision or experience the issue again on more recent TYPO3 version (8.7.x) please reopen it or
open a new issue with a reference to this one. Thank you.

Regards
Riccardo De Contardi

#31 Updated by Sebastian Müller 7 months ago

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
            }
        }
    }
}

Also available in: Atom PDF