Bug #92738
closed
Page not visible in Pagetree when field "t3ver_oid" > 0
Added by Torben Hansen over 3 years ago.
Updated about 3 years ago.
Description
While migrating a TYPO3 website from TYPO3 8.7 to 10.4 I faced the situation, that pages, which were visible in the pagetree in TYPO3 8.7 and 9.5 suddenly disappeared in TYPO3 10.4. Affected pages were also not shown in frontend menus of the website.
I debugged this down and it came out, that affected pages had some "leftovers" from a previously usage of ext:workspaces. The website did use workspaces for many years ago, but the extension is not installed / active currently.
The problem is pretty easy to reproduce in TYPO3 10.4
1) Make sure ext:workspaces is not active
2) Create a page in the pagetree
3) Edit the field "t3ver_oid" in the database and set it to a value greater than 1 (e.g. the uid of the current record)
4) The page disappears from the pagetree, but gets visible when you search for the uid in the pagetree search
Although this may be an edgecase, I think ext:workspace related fields should only be considered when the extension is active.
I have the same problem during a 6.2 -> 10.4 migration with workspace used.
In 10.4, i have some pages hidden in the page tree, but visible when doing a live tree search. In my case, workspace is loaded.
If i change t3ver_oid to 0, the pages are correctly shown.
Fields of workspace have not changed since the 6.2, so it is not a migration problem (apparently).
Just for the records:
If the TYPO3 website does not use workspaces any more, the problem can be fixed by executing the following SQL Query: UPDATE `pages` SET `t3ver_oid` = '0'
- Status changed from New to Needs Feedback
Dear Torben,
this is related to our change in TYPO3 v10 that we removed "pid=-1", so pages with t3ver_oid>0 need to point to a live-record (previously we also had pid=-1 to identify non-live records). In your case you have versioned records but you don't have EXT:workspaces active, so TYPO3 is not even trying to query t3ver_oid>0 records.
There are a few CLI commands (in EXT:lowlevel) to identify such records, but in the case where you have "old" workspace records, your workaround seems fine.
Such cases are really hard to tackle as we don't now the history of such sites, what do you suggest?
Thanks a lot for the explanation about the described behavior. I agree that such cases are really hard to tackle, so I suggest we close the ticket for now, since a solution on how to fix the issue for websites with "old" workspace records is documented here.
- Status changed from Needs Feedback to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by