URL rewrite syntax - quicker than last question hopefully!

Just a quick follow up.

This is almost working…

I have this as my rewrite rule:

RewriteRule ^([^/]*)/$ /lodges.php?GSG_URL=$1 [L]

In the .htaccess of my root directory.

It does work, but does require a / at the end of the URL.


www.mysite.com/myfieldvalue/ does work.


www.mysite.com/myfieldvalue does not work.

In an ideal world these should both work.

How can I change the rule for both variants to work?


In regular expressions, a question mark means the preceding is optional.

RewriteRule ^([^/]*)/?$ /lodges.php?GSG_URL=$1 [L]

Thanks Jeff.

That did fix the issue with the / at the end of the URL for the dynamic URLs.

Unfortunately there is also a WordPress installation on the site which is complicating it further.

Without the ? it works with the /.

And more importantly it doesn’t mess up the blog article URLs.

I did notice that some got messed up if they did have a / at the end of the WordPress URL, but deleting those in WordPress fixed that.

However, when I added in the ? to the rewrite rule, all the WordPress URLs broke - instead of the blog article, it displayed the lodges.php page, but with no data.

This isn’t really a technical problem anymore. The issue is you’re making your URLs so generic that it becomes almost impossible to distinguish between different kinds of URLs.

Let’s say I visit yoursite.com/some-title. Should that be rewritten to lodges.php or index.php? How do you tell the difference?

Good questions. I guess I envisaged a rewrite rule that effectively says:

Where a URL ends in mypage.php?lodge=lodgename, replace mypage.php?lodge=lodgename with lodgename.

By which I mean a visitor can visit:


But see the contents of:


And that the second part of the rule (i.e. lodges.php?GSG_URL=$1) makes that clear - i.e. refers only to the lodges.php page - but it sounds like I have that wrong, and goes a long way to explaining the glitches.

This is new territory to me though.

All I know is that I have a database with a table of lodges.

I have no problem with a dynamic URL of the form:


But the site is opened up to lodge owners to log in and add the details, and they are all being supplied with user friendly URLs of the form:


So my options are:

  1. Create an individual page for each lodge, but that’s way too impractical.

  2. Figure out this URL rewriting to have the best of both worlds - i.e. friendly URLs and a dynamic page.

So starting from scratch, is there another solution that will work better?

ie for a user to be able to browse to:


and see the contents of:


Where ‘lodge name’ is a unique short form of the actual lodge name.

I’ve noticed that a lot of people start out thinking of it this way (replace this ugly URL with this pretty URL), but the technical process goes in the opposite direction. You start with a pretty URL and your rewrite rules need to figure out what the ugly URL would be.

Sounds like the only way to distinguish between a lodge URL and any other URL is by checking the database. Which means you’ll have to do this on the PHP side of things. For every URL that comes in, you’ll have to check if there’s a lodge in your database that corresponds to that URL. If yes, then render the lodge page. If no, then let WordPress continue and check for other kinds of URLs.

The only other (possibly simpler) alternative is to change your lodge URLs. Something like yoursite.com/lodges/lodgename or lodges.yoursite.com/lodgename would work well. (Notice that these explicitly use the word “lodges” somewhere in the URL.)

That PHP stuff sounds beyond my knowledge, and probably beyond a forum post as well if its quite an involved bit of coding.

I’m still not really sure why it seems to work as well as it does.

ie www.mysite.com/lodgename works so long as there is no / at the end of the URL. And that doesn’t mess up the WordPress URLs. Which isn’t perfect, but probably works well enough to go with.

With the addition of the ? it only seems to affect some (admittedly most) blog URLs.

But if I add a test static page it works OK. Is that because the rewrite rule above only affects dynamic URLs?

Correct. There’s typically a “not a file” (!-f) condition applied to the rewrites.

Hi Jeff - thanks for all your help with this yesterday - its much appreciated.

I think I understand a bit better the importance of understanding which way round it all is.

i.e. the rule is basically saying:

If you have a URL of the form www.mysite.com/myfieldvalue you want me to rewrite that and display what is actually at www.mysite.com/mypage.php?myfield=myfieldvalue.

So if the entered URL contains something after the / that isn’t actually a valid value for that field, then the rule goes south, and displays the dynamic page with no data - in this case blog articles with their own URLs separate from the table I do want it to apply to.

Although, having said that, I’m still not clear on why it does seem to work with some blog URLs.

However, we haven’t gone live with this yet, so it might be worth changing the URLs and putting them in a folder /lodges/ as you suggest.

What I currently have is the following:

Real URL of the form:


Which I would like to displayed at:


With the following rewrite rule:

RewriteRule ^([^/]*)/?$ /lodges.php?GSG_URL=$1 [L]

in the .htaccess file within the /lodges/ folder.

That works with and without the /, and it doesn’t seem to break any of the blog pages.

Does that all sound like it should work without any unforeseen problems?


By and large yes, that sounds perfectly fine.

One unintuitive caveat to watch out for. When you have rewrite rules in a subdirectory like that, then none of the root directory rewrites will be applied to requests under the /lodges/ folder. That is, by default, rewrite rules don’t inherit from parent directory to subdirectory.