Bug #57565
Creating new sys_file_metadata record for existing sys_file record doesn't set image dimensions
| Status: | Closed | Start date: | 2014-04-02 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | File Abstraction Layer (FAL) | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 6.2 | Is Regression: | No | |
| PHP Version: | 5.4 | Sprint Focus: | ||
| Complexity: |
Description
Given the presence of a sys_file record with no related sys_file_reference_record
When I am in the metadata "Edit" dialog in the filelist module
The missing sys_file_metadata record will be autocreated
But: (at least) the fields "width" and "height" are not written, which is quite deadly for the f:image ViewHelper
While this might sound like a special case of database inconsistency, it actually seems to be the default case when upgrading from 6.0 or 6.1
Might be related to #44105 et al.
Related issues
History
#1 Updated by Alexander Opitz over 1 year ago
"While this might sound like a special case of database inconsistency, it actually seems to be the default case when upgrading from 6.0 or 6.1"
Did you run the migration wizards? Course this shouldn't be the case if you upgrade from 6.0/6.1.
Updating TYPO3 before 6.0 had an issue, which was solved today with #46020.
The issue behind the auto creation with empty values is #57545. I would like to concentrate me on your upgrade problem in this issue.
#2 Updated by Bernhard Schmitt over 1 year ago
Yep, I ran the migration wizards. One step stated the splitting and creation of FAL stuff, so I didn't skip on that.
Actually, the sys_file_metadata table seemed to be completely populated with records, but they were empty except for the references to sys_file
#3 Updated by Alexander Opitz over 1 year ago
- Status changed from New to Accepted
Ok, we will take a look into this. Can you tell me, which TYPO3 version do you tried to update? And maybe some lines from the sys_file table before migration?
If we found an issue there, do you have the possibility to migrate again with fixed code?
#4 Updated by Bernhard Schmitt over 1 year ago
- File sys_file_export.sql added
Old version was 6.1.5
File records are attached
Migration can be re-done, no problem.
#5 Updated by Alexander Opitz over 1 year ago
Thanks for help, hopefully I have time tomorrow to take a look. The SQL snippet seams to be correct.
#6 Updated by Alexander Opitz over 1 year ago
Hi Bernhard,
I couldn't reproduce this issue, so I need some more information:
Dump of the SQL Structure of the sys_file before migration.
Dump of the SQL Structure of the sys_file_metadata after migration.
The FileTableSplittingUpdate wizard takes all data from sys_file and inserts them into sys_file_metadata in one SQL Statement. I don't think that there is an error, but maybe the table structure has issues.
One possibility in my mind, did you start the "Database analyzer" before migration?
#7 Updated by Bernhard Schmitt about 1 year ago
I've tested this again with 6.2.3 including running the complete set of install tool upgrade wizards and scheduler tasks and there seem to be no further problems regarding image dimensions.
#8 Updated by Markus Klein about 1 year ago
- Status changed from Accepted to Needs Feedback
Please test again, once 6.2.4 is released.
#9 Updated by Markus Klein about 1 year ago
- Status changed from Needs Feedback to Closed
Correction. Closing this as it seems resolved.