Forums / General / URL Aliases have no effect in ezP 4.0

URL Aliases have no effect in ezP 4.0

Author Message

Felix Leimbach

Thursday 10 April 2008 6:55:49 am

Hello forum,

one of my sites which I recently upgraded to ez Publish (from 3.9.3 over 3.10.0 to 4.0.0) does not seem to act upon url aliases anymore. They just don't seem to have any effect.

Example:
In the admin interface under the "global URL aliases" I add a simple alias:
Alias: /test
Destination: /content/view/full/2564

But http://mysite.com/test contains en empty page while http://mysite.com/content/view/full/2564 returns the desired content.

Now what's interesting is the SQL Debug output:

Notice: eZMySQLDB::query(1 rows, 0.378 ms)
SELECT e0.id AS e0_id, e0.link AS e0_link, e0.text AS e0_text, e0.text_md5 AS e0_text_md5, e0.action AS e0_action, e0.is_alias AS e0_is_alias
FROM ezurlalias_ml e0
WHERE e0.parent = 0 AND (e0.lang_mask & 3 > 0) AND e0.text_md5 = MD5( 'test' )
LIMIT 0, 1

So the alias IS BEING FOUND in urlalias_ml as it returns one row!
BUT it does not seem to be used in any way as just below I get this error in the debug output:

Error: error/view.php
Error ocurred using URI: /test

Interestingly enough the same happens when I define an URL wildcard alias instead.

Details on the site:
* Upgraded to from 3.9.3 to 3.10 and skipped running updateniceurls.php as described in the manual (for a direct 4.0 upgrade afterwards)
* Ran updateniceurls.php in 4.0 and it seems to have populated urlalias_ml correctly

Any idea?

Kristof Coomans

Thursday 10 April 2008 10:31:59 am

Hi Felix

I can not reproduce the issue that occurs there, but I'm using a fresh installation. Could you report this problem in the issue tracker please and provide us a dump of the database? Thanks!

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Felix Leimbach

Thursday 10 April 2008 12:05:47 pm

Hey Kristof,

thanks for looking - created issue http://issues.ez.no/IssueView.php?Id=12845
About the DB dump:
The DB is quite large and should be kept semi-confidential at least :)
Is it enough for you to have the ezurlalias and ezurlalais_ml tables?

Felix Leimbach

Saturday 12 April 2008 12:01:30 am

Spent an evening debugging this stuff and here's the result with a preliminary fix which Works For Me (TM). Someone from the eZ crew should look into my fix, because it may be too simplistic or even plain wrong for general use.

Anyway, here are my findings:
File #1 /index.php:
a) The code does run into the if clause of below the comment "Check for URL translation". It does fill $translateResult correctly and sets $objectHasMovedError to true as expected
b) On line around #702 it calls:
$module->handleError( eZError::KERNEL_MOVED, 'kernel', array( 'new_location' => $objectHasMovedURI ) );

The $module seems to be error-module, so that leads us to file #2 kernel/error/view.php:
a) $errorHandlerType is set to 'redirect' here
b) Thus it enters the if-clause at around line #105 where it redirects to the 'ErrorSettings' => 'DefaultRedirectURL' !!! Which is of course non-sense, as we have been given a NEW LOCATION and should not use the DefaultRedirectURL from the INI settings

Instead of entering the if-clause at line #105 I made it enter the if-clause above at #78 which does issue a HTTP 301 (moved permanently). I realize that a HTTP code is probably not what was intended for the url_alias scenario, but it does the job for now until this gets eZ's attention.

Patch is attached to the issue linked in my previous post.

Felix Leimbach

Friday 13 February 2009 12:37:40 pm

OK, bug is fixed after upgrading from 4.0.0 to 4.0.2
Had to re-create the URL alias, though.