Core

Bug #39904

Unresized image not displayed in FE after move in filelist

Added by internezzo ag 9 months ago. Updated 6 months ago.

Status:

Resolved

Start date:

2012-08-17

Priority:

Must have

Due date:

Assignee:

Steffen Ritter

% Done:

100%

Category:

File Abstraction Layer (FAL)

Target version:

6.0.0-RC1

TYPO3 Version:

6.0

Complexity:

PHP Version:

Votes:

Description

When an image is moved in the filelist which is used unresized in a content element (CE), the wrong path is used in the FE.

Steps to reproduce:

Create folder test1 and test2 and upload an image to test1
Create CE with type image and integrate the image
Check FE: image is directly linked to fileadmin/user_upload/test1/image.jpg
Move image to test2 folder in filelist
Clear cache / reindex FAL with scheduler task
Check FE: image is still linked to test1 folder --> image is not displayed
Edit CE: resize image
Check FE: image is displayed correctly from processed folder
Move image back and forth: FE remains intact as long as the image is resized

Related issues

related to Core - Bug #40033: Relation lost after renaming folder	Resolved	2012-08-21
related to Core - Bug #40669: FAL files get reindexed in storage null when used with tt...	Resolved	2012-09-06
blocked by Core - Bug #43059: File processing is broken	Resolved	2012-11-17

Associated revisions

Revision 66c204f0
Added by Andreas Wolf 6 months ago

[TASK] Refactor FAL file processing

File processing is a central part of TYPO3's file usage, as e.g. all
images in content elements have to be resized when they don't fit the
requirements. However, the current implementation of file processing
with FAL has several drawbacks and shortcomings, not to mention quite a
few bugs.

This patch brings a completely reworked infrastructure behind the
File Processing Service, while keeping the external API unchanged.

The processing to be done is described in tasks, which are part of a
ProcessedFile's properties. The processing itself is now moved to
processors, which could execute the tasks using different utilities,
e.g. ImageMagick or some cloud image processing service. Currently,
there is only a local image processor implementation, which relies on
ImageMagick/GraphicsMagick (i.e. uses the same configuration as the old
processing).

The processed file class now also supports safe handling of unchanged
files, i.e. files that should have been processed, but didn't need
processing.

Fixes: #43059
Fixes: #39904
Fixes: #40033
Fixes: #40669
Releases: 6.0

Change-Id: I186a46f9923dacd98be655d72be2bd89b43866c2
Reviewed-on: http://review.typo3.org/14310
Reviewed-by: Helmut Hummel
Tested-by: Helmut Hummel

History

#1
Updated by Andreas Wolf 9 months ago

Status changed from New to Needs Feedback

What I don't get from your description: Did you move the file manually or by using FAL methods? Because the former method might sometimes break stuff, though we have taken some measures to ensure consistency of the file index; the latter should definitely not break anything. Maybe this issue is related to #40033 - we'll have to check that.

#2
Updated by Marcel Burkhalter 9 months ago

I moved the file in the backend module filelist.

#3
Updated by Andreas Wolf 9 months ago

Ok. Could you check if the index record in sys_file is updated, i.e. if the identifier of the file is changed to .../test2/...? This should normally happen, but maybe something is broken here.

#4
Updated by Andreas Wolf 9 months ago

Andreas Wolf wrote:

Ok. Could you check if the index record in sys_file is updated, i.e. if the identifier of the file is changed to .../test2/...? This should normally happen, but maybe something is broken here.

Forget what I said here... I found the reason for this bug: Even for files where no processing is applied (because they don't have to be resized etc.), a ProcessedFile object is created and linked to the content record. This record points to the original location of the file, but is not updated when the file is moved. Thus the relation breaks.

A solution could be to simply not create the ProcessedFile altogether when a file is not changed. I don't know why it happens at all or why there is no check if the file has been processed before creating the record...