Revision history for ModRewriteDevelopment


Revision [23220]

Last edited on 2016-05-20 07:38:47 by JavaWoman [Replaces old-style internal links with new pipe-split links.]
Additions:
[[Docs:ModRewrite | Documentation page]]
Deletions:
[[Docs:ModRewrite Documentation page]]


Revision [19191]

Edited on 2008-01-28 00:14:43 by JavaWoman [Modified links pointing to docs server]
Additions:
[[Docs:ModRewrite Documentation page]]
Deletions:
[[ModRewrite Documentation page]]


Revision [16961]

Edited on 2007-05-31 23:27:31 by JavaWoman [Reverted]
Additions:
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.
~& 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: %%
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>
%% I tried playing with [NC] but it didn't solve the problem.
~~~~~~&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: %%(apache)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 use %%(apache)RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]%% with url ""http://localhost/NewPage/EdiT"" you have $_GET['wakka'] = "newpage/EdiT". --DotMG
~~~~~~~~~~&But "newpage/EdiT" would still give you "newpage" instead of """NewPage""" - so how is this a workaround? --JavaWoman
~~~~~~~~~~~&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 :
%%(php)// 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];
}
}%% --DotMG
~&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
Deletions:
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.
~


Revision [16760]

Edited on 2007-05-31 10:45:01 by Su6H1z [Reverted]
Additions:
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.
~
Deletions:
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.
~& 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: %%
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>
%% I tried playing with [NC] but it didn't solve the problem.
~~~~~~&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: %%(apache)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 use %%(apache)RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]%% with url ""http://localhost/NewPage/EdiT"" you have $_GET['wakka'] = "newpage/EdiT". --DotMG
~~~~~~~~~~&But "newpage/EdiT" would still give you "newpage" instead of """NewPage""" - so how is this a workaround? --JavaWoman
~~~~~~~~~~~&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 :
%%(php)// 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];
}
}%% --DotMG
~&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


Revision [8711]

Edited on 2005-05-29 18:37:13 by JavaWoman [move to subcategory]
Additions:
CategoryDevelopmentArchitecture
Deletions:
CategoryDevelopment


Revision [7716]

Edited on 2005-04-29 13:33:49 by JavaWoman [reply to DotMG (+ heading and sig)]
Additions:
===Possible solutions===
}%% --DotMG
~&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
Deletions:
}%%


Revision [7715]

Edited on 2005-04-29 13:15:39 by DotMG [Fixing lowercase url.]
Additions:
~~~~~~~~~~~&No! your will no longer have newpage/edit but ""NewPage/edit"". For another solution, see below : (DotMG).
Solution for lowercasing url :
%%(php)// 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];
}
}%%


Revision [7583]

The oldest known version of this page was created on 2005-04-25 18:41:00 by NilsLindenberg [Fixing lowercase url.]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki