rewrite all dynamic pages in a folder to index.php

[nmjudy]

I have to take part of my site down for maintenance. I've created a 503 index.php page in the folder that needs fixing (for example articles).

I need to redirect all dynamic pages that used to be found in www.mydomain.com/articles/ to www.mydomain.com/articles/

Dynamic pages may look something like this:

www.mydomain.com/resources/modules.php?with-some-string

or

www.mydomain.com/resources/index.php?with-some-string

[sublime1]

I need to redirect all dynamic pages that used to be found in www.mydomain.com/articles/ to www.mydomain.com/articles/

Is this a typo? Do you mean "return the index.php with a 503 response", or "redirect", perhaps to a different location.

What does the index.php file do -- just say "Sorry, down for maintenance, try again soon?"

Through what manner are you causing the server to return the 503 status? ErrorDocument? RewriteRule? PHP?

When you say "all dynamic pages" does this imply that there are static pages in or below the /articles/ directory that would be unaffected?

Tom

[nmjudy]

Hi Tom,
Thanks for the reply. The server is returning a 503 status through php code in the index.php that resides in the articles directory. The index.php page just says, "Sorry, down for maintenance, try again soon."

I would like ALL pages in the articles directory to redirect to /articles/index.php or just /articles/

Because this was an old Postnuke installation, I think all the pages in this directory were dynamic. At least, these are the ones I would like to redirect.

[sublime1]

So, assuming .htaccess in the document root, I think you need something like these:

RewriteCond %{THE_REQUEST} !^[A-Z]+\ /articles/index\.php\ HTTP/
RewriteRule ^articles/ /articles/index.php [L]

I am not completely sure you need the RewriteCond which will match any request except

GET /articles/index.php HTTP/

. The RewriteRule performs an internal rewrite of any path starting with articles/ (in this case, because .htaccess context, leave off the leading slash), serve the file /articles/index.php and stop processing more rules.

The bit I am still learning is that in the .htaccess context, any internal rewrite results in a recursive process of re-checking all existing .htaccess files using the newly rewritten path. I think the initial RewriteCond is needed to prevent the recursing iteration from matching again, in which case you would have an infinite loop.

I have completely ignored anything about dynamic URLs. I believe the problem, as I understand, is "anything in the /articles/ path should get the special index.php which returns a 503 response." If I have missed some nuance, then I probably need more info.

Let me know how this works, either way. I am well over 53% confident that I have this about right :-)

Tom

[jdMorgan]

In this case, the RewriteCond can be simplified:

RewriteCond %{REQUEST_URI} !^/articles/index\.php$
RewriteRule ^articles/ /articles/index.php [L]

The "RewriteCond %{THE_REQUEST}" construct is only needed with URL-canonicalization redirects where there is also an internal rewrite to a filepath that matches the pattern of that redirect rule, creating a rewrite/redirect loop. This often occurs, for example, when new static or SEO-friendly URLs are rewritten to dynamic filepaths, and then a redirect rule is added to stop direct HTTP access by the client using the old dynamic filepath as a URL.

A general rule of thumb is this: To stop a loop inherent is a single rule, use RewriteCond %{REQUEST_URI} or RewriteCond $1 (where $1 is a back-reference to the requested URL-path captured by the RewriteRule). To stop a loop that results from the interaction between two rules -- an external redirect and an internal rewrite which each target paths matching the other rule's pattern, use RewriteCond %{THE_REQUEST}.

Some Webmasters use RewriteCond %{REDIRECT_STATUS} !="" for this latter purpose, but the problem with that is that *any* preceding rewrite can set that variable, leading to a failure to redirect non-canonical requests if any "global" rewrite at the server config level has already been applied.

However, the previously-posted code will work despite being slightly over-complicated, so I'd say it was more like 95% correct... :)

Jim