Bug #91235

News Detail Page 404 after upgrade 9.5.16

Added by Tayfur no-lastname-given 9 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
Start date:
2020-04-29
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

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.

routeEnhancers:
  NewsPages:
    type: Extbase
    limitToPages:
      - 14
      - 13
    extension: News
    plugin: Pi1
    routes:
      -
        routePath: '/{news-title}'
        _controller: 'News::detail'
        _arguments:
          news-title: news
      -
        routePath: '/list/{page}'
        _controller: 'News::list'
        _arguments:
          page: '@widget_0/currentPage'
      -
        routePath: '/tag/{tag_name}'
        _controller: 'News::list'
        _arguments:
          tag_name: overwriteDemand/tags
      -
        routePath: '/archive/{year}/{month}'
        _controller: 'News::archive'
    defaultController: 'News::detail'
    defaults:
      page: '0'
    requirements:
      news-title: '^[a-zA-Z0-9].*$'
      page: \d+
    aspects:
      news-title:
        type: PersistedAliasMapper
        tableName: tx_news_domain_model_news
        routeFieldName: path_segment

Files


Related issues

Related to TYPO3 Core - Bug #88720: Adding pid option to resolve function of PersistedAliasMapper (Multi-site handling and Extbase enhancer slugs)Closed2019-07-11

Actions
Related to TYPO3 Core - Bug #91245: foo/index.html leads to 404 since TYPO3 9.5.16Closed2019-06-272019-06-27

Actions
Related to TYPO3 Core - Bug #91246: routeEnhancer defaults not applied in TYPO3 v9.5.16Closed

Actions
Related to TYPO3 Core - Bug #91378: Slug isUniqueInTable is brokenClosedXavier Perseguers2020-05-13

Actions
Related to TYPO3 Core - Bug #91438: SiteAccessorTrait is too strict, when resolved record is not part of a siteClosed2020-05-19

Actions
Related to TYPO3 Core - Bug #91519: News Detail Page 404 after upgrade 9.5.18Closed2020-05-29

Actions
Has duplicate TYPO3 Core - Bug #91397: PersistedAliasMapper: 404 error when linking to a detail page and linked data item is outside webrootClosed2020-05-14

Actions
#1

Updated by Benni Mack 9 months ago

  • Related to Bug #88720: Adding pid option to resolve function of PersistedAliasMapper (Multi-site handling and Extbase enhancer slugs) added
#2

Updated by Benni Mack 9 months ago

  • Target version set to next-patchlevel
  • Is Regression set to Yes
#3

Updated by Benni Mack 9 months ago

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.

#4

Updated by Gerrit Code Review 9 months ago

  • Status changed from New to Under Review

Patch set 1 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

#5

Updated by Gerrit Code Review 9 months ago

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

#6

Updated by Stephan Großberndt 9 months ago

  • Related to Bug #91245: foo/index.html leads to 404 since TYPO3 9.5.16 added
#7

Updated by Gerrit Code Review 9 months ago

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

#8

Updated by Gerrit Code Review 9 months ago

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

#9

Updated by Stephan Großberndt 9 months ago

  • Related to Bug #91246: routeEnhancer defaults not applied in TYPO3 v9.5.16 added
#10

Updated by Gerrit Code Review 9 months ago

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

#11

Updated by Helmut Hummel 9 months ago

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?

#12

Updated by Markus Bischof 9 months ago

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.

#13

Updated by Vasyl Mosiychuk 9 months ago

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...

#14

Updated by Markus Bischof 9 months ago

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.

#15

Updated by Gerrit Code Review 9 months ago

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

#16

Updated by Gerrit Code Review 9 months ago

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

#17

Updated by Helmut Hummel 9 months ago

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"

#18

Updated by Matthias Krappitz 9 months ago

@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

#19

Updated by König David 9 months ago

@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];
#20

Updated by Helmut Hummel 9 months ago

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.

#21

Updated by Henrik Ziegenhain 9 months ago

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?

#22

Updated by Helmut Hummel 9 months ago

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).

