Project

General

Profile

Actions

Bug #90436

open

Some weird behaviour with autogenerated site config

Added by Christian Eßl almost 5 years ago. Updated 4 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
-
Start date:
2020-02-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Preset:
We already have an existing page root "Root A".

Step 1
Now create a new Page root "Root B".
TYPO3 will now automatically generate new site config in the format "autogenerated-96-26657d5ff9".
The page has the checkbox "is_siteroot" NOT checked.

Step 2
Move the page "Root B" somewhere inside "Root A" to make it a part of its page tree.

If you now visit the Site config module, the autogenerated site config will be now marked as unassigned.
But if you open the page in the pages module, it will still have its site config for "autogenerated-96-26657d5ff9" assigned, which can lead to many bugs.

Examples:

- My site config for "Root A" allows for translations, but I can't translate the page "Root B", as the autogenerated site config has no other languages than "Default".
- If I open the page with the "view" button, the url will look something like "https://typo3.ddev.site/autogenerated-96/en/root-b"

My conclusions:
- Autogenerated site configs should only be created, if you create a page set with "is_siteroot" to true.
- If I delete a root page, its autogenerated (!) site config should be deleted as well.
- It's weird, that the Site config module shows the site config as "unassigned", but it is actually loaded in several places, as can be seen from the behaviour. My understanding was, that a page would need to have "is_siteroot" set, but that is apparently not the case?


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #89311: Flaws in site configuration when creating new page on root-levelRejected2019-09-30

Actions
Related to TYPO3 Core - Bug #93423: wrong https in slug of one pageClosed2021-02-03

Actions
Related to TYPO3 Core - Feature #89142: Create sites when a page in generated on root levelClosed2019-09-11

Actions
Actions #1

Updated by Christian Eßl almost 5 years ago

  • Description updated (diff)
Actions #2

Updated by Christian Eßl almost 5 years ago

  • Description updated (diff)
Actions #3

Updated by Christian Eßl almost 5 years ago

  • Related to Bug #89311: Flaws in site configuration when creating new page on root-level added
Actions #4

Updated by Christian Eßl almost 5 years ago

Looked into it, how the Site module determines, which site config is "assigned" and which is "unassigned".

It gets $allSites in SiteConfigurationController::getAllSitePages(), that either are pid=0 and no sysfolder or have is_siteroot=1.
It then iterates through all site configs it can find and checks, if the site config matches a site in $allSites.

This is_siteroot=1 check however is NOT present in the actual code, that loads in site config, when used in backend editing, frontend, etc. (See description above)
So a site config can be seen as "unassigned" in the site config module, but be actually in use.

Actions #5

Updated by Christian Eßl over 4 years ago

Another problem with autogenerated sites.

- Create as Page "Redirects Test" on pid= 0 (an autogenerated site will be generated)
- Move the page into another page tree
- The autogenerated site is now marked as inactive, but stays there
- Hide the page "Redirects Test"
- Now create a Redirect from this pages slug to another page

Calling the redirects source url will now trigger an error:

Argument 1 passed to TYPO3\CMS\Frontend\Controller\ErrorController::pageNotFoundAction() must implement interface Psr\Http\Message\ServerRequestInterface, null given, called in /var/www/html/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php on line 1372

Apparently the site config of the autogenerated, inaccessible site config was loaded. Then the pageNotFoundAction was called with $GLOBALS['TYPO3_REQUEST'], which was NULL.

Actions #6

Updated by Christian Eßl over 4 years ago

As far as I see, the autogenerating of site configs and "leaving them there", once you, for example, move the page around, is at the moment very error prone.
From a users perspective this could lead to a lot of weird bugs, that are hard to determine and notice, because a hidden, autogenerated site config is still lurking around somewhere. Like my example with the broken redirect above.

Actions #7

Updated by Franz Holzinger almost 4 years ago

  • Related to Bug #93423: wrong https in slug of one page added
Actions #8

Updated by Thomas Oliver Moll over 2 years ago

Wow, this is a confusing feature - and I still not fully understand when this is triggered.

I just got a support ticket from one of our (inexperienced) local TYPO3-admins, who does not know what she did, but somehow generated these configs, that were totally useless, because they contained not the needed data.

Actions #9

Updated by Oliver Hader about 2 years ago

  • Related to Feature #89142: Create sites when a page in generated on root level added
Actions #11

Updated by Oliver Hader about 2 years ago

Setting to "accepted", since there is no automated process to get rid of those autogenerated sites when a better & more specific site config was provided.

Actions #12

Updated by Julian Hofmann 4 months ago

We also had problems with the behavior today: a page was created and then deleted. However, the generated SiteConfiguration remained.

In short:
TYPO3 generates the autogenerated SiteConfiguration via hook. If you don't want this, then the hook can also be removed:

unset($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][\TYPO3\CMS\Core\Hooks\CreateSiteConfiguration::class]);

Actions

Also available in: Atom PDF