Bug #60196
closed
FAL resource problem detected -> Umlaut problem although UTF8filesystem is set
0%
Description
Over months this T3 was working flawless. From yesterday to today nothing was changed on server nor in settings.
Opening a tx_news with an attached file with an umlaut in filename results in:
WARNING! FAL resource problem detected. The field "media" has been reset to an empty value in order to prevent fatal, unrecoverable errors. The actual message is a TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException which states: (1320575630) Folder uploads/tx_news/2014-07-07_Verbrauchsg%C3%BCter.jpg does not exist.
- While the file is correct uploaded to uploads/tx_news/2014-07-07_Verbrauchsgüter.jpg in filesystem and the relation in tx_news_domain_model_media is correct utf8
- The file is directly accessible with http://my.domain/uploads/tx_news/2014-07-07_Verbrauchsg%C3%BCter.jpg
- LocalConfiguration.php has
'SYS' => array(
.
.
'UTF8filesystem' => '1',
'systemLocale' => 'de_DE.utf-8',
't3lib_cs_convMethod' => 'mbstring',
't3lib_cs_utils' => 'mbstring',
.
.
)
- Fileadmin
Works without problems on files with umlauts. Thumbs are generated and files are accessible.
- T3 Version
6.1.9 && 6.1.10 tested
- PHP Version
5.5.14 && 5.4.30 tested
No idea where this shall come from. Any help welcome.
Updated by d.ros no-lastname-given over 10 years ago
- T3 Version
6.1.9 && 6.1.10 tested
- PHP Version
5.5.14 && 5.4.30 tested
Does not occour in 6.3.dev git from today
Updated by Stefan Neufeind over 9 years ago
I think I just saw the same thing on 6.2.11. Toggling "UTF8filesystem" to set or not doesn't make a difference when trying to open the filelist in backend. The filesystem is already using utf8. systemLocale is de_DE.utf8, so should be correct as well. Filelist complains that it can't read permissions for a file which has special characters.
Updated by Stefan Neufeind over 9 years ago
Resolved for me on 6.2.11. Turned out that some database-fields were still latin1 although the database-connection was at utf8. After resolving that existing sys_file-records which caused problems also needed to be removed. Files got indexed clean again afterwards for me, no errors anymore.
Updated by Riccardo De Contardi about 9 years ago
- Status changed from New to Needs Feedback
- Assignee set to d.ros no-lastname-given
Hi, sorry for the late answer.
Is the solution proposed by Stefan Neufeind good for you? Can you give us feedback?
Thank you!
Updated by d.ros no-lastname-given about 9 years ago
I answered in #1 that it did not occour in 6.3.git ... and I did not run into this again so far.
Updated by Riccardo De Contardi about 9 years ago
If you agree, then, I'll close it
Updated by Stefan Neufeind about 9 years ago
- Status changed from Needs Feedback to Closed
Seems to be working on 6.2 and later meanwhile. Thanks for the feedback.