#23

Updated by Helmut Hummel 9 months ago

  • Is Regression changed from Yes to No
#24

Updated by Helmut Hummel 9 months ago

  • Status changed from Under Review to Needs Feedback

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?

#25

Updated by Henrik Ziegenhain 9 months ago

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.

#26

Updated by Matthias Krappitz 9 months ago

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.

#27

Updated by Henrik Ziegenhain 9 months ago

'unique' is also working. Thanks Helmut!

#28

Updated by König David 9 months ago

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.

#29

Updated by Michael Christian 9 months ago

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!

#30

Updated by Karsten Nowak (undkonsorten) 9 months ago

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.

#31

Updated by König David 9 months ago

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.

#32

Updated by Gerrit Code Review 9 months ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 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

#33

Updated by Gerrit Code Review 9 months ago

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

#34

Updated by Stefan Müller 9 months ago

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...

#35

Updated by Gerrit Code Review 9 months ago

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

#36

Updated by Helmut Hummel 9 months ago

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.

#37

Updated by Gerrit Code Review 9 months ago

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

#38

Updated by Gerrit Code Review 9 months ago

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

#39

Updated by Gerrit Code Review 9 months ago

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

#40

Updated by Gerrit Code Review 9 months ago

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

#41

Updated by Gerrit Code Review 9 months ago

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

#42

Updated by Helmut Hummel 9 months ago

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?

#43

Updated by Gerrit Code Review 9 months ago

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

#44

Updated by König David 9 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#45

Updated by Gerrit Code Review 9 months ago

  • Status changed from Resolved to Under Review

Patch set 1 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

#46

Updated by Gerrit Code Review 9 months ago

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

#47

Updated by Gerrit Code Review 9 months ago

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

#48

Updated by König David 9 months ago

  • Status changed from Under Review to Resolved
#49

Updated by Henrik Ziegenhain 9 months ago

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

#50

Updated by Benni Mack 9 months ago

  • Status changed from Resolved to Closed
#51

Updated by Oliver Hader 9 months ago

  • Related to Bug #91397: PersistedAliasMapper: 404 error when linking to a detail page and linked data item is outside webroot added
#52

Updated by Hagen Gebauer 9 months ago

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.

#53

Updated by Henrik Ziegenhain 9 months ago

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.

#54

Updated by Helmut Hummel 9 months ago

  • Related to deleted (Bug #91397: PersistedAliasMapper: 404 error when linking to a detail page and linked data item is outside webroot)
#55

Updated by Helmut Hummel 9 months ago

  • Has duplicate Bug #91397: PersistedAliasMapper: 404 error when linking to a detail page and linked data item is outside webroot added
#56

Updated by Helmut Hummel 9 months ago

  • Related to Bug #91378: Slug isUniqueInTable is broken added
#57

Updated by Helmut Hummel 9 months ago

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)

#58

Updated by Hagen Gebauer 8 months ago

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.

#59

Updated by Helmut Hummel 8 months ago

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.

#60

Updated by Harald Witt 8 months ago

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

#61

Updated by Helmut Hummel 8 months ago

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.

#62

Updated by Harald Witt 8 months ago

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

#63

Updated by Helmut Hummel 8 months ago

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.

#64

Updated by Harald Witt 8 months ago

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

#65

Updated by Helmut Hummel 8 months ago

  • Related to Bug #91438: SiteAccessorTrait is too strict, when resolved record is not part of a site added
#66

Updated by Helmut Hummel 8 months ago

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.

#67

Updated by Helmut Hummel 8 months ago

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.

#68

Updated by Harald Witt 8 months ago

Thanks again.
Works perfect :-)

#69

Updated by Stephan Großberndt 8 months ago

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.

#70

Updated by Hagen Gebauer 8 months ago

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.

#71

Updated by Jacco van der Post 6 months ago

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.

#72

Updated by Oliver Hader about 2 months ago

  • Related to Bug #91519: News Detail Page 404 after upgrade 9.5.18 added

Also available in: Atom PDF