TYPO3 Core

Ever image which I upload inside of the file browser window (in order to add an image to a product), is added in FAL to sys_file with width and height = 0.

The uploaded image is stored into the folder fileadmin/user_upload .

All the DB checks and Updates have been executed in the Install Tool.

The sys_file table contains the width and height. And also the sys_file_metadata contains the width and height fields.
I have filled in the width and height into the table sys_file manually. Because the automatic generation always gave zeros to it. However then the image has always full size in the FE.
And another image is still not shown even with width and height set manually from phpMyAdmin.

I only get unchecked recommendations:

ALTER TABLE sys_file CHANGE crdate zzz_deleted_crdate int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE cruser_id zzz_deleted_cruser_id int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE deleted zzz_deleted_deleted tinyint(4) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_oid zzz_deleted_t3ver_oid int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_id zzz_deleted_t3ver_id int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_wsid zzz_deleted_t3ver_wsid int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_label zzz_deleted_t3ver_label varchar(30) NOT NULL default '';
ALTER TABLE sys_file CHANGE t3ver_state zzz_deleted_t3ver_state tinyint(4) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_stage zzz_deleted_t3ver_stage int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_count zzz_deleted_t3ver_count int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_tstamp zzz_deleted_t3ver_tstamp int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3ver_move_id zzz_deleted_t3ver_move_id int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE t3_origuid zzz_deleted_t3_origuid int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE title zzz_deleted_title tinytext;
ALTER TABLE sys_file CHANGE width zzz_deleted_width int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE height zzz_deleted_height int(11) NOT NULL default '0';
ALTER TABLE sys_file CHANGE description zzz_deleted_description text;
ALTER TABLE sys_file CHANGE alternative zzz_deleted_alternative text; 

ALTER TABLE sys_file DROP KEY parent;
ALTER TABLE sys_file DROP KEY t3ver_oid; 

This is the structure:

sys_file

Colonne    Type    Null    Défaut     Commentaires
uid     int(11)    Non            
pid     int(11)    Non     0       
tstamp     int(11)    Non     0       
crdate     int(11)    Non     0       
cruser_id     int(11)    Non     0       
deleted     tinyint(4)    Non     0       
t3ver_oid     int(11)    Non     0       
t3ver_id     int(11)    Non     0       
t3ver_wsid     int(11)    Non     0       
t3ver_label     varchar(30)    Non            
t3ver_state     tinyint(4)    Non     0       
t3ver_stage     int(11)    Non     0       
t3ver_count     int(11)    Non     0       
t3ver_tstamp     int(11)    Non     0       
t3ver_move_id     int(11)    Non     0       
t3_origuid     int(11)    Non     0       
type     varchar(10)    Non            
storage     int(11)    Non     0       
identifier     text    Oui     NULL       
extension     varchar(255)    Non            
mime_type     varchar(255)    Non            
name     tinytext    Oui     NULL       
title     tinytext    Oui     NULL       
sha1     tinytext    Oui     NULL       
size     int(11)    Non     0       
creation_date     int(11)    Non     0       
modification_date     int(11)    Non     0       
width     int(11)    Non     0       
height     int(11)    Non     0       
description     text    Oui     NULL       
alternative     text    Oui     NULL       
last_indexed     int(11)    Non     0       
missing     tinyint(4)    Non     0       
metadata     int(11)    Non     0       
identifier_hash     varchar(40)    Non            
folder_hash     varchar(40)    Non            

Index

Nom de l'index    Type    Unique    Compressé    Colonne    Cardinalité    Interclassement    Null    Commentaire
PRIMARY    BTREE    Oui    Non    uid    595    A    Non    
parent    BTREE    Non    Non    pid    1    A    Non    
deleted    1    A    Non
t3ver_oid    BTREE    Non    Non    t3ver_oid    1    A    Non    
t3ver_wsid    1    A    Non
sha1    BTREE    Non    Non    sha1 (40)    595    A    Oui    
folder    BTREE    Non    Non    storage    5    A    Non    
folder_hash    595    A    Non
tstamp    BTREE    Non    Non    tstamp    29    A    Non    
lastindex    BTREE    Non    Non    last_indexed    1    A    Non    
sel01    BTREE    Non    Non    storage    1    A    Non    
identifier_hash    595    A    Non

