but they don’t work. Many close variants do work, but as soon as the rule gets that slash after “photo/”, the pattern is not recognized (the file opens as if there were no rewrite rule). Thus, this works (accessing another directory):
There is no photo.php in the root directory. The root directory contains photo/ which contains photo.php, which is that directory’s index (photo/.htaccess has DirectoryIndex photo.php).
I wasn’t familiar with Options -MultiViews (so have briefly read up on it) and have now written it into (root) /.htaccess. That hasn’t helped.
I had had this RewriteRule in photo/.htaccess but have moved it to (root) /.htaccess. That hasn’t helped.
When photo.php is called by the URL with the GET data (entered in full form into the browser address bar), it handles the GET and displays correctly. The problem is in the RewriteRule.
What seems odd is that I have a similar folder, also in the root directory, that uses this exact setup for handling simplified URL/GET calls, and it works perfectly.
[rant #1][indent]The use of “lazy regex,” specifically the :kaioken: EVERYTHING :kaioken: atom, (.*), and its close relatives, is the NUMBER ONE coding error of newbies BECAUSE it is “greedy.” Unless you provide an “exit” from your redirection, you will ALWAYS end up in a loop![/indent][/rant #1]
Solution: Either use a RewriteCond to exclude photo.php from your RewriteRule OR get specific about what you want to redirect!
Don’t get disheartened! The folks here are all very helpful.
What I meant with my “Solution” was:
RewriteEngine on
RewriteCond %{REQUEST_URI} !photo\\.php
RewriteRule photo/(.*)$ photo/photo.php?ph=$1 [L]
where the exclusion is NOT photo.php
OR
RewriteEngine on
RewriteRule photo/([^.]*)$ photo/photo.php?ph=$1 [L]
where you’re excluding the dot character from the atom created as $1.
Which solution you choose will depend upon the content that you have after photo/ and both methods effectively fail to match index.php so there will be no loop.
I refer you to the tutorial Article linked in my signature as it’s helped many members for the last five or six years.
One additional pointer then which could save some headaches if your index.php does not allow a null value of ph: The * metacharacter means ZERO or more whereas the + means ONE or more. In most cases, you’d want to have at least one of your characters for the value of ph.
A second point is that the | pipes in a character range definition are not only not necessary but may cause problems. Further, the - has dual meaning as it’s part of a character range definition ( [a-c] means a, b, or c are acceptable) OR, if the first (or last - there’s some debate about that), mod_rewrite is smart enough to understand that it’s not part of a character range.
Please note that the Last flag IS important otherwise it will be ANDed with any further mod_rewrite code in your .htaccess!
Of course, if you'd read my (signature-linked) tutorial Article, you would have learned all about mod_rewrite and be correcting others with code similar to yours. ;(
Regards,
DK
Thank you. The index.php GET-handler indeed includes an if-null option supplying a random choice from an array. In fact that’s the default option, as the GET-specified choice is mainly for follow-up page calls.
The [L] flag had been set (also [NC]), though to focus the point in question I had omitted it from the post. Thank you for emphasizing it. (This code is in a sub-directory containing just that one file (index.php), and it’s only line in that htaccess, so the [L] flag had seemed optional.)
The pipes notation seems to work in both my local and remote servers though for best robustness I will heed your caution and emend the code accordingly.
Alas I had not yet studied thoroughly your excellent article, as I’ve been using an ample range of good guides, and will add your article to my list for careful reading. Of course if we were all to master the available sources, forums like this would not exist. Seeking clarification of persistently baffling points can be a reasonable thing to do.
Your responses are much appreciated as my aim is not only to create pages that seem to work but to learn to write accurate code. Early in C-application-writing days I adopted the habit of making every possible mistake deliberately and repeatedly, to insure maximum thoroughness of understanding. So knowing that something might not work someday even when it seems to work today is part of this thoroughness principle.
