Bug #45168

Wrong image displayed in FE if not resized

Added by Henrik Ziegenhain over 8 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
File Abstraction Layer (FAL)
Target version:
Start date:
2013-02-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.0
PHP Version:
5.3
Tags:
Complexity:
medium
Is Regression:
Sprint Focus:

Description

I recentyl stumpled upon a strange bug.

In a CE text with image an image "file-a.jpg" is inserted and the preview image showes the right one.
But in FE a completly wrong "file-b.jpg" is displayed.

I can not say whats going wrong here, but if i resize the image (Original File is e.g. 500x200px) to a width of 500px the right one gets rendered.

I am really confused - a few days ago this worked like expected. Maybe related with the update from 6.0.0 to 6.0.1?


Related issues

Related to TYPO3 Core - Bug #44988: Arbitrary image is shown, if all images are set to hiddenClosed2013-01-30

Actions
Related to TYPO3 Core - Bug #44073: Checksum needs to be updated after file processingClosed2012-12-17

Actions
Related to TYPO3 Core - Bug #45308: uid of processed file is sometimes updated during processingClosedAndreas Wolf2013-02-09

Actions
Related to TYPO3 Core - Bug #46020: Image size is 0 when not scaledClosedAlexander Opitz2013-03-04

Actions
Related to TYPO3 Core - Bug #57585: Wrong Picture in FEClosed2014-04-03

Actions
Is duplicate of TYPO3 Core - Bug #44616: Image caching broken for im_noScaleUp = 1ClosedAndreas Wolf2013-01-17

Actions
#1

Updated by Max Roesch over 8 years ago

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

#2

Updated by Max Roesch over 8 years ago

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.

#3

Updated by Henrik Ziegenhain over 8 years ago

Strange.
I can confirm the mentioned behavior from Max.

#4

Updated by Henrik Ziegenhain over 8 years ago

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.

#5

Updated by Max Roesch over 8 years ago

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

#6

Updated by Camelia M over 8 years ago

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)

#7

Updated by Max Roesch over 8 years ago

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

#8

Updated by Andreas Wolf over 8 years ago

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.

#9

Updated by Max Roesch over 8 years ago

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"

#10

Updated by Max Roesch over 8 years ago

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

#11

Updated by Henrik Ziegenhain over 8 years ago

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?

#12

Updated by Max Roesch over 8 years ago

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.

#13

Updated by Andreas Wolf over 8 years ago

  • Status changed from New to Accepted
  • Assignee set to Andreas Wolf
  • Target version set to 6.0.2
  • Complexity set to medium

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

Max Roesch wrote:

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.

Truncating the table will regenerate the cache and fix the problem until the uids are mixed up again. I still don't know when exactly this happens, but I guess that we can find it out.

Henrik Ziegenhain wrote:

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

Both of these are part of the cache, but I only meant the table. The files will still be around when you truncate the table, but that's only a matter of diskspace, it does not do any harm. You could of course also empty the folder fileadmin/_processed_/, but that's not strictly required.

#14

Updated by Max Roesch over 8 years ago

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)

#15

Updated by Henrik Ziegenhain over 8 years ago

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.

#16

Updated by Andreas Wolf over 8 years ago

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)?

#17

Updated by Camelia M over 8 years ago

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

#18

Updated by Camelia M over 8 years ago

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

#19

Updated by Andreas Wolf over 8 years ago

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.

#20

Updated by Andreas Wolf over 8 years ago

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.

#21

Updated by Andreas Wolf over 8 years ago

  • Status changed from Accepted to Needs Feedback
#22

Updated by Henrik Ziegenhain over 8 years ago

Yeb. Problem seems to be resolved. Thank you.

#23

Updated by Andreas Wolf over 8 years ago

  • Status changed from Needs Feedback to Resolved

Closing this is as it is apparently fixed. If you experience a similar problem, please open a new bug report and link it to this one (or mention this issue's ID in the description).

#24

Updated by Riccardo De Contardi about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF