Drupal 6

Following my first look at Drupal 7 and my notes on building a "sandbox" Drupal 7 site, here's a report of my next stop in going 7: upgrading a site from Drupal 6 to Drupal 7.

Someday you'll likely want to do the same. But this is a major upgrade, not a trivial "Drupal 6.19 to Drupal 6.20" kind of affair. "Yeah, one of these days I need to get around to that", you say... while your poor D6 sites fidget anxiously... like nervous freshmen huddling outside the gym locker room... fearing the gauntlet of cackling seniors daring them to walk on in.... 

Oops, sorry; serious flashback. Anyway, a major upgrade is a can't-avoid-it-forever exercise, so let's charge in. I ran into problems during my experience (gee, there's a surprise : /  ), but I managed to fix them as outlined below. If you've got a Drupal 7 installation running and are ready to uplift an old site or two, read my tale and let me know if it's of any help!

Here's a checklist I used when quickly setting up a new sites in Drupal 6. It's appeared on this site earlier, but buried away in an obscure older page (Checking out Drupal 6: Dipping into new site creation); I'm moving it here so it'll have its own page that I'll remember (?) to update more frequently.

I hope this'll be helpful to Drupal beginners who are unsure what key tasks they should consider after installing Drupal. Bt don't dive into the list just yet! Some pretty important disclaimers come first:

Read these first!

1. My checklist is for sites built upon a copy of my existing Drupal "sandbox" installation. That's covered in the first few items of the list; Drupal installation from scratch isn't covered. Chances are you might need to replace items 1-4 with the standard procedure for setting up a new site.
2. My sandbox database already includes lots of things set up that I almost always want for a new site: can't-do-without-'em modules already enabled, input formats created, key content types configured, and so on. To better aid readers, I'll add those into the list over time.
3. The checklist represents just the basics to build the framework for a "generic" new site (to the extent that such a thing exists). After that comes the real work of web site creation: customizing and building all the features specific to the new site! That, of course, can't be covered here.
4. The list makes sense for the sites I typically make; it may be all wrong for you. Treat as reference and entertainment. (And parts may be all wrong for me; let me know if I'm doing something dumb and need to stop!)

The checklist

Here we go:

1. Create directory for the new site within Drupal installation (per general Drupal installation procedures)
2. Create empty database for the new site (via my ISP's online tools)
3. Import a copy of my sandbox site's database into the new database (via phpMyAdmin)
4. Make sure new site directory's settings.php file uses correct domain and database info
5. Log in to new site (Unasked-for tangent, and admonishment to writers everywhere: Note that that's "log in to site", not "login to site". Major pet peeve. Grrr.) 
6. Change ID 1 user info (which is still the same as sandbox site) to new info appropriate for new site
7. Put site in maintenance mode at admin/settings/site-maintenance
8. Enable or disable key modules at admin/build/modules
9. Handle any pressing warnings/notices tossed up by Drupal
10. Change site info at admin/settings/site-information
11. Enable and select theme. If an existing theme will be modified into a new unique theme, first create and rename a copy of the theme within the new site's themes directory. 
12. Make sure file system at admin/settings/file-system is set to sites/<domain>/files
13. Set site's meta tags at admin/content/nodewords, including Description under Front Page tab (requires Meta Tags module)
14. Set site's contact info at /admin/build/contact
15. Change sandbox site info at admin/settings/forward (requires Forward module)
16. Get Google Analytics ID via Analytics account, add at admin/settings/googleanalytics (requires Google Analytics module)
17. Set XML Sitemap, submit to Google (requires XML Sitemaps module)
18. Remove unneeded menu items (left over from sandbox setup) at admin/build/menu
19. Make sure email for site works
20. Once all is working, turn of error logging to screen at admin/settings/error-reporting

Steps after that start getting pretty site-specific, so the list ends there. The important thing is that the above takes me to a functioning beginning, without my having to think hard.

What's your (probably better) site setup checklist?

Here's a typical error message that can pop up, for authenticated and anonymous users alike, when Drupal chokes on something:

warning: array_map() [function.array-map]: Argument #2 should be an array in /home/your-directory/your-Drupal-installation/modules/system/system.module on line 1015.

The latter part of the path, modules/system/system.module, is generic to any Drupal setup. But the former part, /home/your-directory/your-Drupal-installation/, refers specifically to your own directory setup. That's obviously useful to the admin (should he for some reason not know the path), but is it wise to be revealing such directory info to strangers?

I can't say offhand what that extra info means to a malicious hacker. But following the general maxim of giving such malcreants no info they shouldn't have, is there a way to stop Drupal from revealing paths in its error messages?

Long overdue: A site face lift! This is just a first step: quick, slap-it-up application of a new theme. You're looking at a polished theme by pros: Tapestry, from the good folks at RoopleTheme. Want a theme built from the ground up for easy modding? Check out this feature list... which I'll introduce shortly. The RoopleTheme site appears out of action at the moment. (Probably something I did. : / ) 

Next, more changes to make things more to my liking. A little more white space to de-clutter things, more oomph in the content headers... and, oops, I've neglected to put my secondary menu anywhere. Forgive sudden jumps and spasms in the layout as I tweak the live site.

In this earlier Drupal Question, I lamented how changing a site's Private download method to Public resulted in non-displaying images with wacky URLs. Well, the problem is solved... or at least, it's just not there any more. Why? Well, maybe you could help explain. See the link for the full description of the problem and the new solution-of-sorts.

No closure, just working images. I guess that will have to do.