Bug #58889
closed
Checksum in generated images changes
0%
Description
Hi guys,
this is my first post in forge, so please correct me if any further information is missing or I just did not found the according issue.
I have a problem with image generation in 6.1.8:
Some images change the filename (sometimes) after clearing the cache - more concrete the shortmd5-checksum changes for a reason.
The problem is that filenames don't stay consistent which is quite bad for pages which are sent as newsletters. In case this happens the filename changes, but the image itself is not generated. After reloading the page and clearing the cache it works again. Usually the filename changes between two versions but causes that images do not appear on the website.
The page was migrated from 4.x. Mostly the image generation problem occurs with elements which are not using FAL (tt_news).
e.g.
data getChecksumData(): array(3) {
[0]=>
string(4) "7356"
[1]=>
string(19) "Image.CropScaleMask"
[2]=>
string(204) "a:9:{s:5:"width";s:4:"250c";s:6:"height";s:4:"200c";s:13:"fileExtension";N;s:8:"maxWidth";i:250;s:9:"maxHeight";i:200;s:8:"minWidth";i:0;s:9:"minHeight";i:0;s:7:"noScale";N;s:20:"additionalParameters";N;}"
}
checksum getConfigurationChecksum(): 78dee28c78
data getChecksumData(): array(3) {
[0]=>
string(4) "7356"
[1]=>
string(19) "Image.CropScaleMask"
[2]=>
string(204) "a:9:{s:5:"width";s:4:"250c";s:6:"height";s:4:"200c";s:13:"fileExtension";N;s:8:"maxWidth";i:250;s:9:"maxHeight";i:200;s:8:"minWidth";i:0;s:9:"minHeight";i:0;s:7:"noScale";N;s:20:"additionalParameters";N;}"
}
checksum getConfigurationChecksum(): fafdab6470
What can cause such a behaviour? Any hint what the problem could be?
Opcache has already been disabled.
Regards,
Karin
Files
Updated by Karin Feichtner almost 10 years ago
The example image uses storage 1, there are other images with same filename and same content with storage 0 (but not uid 7356).
There are also two languages on the website.
Maybe these facts are related to the issue, that the checksum is available in two variants. Unfortunately I cannot reproduce the problem properly but it occurs several times a day - error logfile with images not available is a good ressource.
Regards,
Karin
Updated by Karin Feichtner almost 10 years ago
- File empty-entries-sys-file-proc.jpg empty-entries-sys-file-proc.jpg added
- Assignee deleted (
Markus Klein)
Tried to clear typo3temp/_processed and also database table sys_file_processed but did not help. But I recognized that there are a lot of empty entries in sys_file_processed table. Is this normal?
Updated by Markus Klein almost 10 years ago
Hi Karin,
don't know if the empty columns in sys_file_processed table may cause problems.
But a question to your getChecksumData() array given above. Is this the result of AbstractGraphicalTask::getChecksumData() or AbstractTask::getChecksumData().
If this is the result of AbstractGraphicalTask::getChecksumData() it is a) impossible that you get different md5 hashes b) I'm missing a fourth array element.
So I guess this is the output of AbstractTask::getChecksumData().
Updated by Karin Feichtner almost 10 years ago
Hi Markus,
sorry forgot to mention, output is from AbstractTask::getChecksumData() which generates the filename of the processed images as far as I noticed.
Updated by Markus Klein almost 10 years ago
Ok, but the checksum is calculated from the output of AbstractGraphicalTask::getChecksumData(), which adds the serialized $GLOBAL['TYPO3_CONF_VARS']['GFX'] array to the array returned by AbstractTask::getChecksumData().
So the only reason why the hash changes is, that $GLOBAL['TYPO3_CONF_VARS']['GFX'] changes, maybe try to debug why that happens.
Updated by Karin Feichtner almost 10 years ago
Thanks a lot for the helpful hint.
The behaviour occurs if a GFX setting is defined more than once with different values, e.g. in LocalConfiguration (where it should be) and overwritten in another individual extension.
Topic can be closed please.
Updated by Markus Klein almost 10 years ago
Interesting. The question arises why those settings from the extension are not always applied?
Updated by Markus Klein almost 10 years ago
- Status changed from New to Needs Feedback
Updated by Karin Feichtner almost 10 years ago
Hi,
image checksum problems only occured where this individual extension was involved.
Difference was in jpg_quality setting:
"jpg_quality";i:100 (set in extension)
"jpg_quality";s:2:"85" (set in localconfiguration via install tool)
I cannot reproduce when exactly it occured. I discovered it mostly as soon as editors made changes, while switching languages or generating pages uncached with no_cache parameter - but only sometimes. So something related with caching - maybe sometimes the ext_tables of the extension was loaded before localconfiguration and sometimes afterwards - for whatever reason? Unfortunately I know not much about core functionality in detail.
Regards,
Karin
Updated by Markus Klein almost 10 years ago
LocoalConfiguration is always loaded first.
Is this configuration overwritten in ext_tables or ext_localconf? I would suggest to put this inline into ext_localconf.
Updated by Markus Klein almost 10 years ago
- Category deleted (
File Abstraction Layer (FAL))
Updated by Karin Feichtner almost 10 years ago
Configuration was in ext_tables but in fact it is not necessary. I just took over the website and removed it now.
I also tested to put it in ext_localconf and did not discover any problems - the overwriting configuration of ext_localconf was taken in all cases. Thanks for your help.
Updated by Markus Klein almost 10 years ago
- Status changed from Needs Feedback to Closed
Thanks for checking this, so it is not a Core bug. The setting was just in the wrong file.
Closing this ticket now.
Cheers