Stumped on concepts and clean urls

Topics: User Forum
Apr 17, 2010 at 1:34 AM

I'm trying very hard to understand the rules for this, but am still stumped.

If someone can point me in the right direction, I'd be very much obliged.

I have a website (example.com) that is a Drupal site (with clean urls running). I also have a Wordpress blog (example.com/blog) that will soon be part of the Drupal site (importing posts into Drupal and ditching WP entirely).

The Wordpress links are currently:
example.com/blog/index.php/yyyy/mm/blog-entry-title

The new Drupal links will be:
example.com/blog/yyyy/mm/blog-entry-title

Note that the yyyy and mm are year and month and the only difference in URLs is that the index.php is gone.

I'm trying to understand exactly what I need to do to get there. Am I redirecting from the old URL (with index.php) to the new non-index.php URL? Or is this simply a rewrite, the way IIRF is rewriting the Drupal URLs to not display the "index.php?q="? Is this even possible with the clean URLs running?

Much obliged to anyone who can clue me in. Thanks.

Coordinator
Apr 17, 2010 at 11:27 AM

Yes, redirect.  If I were you here's what I would do....

You're migrating, from WP to Drupal.  So you want to redirect (301) the old, long WP URLs to the short form used by Drupal.  Obviously you can do this only after you've migrated the content.

The rule for this is: 

RedirectRule  ^/blog/index.php/([0-9]+)/([0-9]+)/(.*)$  /blog/$1/$2/$3 [R=301]

With that rule running, any reference to the old-style link (the one with index.php) will continue to "work". When someone clicks on a link like that, it will be sent to your server, then IIRF will send a 301 (Moved Permanently) response.  The browser will then request the shorter form of the URL, which gets handled by Drupal.

 

Apr 17, 2010 at 4:54 PM

Aha! The light bulb has come on, I think.

Cheeso, thanks so much for your help!

After a little more trial and error it's now confirmed working on a localhost install (WinXP). (Actual install will be on IIS6 webserver, but this is for testing.)

Here's what I've got now in my ini file:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RedirectRule  ^/blog/index.php/([0-9]+)/([0-9]+)/(.*)$  /blog/$1/$2/$3 [R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(?!favicon.ico$)([^?]*)(?:\?(.*))?$ /index.php?q=$1&$2 [L]

There may be a way to shorten that, in which case, I'm all ears.

The first set of conditions and the redirect rule is for the WP links.

The second set is for Drupal's clean URLs feature. (By default, Drupal's links look like "example.com/index.php?q=user/login" or whatever. In IIS, it requires a properly configured IIRF to enable the clean URLs.)

I wasn't certain whether there was any significance to the order of the rules, so I put them in the above order thinking that the redirect, if the conditions were true, would happen first, and then the URL would be rewritten per the second rule. That seems to be the case, but again, anyone else is free to correct me on this.

Thanks again.

Coordinator
Apr 17, 2010 at 5:04 PM
Edited Apr 17, 2010 at 5:08 PM

It looks good.

The order IS important because you don't want the /blog/index.php... rules to be rewritten as if they were Drupal URLs.  You need to redirect first.  Then, the 2nd rule will grab the redirected request, and rewrite.  So, yes, that makes sense. 

On the first rule, you probably don't need the two RewriteConds.   They say, in effect "apply the associated rule, unless the REQUEST_FILENAME resolves to an actual filesystem file or directory."  This is normally done in order to allow requests for static content to be handled efficiently - things like .css or .js files, or image files.   But, if the URL pattern in Rule #1 matches, there will never be a filesystem entity that matches, especially given that index.php is the file, and index.php/anything will never be a file.  So, I think those two conditions are extraneous.  The rule will work, but it will be less efficient than it could be.   The same conditions on rule #2 are necessary, though. 

One more thing: If I were you I would strongly consider putting some comments in that IIRF.ini file, to remind myself what I was trying to do when I wrote the rules.!!