TYPO3 Core

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.

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.

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.

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.

The "autogenerated" behavior has been introduced with issue #89142 (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.1/Feature-89142-CreateSiteConfigurationIfPageIsCreatedOnRootLevel.html).

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.

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]);