TYPO3 Core

The respective issue is this line:
https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7d#diff-5b5bf7e4ef1064e0c3dbbacb760fe7bfR79

The best solution is to only allow site-specific areas in the RouteEnhancer with an additional property like "respectCurrentSite" and only activate this when the property is set.

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

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

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

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

After upgrading TYPO3 from 9.5.15 to 9.5.16 i get 404 error when i open the news detail page

Can you describe your setup a bit? How many sites do you have configured, where is/are the news folder/s located and on which sites are news shown from this/these folde/sr?

I've the same problem on a bigger instance here. The setup is as described below

• Page root for every domain (www.firstdomain.com, www.seconddomain.com, ...)
• A dedicated page root (global.mydomain.com) for some records which are used globally (e.g news, employees, ...)
• Records from global.mydomain.com are used on several other page roots

In global.mydomain.com there is a Sys Folder for news which will be used on serveral root pages. If a news detail page on e.g. www.firstdomain.com should display a news record which is stored in global.mydomain.com the described error happens.

From my point of view the behaviour of the system should not be changed in LTS versions. Adding a new option but keeping the behaviour should be the way to go. It's clear to me that TYPO3 CMS is a complex system and such things can and will happen again. As far as I can tell it's not the best practice if the one that changes the code is the one that review the code as it happens in the original commit: https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7d.

Tayfur no-lastname-given wrote:

After upgrading TYPO3 from 9.5.15 to 9.5.16 i get 404 error when i open the news detail page. All links to detail view are broken.
The links didn't changed, but TYPO3 can not resolve it.

[...]

I have updated yesterday and I do not have this problem...

Vasyl Mosiychuk wrote:

Tayfur no-lastname-given wrote:

After upgrading TYPO3 from 9.5.15 to 9.5.16 i get 404 error when i open the news detail page. All links to detail view are broken.
The links didn't changed, but TYPO3 can not resolve it.

[...]

I have updated yesterday and I do not have this problem...

This only happens if the news records are in another page tree (site root) than the news detail page.

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

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

Markus Bischof wrote:

In global.mydomain.com there is a Sys Folder for news which will be used on serveral root pages. If a news detail page on e.g. www.firstdomain.com should display a news record which is stored in global.mydomain.com the described error happens.

Thanks for describing your setup. This is helpful!
It clearly show though, that the TCA configuration for the path_segment field is factually wrong to match your use case.
The use case you are describing is having a global news folder and rendering (generating URLs for) these records in every site.
This means slugs must be configured to be globally unique (eval "unique" instead of "uniqueInSite").

Why is that so? If you'd be introducing an additional news folder in one site, TYPO3 would allow a News slug in this folder to be the same
as a News slug in the global folder, eventually leading to URLs being resolved to wrong records.

It is unfortunate that the default configuration of the News extension is "uniqueInSite"

From my point of view the behaviour of the system should not be changed in LTS versions.

That would technically mean to stop fixing bugs. The initial change was a bugfix. When one configured the slug field to be uniqueInSite,
to rightfully allow different sites to have the same slug for different news, it happend, that a wrong news record was resolved.
With only the two slug de-duplication options "unique" and "uniqueInSite", the current behaviour is the correct behavior.

Adding a new option but keeping the behaviour should be the way to go.

Don't get me wrong, I totally understand, the troubles when a bugfix release breaks your TYPO3 instance.
But please also understand two things:

1. It is broken because of a wrong configuration, than now takes effect. That it didn't take effect was a bug.
2. I we revert the current behaviour it will mean, we break the TYPO3 instance for people having their TYPO3 instance configured correctly, basically adding the bug again.

It's clear to me that TYPO3 CMS is a complex system and such things can and will happen again.

They will happen, as long as we're going to fix bugs.

As far as I can tell it's not the best practice if the one that changes the code is the one that review the code as it happens in the original commit: https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7d.

That is a wrong assumption. This issue was discovered, discussed, developed and reviewed by multiple people. What you link here is the straightforward backport from 10.4. to 9.5, which we allow to go in without any further reviews.

Long story short: We will apply a change, that will make your TYPO3 installation work without any changes on your side.
Nevertheless I highly recommend you to change the News slug TCA to be "unique" instead of "uniqueInSite"

@Helmut Hummel: The TCA documentation for slug fields only speaks of eval options "uniqueInSite" and "uniqueInPid", whereas you are talking of "uniqueInSite" and "unique". What is correct?
https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/Slug.html#eval

@Helmut Hummel, after your post i checked the TCA documentation and then also the core, and i only see configuration/use-cases for the options "uniqueInSite" and "uniqueInPid". Are you sure that the option "unique" work for the slug-field?

From DataHandler method checkValueForSlug:

        $evalCodesArray = GeneralUtility::trimExplode(',', $tcaFieldConf['eval'], true);
        if (in_array('uniqueInSite', $evalCodesArray, true)) {
            $value = $helper->buildSlugForUniqueInSite($value, $state);
        }
        if (in_array('uniqueInPid', $evalCodesArray, true)) {
            $value = $helper->buildSlugForUniqueInPid($value, $state);
        }

        return ['value' => $value];

König David wrote:

@Helmut Hummel, after your post i checked the TCA documentation and then also the core, and i only see configuration/use-cases for the options "uniqueInSite" and "uniqueInPid". Are you sure that the option "unique" work for the slug-field?

Yes, this eval option exists for a long time already and is also used for other contexts e.g. backend user name.
It ensures for any TCA defined table, that values of a field are unique for the complete TYPO3 installation.

Helmut Hummel wrote:

König David wrote:

@Helmut Hummel, after your post i checked the TCA documentation and then also the core, and i only see configuration/use-cases for the options "uniqueInSite" and "uniqueInPid". Are you sure that the option "unique" work for the slug-field?

Yes, this eval option exists for a long time already and is also used for other contexts e.g. backend user name.
It ensures for any TCA defined table, that values of a field are unique for the complete TYPO3 installation.

Uhhm... OK. Tested "uniqueInPid" this morning and it works quite perfect for me in 9.5.16 without any patch - was not aware, that "unique" also is applicable for slug fields. Missing documentation or is it a 'misconfiguration, but some kind of works' thing again?

Henrik Ziegenhain wrote:

Uhhm... OK. Tested "uniqueInPid" this morning

You mean you tested setting it to "unique", right?

and it works quite perfect for me in 9.5.16 without any patch - was not aware, that "unique" also is applicable for slug fields.

Cool, thanks for the confirmation.

Missing documentation or is it a 'misconfiguration, but some kind of works' thing again?

It is missing documentation or clarification for the different use cases. What you did is applying correct configuration for your use case.
A release of ext:news is pending, changing the default to "unique" (and the option to change this default to "uniqueInSIte" via extension setting).

Helmut Hummel wrote:

Henrik Ziegenhain wrote:

Uhhm... OK. Tested "uniqueInPid" this morning

You mean you tested setting it to "unique", right?

Hi Helmut,

no, I meant 'uniqueInPid' since I did not know about 'unique' in slug-fields.
'uniqueInPid' worked for me - 'uniqueInSite' resulted in 404 on detail page.

I will give 'unique' I try later this day.

Can the other watchers of this ticket, please confirm, that changing the TCA of "path_segment" to "unique" (like in the currently pending ext:news release) fixes this issue?

Yes, works for me, but it should be added to the TCA documentation of slug fields then I would say to reduce confusion.

'unique' is also working. Thanks Helmut!

I test it with my own extension (wich also was broken) and with 'unique' as eval it work as it should.
Thank you Helmut for your explanations.

NO, "unique" or "uniqueInPid" isn't working at BE!
After setting "unique" or "uniqueInPid" it's possible to create a new item with the same slug (in the site in different sysfolders).