sys_file_metadata
Colonne    Type    Null    Défaut     Commentaires
uid     int(11)    Non            
pid     int(11)    Non     0       
tstamp     int(11)    Non     0       
crdate     int(11)    Non     0       
cruser_id     int(11)    Non     0       
sys_language_uid     int(11)    Non     0       
l10n_parent     int(11)    Non     0       
l10n_diffsource     mediumblob    Non            
t3ver_oid     int(11)    Non     0       
t3ver_id     int(11)    Non     0       
t3ver_wsid     int(11)    Non     0       
t3ver_label     varchar(30)    Non            
t3ver_state     tinyint(4)    Non     0       
t3ver_stage     int(11)    Non     0       
t3ver_count     int(11)    Non     0       
t3ver_tstamp     int(11)    Non     0       
t3ver_move_id     int(11)    Non     0       
t3_origuid     int(11)    Non     0       
file     int(11)    Non     0       
title     tinytext    Oui     NULL       
width     int(11)    Non     0       
height     int(11)    Non     0       
description     text    Oui     NULL       
alternative     text    Oui     NULL       
categories     int(11)    Non     0       

Index

Nom de l'index    Type    Unique    Compressé    Colonne    Cardinalité    Interclassement    Null    Commentaire
PRIMARY    BTREE    Oui    Non    uid    593    A    Non    
file    BTREE    Non    Non    file    593    A    Non    
t3ver_oid    BTREE    Non    Non    t3ver_oid    2    A    Non    
t3ver_wsid    2    A    Non
fal_filelist    BTREE    Non    Non    l10n_parent    2    A    Non    
sys_language_uid    2    A    Non

The sys_file table changes are no recommendations but mandatory. Could you run these changes and try again?

Are the width and height field of sys_file_metadata set for existing images?

Strange thing is that the id are in a strange order. The newer file has a lower id than the existing file.

Could you try to upload a different file directly in file module?

I want to use the file browser of the List Module to upload the image file and connect it to a product.
I think that I have also added the 'Uhr-Waltons' a second time. I have tried to fix the image size by removing and reassigning of the same image.

I have now added the file "SaguaroNationalParkArizona.jpg" using the fileadmin Module.

$sys_file = array(
  array('uid' => '530','pid' => '0','tstamp' => '1409206290','type' => '2','storage' => '1','identifier' => '/SaguaroNationalParkArizona.jpg','extension' => 'jpg','mime_type' => 'image/jpeg','name' => 'SaguaroNationalParkArizona.jpg','sha1' => '7525c71cb267fe13fda0468fb28f03ff5fa6ca52','size' => '189313','creation_date' => '1409206290','modification_date' => '1409206290','last_indexed' => '0','missing' => '0','metadata' => '0','identifier_hash' => '89c2065ebdc0ae0720537726b2091c27eaa472a4','folder_hash' => '42099b4af021e53fd8fd4e056c2568d7c2e3ffa8')
);

The new file has not meta_data record?

Requête SQL : SELECT uid,file,width,height,title FROM `sys_file_metadata` WHERE file = 530 LIMIT 0, 25 ;
Lignes : 1
uid     file     width     height     title
530     530     1600     1200     NULL

Does it work now for new uploaded files?

And the filebrowser popup windows has a third bug:

The uploaded image JPG has an empty mime_type field.

uid     identifier     extension     mime_type     name

505     /user_upload/taylor_swift_1211323728.JPG    jpg     <empty>    taylor_swift_1211323728.JPG    

I can not reproduce your upload bug. I tested with the fe_users image field that also uses the old method like tt_products.

MimeType and dimensions are set correctly in DB.

You are sure the database structure of sys_file and sys_file_metadata is correct?

I do not really understand the problem you are facing.

Are the width and height fields removed from sys_file? These need to be removed because internaly the sys_file and sys_file_metadata are merged/used as one.

Did you try to set the missing flag to 1 in sys_file and run the indexer task for each storage? That makes sure that the width and height are set (again) for all image records.

Gr. Frans

The images of products are shown in their full sizes. They should instead be shown in reduced sizes in the FE. Is this understandable? What is unclear?

No, I did not remove or change anything. I just deleted the image caches in the Install Tool.

Here again the table structur of sys_file:

sys_file
Colonne    Type    Null    Défaut     Commentaires
uid     int(11)    Non            
pid     int(11)    Non     0       
tstamp     int(11)    Non     0       
last_indexed     int(11)    Non     0       
missing     tinyint(4)    Non     0       
storage     int(11)    Non     0       
type     varchar(10)    Non            
metadata     int(11)    Non     0       
identifier     text    Oui     NULL       
identifier_hash     varchar(40)    Non            
folder_hash     varchar(40)    Non            
extension     varchar(255)    Non            
mime_type     varchar(255)    Non            
name     tinytext    Oui     NULL       
sha1     tinytext    Oui     NULL       
size     int(11)    Non     0       
creation_date     int(11)    Non     0       
modification_date     int(11)    Non     0       

As I have already written before, this table sys_file has no fields 'widht' and 'height' any more. And it still does not work.

I do not understand this question:
"Did you try to set the missing flag to 1 in sys_file and run the indexer task for each storage? That makes sure that the width and height are set (again) for all image records."

How can I do this? Why does not TYPO3 do this for me?
What is a missing flag? Where is it? Where do I find a storage for the product files? How must I start the indexer task?

The problem you are facing is missing height and width values in sys_file_metadata

Have a look at the linked issue for instructions to get them back.

https://forge.typo3.org/issues/46020#note-80

Hi Franz,

So if I understood you correct all new uploaded and all existing images the width and height are set in sys_file_metadata.

New uploaded images are correctly resized in FE but existing images are not?

And before upgrading TYPO3 everything worked correct on this server? (Just asking to be sure).

