Forum Moderators: phranque
Currently this is the way I have setup my .htaccess file below, but when you go to
[example.com...]
the files path seems to be broken (you'll notice a broken image) and the other links revert to the old "index.php?section=1" format.
-------------Current .htaccess file--------------
## For people not running with correct DirectoryIndex settings
## But who are able to override Apache settings
## NOTE: This file does NOT apply to IIS
Options +FollowSymLinks -MultiViews
RewriteEngine on
RewriteBase /
RewriteRule index/(.*)/(.*)$ /index.php?$1=$2
RewriteRule index/section/1/files/(.*)$ /files/$1
DirectoryIndex index.php
--------------End .htaccess file-----------------
As you will notice, I tried to correct for the picture on the main page to see if that rewrite format would work, but if you visit the corrected link, you will see that it did nothing at all. I would like to know if it is possible to correct for the image problems with the directory it is looking for things in (currently the /files/ root after the main domain, but is added onto any additional mods I do, so for example it becomes /index/section/1/files/ which is unacceptable) and also know whether or not I can get the .htaccess to update the links on the page to reflect the mod_rewrite.
I finally cleared the major hurdle by getting this to work before asking for help from the forums, which I have also been reading for some time, but I still can't figure out the other two problems on my own, so any help or suggestions you have would be greatly appreciated. My college doesn't offer any programming classes to cover the type of knowledge I need, so I am stuck learning on my own and, hence, trying to draw from the creativity and knowledge of others. Thanks in advance for being so helpful!
P.S.- I would also like to try and figure out how to get the calendar and news modules working properly on my site. <snip> Thanks!
[edited by: jdMorgan at 1:04 pm (utc) on May 19, 2005]
[edit reason] Removed specifics per TOS. [/edit]
RewriteCond %{REQUEST_URI}!.*(jpg¦gif)$ [NC]
RewriteRule index/(.*)/(.*)$ /index.php?$1=$2
RewriteCond %{REQUEST_URI} .*/files/
RewriteRule .*/files/(.*)$ /files/$1
DirectoryIndex index.php
-------------End .htaccess file-------------------
I made the above changes to the .htaccess file this morning and everything seems to be working better now, but I still can't figure out how to update the linking files... Is the .PHP file responsible?
However, one thing that can easily get you into trouble is the use of multiple (.*) sub-patterns in one pattern.
For example, given the requested local URL-path, /a/b/c/ and the pattern ^(.*)/(.*)$ how do you want the path-parts assigned to the parenthesized sub-expressions? It would be perfectly valid for mod_rewrite to put "a/b" into $1 and "c/" into $2, or alternately, to put "a" into $1 and "b/c/" into $2. The pattern is insufficiently-specific. By default, the first case is what mod_rewrite will do, but it has to work hard to do it, requiring three trials per request to get a match. Also, as demonstrated, the pattern with two (.*) subexpressions will match any requested URL-path, as long as it has at least one slash somewhere in the middle. It's very ambiguous, and therefore inefficient -- and may lead to unexpected results.
A better approach is to use forward-looking negative matches, such as ([^/]+)/([^/]+)/? to specifically look ahead for slashes, and stop matching into the current sub-pattern as soon as one is found. In this example, only local URL-paths with one slash in the middle and an optional one on the end, such as "/a/b/", will be matched, and "/a/b/c/" will not be matched. The other advantage is that mod_rewrite knows exactly what character it's looking for to end the sub-pattern match, so only one trial is required and it's much more efficient.
On "how to update the linking files", mod_rewrite can't help; It only processes/rewrites incoming URLs to decide what content will be served. Once the content-handler API phase is started, mod_rewrite is done. Any changes to links on your pages have to be done on those pages themselves, or to the script that generates them.
One thing that often causes problems is the use of relative links, such as <img src="images/picture.jpg">. Here, the browser resolves the image URL by taking the current page's directory, and adding "/images/picture.jpg" to that. If you have rewritten URLs into a different directory, it won't work. It's usually better to use <img src="/site/images/picture.jpg"> which is evalutated relative to the current domain only.
Jim