After the 9.5.16-change (https://review.typo3.org/c/Packages/TYPO3.CMS/+/61585) we need a new eval for slug-fields like:
uniqueInDb or uniqueInTable!

NO, "unique" or "uniqueInPid" isn't working at BE!

I can confirm the same behaviour in TYPO3 10.4.1 in my extension. I changed the path_segment eval to unique. The single view in frontend is working fine again but in the backend it's possible to create the same slug value in different data.

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

Can confirm the behaviour for all my extbase records (not only news). Moving the data-folders into the site-root-tree fixes the problem. Waiting for next minor release and hope for fix...

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

Michael Christian wrote:

NO, "unique" or "uniqueInPid" isn't working at BE!
After setting "unique" or "uniqueInPid" it's possible to create a new item with the same slug (in the site in different sysfolders).

I'm sorry, that's indeed the case. I wasn't aware of the fact that slug fields get a dedicated handling in DataHandler, where the unique eval condition is NOT evaluated.

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

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

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

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

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

König David wrote:

Can also confirm that the generating of the slug did not work correctly with "unique"
the slug field is also filled with the same value in the same sys-folder.

In the Screenshot I let the backend generate the same slug three times, twice in the same PID.

Thanks David for the initial work on the patch. I updated it with tests, fixed a minor thing and updated the commit message
as well to reflect the changes made.

Can everybody please test the changes?

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

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/+/64455

Patch set 3 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/+/64455

Thanks for taking care.
Shouldn't we also reflect these changes (`unique` as valid eval value now) in TCA Documentation?

I don’t know how to test patches and I don’t know whether the latest patch is already included in 9.5.17 or 10.4.2 respectively. However, in both of the latest LTS versions, 9 and 10, I have a major issue with eval=>unique:

Everytime I hit save on a previously stored record, a -1 will be added to the path_segment. Apparently the check for being unique compares the record with its currently stored version as well, noticing that the path_segment already exists. This happens in tx_news as well as in some of my own extensions with a path_segment field (that I had just changed to eval=>unique).

Also I don’t understand why a slug field now shows the domain in front of the text field!? This is completely misleading for an editor since usually there is a page slug in between the domain and the record path_segment.

Hagen Gebauer wrote:

I don’t know how to test patches and I don’t know whether the latest patch is already included in 9.5.17 or 10.4.2 respectively. However, in both of the latest LTS versions, 9 and 10, I have a major issue with eval=>unique:

Everytime I hit save on a previously stored record, a -1 will be added to the path_segment. Apparently the check for being unique compares the record with its currently stored version as well, noticing that the path_segment already exists. This happens in tx_news as well as in some of my own extensions with a path_segment field (that I had just changed to eval=>unique).

This was addressed and already fixed in #91378

Also I don’t understand why a slug field now shows the domain in front of the text field!? This is completely misleading for an editor since usually there is a page slug in between the domain and the record path_segment.

Didn`t notice that, but you`re right. This is misleading.

Henrik Ziegenhain wrote:

Also I don’t understand why a slug field now shows the domain in front of the text field!? This is completely misleading for an editor since usually there is a page slug in between the domain and the record path_segment.

Didn`t notice that, but you`re right. This is misleading.

Are you both on 10.4 or 9.5?

In 10.4 (as far as I can see) this always was the default behaviour, in case the folder was part of a site to show the base URL for that site as prefix for slug fields.
But this can be adapted with a user function, introduced here: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62270

In 9.5 you can only influence this by moving out the record folder (not inside a site), or by some FormEngine data provider adding your own fake site object (not tested)

Are you both on 10.4 or 9.5?

I currently have running an instance each on both versions.

In 10.4 (as far as I can see) this always was the default behaviour, in case the folder was part of a site to show the base URL for that site as prefix for slug fields.
But this can be adapted with a user function, introduced here: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62270

Thank you. By this I somehow managed to at least only show a '/'

In 9.5 you can only influence this by moving out the record folder (not inside a site), or by some FormEngine data provider adding your own fake site object (not tested)

Well, I just had to move my storage folders below my siteroot page in order to not get a 404 on detail pages … after years of having them on the same level. See this issue :) I might be able to move it back though once the fix to the bug of the added -1 is being implemented.

Hagen Gebauer wrote:

Well, I just had to move my storage folders below my siteroot page in order to not get a 404 on detail pages … after years of having them on the same level. See this issue :) I

I tried to give a detailed explanation on the what and why,
Let me know if I can help even further.

might be able to move it back though once the fix to the bug of the added -1 is being implemented.

Here is the whole story (well, sort of):

The light bulb was broken and has been fixed, because some people needed light in the evening.
Unfortunately it was forgotten, that now the light will stay on the whole night, as the switch was left turned on.
RIghtfully people who always wanted to have it and had it dark in the night complained, that the bulb being annoyingly bright.
So it was suggested to unscrew the light bulb as a fix. This would have caused people who wanted to work late and needed light,
to not only turn the switch on, but also screw in the lightbulb again. People who liked it dark would have been happy, others who
dependend on the light not so much.
So it was agreed upon to instruct people who liked being in the dark to just switch off the light.
It was assumed the switch does what it supposed to do, being able to turn the light off.
But there was an oversight. It did turn the light off, but also switched off the freaking fridge. This was quite unfortunate.
So the wires of the switch have been checked and re-arranged, so that it now properly switched the light off,
but not the fridge, this was tested to work. Except that it wasn't verified that the switch now turned the ceiling fan ON.

So, yes, this was kind of slapstick bug fixing, but still: Switch and light are now working properly.
So please, since we worked hard to fix this, don't ask to unscrew the lightbulb again :)

The real fix you are looking for (now) is changing the TCA of the slug field to "unique".
Well, "now" in terms of: once you apply fix for #91378 or wait for the next release, which will be out soon.

Thanks.

Hi,
I was updating to 9.5.17 yesterday and I noticed, that the problem is still the same. Deactivating the routeEnhancer "NewsPlugin" helps - but it's not nice.
Her some Infos about my configuration:

I don't have any "unique"-problem because I append the news-uid to the slug in my routeEnhancer "NewsPlugin".

I cannot confirm that moving the news folder inside the site root helps.

I have a lot of sites (domains) and a central news folder with subfolders. I pick up the news to show in a list-view form the news folder plus one level by means of categories. So the same news article can appear on multiple sites.

Now I deactivated the routeEnhancer "NewsPlugin" for all my sites and all functions properly.
Still waiting for the problem to be solved

Harald

Harald Witt wrote:

Now I deactivated the routeEnhancer "NewsPlugin" for all my sites and all functions properly.
Still waiting for the problem to be solved

It is meanwhile solved. I explained it how and why it was solved this way:
https://forge.typo3.org/issues/91397#note-12

Can you please just try to set the eval setting of the slug filed to "unique"?
Thanks.

Hi Helmut,
yes I can confirm, that setting eval to unique helps.
But I don't understand why. Appending the uid to the slug should be enough to make the speaking url unique. In 9.5.14 this did function properly.
I use this mechanism also for other plugins and there's no problem. But that routeEnhancers are of type "Plugin" and not "Extbase".

Hope this will function soon exactly like in earlier versions
Harald

Harald Witt wrote:

yes I can confirm, that setting eval to unique helps.

OK, thanks.

But I don't understand why. Appending the uid to the slug should be enough to make the speaking url unique.

Thanks for bringing upo this use case here. The difference to the previously discussed cases is, that you ensure
uniqueness of the URIs by appending a unique identifier (uid) yourself.
That is fine and means, that ensuring uniqueness on saving the record is not required for you.

You need to configure TYPO3 that it does what you need on save, by unsetting "eval" completely (or setting it to an empty value).

I use this mechanism also for other plugins and there's no problem. But that routeEnhancers are of type "Plugin" and not "Extbase".

That is fine. Just unset eval and you should be good to go. Can you confirm that unsetting eval for the slug fields works for you as well?

Hope this will function soon exactly like in earlier versions

It does when unsetting eval.

Hi Helmut,
thank you for your hint. Yes, unsetting eval works perfect!

By the way:
Unsetting eval in myExt via Configuration/TCA/Overrides/tx_news_domain_model_news.php is not ever possible.
This is because the news extension use the override mechanism itself for the field "path_segment".
And the override of "news" is done AFTER the override of "myExt".
Using the name "zzz_myExt" instead would help.
So I'll write a request for news to integrate the override inside the normal TCA.

Harald

Helmut Hummel wrote:

Harald Witt wrote:

Hope this will function soon exactly like in earlier versions

It does when unsetting eval.

To explain this a bit more. When your news folder wasn't or isn't connected to a site (e.g. storage page in site root and without site configuration), but still configured "uniqeInSite",
TYPO3 currently completely drops the unique check and allows duplicate slugs. TYPO3 thus imitates the bahaviour when eval is not set at all.
This for sure isn't optimal and TYPO3 should rather be vocal about such misconfiguration or misuse.

Since it is this way, the behaviour of enhancers should be adjusted accordingly, which I now fixed here: https://review.typo3.org/64520

In any case, for your use case, the correct TCA configuration is to remove the eval setting, because you resolve conflicting slugs by adding a unique identifier in the route enhancer.

Harald Witt wrote:

Hi Helmut,
thank you for your hint. Yes, unsetting eval works perfect!

Good to hear, thanks!

By the way:
Unsetting eval in myExt via Configuration/TCA/Overrides/tx_news_domain_model_news.php is not ever possible.
This is because the news extension use the override mechanism itself for the field "path_segment".

Actually, it does not:
https://github.com/georgringer/news/tree/c0a7da2e1f3b6a73d9a8b0779c68b7b46eb5728c/Configuration/TCA

And the override of "news" is done AFTER the override of "myExt".
Using the name "zzz_myExt" instead would help.
So I'll write a request for news to integrate the override inside the normal TCA.

If your extension needs to change TCA that another extension provides, your extension needs to define a dependeny to it.
This can be done in ext_emconf.php by either adding the dependency to "depends", or if it is an optional dependency, to "suggest"

TYPO3 then ensures your extension is loaded after its depnendency and you can properly overwrite TCA defined there.

Thanks again.
Works perfect :-)

I had the case where until 9.5.14 news worked without issues and until 9.5.18 I get a 404 - the news folder in this case was not the tree of any site, but on root level (pid=0). I had to move it into the folder containing a site to make it work again.

Stephan Großberndt wrote:

I had the case where until 9.5.14 news worked without issues and until 9.5.18 I get a 404 - the news folder in this case was not the tree of any site, but on root level (pid=0). I had to move it into the folder containing a site to make it work again.

Hi!

This is due to the definition of the slug field: eval=>uniqueInSite as written in some of the many comments above :) In the latest version(s) of the News extension you can now change that settings in the Extension Configuration from within the T3 backend:
Records // Slug behaviour (records.slugBehaviour)

Set it to unique instead of uniqueInSite and it should work again.

Stephan Großberndt wrote:

I had the case where until 9.5.14 news worked without issues and until 9.5.18 I get a 404 - the news folder in this case was not the tree of any site, but on root level (pid=0). I had to move it into the folder containing a site to make it work again.

Thanks for sharing this.