TYPO3 Core

I can confirm, that we are experiencing the same problem. Having said that, our initial tests show that it seems that this occurs only, if EXT:gridelements is installed. We can not reproduce the problem on a fresh, clean 6.2.x instance - but as soon as we install EXT:gridelements (in our case, it is version 3.0.0), we see the issue.

@Markus Klösges: are you using EXT:gridelements, too? If so, I am happy to report this as an issue at EXT:gridelements.

Note: also see discussion in German TYPO3 forum (started by Markus)

@Markus Klösges: are you using EXT:gridelements, too? If so, I am happy to report this as an issue at EXT:gridelements.

No, EXT:gridelements is not installed in both installations. These are older ones using EXT:TemplaVoila. Maybe both extensions put Elements in colPos=-1 to display them only nested in other Elements?
I'm not sure how to test against this... Any Ideas?

I get the same issue on a clean install of 6.2.7

• create a text element with a link to a file in RTE
• publish workspace item
• edit content element (add text or something)
• publish updated element
• change content element: remove filelink.
• publish updated content element.

References in filelist now show 2 references.
The references are (inactive) workspace versions.
Impossible to delete file.

Eva: how "clean" is your 6.2 instance? Do you mean, you installed TYPO3 CMS and have not added any extensions, no TypoScript code, no additional BE users, nothing? Is it really absolutely clean?

We see this issue on one of our client's sites but we are unable to reproduce this on our test server with a really clean instance (nothing configured yet). Having said this, yes, I agree, the number of references in the Filelist looks weird (but possibly makes sense, if you push a change from one workspace to another, because then you might have two instances of the record).

Very clean: downloaded and installed TYPO3 6.2. No extensions, config or introduction package.

Indeed - a very clean install is sufficient to get this behaviour. I have just done:

- Download typo3_src-6.2.7.tar.gz from typo3.org
 - Untar
 - set up new vHost
 - ln -s ../typo3_sources/typo3_src-6.2.7 typo3_src
 - ln -s typo3_src/index.php index.php
 - ln -s typo3_src/typo3 typo3
 - chown apache:apache . -R
 - touch FIRST_INSTALL

- run Install-Wizzard - No Distribution installed.

- go to Extension Manager and install workspaces
 - create a new Workspace 'testWorkspace' on Root-Level with admin as owner and RootPage as Mount Point
 - Upload a .jpg to fileadmin
 - Create a Page 'LandingPage'
 - Insert a ContentElement Text&Images in Column 'Normal' in LIVE-Workspace with uploaded .jpg attached
 => Now FileReference Count in Fileadmin shows 1 Reference - as Expected.
 - Change to Workspace 'testWorkspace'
 - Edit ContentElement and remove Image-Reference
 => Now FileReferenceCount in Fileadmin shows 3 References - not as expected but would be ok since its not published yet.
 - Publish Workspace Version to 'Live'
 => Now FileReferenceCout in Fileadmin shows 1 Reference - not as expected, the file isn't referenced anywhere.
 ==> unable to delete File.

I hope this will help to fix that or to point someone in direction...

Edit:
The records in 'sys_file_reference' are marked as 'deleted'=1. Maybe this isn't handled properly?
If this is set to deleted in that cases, one could delete a file in question if all file_references are 'deleted'?!
Edit2:
Updating the reference-index works in this circumstance. In the live system it doesn't, so we have diffrent cases here. But I think the ref-index should stay consistent and it should not be necessarry to run 'update Ref-index'.

We tested this issue carefully and were able to figure out some more details.
This problem is reproducible (see issue #64253 for detailed step-by-step instructions how).

Hello,

we are probably experiencing the same problem concerning FAL / workflow. Until a fix is available, what can we do as workaround? Updating reference index was mentioned, but the problem is still reproducable on our site after updating ref index. The lowlevel_cleaner was mentioned. How exactly did you run it?

I also have a general question concerning bugfix and update procedure: For quite a fix bugs, the target version has been set to 7.x. Does this mean, that a fix for 6.2 will not be available?

TIA

Sybille

Sybille Peters wrote:

Hello,

we are probably experiencing the same problem concerning FAL / workflow. Until a fix is available, what can we do as workaround? Updating reference index was mentioned, but the problem is still reproducable on our site after updating ref index. The lowlevel_cleaner was mentioned. How exactly did you run it?

as I didn't have ssh-access to the machine running the installation I wrote some php-wrappers to get the scripts running. The cleanup-script itself lies in typo3 directory and a 'help' message is displayed like this (from commandline)
typo3/cli_dispatch.phpsh lowlevel_cleaner --showhowto

to use this I did some custom and quickAndDirty script like this:
exec("/usr/bin/php53 /[absolutePathToTypo3]/typo3/cli_dispatch.phpsh lowlevel_cleaner --showhowto 2>&1", $ausgabe, $return);
foreach ($ausgabe as $line)
echo "<p>$line</p>";

echo "Return Value:$return\n";
?>
WARNING: I do not know what can happen if you do this with wrong parameters or even like this on your machine. Always have a backup and Do NOT leave such scripts on the server. Better do all this stuff under .htaccess or sth like that. That's only some ugly workaround.

Then i changed the commands as the 'showhowto' said (in "SUGGESTED ORDER OF CLEAN UP"). I think after versions everything worked again.

I also have a general question concerning bugfix and update procedure: For quite a fix bugs, the target version has been set to 7.x. Does this mean, that a fix for 6.2 will not be available?

Generally it means that the bugs will be fixed in some 7.* versions first. After that they may be back-ported to 6.*

A patch for that problem is on the way in #64253 and (I hope) will be backported to 6.2 also because its really annoying.

Thank you for the information. We can run the lowlevel cleaner directly from the shell (which I think is also recommended, might get PHP timeouts otherwise). I was just wondering which of the many toolkeys you used:

typo3/cli_dispatch.phpsh lowlevel_cleaner
...
missing_files
missing_relations
double_files
rte_images
lost_files
orphan_records
deleted
versions
cleanflexform
syslog

deleted? and then update ref index? ...?

Sybille Peters wrote:

Thank you for the information. We can run the lowlevel cleaner directly from the shell (which I think is also recommended, might get PHP timeouts otherwise). I was just wondering which of the many toolkeys you used:

definitely recommended to do it that way - yes.

I just went allong as the script says

So
orphan_records
versions

update refindex and that solved it for me.
You could go further in 'Suggested order of cleanup' but that fixed it for me.

Is there an update for this issue? We can still reproduce this in 9.5.6 with a blank installation.

The frontend is not affected from this, since only images in the "LIVE"-Workspace are rendered. In the backend, however, are all images are shown regardless of its workspace.

This is a problem in particular when the FAL-Field has a limit because the user is unable to change the image until the draft-Workspace is published.

Patch https://review.typo3.org/c/Packages/TYPO3.CMS/+/65510 fixes one of the two issues: Deleting an image in workspaces will now reset the usage count to 0 instead of 1. The other issue is that adding an image in workspaces counts as two relations. This will be tackled with another patch / issues that will be related to this one here, then.

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65510

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65510

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65510

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65628

Patch set 2 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65628