Forum Moderators: phranque
I'm putting the site into the MODx CMS which I am learning as I do the conversion. I've tried to "trick" MODx by putting forward slashes as part of the "alias" which it uses to create the friendly URL's but it simply dropped the slashes which ran the folder name together with the file name: /folder/page.html became folderpage.html which was not the result that I needed. There may be another way around this but I'd actually rather simply drop the folder since it's bugged me for several years now. It goes back to when I first created the site back in 2000 and didn't know much of anything. Yes, I know good URL's never change.
The only way I can see to go forward is to use a redirect that drops the folder completely out of the URLs. I cannot test it as the site that I'm converting is live and must remain intact until the MODx version has been completed, and the conversion might me take months to finish.
The redirect needs to only deal with the files in the one folder, the site's index file was never in the folder. Will the following code work for my purpose of taking a current URL of http://www.example.com/folder/page1.html to the new form of http://www.example.com/page1.html without touching the index.html?
redirectMatch 301 ^/folder/ http://www.example.com/
I suspect that you're confused, thinking that you need to use an external redirect and change the URL. You don't. All you need to do is take a request for the URL-path /folder/abc and tell the server to get that content from filepath /abc instead of from filepath /folder/abc. So the filepath may change, but the URL does not. This is what an internal rewrite is good for.
If you opt to use mod_rewrite, you can in fact test your rule(s) on a live server without impacting normal operation. Simply provide logic in or surrounding the rules to be tested that will only execute the test code if the request comes from your own IP address, bypassing the new code for all other requests. :)
Jim
I'll look further into the documentation and see how much more I can get confused. I do know that I want to issue 301's for these URLs and be rid of the folder for the next never. Hopefully all in one command instead of a series of one liner's.
RewriteEngine On
RewriteRule ^folder/(.*)$ http://example.com/$1 [R=301,L]
Thanks again.
Redirect 301 ^/folder/ http://www.example.com/
However, if you use --or plan to use-- mod_rewrite for any external redirects (or internal rewrites), then use it for all redirects. Otherwise, you can lose control of which directives are executed first, since directives are processed in per-module order, and not necessarily in the order in which they appear in your config files.
For example, servers are usually configured to execute mod_alias first and mod_rewrite later, but this is not always true. Mixing directives from different modules --even if it works correctly today-- leaves you vulnerable to a server configuration change or upgrade which alters the module execution order, which can 'break' your code.
Jim
If I understand your last paragraph correctly, one should keep all the commands grouped by type so that all the mod_rewrites are together, redirects are together, and so on. If so, that is good to know. I've got mine that way as it is but my reason was just to be somewhat organized. Is there a preferred order that these "modules" should be in or does that matter?
Now, speaking only of mod_rewrite, put your external redirects ( i.e. rules ending like http://example.com/ [R=301] ) first, followed by all of your internal redirects. And put directives in each of those two groups in order from most-specific pattern to least-specific pattern -- or equivalently, in order from fewest URLs affected to most URLs affected.
The main goals are to avoid having a an external redirect expose an internally-rewritten filepath to the client, and to avoid multiple, chained, or stacked redirects.
Jim
I'm thinking/hoping this might be a clue as to what's gone wrong.
The original problem addressed in this thread is now working as it should. Yay! It seems that putting the redirect code at the top of the .htaccess file and renaming the folder back to its original name has finally clicked.
The old redirects still aren't working but they're now the lesser problem.
...that will only execute the test code if the request comes from your own IP address
Example (change digits to your IP):
RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$
RewriteCond ...
RewriteCond ...
RewriteRule ...
[edited by: SteveWh at 10:36 am (utc) on June 24, 2009]
As for the old redirects, well I've only been getting one or two of them a month for well over a year now. I feel that getting a 404 for them now is reasonable, especially with the 404 page that I have set up. There weren't many of them anyway.
Steve, thanks for that info. Maybe it will be needed at some point in the future. I'm beyond it now as the site is now live and functioning since Sunday. Yahoo is already sending traffic to the new "folder-less" versions of the pages. They're fast to get it reindexed.
Then you go and change hosts, and over there all your RewriteRules are processed before your Redirects... Now your internal filepaths previously "hidden" by rewrites will be exposed out into URLs, will be indexed, will cause Redirection Chains and Duplicate Content issues, and will go on to cause ranking and traffic issues with your site.
To be clear, the directives in .htaccess are not processed from top to bottom like some sort of computer program. Instead, Apache runs each Module (Mod_Auth, Mod_Rewrite, Mod_MIME, and so on) in turn, and each module processes only the stuff that it can deal with. Per-module they do work from top to bottom, but only looking for their own stuff.
So, if you have stuff from two different Modules, all of the stuff for one module will be processed, and then all of the other stuff for the other module will be processed. Depending on the host this may be "A" then "B", and on another "B" then "A". One of those configurations will give you lots of grief. You can avoid all of that by using Mod_Rewrite code for all of your Redirects as well as for all of your Rewrites. When you do that, Mod_Rewrite will process them in the order they appear in the file. Now you have regained control.
It may be that you don't have time to make this change now but if you don't, I suggest that you document this problem in the .htaccess file itself, so that if this "Doomsday scenario" occurs, anyone who can read will have a good clue to fix the problem.
Jim