It could be that the sys_file_processed table has wrong values (probably happened direct after upgrade when your table structure wasn't correct yet). Could you try to truncate this table and also remove all files from the fileadmin/_prosessed_ folder? That would forse the system to recreate the processed (resized) files.

I saw you have image files with the extension name in upper case. It could also be you run into the problem described here #62247

Gr. Frans

Frans: "So if I understood you correct all new uploaded and all existing images the width and height are set in sys_file_metadata."

yes

Frans: "New uploaded images are correctly resized in FE but existing images are not?"

No. There is no difference. It does not matter if the image existed before or if it has been added after the upgrade to TYPO3 6.2. The image are always in the wrong full size in the FE.

Frans: "And before upgrading TYPO3 everything worked correct on this server? (Just asking to be sure)."
Yes, everything did work fine in former versions of TYPO3 on both servers.

Frans: "It could be that the sys_file_processed table has wrong values (probably happened direct after upgrade when your table structure wasn't correct yet). Could you try to truncate this table and also remove all files from the fileadmin/_prosessed_ folder? That would forse the system to recreate the processed (resized) files."
I have just executed these steps. They have no effect.

TRUNCATE sys_file_processedfile

Frans: "I saw you have image files with the extension name in upper case. It could also be you run into the problem described here #62247"

There is no difference if the image has the file extension '.png', '.JPG' or '.jpg'. All images are shown in the wrong full size in the FE.

Are there sys_file_processedfile records created for the images that are shown incorrect?
Are the shown images the real imaģes or do they link to a processed file?
What code/fluid/typoscript do you use to show the images?

Gr. Frans

Frans: "Are there sys_file_processedfile records created for the images that are shown incorrect?"
Yes. However all the image files in the _processed folder have the size 0.

[franz@localhost fileadmin]$ cd _processed_/
[franz@localhost _processed_]$ ls -l
total 0
-rw-r--r-- 1 apache apache 0 nov.   3 20:18 preview_Cecilia-Lina-Soerensen-1_578bf8e315.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:14 preview_SaguaroNationalParkArizona_099c2d4227.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:17 preview_SaguaroNationalParkArizona_7571662653.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:17 preview_taylor_swift_1211323728_01_64ef3b6bad.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:18 preview_taylor_swift_1211323728_c4555cfc69.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:17 preview_taylor_swift_1212938139_02811ae73a.jpg
-rw-r--r-- 1 apache apache 0 nov.   3 20:17 preview_Uhr-Waltons_01_3a2375b2d8.png
-rw-r--r-- 1 apache apache 0 nov.   3 20:18 preview_Uhr-Waltons_d06f8aa994.png

Frans: "Are the shown images the real imaģes or do they link to a processed file?"
The images in the FE are linked this way:

http://localhost/fileadmin/user_upload/taylor_swift_1212938139.JPG

Frans: "What code/fluid/typoscript do you use to show the images?".

tt_products list and basket view plugin.

Normal content elements with images render correct?

I'm not familiar with code of tt_products.

And in the bachend the preview/thumbnails are resized correct?

The TYPO3 backend in TYPO3 6.2 is broken: No image icons are shown. TCE shows an empty image.

The image tests in install tool give the correct result?

Install -> Test setup

So, you have your error or the issue behind your real problem. Fix the path to your image/graphics magic.

I do not know why the Install Tool did not set this correctly during the upgrade process. These settings were fine for TYPO3 6.1. All former versions of TYPO3 did set this automatically correct. In TYPO3 6.2 I went through all upgrade steps without any success.
I did install Graphics Magick and I changed the settings in the Install Tool explicitely for Graphics Magick. Now the image sizes are correct in the Frontend and the Image Icons are visible in the TYPO3 backend.

I don't know, what you are doing in your installations, but the configuration isn't changed between 6.1 and 6.2. As you say you now installed GraphicsMagic I would say, it wasn't there before.

So I'd like to close this issue now. Ok?

I am quite sure that there has been no bug with TYPO3 6.1. This bug has been introduced with TYPO3 6.2..

Close this issue. However then other users who get into the same trap won't find it.

So how should it have working with TYPO3 CMS 6.1 if there was no GraphicsMagic installed?

If you do not believe me, then have a look at the image install-configuartion-image.png which I have added before. There you can see that ImageMagick has always been installed and working without any troubles. I did now install GraphicsMagick to make sure that this can't be the reason that the images in the FE and BE do not work with TYPO3 6.2.

As I have no possibilities to look on your system I don't know what is installed on your system and where it is.

You installed Graphix Magic, changed the path accordingly and it worked => For me it looks like it wasn't working before course no such things installed.

The screenshot "install-configuartion-image.png" only tells me that you used a custom configuration with GM and not ImageMagic, but it doesn't show me the functionality from before.

However the image "install-configuartion-image.png" shows that ImageMagick is listed there in green color. The green colors gives you a hint that ImageMagick does exist.
And the rpm package is installed: imagemagick-6.8.7.0-2.1.mga4

No, the image "install-configuartion-image.png" shows GraphicsMagick in red color. This is because at the moment of the screen shot no Graphics Magick has been installed.
I have made the screenshot before the installation of Graphics Magick.

https://forge.typo3.org/issues/61181#note-29

The problem is that TYPO3 6.2 cannot handle the grahpic settings from TYPO3 6.1. TYPO3 6.2 does not even show an error message or give a hint during the upgrade process.

From which TYPO3 Version is this screenshot?

And again, the screenshot shows that you selected "Custom configuration" and there you tried to use "gm" which is graphicsmagic ... but like the screenshot also says (how you correctly wrote) graphicsmagic isn't installed (in normal place like /usr/bin).

So all what the screenshot tells me is: "This can't work!"

This screenshot has been taken in the Install Tool TYPO3 6.2.
No, I did not try to change anything here since TYPO3 6.1.

I did not realize the not working ImageMagick because before the images were coming from the cache. Only when I used the TYPO3 6.2 Install Tool, then the images were not shown any more correctly. The images were not shown in the beginning, after some fixes the images were shown with full size. Many months ago I did use GraphicsMagick. However after a fresh software upgrade (every software completely removed) I did install ImageMagick. Everything seemed to work fine with it until the day when I cleared the image caches. And TYPO3 6.2 had some other issues (see above) with images. This website did not change since many months.

I am sorry, that I do not check everything during the upgrade process. I did not guess the reasons. Are there any chancse to get TYPO3 improved with error messages instead of just not working correctly, if I reproduce this? This could prevent other users to fall into the same list of traps. I will not reproduce this, if nothing will be improved with TYPO3.

Hi Franz,

it would be great if you could reproduce it. I just tried it on my machine but with the given settings from your screenshot I couldn't get the image processing working without installing GraphicsMagic.

I tested your settings in a 4.5 installation and there the gm settings worked even do the test tell /usr/bin/gm was called. What isn't true because there is no /usr/bin/gm library on my machine.

You are sure previous version was 6.1 and no other system updates were performed in the meanwhile?

The image handling is really well covered in the install tool. The test tell you immediately if something doesn't work.
But if it really worked with the previous settings in 6.1 on your machine and after update not anymore than maybe a extra check/upgrade step is needed.

gr. Frans

Hello Frans,

I could just reproduce this on the same server with another TYPO3 installation (fresh install of TYPO3 6.2 and a Graphics Magick [Active]
GraphicsMagick was found in path /usr/bin/). The image generation in the backend and Install Tool was without any problems. Only the images in the FE extension were of full size.
However the "TRUNCATE sys_file_processed" could solve the problem here.

Frans: "You are sure previous version was 6.1 and no other system updates were performed in the meanwhile?".
-> In the meanwhile I can remember that many months before I had tried to use 6.2 beta3 and then I went back to 6.1.

Frans: "The image handling is really well covered in the install tool. The test tell you immediately if something doesn't work."
-> Yes, but former versions of TYPO3 did automatically warn me on the first page of the Install Tool about a mismatch in the GM/IM configuration. This feature is not in 6.2. And because it is an update, I did not reexecute these tests. And I was thinking about a bug in the FAL.

Frans: "But if it really worked with the previous settings in 6.1 on your machine and after update not anymore than maybe a extra check/upgrade step is needed."
-> A check in the Install Tool should be made automatically as in former versions of TYPO3. And a clear button should truncate the table sys_file_processed and remove the files in typo3temp/_processed_.

Franz Holzinger wrote:

However the "TRUNCATE sys_file_processed" could solve the problem here.

Is already part of the upgrade process (one of the upgrade wizards)

Frans: "The image handling is really well covered in the install tool. The test tell you immediately if something doesn't work."
-> Yes, but former versions of TYPO3 did automatically warn me on the first page of the Install Tool about a mismatch in the GM/IM configuration. This feature is not in 6.2. And because it is an update, I did not reexecute these tests. And I was thinking about a bug in the FAL.

Not sure if a wizard is here the correct solution or only pointing the user to 'Install tool' -> 'Configuration presets' there are more settings you should check after upgrade.

Frans: "But if it really worked with the previous settings in 6.1 on your machine and after update not anymore than maybe a extra check/upgrade step is needed."
-> A check in the Install Tool should be made automatically as in former versions of TYPO3. And a clear button should truncate the table sys_file_processed and remove the files in typo3temp/_processed_.

As mentioned above one of the already existing upgrade wizards clears the sys_file_processed table when upgrating from 6.1