Drupal 7 was released for "production" a little over a year ago at the Drupalcon Chicago. Upon returning from that event, I put a week or so into trying to convert from Drupal 6 to Drupal 7. This produced a series of disappointed-sounding blog entries as my attempts failed. I kept trying every few months, hoping that a new D7 release, or an improvement in my Drupal skills, would yield success.
I've finally succeeded.
I implemented an AMP stack on my Mac. "AMP" means "Apache," "MySQL," and "PHP;" it required me to install MySQL and hook it all together. Then I moved the laborious conversion process to my desktop. My efforts succeeded a few weeks ago, but I was stymied when I tried to deploy the converted site onto my GoDaddy hosting. I finally tracked the problem down - where else - in the .htaccess file defaults.
My main reason for going to Drupal 7 was my curiosity about the Semantic Web, and a desire to make use of D7's built-in RDF support. I'm still not sure how I'll be using it, but now at least I have a starting point.
Another reason was that D7 incorporates the "Content Construction Kit," a previously-separate Drupal module for adding new fields to D7 database entries.
Yet another reason was that D7 incorporates an on-line update mechanism for modules and themes. I can just go to the Updates page and install the updates directly. I still have to go through the famously ugly process of manually replacing core files to do a core update, but at least they've automated some of the update process.
In any case, I knew I'd want to convert to D7 eventually, and the conversion promised to be ugly. I decided I'd get it over with before I spent too much time customizing my site.
Two things significantly delayed my conversion: a series of database problems and a .htaccess problem.
The database problems arose because the Drupal 6 database contained things that the D7 conversion process did not expect. I saved one error message about there being a "role_permission" table that wasn't expected to exist. There was a similar error that cropped up about an unexpected index in the "system" database table.
I eventually got rid of all of the database problems by judiciously hunting down the errors listed by the Schema module's database checking. The Schema module apparently looks at a description of what the database is supposed to contain and compares it against the database structures that actually exist. It identifies database tables created by now-deleted modules, it finds mistyped or mislabeled data fields, and reordered index definitions.
I taught myself enough of "phpmyadmin" to go in and administer the MySQL database. I deleted the numerous extra tables and indices and misdefined thingamajigs. When finished, I'd fixed everything except an misbehaving index definition in the "blog_api" table. I couldn't figure out how to fix it.
But the changes I made allowed the conversion to succeed.
The .htaccess file belongs to the Apache web server. If it's wrong, Apache might not be able to find the files that make up the web site. That's generally the sort of problem I encounter. Another problem I've run into are failures of "rewrite rules." When you type a web site URL that contains nothing but letters and/or digits interspersed among several slashes, Apache is rewriting the URL. Thus, if the rewrite rules fail, then Drupal (or WordPress) can't figure out what page you really want.
Another problem I encountered was that Drupal couldn't find formatting information. It would retrieve the home page and display its contents, but it appeared as plain text interspersed with imagery.
I tracked this one down to the "RewriteBase" instruction in the .htaccess file. Both RewriteBase instructions were commented out and disabled (a # character in front of the text). When I enabled "RewriteBase /" everything started to work.
I blame the .htaccess problem on environmental differences between the Mac-based AMP stack and the GoDaddy stack. The default .htaccess from the D7 distribution works pretty well, except that