TYPO3 Core

I can confirm.

Reproduced like this:

1. Uncheck all checkboxes in user group > Access Lists > Page types [pagetypes_select]
2. switch user to user in this group
3. I get spinner ...

i can confirm this. But resetting backend unser preferences solves the issue, so it seams something in the user preferences is causing the issue.

In maintenance the backend user settings of all users can be reset.

Peter Wimmer wrote:

i can confirm this. But resetting backend unser preferences solves the issue, so it seams something in the user preferences is causing the issue.

In maintenance the backend user settings of all users can be reset.

Reseting the backend unser preferences does not help in my case.... :-(

I had also a missing page tree when updating to 9.5.20 - with message "Page tree error - 500 Internal Server Error". But this problem is already a little bit older, see #91407. Resetting the backend user preferences helps in this case, even better is the wizard "Update backend user configuration array" in the backend upgrade module.

This issue is not related to serialization, thus removing the reference to #91407.
It seems this issue has been introduced recently with #88943 in https://review.typo3.org/c/Packages/TYPO3.CMS/+/65027

I can confirm this as well.

We are not providing the drag and drop feature for new pages to our clients and we have the same errors in the browsers.All pages are deleted from the D&D using the TSconfig feature options.pageTree.doktypesToShowInNewPageDragArea

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

Tested and solved the two described problems in my TYPO3 9.5.20 installations

ok, I just had to adapt the fourth TYPO3 installation, because this error occured in our system. A downgrade is not possible due to security reasons.
Is there currently a workaround how I can fix the bug without changing the core? Otherwise I find it a bit difficult to delay the editors until the next patch level, is there a date for that?

Best Regards
Sven

Sven Juergens wrote:

ok, I just had to adapt the fourth TYPO3 installation, because this error occured in our system. A downgrade is not possible due to security reasons.
Is there currently a workaround how I can fix the bug without changing the core? Otherwise I find it a bit difficult to delay the editors until the next patch level, is there a date for that?

Best Regards
Sven

• the original changes introduced with v9.5.20 and v10.4.6 were reverted in v9 and v10 Git branches (mid August 2020)
• the reverted change was revised and merged again https://review.typo3.org/q/I2691c531b419398325989070c375a9ec0d08ae82 (August 17th, 2020)
• there are still a couple of new regressions that have not been tackled yet → see https://forge.typo3.org/issues/92091

Hello, Oliver,
thanks for your information.
From a pure user point of view it is a bit difficult.
There was a security update for TYPO3, which included another bug. A bug which was unfortunately so big that some editors can't use TYPO3 anymore. So a published stable TYPO3 version is not usable under certain circumstances. A downgrade is not possible. As an affected user you have no other choice than to apply patches or to change to a git version of TYPO3, because you cannot use the current stable version. I am still a big fan of TYPO3 and I can understand many necessities, but especially the last updates were always a bit difficult. But then came at least a short time later RegressionUpdates, so at least a stable version was available online on get.typo3.org.

Sven Juergens wrote:

Hello, Oliver,
thanks for your information.
From a pure user point of view it is a bit difficult.
There was a security update for TYPO3, which included another bug. A bug which was unfortunately so big that some editors can't use TYPO3 anymore. So a published stable TYPO3 version is not usable under certain circumstances. A downgrade is not possible. As an affected user you have no other choice than to apply patches or to change to a git version of TYPO3, because you cannot use the current stable version. I am still a big fan of TYPO3 and I can understand many necessities, but especially the last updates were always a bit difficult. But then came at least a short time later RegressionUpdates, so at least a stable version was available online on get.typo3.org.

I totally understand the point and implications, but don't have any other solution for this.
For the change in the page tree that was causing these issues lots of people have been involved reviewing and testing the change. The consequences of your statements would be not to trust those reviewers and the community anymore.

Currently we only can to combined security and patch level releases - thus, there's always a risk a some bug fix introduced a new bug fix. The only alternative would be to publish standalone security versions, e.g.

• last regular release TYPO3 v9.5.19
• security release, only containing security fix, but no other fixes
  • create new branch 9.5.19.x based on tag v9.5.19
  • apply security changes to 9.5.19.x branch and to regular 9.5 branch
  • create v9.5.19.1 security only release from 9.5.19.x branch
  • create v9.5.20 security and bug fix release from 9.5 branch
• regressions then again would have to be fixed in both 9.5.19.x and 9.5 branches
  • leads to v9.5.19.2 regression fixes for 9.5.19.1
  • leads to v9.5.21 regression fixes for 9.5.20

Thus, instead of currently releasing two versions (for 9.5 and 10.4) we would then have to release four versions (9.5.19.1, 9.5.20, 10.4.a.1, 10.4.a+1). Basically all processed would have to be adjusted - Git, review.typo3.org, get.typo3.org, maintenance pages & content, bamboo.typo3.com, Travis CI, ... any other tools being involved here.

In general it currently would help if people were using the existing 9.5 and 10.4 dev-branches(!) in their sites under development.

In general it currently would help if people were using the existing 9.5 and 10.4 dev-branches(!) in their sites under development.

I think that is a very good suggestion. I had not thought of that. I will change some of my dev + test sites to use latest versions of the core from git.

Incidentally, I was one of the reviewers of the patch that initially caused the problem. I did feel bad about the mess, but the patch did not cause any problems on my site and I have been happily using it since. Actually it fixed a big and annoying problem of page tree performance which made the page tree almost unusable for admins. So, you see it is not always easy to detect all possible error cases in advance. The core contributors are already doing a lot, e.g. by adding tests etc.

I think it would help a lot if more people reviewed and tested the patches on Gerrit and did use latest versions of core from git on test and dev servers.