If a local file storage is outside the document root, images are sometimes not shown if multiple images are on a page.
This possibility was introduced with this patcheset: https://review.typo3.org/#/c/27760/
If there are many (5-10) images on a page, some of them are not shown. Maybe it is a concurrency-issue, it happens with apache and mod_php.
#2 Updated by Jost Baron over 5 years ago
I can't identify a definite error message in the log, only two candidates:
[error] [client x.y.z.w] PHP Catchable fatal error: Argument 1 passed to TYPO3\\CMS\\Core\\Utility\\ArrayUtility::setValueByPath() must be an array, integer given, called in /.../typo3_src-6.2.4/typo3/sysext/core/Classes/Configuration/ConfigurationManager.php on line 202 and defined in /.../typo3_src-6.2.4/typo3/sysext/core/Classes/Utility/ArrayUtility.php on line 176, referer: [...] [notice] child pid 8662 exit signal Bus error (7)
The used PHP-Version is the one that comes with the latest Ubuntu 12.04 LTS as mod_php.
In the frontend, there was only an empty space where the image should be - when viewing the image info, the image file was small (2 Bytes or something).
Sorry for the vague info, can't reproduce this anymore, since I've fixed it by moving the fileadmin into the document root.
#3 Updated by Jost Baron over 5 years ago
I've looked a bit more into this, it also happens in a fcgid-setup.
The problem is that the
$localconfiguration retrieved in line 201 of
TYPO3\CMS\Core\Configuration\ConfigurationManager is invalid. It is the integer 1. Thus the error message posted above.
The above two error messages are sometimes accompanied by this one:
[fcgid:warn] [pid 24055] [client 127.0.0.1:52844] mod_fcgid: stderr: PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'LocalConfiguration invalid.' in [...]/typo3_src-6.2.4/typo3/sysext/core/Classes/Configuration/ConfigurationManager.php:276, referer: [...]
So if I had to do a wild guess, I'd say that the LocalConfiguration is rewritten by each of the requests to an image (can confirm that), and locking does not work (maybe because its an eID script?). But I have no idea how to check if this is the actual reason, and how to fix it.
Also, some more info on my setup (had to rebuild it):
1. There is a folder "fileadmin" outside the document root
2. That folder is linked with a symlink in the document root, since otherwise TypoScript templates are not found and the install tool complains.
3. The storage record is non-hidden, has an absolute path, uses case sensitive paths, is set as default storage, the folder for temporary files is not set, is searchable, is writable, is online, but is not public. Setting it to public results in TYPO3 complaining and setting it non-public again.
4. The whole installation was updated from 4.2.
#4 Updated by Markus Klein over 5 years ago
[notice] child pid 8662 exit signal Bus error (7)
This is very weird, so there is a server problem as well.
Never heard that LocalConfiguration is rewritten all the time.
Having the storage non-public does not make sense from what you wrote.
What is the URL of the not working image?
#5 Updated by Jost Baron over 5 years ago
The image URI is
I've looked again, when accessing the above URL the
LocalConfiguration.php is at least touched, the last modification time changes. I've made sure nothing else (like the AJAX-requests from the Backend) is requesting something. I do have an
AdditionalConfiguration.php-file, but its last modification was 10 days ago.
#7 Updated by Jost Baron over 5 years ago
I see the correct image (always, but especially for the images that did not work when embedded into the page).
Also, the non-working images on a single page change with each request, seemingly at random. It does not matter if the images are cached (TYPO3 returns a 304 code) or if the images are really transferred. The response for the not working images a HTTP 500.
#10 Updated by Jost Baron over 5 years ago
There are no more error messages, only one I have not posted yet is this one:
[Wed Jul 23 21:11:58.037103 2014] [fcgid:warn] [pid 31189] (104)Connection reset by peer: [client 127.0.0.1:53970] mod_fcgid: error reading data from FastCGI server, referer: [...] [Wed Jul 23 21:11:58.037190 2014] [core:error] [pid 31189] [client 127.0.0.1:53970] End of script output before headers: index.php, referer: [...]
But thats only the fcgid-equivalent of the one above with the bus error.
AdditionalConfiguration.php contains this:
ServerspecificConfiguration.php contains this (or something similar):
<?php use \TYPO3\CMS\Core\Configuration\ConfigurationManager; ConfigurationManager::setLocalConfigurationValueByPath('DB/database', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('DB/host', 'localhost'); ConfigurationManager::setLocalConfigurationValueByPath('DB/password', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('DB/username', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('GFX/colorspace', 'RGB'); ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_server', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_username', 'foobar'); ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_password', ''); ConfigurationManager::setLocalConfigurationValueByPath('MAIL/transport_smtp_encrypt', ''); ConfigurationManager::setLocalConfigurationValueByPath('SYS/enableDeprecationLog', 'file');
#11 Updated by Markus Klein over 5 years ago
Ok, here we come closer to the problem why your LocalConfiguration file is rewritten all the time.
ConfigurationManager::setLocalConfigurationValueByPath() rewrites the file on EVERY call!
What you want to do is actually:
$GLOBALS['TYPO3_CONF_VARS']['DB']['database'] = 'foobar'; $GLOBALS['TYPO3_CONF_VARS']['DB']['host'] = 'host'; ...
You do not want to persist this configuration, you just want to override it.
Keep in mind that the LocalConfiguration is cached and may not always be read from the file, only the AdditionalConfiguration is read everytime.
#12 Updated by Jost Baron over 5 years ago
Ok, this has solved the problem. Thanks for your time!
Shouldn't the LocalConfiguration.php be protected against concurrent write access, in case someone does a thing like I did? In that case a performance hit would occur since requests become serialized, but there would not be any random failures.
#13 Updated by Markus Klein over 5 years ago
- Status changed from New to Closed
Well, there should never be a situation where one might trigger two requests in parallel that modify the LocalConfiguration file.
Moreover locking at this low level is really tough and generally there is no clean locking mechanism for PHP that works everywhere.
So my answer is, No.