Mod_rewrite Development/Discussion
Problems with Windows based servers?
Typing "http://MyWikkaSite/WikkaPage" does not work and I have to type "http://MyWikkaSite/wikka.php?wakka=WikkaPage".
I have a windows 2K base, Apache+PhP+MySql and no trouble so far with my Wikka. As I fear I could have broke something with some additional code of mine, I tried a new setup from scratch and still have the problem.
Any idea where this could comes from? --ChristianBarthelemy
- In Wikka, as distributed, the .htaccess file(s) take care of the rewriting, so if you want to use mod_rewrite, .htaccess is necessary - unless you copy the content into a section in httpd.conf (if you have root access). Without the appropriate mod-rewrite statements in either .htaccess or httpd.conf no rewriting will take place. -- JavaWoman
- the .htaccess file delivered with Wikka 1.1.5.3 is in the Wikka folder - still not working - I will try again later on...
- Works just fine on my Windows development machine. There is no dependency with Windows - only with Apache itself. What is important though is that the Apache version used has mod_rewrite available (as module, or compiled into it). If you don't control the server (or don't have root access) ask your hosting provider is mod_rewrite is available. Has it worked before on your server? If so, was Apache upgraded to a new version, or reconfigured?
- You were right: only 'AddModule mod_rewrite.c' was uncommented in the httpd.conf file while 'LoadModule rewrite_module modules/mod_rewrite.so' was not activated. Thanks a lot. This new InlineCommentFormatter is really nice! --ChristianBarthelemy
- So it works now, but I still have a strange problem when I try to create a new page by forcing the url to http://wikka.jsnx.com/ModRewrite/NewPage the system proposes me to create newpage instead of NewPage. I get this problem with a brand new 1.1.5.3 and rewrite_mode on. It disapears if I remove the rewrite mode. I have the same symptom by using the {{newpage}} action. JavaWoman - as you also are using a windows/apache system could you please tell me if you have the same problem? --ChristianBarthelemy
- Christian, I have no problems creating new pages with capitalized names as specified on my development system (Win2K/Apache/MySQL).
- http://[wikkadomain]/NewPage - tries to load NewPage, finds it does not exist, and offers to create it; the page header shows the correct name
- You can shortcut this by immediately adding /edit (to invoke the 'edit' handler) to the url and you get the to-be-created page immediately in edit mode: http://[wikkadomain]/NewPage/edit
- Using the form from the {{newpage}} action has the same result as the shortcut described above
- Note that your syntax above (http://wikka.jsnx.com/ModRewrite/NewPage) is not correct: this would be interpreted as applying a handler named 'NewPage' (which is equivalent to 'newpage' to the ModRewrite page (such a handler does not exist); it should be http://wikka.jsnx.com/NewPage (or http://wikka.jsnx.com/NewPage/edit). --JavaWoman
- "http://135.1.1.227/wikka/NewPage/edit" drives my system to create newpage. It is likely to be an Apache settings problem and it is clearly linked with the mod_rewrite. I have the same problem whatever way I try to create NewPage. Could this be be caused with my .htaccess file: I tried playing with [NC] but it didn't solve the problem.
<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.*/[^\./]*[^/])$ $1/ RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L] </IfModule>
- How is it "clearly linked with mod_rewrite"? What happens when you use the full URL "http://135.1.1.227/wikka/wikka.php?wakka=NewPage/edit" ? What happens when you load an existing page using the full URL? I don't see anything in your .htaccess that would be related with lower-casing a URL or parts of it; can there be a settting elsewhere in your Apache? httpd.conf? --JavaWoman
- "http://135.1.1.227/wikka/wikka.php?wakka=NewPage/edit" works fine even with mod_rewrite enabled. "http://135.1.1.227/wikka/wikka.php?wakka=ExistingPage" displays the right page. I cannot detect anything not normal in my httpd.conf. :-(( --ChristianBarthelemy
- Did a bit of digging and Googling ... this behavior actually seems to be a known bug in Apache... see http://www.sitepoint.com/forums/archive/index.php/t-143070.html which I think matches your problem - as well as a suggested workaround. --JavaWoman
- I also had the same problem! This was my workaround: The rewritten URLs are http://localhost/wikidir/NewPage, and I put RewriteRule in the root directory, like this:
RewriteRule ^wikidir/(.*)$ realwikidir/wikka.php?wakka=$1 [QSA,L]It seems that the Win32's mod_rewrite module lowercases only the texts before the first slash. If you useRewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]with url http://localhost/NewPage/EdiT you have $_GET['wakka'] = "newpage/EdiT". --DotMG
- No! your will no longer have newpage/edit but NewPage/edit. For another solution, see below : (DotMG).
- I just found the SitePoint forums are no longer searchable or accessible without an account (free, but I didn't bother); here's another explanation of this bug: http://www.issociate.de/board/post/154198/%5Burl_rewrite%5D_uppercase_changed_to_lowercase.html . The bug was (later) fixed in Apache 2.0 but it remains in 1.3.x - see http://www.mailarchives.org/list/apache-httpd-bugs/msg/2004/02267 . --JavaWoman
Possible solutions
Solution for lowercasing url :// split into page/method
if (preg_match("#^(.+?)/(.*)$#", $wakka, $matches)) list(, $page, $method) = $matches;
else if (preg_match("#^(.*)$#", $wakka, $matches)) list(, $page) = $matches;
#Fix lowercase mod_rewrite bug:
if (strtolower($page) == $page)
{
$pattern = preg_quote($page, '/');
if (preg_match("/($pattern)/i", urldecode($_SERVER['REQUEST_URI']), $match_url))
{
$page = $match_url[1];
}
}
--DotMGif (preg_match("#^(.+?)/(.*)$#", $wakka, $matches)) list(, $page, $method) = $matches;
else if (preg_match("#^(.*)$#", $wakka, $matches)) list(, $page) = $matches;
#Fix lowercase mod_rewrite bug:
if (strtolower($page) == $page)
{
$pattern = preg_quote($page, '/');
if (preg_match("/($pattern)/i", urldecode($_SERVER['REQUEST_URI']), $match_url))
{
$page = $match_url[1];
}
}
- While this seems to fix a URL for existing pages, those are actually not a problem: my tests indicate an existing page will be matched regardless of how it is capitalized. The main problem with lowercased URLs (as a result from this Apache bug) is in creating new pages: the URL does not match the intended CamelCase page name and Wikka will offer / try to create the page name in lowercase - and you cannot tell it to use a different name. I'll write up a few possible approaches for working around this coming out of a discussion we had recently on #wikka - but so far nothing is a complete solution. More later. --JavaWoman
CategoryDevelopmentArchitecture
