|Spread-out conversion to Drupal|
Use URL rewrites?
I'm just finishing the conversion of a small static HTML site (25 pages) to Drupal. I think things went well. I like the ease with which functionality and widgets can be added (via modules).
Now I'm ready to get started with my big site (300 pages). The problem is, there is just no way this (completed) transfer is going to take less than 6 months to a year. (I'll be updating content and graphics.)
Can this transfer be done in parts, page by page?
How would a visitor's request for a page transferred to Drupal:
be identified and shunted to Drupal:
(example.com/drupal/page100.html I guess)
Whereas an unconverted static html page (example.com/page200.html) not redirected to drupal.
Of course, retaining the original URL (example.com/page100.com) for the pages transferred to Drupal would be paramount.
Are you sure you don't want the Apache forum? ;)
Well, no matter, because the person who is going to answer your question is on vacation. But he will be back before your site is 100% converted.
You have probably already figured out that the most important question is how to deal with the Great Divide. On one side: pages that have been converted and are now going to be handled by your CMS-- here Drupal, though it could be anything. On the other side: pages that are still in static-html form so they have to be ignored by all rewriting. You don't want 300 individual RewriteRules clogging up your htaccess. Sure, it's physically possible-- it's just not pretty.
It would be superb if you could make the change one directory at a time. Then you've got an obvious, visible identifier that all your RewriteRules can look for: this group of URLs go to Door #1, that group go to Door #2.
Conversely, it would be decidedly un-fabulous if you had to rewrite all requests to a transitional php script which then picks out which pages go to the CMS and which ones are allowed to get served up as-is. As with the 300-rewrite-rules scenario, a double-rewrite solution is doable but not pretty.
Does it absolutely have to be done in installments? Is there any possibility of doing the work offline and unveiling the whole new improved version after everything is done? Do you have a lot of dynamic content-- I mean truly dynamic, user-generated stuff, not just php doodahs? Will the change be clearly visible to the user, or is it primarily behind the scenes?
|Of course, retaining the original URL (example.com/page100.com) for the pages transferred to Drupal would be paramount. |
You can use your old URLS if you want to, it depends on how you import the data, there are diff ways, I tried several and ended up doing a manual export - import. Even cleaned up the content before :)
Anyway I migrated thousands of pages with their old URLs to new drupal installations. Check here:
If you already have your content on drupal you can still easily import only the url maps. Not as difficult as it sounds.
Thank you both for the replies. I do have a structure where I can do it one subdirectory at a time.
I didn't put this in the Apache forum, because I don't know enough to realize that's where it belongs.
Thanks again, I'm so eager to get started making this change.
I know it's a different animal but Joomla has tools for
1. Making conversion easier - It will take your pages and bring them into the database with some hand massaging required
2. Tools to help with SEO that will do things like show you 404's on your site and allow you to easily redirect tto the proper page.
Not sure what is available for Drupal
Just FYI -
1. Drupal has a few tools. The Migrate module will let you pull from all kinds of databases, but you'll have to set it up yourself if you aren't doing something common (like Wordpress or something). You can also use the Feeds module to import if you have a feed. But read explorador's thread for more. Sometimes nothing really works but a lot of manual labor. I don't know of anything that crawls a site and grabs page content and puts it into Drupal.
2. SEO tools - not a Joomla user, but Drupal SEO tools are pretty extensive in terms of handling redirects, URL "aliases" and more. From what I've read, my impression is that the SEO tools available in Drupal are more extensive than in Joomla, but that may be old information.
This turned out to be super easy.
Started with a new host.
I just installed Drupal in my root.
Uploaded all my static HTML pages to their original subdirectories in the root.
Set the default handler in .htaccess:
DirectoryIndex index.htm index.php index.html
Done! Zero (new) redirects.
Apache looks for static html URL's first, if it can't find the URL it looks to Drupal.
Now I can convert pages at will. As they're converted to Drupal I just delete their .htm verson, apache defaults to Drupal.
What the bleep? You mean all this time, ALL the pages you were concerned with were directory index pages?
Or are there a couple more lines in htaccess that you've left out? I see how it would work-- and it's pretty ### ingenious-- but I don't see how the DirectoryIndex line alone would get you there.
Lucy, he needn't mean that at all.
The fundamental rewrite on Drupal looks for a file or directory and if it finds it, it doesn't do the rewrite (ditto for WP).
This means that you don't need any special rewrite to keep Drupal from loading when you really want your static page. Even if you have drupal page with the same URL, it will never load because Drupal will never start up to check the database to look for that URL.
The only place you have an issue is the home page. If your order is php then htm and html, like so:
DirectoryIndex index.php index.htm index.html
Then the first file it will hit in root with the naked domain (i.e. no file spec) will be index.php which necessarily must be Drupal. So you have no means of serving up index.htm as your home page on the plain domain.
If you have the order Broadway is using, you can actually have a static index.htm supersede the index.php file, and you only hit Drupal after a specific rewrite to index.php
That of course only applies to the root directory. Elsewhere there's nothing to worry about.
I've done this with older versions of Drupal where caching wasn't any good and the home page was very server intensive (often the case because it can pull so many pieces from the DB). I'd capture the Drupal output with output buffering, create a static HTML page and serve that up with my home page, regenerating it periodically with... actually I don't remember (a cron job I suppose).
Gotcha. What threw me was the word "handler", which I took to mean "If there's a request for php, first check whether there exists a static html page with the same name".