Bug #61181

FAL: file maxW and maxH are ignored

Added by Franz Holzinger about 7 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
Start date:
2014-08-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

see also https://forge.typo3.org/issues/46020

After an upgrade from TYPO3 6.1 to 6.2 and the execution of all update steps in the Install Tool, the images in my FE extension are changed to full size.

I did also clear cache_imagesizes.

$imageCode = $cObj->getContentObject($contentObject)->render($imageConf);

file.maxW = 100
file.maxH = 200

This however results in:

<img src="uploads/pics/Uhr-Waltons.png" width="299" height="401" alt="" /><

The image is not resized any more as in TYPO3 6.1.

And on another site the images are always size=0. maxW and maxH get ignored.


Files

228211-product-list.png (165 KB) 228211-product-list.png product list with 2 products and their images Franz Holzinger, 2014-08-28 07:11
228211-product-list-image2.png (413 KB) 228211-product-list-image2.png second image added to first product is too big Franz Holzinger, 2014-08-28 19:39
bug#61181-image-taylor.html (13 KB) bug#61181-image-taylor.html Franz Holzinger, 2014-09-04 12:32
bug#61181 -sys_file_metadata.pdf (99.7 KB) bug#61181 -sys_file_metadata.pdf width=299 heigth=401 Franz Holzinger, 2014-10-25 16:10
install-configuartion-image.png (52.6 KB) install-configuartion-image.png Configuration presets image processing Franz Holzinger, 2014-11-12 13:50

Related issues

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

Actions
Related to TYPO3 Core - Bug #62247: FAL: Uppercase File Extensions of Image cannot be displayed RejectedBenni Mack2014-10-15

Actions
Related to TYPO3 Core - Bug #62400: Lot of entries in sys_file_processed with name=NULL and identifier emptyRejectedAndreas Wolf2014-10-22

Actions
Related to TYPO3 Core - Bug #59216: Image dimensions (width/height) are 0 when not scaledClosed2014-05-30

Actions
Related to TYPO3 Core - Bug #58019: FAL Indexer for broken files: Column 'width' cannot be nullRejected2014-04-17

Actions
Related to TYPO3 Core - Bug #54533: imgResource.noScale doesn't scale image tagRejected

Actions
Related to TYPO3 Core - Bug #50392: Specifying size in ImageViewHelper does nothingClosed2013-07-24

Actions
Related to TYPO3 Core - Bug #44105: Image size does not get updatedClosed2012-12-19

Actions
Related to TYPO3 Core - Bug #45922: image replacement, width and height are kept even i change my imageClosed2013-02-28

Actions
Related to TYPO3 Core - Bug #46446: sys_file doesn't get updatedClosed2013-03-20

Actions
Related to TYPO3 Core - Bug #52658: Overriding image does not change the dimensionsRejected2013-10-10

Actions
Related to FAL Indexing - Bug #60215: sys_file_processedfile with empty identifier and name fieldsUnder ReviewBenni Mack2014-07-09

Actions
Related to TYPO3 Core - Feature #72744: Install Tool should warn about wrong/absent Imagemagick configuration on the tab 'Important actions' Closed2016-01-15

Actions
#1

Updated by Franz Holzinger about 7 years ago

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 .

#2

Updated by Frans Saris about 7 years ago

  • Status changed from New to Needs Feedback

Is the database compare empty or are there still tasks to perform?

Especially interesting are removing columns from the sys_file table.
If I'm not mistaken width and height is moved from sys_file to sys_file_metadata and I expect that these columns aren't removed from sys_file yet

#3

Updated by Franz Holzinger about 7 years ago

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

#4

Updated by Frans Saris about 7 years ago

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

#5

Updated by Frans Saris about 7 years ago

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

#6

Updated by Franz Holzinger about 7 years ago

I have now executed all unchecked (not mandatory) issues in the Database section of the Install Tool. Now there is no issue any more.
However the result remains unchanged.

I did clear also the table cache_imagesizes.

sys_file

Colonne    Type    Null    Défaut     Commentaires
uid     int(11)    Non            
pid     int(11)    Non     0       
tstamp     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       
sha1     tinytext    Oui     NULL       
size     int(11)    Non     0       
creation_date     int(11)    Non     0       
modification_date     int(11)    Non     0       
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    497    A    Non    
sha1    BTREE    Non    Non    sha1 (40)    497    A    Oui    
folder    BTREE    Non    Non    storage    1    A    Non    
folder_hash    497    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    497    A    Non

