Error 404 when last alias in friendly URL path starts with a special character

12 Posts

inertica Reply #1, 16 years, 7 months ago

Hello,

bumped into a problem with TransAlias(?) and friendly urls. If the last page’s alias starts with a special character, f.ex. ä, ö, å, the system throws a 404 page. No problems if special characters are in the middle or end of alias, only the first letter in the friendly url path’s last alias creates this problem. I haven’t digged deeper in the plugin yet.

Using Evolution 1.0.2, tried both upgraded from 0.9.6.3 and clean install of 1.0.2. Tested urls with IE8 and FF3.6.

Examples:
---------
These work nicely:
domain.xx/mä
domain.xx/mä/räm
domain.xx/äm/räm

These don’t (not even with special chars url-encoded):
domain.xx/äm
domain.xx/mä/äm

Anyone else can duplicate the problem?

EDIT: topic title changed, might not be a problem with TransAlias

MODX Staff
10,725 Posts

opengeek Reply #2, 16 years, 7 months ago

I tried creating a Resource with äm and it seemed to work fine at http://localhost/evo/äm and http://localhost/evo/mä/äm - not sure I understand what this has to do with TransAlias though.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

12 Posts

inertica Reply #3, 16 years, 7 months ago

Hmm, could something else interfere? As previously stated, I haven’t had time to dig into TransAlias - is the plugin only activated when saving document and alias?

Could this be web server / .htaccess or database related?

Using Apache 2.2.14, request error logged with "äm"-alias:
[09/Feb/2010:13:40:11 +0200] "GET /evotest/C3%A4m HTTP/1.1" 404

DB values of aliases seem ok collation in db, table and fields is utf8_general_ci.

MODX Staff
10,725 Posts

opengeek Reply #4, 16 years, 7 months ago

Quote from: inertica at Feb 09, 2010, 09:01 AM

Could this be web server / .htaccess or database related?

Using Apache 2.2.14, request error logged with "äm"-alias:
[09/Feb/2010:13:40:11 +0200] "GET /evotest/C3%A4m HTTP/1.1" 404

That appears to be Apache-related, but I’m not certain by any means.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

12 Posts

inertica Reply #5, 16 years, 7 months ago

Quote from: OpenGeek at Feb 09, 2010, 09:33 AM

Quote from: inertica at Feb 09, 2010, 09:01 AM

Could this be web server / .htaccess or database related?

Using Apache 2.2.14, request error logged with "äm"-alias:
[09/Feb/2010:13:40:11 +0200] "GET /evotest/C3%A4m HTTP/1.1" 404

That appears to be Apache-related, but I’m not certain by any means.

Yes, it might, even the log files seem ok. Problem is present in our server and also in hosting company’s server.

Normal files with starting with ’ä’ character are working fine w/ Apache:

[10/Feb/2010:13:08:18 +0200] "GET /evotest/%C3%A4m.html HTTP/1.1" 200
[10/Feb/2010:13:17:33 +0200] "GET /evotest/%C3%A4m HTTP/1.1" 200

RewriteLog looks ok with ’ä’ as first and non-first character:

