TYPO3 Core

I experience the same problem with 9.5.17.
There are no changes in the Aspect classes from 16 to 17.
The related issues result in the same 404 error but were caused by identical slug values from different folders in different sites.
In my case the slugs are generated correctly and there exists only a single folder containing my records.

It sounds like comment https://forge.typo3.org/issues/88720#note-38 is describing the problem I have.

Disabling the PID check via a new setting might be the safest option in my opinion.

Thanks!
Ulrike

This is basically a duplicate of #91235

Let me stress again, that I totally understand that having a bugfix release break your installation is troublesome.
Sorry for that.

Nevertheless that changes applied are a valid fix. We (and I in particular) underestimated how much the use case of having records in a different
site than where they are rendered is out in the wild.

Can you please adjust the PID check or add an additional configuration parameter to disable that check?

There actually is a configuration that is checked. That is the "eval" setting "uniqueInSite". If you change that to eval to "unique",
the behaviour is exactly like you'd expect. Slugs are enforced to be unique in the complete TYPO3 installation, enabling you to render them with URLs in any site.

Be aware though, that the currently released versions still have a bug related to uniqueness of slugs on save, that was addressed here: https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276
A release is pending for that.

Hi Helmut,

I am sorry but I do not agree on this:

There actually is a configuration that is checked. That is the "eval" setting "uniqueInSite". If you change that to eval to "unique",
the behaviour is exactly like you'd expect. Slugs are enforced to be unique in the complete TYPO3 installation, enabling you to render them with URLs in any site.

My slugs are unique, as I only have a single folder containing all my records. The URLs are generated correctly but I am not allowed to access the page due to this function in SiteAccessorTrait:

    /**
     * Determines whether page is contained in current site
     * (resolved from current SiteLanguage).
     *
     * @param int $pageId
     * @return bool
     */
    protected function isPageIdContainedInSite(int $pageId): bool
    {
        try {
            $expectedSite = $this->getSiteMatcher()->matchByPageId($pageId);
            return $expectedSite->getRootPageId() === $this->site->getRootPageId();
        } catch (SiteNotFoundException $exception) {
            return false;
        }
    }

As far as I understand it, the pageId checked in that function is the records PID and not the detail page PID. If this assumption is correct, then a different eval setting for the slug field will not solve this issue.

I would appreciate if you could check my assumption.

Thank you!
Ulrike

Hi Ulrike!

cosmoblonde GmbH wrote:

My slugs are unique, as I only have a single folder containing all my records.

Yes, that's fine and I totally get, that it is annoying that you now need to take action.
However there are other users with other use cases and therefore different setups.

The URLs are generated correctly but I am not allowed to access the page due to this function in SiteAccessorTrait:

There are three angles to look at it.

1. Saving a record / slug generation
2. URL generation
3. URL resolving

URL generation is the easiest one, so let's start here.
Generated URLs are based on the site they are generated for and use the slug stored in the database.

URL resolving is a bit trickier, but only a bit.
URLs are split into multiple parts and each part is resolved individually.
A configured PersistentAliasMapper recieves a slug and must resolve a single record UID as result.
For this to work, slugs stored in the database must be unique for the current site.
In other words: A single/distinct URL in a site must resolve to exactly one page exactly, one language and exactly one record.
How is it guaranteed that one part of the URL representing a record (the slug) is only representing one record?
It is done when generating the slug/ saving the record.

Which leads us to slug generation:
Due to how TYPO3 works in general, records are not free floating, but alwasy bound to a storage page.
This storage page has some location in the page tree.
When an editor now creates or edits a record, TYPO3 must ensure the slug is unique enough, so that
URLs (to repeat: URLs are always generated based on a site) are unique as well.

Now here comes the clue:
When saving a record, TYPO3 must know, in which site(s) the slug is going to be used to resolve exactly one record.
This is (currently) done like that:

• When TCA eval setting for the slug field is set to "uniqueInSite", the site of the storage page is resolved and it is checked whether other records in the site of the storage page exist, which have the same slug
• When TCA eval setting is "uniqueInPid", then only slugs in the same storage folder must be unique
• When TCA eval setting is "unique", then slugs of this record type must be unique in the complete TYPO3 instance

This means:

If you have two different storage folders for e.g. news in two different sites, a news stored in site A can (is allowed to have) have the same slug as a news stored in site B, when TCA is set to "uniqeInSite".
For URL resolving this means, TYPO3 must ensure the correct news record, the one that belongs to the correct site, must be resolved.
And exactly this is what has been fixed.

You could now argue, that this should only happen, if you configure your persistent alias mapper accordingly (which is basically what ask for in this ticket).
This would mean however, that we would have two settings for the exact same thing. People with this use case, would need to configure both and need to configure both (TCA and routing config) to match.

It is true, that most of the above does not apply to your use case. From a technical and conceptual point of view, your use case is to have a global
record storage and having URLs to these records in one or more sites. The correct global configuration for that use case is to set the TCA to "unique"

As far as I understand it, the pageId checked in that function is the records PID and not the detail page PID. If this assumption is correct, then a different eval setting for the slug field will not solve this issue.

I would appreciate if you could check my assumption.

The check for the TCA setting is done here:
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/AspectTrait.php#L24-L30

The information whether the slug field is set to uniqueInSite is stored in a property here:
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/PersistedAliasMapper.php#L138

The filtering based on site you mention is only performed in the end, when TCA is set to uniqueInSite
https://github.com/TYPO3/TYPO3.CMS/blob/cb0d4629d8c45539ee1d0fee25905a501532a0ea/typo3/sysext/core/Classes/Routing/Aspect/PersistedAliasMapper.php#L240

This means, you need to change TCA to "unique" and your use case is covered with a simple configuration change, just like you desired to have.

(note though that you may still be affected by a bug in the currently released versions until this fix https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276 is released)

Please check whether changing TCA indeed works in your instance (like I would expect and have verified in test setups).

Thanks

Hi Helmut,

thanks for the detailed explanation. I did not realize that the eval=unique setting (which is never mentioned in any documentation) is also checked when resolving an URL.
The change in the TCA did indeed fix the issue!

Thank you!
Ulrike

cosmoblonde GmbH wrote:

thanks for the detailed explanation. I did not realize that the eval=unique setting (which is never mentioned in any documentation)

This has been fixed meanwhile:

https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Slug.html#eval

The change in the TCA did indeed fix the issue!

Thanks. To be sure to not run into another issue, please make sure to apply this change in case you are on latest released version:
https://review.typo3.org/q/Ie7862b22a06996a9d7ca484a01d7a1859c8f7276

A new release is planned soon as well.