TYPO3 RealURL重定向循环，用于具有相同标题的链接和页面

Question

Most of this seems irrelevant after a number of Debugging. Read EDIT2 for what you need to know.

I recently took over development of a TYPO3 webpage and added two new postVars to the realurl_conf.php

It works as expected on the primary language, but on some pages when viewing it in a different than the primary language I fall into a redirect loop.

The loop (Temporary Redirect - Code 307) can be reproduced by opening a website, like http://example.com/subpage/?L=2 where 2 is the language ID for English and subpage is the title in English. If I open the page via the link http://example.com/unterseite/?L=2 I get the correct page, while unterseite is the title of the page in the primary language.

Unfortunately I am unable to see the pattern, as to which pages are affected. A total of 3 pages show this misbehaviour, two having child-subpages and the third being a standard page with no children. The other 11 pages work as expected, with 2 other pages having children.

All pages are of the standard content type.

A failing realurl_conf.php looks like this:

 
 
 
 
  
  
  <?php $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['realurl'] = array ( '_DEFAULT' => array ( 'pagePath' => array ( 'type' => 'user', 'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main', ), ), );
 
 
  

I do not seem to find the issue and I've been googling about it for the last week.

Any hint or specific help is very much appreciated.

EDIT: removed unneccessary lines. The problem occurs reliably with the remaining code With the tx_realurl class (not advanced), the problem does not occur, but the behaviour is not as expected.

EDIT2: After a lot of Xdebug debugging, I realized that there is a page with a title say Subpage and there is a secondary menu that contains a link to that page. When opening the URL example.com/subpage/ it detects that subpage is a link to subpage and redirects to subpage. So what I am looking for is a way to give pages precedence over links, if there is more than one match.

Answer 1

I guess this is wrong and should be removed:

'valueDefault' => 'de',

The default values for the L-parameter should be set in TypoScript and not in RealUrl. And I think that a number value must be entered here, if used.

Answer 2

TYPO3 has a ".htacess" file shipped under "_.htaccess". From TYPO3 6.2.4 I get this:

RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L]

# Main URL rewriting.
# For httpd.conf, use this line instead of the next one:
# RewriteRule .* /TYPO3root/index.php [L]
RewriteRule .* index.php [L]

Compare your ".htacess" file with the entries from TYPO3's "_.htaccess". Maybe you are missing the L parameter there.

You should give a detailed example about the redirections which you have on your website.

Answer 3

I just encountered today the second site having this issue after upgrading TYPO3 and realurl.

TL;DR solution: change the 'Speaking URL path segment' of the shortcut to anything different from it's name .

The scenario on my side is:

• TYPO3 6.2.27 ;
• realurl 2.1.1 / 2.1.4 (these are the two cases encountered until now), but this may happen with all 2.x versions;
• page and shortcut with the same name at the same 'path level' ; remember that this could be the same pagetree level or different pagetree levels, but having parent pages with checked ' Exclude from speaking URL ' checkbox in a manner that bring the two elements at the same 'path level'.

It seems to me that this only appears when realurl 2.x is installed. Both sites had realurl 1.12.x or 1.13.x before the upgrade and there were no issues.

Until the issue is solved at the code level, a possible solution is changing the 'Speaking URL path segment' of the shortcut to anything different from it's name . The path segment is not used anywhere, but changing it gets you out of this trouble.

This stopped the redirects on both sites for several page / shortcut pairs on my side.

Answer 4

Another source for a realurl recirect loop:

For me it was a broken manual realurl config that had a non-existent rootpage_id set. Switching to auto-configuration or changing to a correct rootpage_id both fixed the problem.