TYPO3: all urls show the start page (How to debug?)

1
votes

I have an installation with TYPO3 9LTS where all URls show the start page after the last deployment.

Our system has a deployment in three steps: dev, test, prod.

I have build new features on dev and got it working so I deployed it to the test system (including an update to the latest version 9.5.18 of TYPO3). On the testsystem (which worked nicely before) I can see only the startpage as all URLs (which are calculated correctly) result in showing the startpage.

With ext:realurl I cold inspect the array $_GET to inspect which paramters realurl has decoded.

Where does TYPO3 store the detected page uid and possible other parameters?

Maybe I have some errors in the YAML configuration of the routeEnhancers.
How can I detect errors in the routeEnhancers configuration? (although the same configuration works on the dev system)

EDIT:

As there are multiple answers hinting to uniqueInSite: maybe there are multiple errors, but I have one solution which makes my installation work: I can't use conditions for the domain.

I leave the question open/ unanswered as long as there is no solution to systematicly find an error in URL-resolving.

There might be also problems with the uniqueInSite, but that results normaly in a 404 which is handled separately and which nomaly does not result in the startpage to display.

5
typo3slugtypo3-9.x
I had the same problem about a year ago. Unfortunately I forgot what it exactly was, but it had nothing to do with the routeEnhancer. My questions would be: - Is your system running behind a proxy? Are settings therefore okay? - Is your site config correct? - Are the settings of the server (.htaccess) correct? I remind it something to do with those questions... – Rintisch
It also possible that it had something to do with TLS and therefore fitting settings on server level. If I just could remember :-/ – Rintisch
As mentioned under an answer below: Meanwhile I found the reason for my problem (the domain can't be configured with context conditions). And it resulted in a bugreport. But that was luck and not systematic debugging. It seems there is no syntax-check or tracing and the only way would be to debug the underlying PHP-code. :-( – Bernd Wilke πφ

5 Answers

1
votes

I've been debugging an error on one of out installations for 5hours today, and this sounds extremely alike, so maybe this gets you on the right way.

After upgrading from 9.5.15 to 9.5.16 suddenly some Links stopped working erratically. ErrorAHndling wasn't set up so the error resulted in redirection to the root page. The generation of the URLs was fine, but resolving didn't work. The RouteEnhancer in question is PersistedAliasMapper, for example, with the following configuration:

  -
    type: Extbase
    extension: News
    plugin: Pi1
    routes:
      -
        routePath: '/{news-title}'
        _controller: 'News::detail'
        _arguments:
          news-title: news
    defaultController: 'News::detail'
    aspects:
      news-title:
        type: PersistedAliasMapper
        tableName: tx_news_domain_model_news
        routeFieldName: path_segment

This is the configuration for news, basically copy-pasted from the example. It is used in my case to map globally used entities. This worked perfectly before.

An (afaik) undocumented change as of two months ago introduced this bit of code:

    // limit results to be contained in rootPageId of current Site
    // (which is defining the route configuration currently being processed)
    if ($this->slugUniqueInSite) {
        $results = array_values($this->filterContainedInSite($results));
    }

The problem is, that this treats all entities with the eval containing uniqueInSite as being limited to the site. My installation uses entities of many domain models on a global page above all sites. These were no longer found.

So, again, not sure if this is the problem for you. But if this doesn't help, you can try to go the same route as I did: Look up the source on github for the Mapper in question and refer to the changes in a certain time frame.

1
votes

We've got the same problem.

It's caused by [BUGFIX] Respect site for route persisted mappers.
See https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7dd33dfdcd0782afd49924925a623511

We temporary fixed this by changing the TCA config of tt_news:

--- Configuration/TCA/Overrides/tx_news_domain_model_news.php.org       2020-05-27 16:34:07.544603640 +0200
+++ Configuration/TCA/Overrides/tx_news_domain_model_news.php   2020-05-27 16:29:16.763232655 +0200
@@ -22,7 +22,7 @@
             ],
         ],
         'fallbackCharacter' => '-',
-        'eval' => 'uniqueInSite',
+        'eval' => 'uniqueInPid',
         'default' => ''
     ];
 }
1
votes

Check your TCA. You might have 'eval' => 'uniqueInSite' configured. That will cause a 404 if your model object records are stored outside of the root page where you inserted the plugin.

This happened for me after upgrading from 9.5.15 to 9.5.18. Check the j4k3's answer for the change in the core.

Setting 'eval' => 'unique' should fix it in that case.

1
votes

I had the same problem. For me it was caused by havin a forward to https in the htaccess (which worked just fine) but a regular http path in the sites config. The page looked as it should but all pages showed the homepage content while having the correct slug in the address. After changing the site config to https everything worked as should. Stupid me :)

0
votes

In the migration to version 9.x all pages gets a slug. See: \TYPO3\CMS\Install\Updates\PopulatePageSlugs.

Which page to redirect to is done in: typo3/sysext/core/Classes/Routing/SiteMatcher.php:104