I have 5 entries for the 2 images in sys_file:

Requête SQL : SELECT * FROM `sys_file` WHERE name LIKE '%Uhr-Waltons.png%'OR name LIKE '%taylor%' LIMIT 0, 25 ;
Lignes : 5
uid     pid     tstamp     type     storage     identifier     extension     mime_type     name     sha1     size     creation_date     modification_date     last_indexed     missing     metadata     identifier_hash     folder_hash
1     0     1371845027     2     0     /uploads/pics/Uhr-Waltons.png    png     image/png     Uhr-Waltons.png    d837d78911a3c03295853570c77aa93414a96c7b    126286     1348084323     1348084323     0     0     0     28ad2e0cf7104ba77284b33be6ad365d33d6a331     32769845128a22b5e8e3c1edc0da85e35185482d
505     0     1408990980     0     1     /user_upload/taylor_swift_1211323728.JPG    jpg         taylor_swift_1211323728.JPG    2867ba372b341c0f8015da8a164daa88d6e56836    58209     1408990980     1408990980     0     0     0     b46b19dbe93c67c561ed472931b11e1a9050bce9     19669f1e02c2f16705ec7587044c66443be70725
506     0     1408991002     0     0     /uploads/pics/taylor_swift_1211323728.JPG    jpg         taylor_swift_1211323728.JPG    2867ba372b341c0f8015da8a164daa88d6e56836    58209     1408991002     1408991002     0     0     0     d7dba0cb3f0b3cd381a9e9ca19f39ea3f5b4cc35     32769845128a22b5e8e3c1edc0da85e35185482d
507     0     1408991071     0     0     /uploads/pics/taylor_swift_1211323728_01.JPG    jpg         taylor_swift_1211323728_01.JPG    2867ba372b341c0f8015da8a164daa88d6e56836    58209     1408991071     1408991071     0     0     0     e50aeacaa3e77adc995f9a045a705734abf33021     32769845128a22b5e8e3c1edc0da85e35185482d
520     0     1409064774     2     1     /user_upload/Uhr-Waltons.png    png     image/png     Uhr-Waltons.png    d837d78911a3c03295853570c77aa93414a96c7b    126286     1409064755     1348084323     0     0     0     b529359a8c7f735730bfbae3fae41147c01068d3     19669f1e02c2f16705ec7587044c66443be70725

I have configured the extension to not use the former "/upload/pics" but to use "fileadmin/user_upload" as the image upload folder.

[franz@localhost ~]$ ls -l /var/www/html/fileadmin/user_upload/
total 324
-rw-r--r-- 1 apache apache  58209 août  26 16:44 taylor_swift_1211323728.JPG
drwxrwxrwx 2 apache apache   4096 août  28 06:34 _temp_/
-rw-rw-r-- 1 apache apache 126286 août  26 19:27 Uhr-Waltons_01.png
-rw-r--r-- 1 franz  live   126286 sept. 19  2012 Uhr-Waltons.png

I get this result for the corresponding entries in sys_file_metadata

Requête SQL : SELECT uid,file, title, width, height FROM `sys_file_metadata` WHERE file IN (1,505,506,507,520) LIMIT 0, 25 ;
Lignes : 5

uid     file     title     width     height
1     1     NULL    299     401
505     505     NULL    0     0
506     506     NULL    0     0
507     507     NULL    0     0
520     520     NULL    299     401

So the width and height is here 0 for the invisible taylor_swift_1211323728.JPG image of the first product. I have tried to add it for several times. However the size has always been zero. This image has been added under TYPO3 6.2. The other image with title 'Uhr-Waltons' has been added in a former version of TYPO3.

#7

Updated by Frans Saris about 7 years ago

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?

#8

Updated by Franz Holzinger about 7 years ago

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')
);

#9

Updated by Frans Saris about 7 years ago

The new file has not meta_data record?

#10

Updated by Franz Holzinger about 7 years ago

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
#11

Updated by Frans Saris about 7 years ago

Does it work now for new uploaded files?

#12

Updated by Franz Holzinger about 7 years ago

The image upload works on the file module. However the image upload does not work in the popup window to assign the image to a product.

