TYPO3 Core

seems like some misconfiguration to me. hard to tell without any specific details...

I had the same problems.

Here the results of t3lib_getIndpEnv('_ARRAY'):
[HTTP_HOST] => test.test
[TYPO3_HOST_ONLY] => test.test
[TYPO3_PORT] =>
[PATH_INFO] =>
[QUERY_STRING] =>
[REQUEST_URI] => /unternehmen/impressum.html
[HTTP_REFERER] =>
[TYPO3_REQUEST_HOST] => http://test.test
[TYPO3_REQUEST_URL] => http://test.test/unternehmen/impressum.html
[TYPO3_REQUEST_SCRIPT] => http://test.test/unternehmen/impressum.html
[TYPO3_REQUEST_DIR] => http://test.test/unternehmen/
[TYPO3_SITE_URL] => http://test.test/unternehmen/
[TYPO3_SITE_SCRIPT] => impressum.html
[TYPO3_SSL] =>
[SCRIPT_NAME] => /unternehmen/impressum.html
[TYPO3_DOCUMENT_ROOT] =>
[SCRIPT_FILENAME] => C:/www/dummy-3.7.0/index.php
[REMOTE_ADDR] => 127.0.0.1
[REMOTE_HOST] =>
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
[HTTP_ACCEPT_LANGUAGE] => de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

TYPO3_SITE_URL always returns the whole path up to the last slash.

But 'unternehmen' should be part of TYPO3_SITE_SCRIPT, as it is not part of the path to the typo3 frontend but the name of a first level page.
As realurl uses all levels to generate (encode) the path, it should be given the whole path for decoding. Using the 'impressum.html' only, realurl fails to decode the path.

As I am hosting more than one domain within a single installation, I used a dirty quickfix: I made tslib_fe::checkAlternativeIdMethods() use SCRIPT_NAME (and actually strip the leading slash as this makes realurl search for a page named '', as the path is exploded by slashes).

I didn't want to mess up too much in the code as I'm quite new to typo3 and still trying to get my bearings..

So there might be two approaches to changing this behaviour:
1.
Change calculations inside of getIndpEnv to only return the part of the path which is really useful to realurl . But as far as I can see, this would only work if typo3 was called without using aliases, as one cannot tell by the informations held in the $_SERVER variable, which part of the URL was used to find the typo3 directory and which part is simulated by realurl.

2.
Always return the whole path and let realurl do the work. If I am getting it right, x_realurl_advanced::searchTitle() (used if no cached path is found) searches from the beginning of the path. So if the path was 'path/to/installation/level1/level2.html' it would give up after 'path', as a page with this name/alias/etc. does not exist.
Only using level2.html (as it is now) does only work one level deep, because realurl checks for the pid of the page, which in level2 is the uid of the 'level1' page (and not the uid of the root page which realurl expects it to be).
So it should be searching from the back of the path til reaching the wanted pid - or not reaching it, if the path does not exist.

So, I hope I did get everything right and have been able to explain the problem and possible solutions quite clearly.

Oh, here's the corresponding realurl configuration:

$TYPO3_CONF_VARS['EXTCONF']['realurl']['test.test']['fileName']['defaultToHTMLsuffixOnPrev'] = 1;
$TYPO3_CONF_VARS['EXTCONF']['realurl']['test.local.test']['pagePath'] = array('type'=>'user',
'userFunc'=>'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'rootpage_id' => 47);

I also have the same problem:
I have three websites at one Typo3-Installation.
E.g. http://www.in-memoriam-gabi.de is working well, but http://www.bellowski.de has the same problem like described above.
I spent many weeks without beeing able to solve the problem. :-(

edited on: 04.02.05 01:31

I can confirm the problem, and the statement about TYPO3_SITE_URL being wrong. What is greek to me, is the cause of this. I have talked to people having realURL working fine, where the value is correct. This has been reported for PHP 4 and 5, so it doesn't seem to be a PHP issue, and Apache 1.3.x is used for working and non-working sites.

The major point seems to be finding out what causes this. So, please add your setup. Here's mine:
TYPO3 3.8.0
realURL 0.3.0
Apache 1.3.33
PHP 4.3.10
Installed in the document root
regular and simulateStatic URLS working fine

Look at bug #0001274. I think the two are related.

1. If you use the RealUrl extension, then you'll have to enable the next line.
2. You will have to change this path if your TYPO3 installation is located
3. in a subdirectory of the website root. #
4. If you place this in httpd.conf, you cannot use this directive in any case!
   RewriteBase /
   [...]
   --------------

The following httpd.conf works for me:
--------------
RewriteRule ^/(typo3|typo3temp|typo3conf|t3lib|tslib|fileadmin|uploads|showpic\.php)(/.*)?$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^/(.*)$ /index.php [L,E=ORIG_SCRIPT_NAME:/index.php]
--------------
See the related bug.

Perhaps this can solve the issue on IIS installations:

The problem why Typo3 can't return the correct page is that IIS doesn't have the 'REQUEST_URI' variable in $_SERVER. The synonym for this seems to be 'HTTP_SCRIPT_URL'. So I decided to add four lines in the 'getIndpEnv' function (class.t3lib_div.php):

case 'REQUEST_URI':
if (!$_SERVER['REQUEST_URI']) {
--> if (isset($_SERVER['HTTP_SCRIPT_URL'])) {
--> return $_SERVER['HTTP_SCRIPT_URL'];
--> } else {
return '/'.ereg_replace('^/','',t3lib_div::getIndpEnv('SCRIPT_NAME')).
($_SERVER['QUERY_STRING']?'?'.$_SERVER['QUERY_STRING']:'');
--> }
} else return $_SERVER['REQUEST_URI'];
break;

Hope that helps.

Regards
Bjoern

Sorry, if I'm wrong, but I'm rather new to typo3 - and ran into the problem described here...

Isn't the algo for TYPO3_SITE_URL just wrong? It looks from the end - rather than from the beginning of the URL. I suggest:

--- pseudo diff ---
case 'TYPO3_SITE_URL':
if (defined('PATH_thisScript') && defined('PATH_site')) {
$lPath = substr(dirname(PATH_thisScript),strlen(PATH_site));
$retVal = t3lib_div::getIndpEnv('TYPO3_REQUEST_HOST') . '/' . $lPath . ($lPath > '' ? '/' : '');
}
break;
--- pseudo diff ---

... which works like a charm for me ;)

Please enlighten me.
HPO

Is this still a problem? In which menu/function/extension does this bug show up? Can it be reproduced somehow? Big Thx for any further hints, otherwise I'll proceed and close it again ...

Yes, it is still valid. For example, I am sometimes using Stefan Bühler's work-around, but it is still not making the issue solved.

• Version of TYPO3?
• realurl enabled? which Version?
• mod_php or php as cgi?
• windows/mac/linux?

"Doesn't work" is really hard to fix ....