TYPO3 Core

Similar problem here.

Normale CE Textpic:

Image in Backend is correct but frontend renders preview image (thumbnail) of a totally different image.

ClearCache all and clearing proccessed images didn't help.

What's really strange is, when I hide the image and image of the ext-icon from about module is rendered in the frontend.

Investing further on this, trying introduction package and one by one adding extension we use in the current project.

Update:

sys_file:uid:1 => /typo3/sysext/about/ext_icon.gif

First entry of the table

Reproducible:

Fresh introduction package, goto examples "text and images" open CE "Position: In text, left" and just hide the image.

All of the sudden Kasper appears...

Update:

sys_file:uid:1 => kasper-skarhoj1_01.jpeg

On the introduction package, seems there is some kind of fallback if reference is hidden.

Strange.
I can confirm the mentioned behavior from Max.

FAL is still so buggy :(
Extension-Manager shows a product image from the webpage instead of the ext-icon from the extension.

I think something is here completely wrong.

Yep. Found that one to, dbal extension had some nice big fat image :-/

Tried to find some mixed up relation by checking UIDs but did't find a pattern yet

this happens to me too but so far i only noticed it when im_noScaleUp is set to 1 in the install tool. (see bug 44616#note-5)

[[http://forge.typo3.org/issues/44988]]

^This one fixed the problem with the hidden image showing another one. Investigating if it also fixes the rendering of the wrong preview image

Could anyone of you who experiences this error run the following SQL query and report on the results?

SELECT s.uid, f.storage, s.name AS processedname, s.identifier AS processedidentifier, f.name AS origname, f.identifier AS origidentifier, s.checksum FROM sys_file_processedfile AS s LEFT JOIN sys_file AS f ON s.uid=f.uid WHERE LOCATE(s.checksum, s.name) = 0

The interesting part is if the name in processedname does not contain (parts of) origname. Then you experience a bug I found today with the help of Camelia.

I am not sure what causes the bug, but its pretty obvious that at some point the uids of the processed file and the original file get mixed up and the database ends corrupted. This is however no problem, as we can simply flush the processed file cache once this bug is fixed.

Total found 86 results

Most of them have origname ext_icon.gif if the doen't contain any part of the origname.
Then we have some mixed up ones like processedname contains "...seite05.." while origname is "seite22.jpg"

Maybe this helps finding the bug. The installation was started with 6.0.0 Core and moved to 6.0.1.

Total found 24 results.

Same here, processedname does not contain parts of origname.
The Original File in Frontend should be ...fruehling.jpg but is ...twister.jpg - exactly what is found in Database with your select-query.

Applying the above mentions patch from Max didn`t solve this problem. EDIT: but it solves for sure the issue with disabling images /EDIT

Andreas which "processed file cache" do you mean? Database table sys_file_processedfile or the folder in the file system?

Yep the patch didn't fix the wrong preview images, but fixes the wrong image being displayed when the image is hidden in backend. Seems that truncating the sys_file_proccessedfile table fixes the problems temporarily, maybe until there are new images added by editors.

Andreas Wolf wrote:

And it definitely worked with 6.0.0? Or did you add lots of contents since then, so the uid clashes only started to appear then? Please check what uids your conflicting entries (the ones you found with my SQL query have). If they are distributed over the whole range of uids, then the problem seems to have been there before. Otherwise, it might also be new in 6.0.1.

Can't tell for sure anymore but I think we did find two or three images on 6.0.0 but switched to 6.0.1 on rollout

UIDs are ascending in blocks (i.e. the ext_icon ones run from 1 to 65)

Andreas Wolf wrote:

Max Roesch wrote:

Maybe this helps finding the bug. The installation was started with 6.0.0 Core and moved to 6.0.1.

And it definitely worked with 6.0.0?

I also can`t tell you for sure if it worked correctly with 6.0.0. But we also started with 6.0.0 and did the update to 6.0.1 when it came out. There then we discovered the issue.

Max Roesch wrote:

Andreas Wolf wrote:

And it definitely worked with 6.0.0? Or did you add lots of contents since then, so the uid clashes only started to appear then? Please check what uids your conflicting entries (the ones you found with my SQL query have). If they are distributed over the whole range of uids, then the problem seems to have been there before. Otherwise, it might also be new in 6.0.1.

Can't tell for sure anymore but I think we did find two or three images on 6.0.0 but switched to 6.0.1 on rollout

Ok. I just checked the changes that were made to FAL from 6.0.0 to 6.0.1 - there is no change I could easily identify as the cause of this bug. So I still think this bug is in since 6.0.0 (or most likely even the RCs).

UIDs are ascending in blocks (i.e. the ext_icon ones run from 1 to 65)

Ok, but are the uids you found with my query only in a specific range or over the whole spectrum of uids in sys_file_processedfile (maybe also check what the highest uid is)?

I also updated to 6.0.1 from 6.0 but if my memory does not fail me, I think the bug was there before also. Anyway, I know the exact time of the update to 6.0.1 so I think it should not be very hard for me to figure if images from before the update were messed also. I'll check and post back in a few

So I did check and I'm afraid my memory did fail me :(
I had a full backup of the database right before the update so I run the query from Andreas on it and it returns 0 results (although both tables have several hundreds records). I also checked how 'im_noScaleUp' was set and it was set to 1 (I also have full backup of files since I use a versioning system for both db and files). So at least for me it seems that the problem is related to the updated to 6.0.1

Ok, it seems I was wrong about the cause for this problem. The modified checksum comes from the patch for #44073 - this is perfectly ok, though the filename should have been updated.

I'll keep trying to track this down - thanks to everybody who helps with this.

This should be fixed with my patch for #45308. It would be great if you could test this patch (after emptying sys_file_processedfile) and give feedback.

Yeb. Problem seems to be resolved. Thank you.