Bug #61181
closedFAL: file maxW and maxH are ignored
0%
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
Updated by Franz Holzinger almost 10 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 .
Updated by Frans Saris almost 10 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
Updated by Franz Holzinger almost 10 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
Updated by Frans Saris almost 10 years ago
The sys_file table changes are no recommendations but mandatory. Could you run these changes and try again?
Updated by Frans Saris almost 10 years ago
Are the width and height field of sys_file_metadata set for existing images?
Updated by Franz Holzinger almost 10 years ago
- File 228211-product-list.png 228211-product-list.png added
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.
Updated by Frans Saris almost 10 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?
Updated by Franz Holzinger almost 10 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') );
Updated by Frans Saris almost 10 years ago
The new file has not meta_data record?
Updated by Franz Holzinger almost 10 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
Updated by Frans Saris almost 10 years ago
Does it work now for new uploaded files?
Updated by Franz Holzinger almost 10 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.
Updated by Franz Holzinger almost 10 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
Updated by Frans Saris almost 10 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?
Updated by Franz Holzinger almost 10 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.
Updated by Frans Saris almost 10 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
Updated by Franz Holzinger almost 10 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?
Updated by Frans Saris almost 10 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.
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 years ago
- Status changed from Needs Feedback to New
Updated by Frans Saris almost 10 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
Updated by Franz Holzinger almost 10 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.
Updated by Frans Saris almost 10 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
Updated by Franz Holzinger almost 10 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.
Updated by Frans Saris almost 10 years ago
Normal content elements with images render correct?
I'm not familiar with code of tt_products.
Updated by Frans Saris almost 10 years ago
And in the bachend the preview/thumbnails are resized correct?
Updated by Franz Holzinger almost 10 years ago
The TYPO3 backend in TYPO3 6.2 is broken: No image icons are shown. TCE shows an empty image.
Updated by Frans Saris almost 10 years ago
The image tests in install tool give the correct result?
Install -> Test setup
Updated by Franz Holzinger almost 10 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'].
Updated by Alexander Opitz almost 10 years ago
So, you have your error or the issue behind your real problem. Fix the path to your image/graphics magic.
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 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?
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 years ago
So how should it have working with TYPO3 CMS 6.1 if there was no GraphicsMagic installed?
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 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.
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 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!"
Updated by Franz Holzinger almost 10 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.
Updated by Alexander Opitz almost 10 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.
Updated by Franz Holzinger almost 10 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.
Updated by Frans Saris almost 10 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
Updated by Franz Holzinger over 9 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_.
Updated by Frans Saris over 9 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
Updated by Mathias Schreiber over 9 years ago
- Target version set to 7.1 (Cleanup)
- Sprint Focus set to On Location Sprint
Updated by Anja Leichsenring over 8 years ago
- Sprint Focus deleted (
On Location Sprint)