Bug #19088
closedincorrect versioning of images in flexform fields
0%
Description
I use workspaces and templavoila in a project. I created a new workspace called "internal" and for editing 2 be-users. The first one is a standard user who only can change the content in the "internal" workspace. The second user can publish all the changes to the live workspace.
In the head of the website there is a main visual. This image is defined in the datastructure and is set into the flexform field of the page-table.
The error occurs, if there are made changes in a content-element or if there is inserted a new content-lement inside of a page which isn't instantiated yet. Typo3 generates a new instance of the page and the containing content-elements. but the image in the flexform field of the page is broken.
In the backend i get an error message from the filemtime()-function:
###
Warning: filemtime() [function.filemtime]: stat failed for /var/www/test/t3-project/htdocs/uploads/tx_templavoila//var/www/test/t3-project/htdocs/uploads/tx_templavoila/mainvisual.jpg in /var/www/share/cms/typo3/typo3_src-4.2.1/t3lib/class.t3lib_befunc.php on line 1722
###
In the fronend of this workspace, there is no image shown. As you can see the backend path to the image is dublicated.
If i look inside the flexform field, there is the complete path to the image inside of it. But there has to be only the filname!
Inside of the class tcemain i found a comment from casper:
###
Traverse the input values and convert to absolute filenames in case the update happens to an autoVersionized record.
Background: This is a horrible workaround! The problem is that when a record is auto-versionized the files of the record get copied and therefore get new names which is overridden with the names from the original record in the incoming data meaning both lost files and double-references!
The only solution I could come up with (except removing support for managing files when autoversioning) was to convert all relative files to absolute names so they are copied again (and existing files deleted). This should keep references intact but means that some files are copied, then deleted after being copied again.
Actually, the same problem applies to database references in case auto-versioning would include sub-records since in such a case references are remapped - and they would be overridden due to the same principle then.
Illustration of the problem comes here:
We have a record 123 with a file logo.gif. We open and edit the files header in a workspace. So a new version is automatically made.
The versions uid is 456 and the file is copied to "logo_01.gif". But the form data that we sent was based on uid 123 and hence contains the filename "logo.gif" from the original.
The file management code below will do two things: First it will blindly accept "logo.gif" as a file attached to the record (thus creating a double reference) and secondly it will find that "logo_01.gif" was not in the incoming filelist and therefore should be deleted.
If we prefix the incoming file "logo.gif" with its absolute path it will be seen as a new file added. Thus it will be copied to "logo_02.gif". "logo_01.gif" will still be deleted but since the files are the same the difference is zero - only more processing and file copying for no reason. But it will work.
###
So that means to me, the file gets the full path and will be instantiated. But afterwards inside the flexform field there is only the filename and in the filesystem there is a new file which is called mainvisual_02.jpg.
But in my case that doesnt' work. There is no new image in the filesystem and inside of the flexform field there is the full path!
(issue imported from #M8946)
Files
Updated by Administrator Admin about 16 years ago
Somehow the same problem turned up on one of my sites, after i've cleared all the backendcache via ftp account. before, the update went well, i used to change several things and everything was shown verywell in FE.
After that, i tried to downgrade the typo-compatibility-version and this didn't success...
Updated by Tolleiv Nietsch over 13 years ago
- Status changed from New to Closed
- Target version deleted (
0)
Assuming this was a one-time-only issue, I never saw this popping up. Feel free to reopen issue if my assumption was wrong.
Updated by Michael Stucki almost 11 years ago
- Project changed from 624 to TYPO3 Core
- Category changed from Workspaces to Workspaces