http://localhost/typo3/browser.php?mode=file&bparams=data[tt_products][1][image]|||gif,jpg,jpeg,tif,tiff,bmp,pcx,tga,png,pdf,ai|

I have added the new file as a second image of the first product. Now I get the full sized image in the FE. This is the second bug.

#13

Updated by Franz Holzinger about 7 years ago

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    

#14

Updated by Frans Saris about 7 years ago

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?

#15

Updated by Franz Holzinger about 7 years ago

Two bugs are fixed now, if the fields in the Install Tool have been removed. (see attached HTML file). Before I have removed all entries for 'taylor_swift'. Then I have uploaded the image taylor_swift_1211323728.JPG again (http://photobucket.com).

However this is a bad side effect. Why do additional fields of the table sys_file have such a bad influence? This should be changed before a user starts the Filelist module. It is hardly possible to recover from wrong entries with zeros (width=0, height=0).

The main bug still remains. All product images are of full size in the Frontend.

#16

Updated by Frans Saris almost 7 years ago

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

#17

Updated by Franz Holzinger almost 7 years ago

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?

#18

Updated by Frans Saris almost 7 years ago

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

#19

Updated by Franz Holzinger almost 7 years ago

Franz Saris: "The problem you are facing is missing height and width values in sys_file_metadata".

No, this is wrong. I have written this already before (see #61181-10). I am adding the PDF of sys_file_metadata of a second environment where the same error happens.

#20

Updated by Alexander Opitz almost 7 years ago

  • Status changed from Needs Feedback to New
#21

Updated by Frans Saris almost 7 years ago

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

#22

Updated by Franz Holzinger almost 7 years ago

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.

#23

Updated by Frans Saris almost 7 years ago

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

#24

Updated by Franz Holzinger almost 7 years ago

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.

#25

Updated by Frans Saris almost 7 years ago

Normal content elements with images render correct?

I'm not familiar with code of tt_products.

#26

Updated by Frans Saris almost 7 years ago

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

#27

Updated by Franz Holzinger almost 7 years ago

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

#28

Updated by Frans Saris almost 7 years ago

The image tests in install tool give the correct result?

Install -> Test setup

#29

Updated by Franz Holzinger almost 7 years ago

The Install Tool fails with images.


Read jpg
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read gif
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read png
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read tif
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read bmp
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read pcx
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read tga
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read pdf
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Read ai
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Writing gif and png

This verifies that ImageMagick is able to write GIF and PNG files. The GIF-file is attempted compressed with LZW by the \TYPO3\CMS\Core\Utility\GeneralUtility::gif_compress() function.
Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

Image generation failed
ImageMagick / GraphicsMagick handling is enabled, but the execute command returned an error. Please check your settings, especially ['GFX']['im_path'] and ['GFX']['im_path_lzw'].

#30

Updated by Alexander Opitz almost 7 years ago

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

#31

Updated by Franz Holzinger almost 7 years ago

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.

#32

Updated by Alexander Opitz almost 7 years ago

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?

#33

Updated by Franz Holzinger almost 7 years ago

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.

#34

Updated by Alexander Opitz almost 7 years ago

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

#35

Updated by Franz Holzinger almost 7 years ago

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.

#36

Updated by Alexander Opitz almost 7 years ago

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.

#37

Updated by Franz Holzinger almost 7 years ago

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.

#38

Updated by Alexander Opitz almost 7 years ago

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

#39

Updated by Franz Holzinger almost 7 years ago

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.

#40

Updated by Alexander Opitz almost 7 years ago

  • Category set to File Abstraction Layer (FAL)
  • Status changed from New to Rejected

So we only can guess what may or may not happened? It may also possible that it doesn't worked with 6.1 as the images were all in the cache? No chance to get it reproduced?

And after every question you came up with a "new story". Excuse, but I've other things to do.

#41

Updated by Franz Holzinger almost 7 years ago

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.

#42

Updated by Frans Saris almost 7 years ago

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

#43

Updated by Franz Holzinger almost 7 years ago

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

#44

Updated by Frans Saris almost 7 years ago

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

#45

Updated by Mathias Schreiber over 6 years ago

  • Target version set to 7.1 (Cleanup)
  • Sprint Focus set to On Location Sprint
#46

Updated by Anja Leichsenring over 5 years ago

  • Sprint Focus deleted (On Location Sprint)

Also available in: Atom PDF