[10/Feb/2010:13:24:49 +0200] [xxx.yyy/sid#2141730][rid#29f6e88/initial] (2) [perdir /xxxx/yyyy/evotest/] rewrite 'äm' -> 'index.php?q=äm'
[10/Feb/2010:13:25:51 +0200] [xxx.yyy/sid#207b1c0][rid#af206838/initial] (2) [perdir /xxxx/yyyy/evotest/] rewrite 'mä' -> 'index.php?q=mä'

Any ideas where to look and/or debug in MODx Evo core? Any hints from http://wiki.modxcms.com/index.php/Order_of_execution and has something drastically changed in Evolution’s OoE? I’d really like to get this solved and working

MODX Staff
12,272 Posts

Ryan Thrash Reply #6, 16 years, 7 months ago

I’m fairly certain it’s an Apache issue as well. Nothing’s changed in Evo to cause this, other than allowing UTF-8 aliases in the first place. Look at the different Transalias plugin settings, and see if changing those helps.

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

12 Posts

inertica Reply #7, 16 years, 7 months ago

Quote from: rthrash at Feb 10, 2010, 08:28 AM

I’m fairly certain it’s an Apache issue as well. Nothing’s changed in Evo to cause this, other than allowing UTF-8 aliases in the first place. Look at the different Transalias plugin settings, and see if changing those helps.

Thanks for the suggestion, Ryan. Tried changing TransAlias settings and saving the resource with ä-starting alias but no dice: either error 404 keeps popping out or utf-8 characters are ripped out from alias or converted f.ex. from ä to a. Latter conversion is nice (that’s something we’ve been aware of), but that won’t solve the original problem.

Googling around and quickly checking Apache version histories didn’t provide me information regarding this case. Hmmm.

MODX Staff
10,725 Posts

opengeek Reply #8, 16 years, 7 months ago

In my tests, Apache is returning a 200 for my URL:

::1 - - [05/Feb/2010:20:19:58 -0700] "GET /evo/%C3%A4m HTTP/1.1" 200 10141

Do you have any other plugins enabled on your system, or snippets running on that Resource that might be causing problems? Is it published?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

12 Posts

inertica Reply #9, 16 years, 7 months ago

Quote from: OpenGeek at Feb 10, 2010, 10:42 AM

Do you have any other plugins enabled on your system, or snippets running on that Resource that might be causing problems? Is it published?

I’ve run the latest tests on a clean install of Evo 1.0.2. The resource is published, all plugins are disabled (tried disabling also TransAlias, after saving the document with "äm"-alias) and the only snippet on test template is Wayfinder, which seems not to interfere.

By a distant hunch (had some problems exporting site to static HTML a long time ago), found a cause of the problem:

If Configuration -> Friendly URLs -> Use Friendly URL alias path is turned on, error 404 is returned. Turn Friendly URL alias path off and alias is working fine.

Debugging variables to a log file, I found that on manager/includes/document.parser.class.inc.php, line 336, the basename function strips off the first utf-8 character:

$q= basename($q);

A quick and dirty fix, and obviously not the best and most flexible one is to set the locale before the function call to f.ex.

setlocale(LC_ALL, 'fi_FI.UTF8');

Edit:

setlocale(LC_CTYPE, 'fi_FI.UTF8');

seems to be enough.

Could this pose some problems on a multilingual site? Setting the locale at the start of the template via snippet or in manager language include file doesn’t have an effect. Is there be a better place to handle this and could some of the system settings be of help in this case?

MODX Staff
10,725 Posts

opengeek Reply #10, 16 years, 7 months ago

Quote from: inertica at Feb 11, 2010, 07:31 AM

By a distant hunch (had some problems exporting site to static HTML a long time ago), found a cause of the problem:

If Configuration -> Friendly URLs -> Use Friendly URL alias path is turned on, error 404 is returned. Turn Friendly URL alias path off and alias is working fine.

This does not happen in my environment.

Quote from: inertica at Feb 11, 2010, 07:31 AM

Debugging variables to a log file, I found that on manager/includes/document.parser.class.inc.php, line 336, the basename function strips off the first utf-8 character:
$q= basename($q);

This again does not happen in my environment; var_dump($q) right after the basename() call for me returns the expected value:

string(3) "äm"

Quote from: inertica at Feb 11, 2010, 07:31 AM

A quick and dirty fix, and obviously not the best and most flexible one is to set the locale before the function call to f.ex.
setlocale(LC_ALL, 'fi_FI.UTF8');
Edit:
setlocale(LC_CTYPE, 'fi_FI.UTF8');
seems to be enough.

Could this pose some problems on a multilingual site? Setting the locale at the start of the template via snippet or in manager language include file doesn’t have an effect. Is there be a better place to handle this and could some of the system settings be of help in this case?

I think maybe you need to add default_charset = "UTF-8" to your php.ini or .user.ini (in 5.3+), or use php_value in .htaccess to set it.

If that’s not it, this might be affected by the web server configuration as well.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek