i upgraded drupal from 5.2 to 5.5 last night. there have been 2 security updates that i didn't feel were enuff to bother with, but since i intended to install and upgrade a few modules, i thought it best to start off by upgrading the core. this is all in the UPGRADING.txt, so the chronology that follows is meant to serve as an expanded reference for anyone who gets stuck along the way.

pre-upgrade

- back up the sql database: this contains the essence of this site. the content itself, and every admin config setting that departs from the default drupal install. thank goodness for phpmyadmin; since i'd rather not bother with mysql command line stuff at this time, i'd just as well install phpmyadmin. which i don't have to (yay) cuz dreamhost is just that swell.

- back up the site files: tgz the drupal instance; this contains the drupal codebase, modules, and themes (including the luvly one ur seeing now), and any article attachments (screenshots). no sweat here, bigups again to dreamhost and the package with a shell. tar/scp/ba/da/bing.

the importance of the previous two steps should not be overlooked. i ran into a couple problems with my upgrade, but being able to restore the site, both codebase and database, from these two archives above, was a huge relief. as things are starting to break left and right, and ur understanding of things is unraveling, it suprised me that u could drop and re-import the db, remove and reuntar the site files, and presto the site doesn't kno u tried (and failed) to tinker with it.

the upgrade

- make a copy of stuff beyond the core: this whole process learned me about keeping addon modules and themes in the sites/all or similar directory, as it's much easier to maintain. at this point you could copy out ur /sites dir, uploaded /files dir, and .htaccess (if u've made any edits to it), and move on to the next step. if u haven't yet discovered this ability to merge sites/all/modules or sites/all/themes subdirectories with the core (i hadn't) then u'd need copy ur /files and .htaccess, plus single out any non-core modules and themes individualy and keep them nearby. be absolutely sure not to carry over any old core modules, since overwriting new core modules with old ones is bad; this is avoided entirely using sites/all/modules instead of mixing conrtibuted and core modules in /modules.

- put on ur supercap the next couple steps need to be done from user with id 1, and u shouldn't close ur browser until the upgrade process is complete. u'll need to run the upgrade.php, as only user:id1 can do, and i don't want to think about how u'd get logged back in if ur session was dropped (/user i guess, that's the default login page).

put the site in offline/maintenance mode (admin/settings/site-maintenance), ur about to disable modules and revert back to a core theme, and u don't want to scare (or confuse) viewers. this is particularly important for me since i use a module to filter content from anonymous users, and the content would be exposed while the module is disabled.

disable contributed modules and switch to a core theme (bluemarine or garland). the upgrade may not be compatible with certain modules, or they might have their own updates, at any rate the upgrade effort should be isolated, so that core upgrade issues can be sorted before being confronted with any issues brought about by modules or themes.

out with the old, in with the new. then bring back some oldies. keep things nice and tidy by emptying ur site root, and starting fresh by extracting the new 5.5 codebase in to ur site root. then put ur sites dir back and turn ur attention back to ur browser.

update.php: hit this file from a proper url in ur browser, and it should detect ur version stuff, and let perform any updates to the databases needed. u'll want to revisit this after updating any modules, as they occasionally need to update dbs too. if your update worked, then good for fuqn you; you can enable ur modules (if compatible, might need some more updates), take ur site out of maintenance mode, grab a cookie and go outside and play. i'll be out in a minute, after i s'plain what went horribly wrong with my upgrade.

update.php is blank! (or empty!) this sucks. proceeding to poke around in the site, it was running from the 5.5 codebase, but it saw itself as 5.2. hmm.. it sez the db schema is up to date, but that i guess means up to 5.2 date. well best figure out why update.php is blank. a'ight, firstly, in backing up my 5.2 modules, i pruned the core modules from the contributed (since all my modules were in /modules), but i actually lost the prunes. i did a locate, which din't find em, and scratch my head as i think to myself how long overdue i am to sit down with the proper find command, tho this wasn't the time.

i later found them: i had missed watchdog as a core module, and had put a modules dir inside watchdog with the rest of the core 5.2 modules.

omfg what a retard. ya ok well i browsed my buffer and i can't see where i did that, so it is indeed a completely retarded move, that i can't explain.

the problem this caused was twofold, which all relates to a third. firstly overwriting the new watchdog with the old wasn't good, ok shame on u. no biscuit. duping all ur other old core modules inside the old watchdog, well, again that's just retarded. but these problems, i discovered here, were complicated by drupal seeing modules as moved, and not unseeing this and acknowledging their previous, original, and proper location. therefore, not only where they seeing the wrong ones, but clearing out the old ones made it think they were gone altogether, as it didn't fallback to the default location. boo-hoo none of my cached pages will let me unfuq my site! well it's a damn good thing i backed it up, cuz i restored the code and database a few times while figuring all this out.

in my debugging, i was also lead to this comment, which mentions how to turn on the verbose output for update.php, which compliments the ability (documented before the fold in the file itself) to turn off access control (user id 1 access only).

starting over after the upgrade. after sorting the module mess out, updating them was straightforward, except simplemenu choked. i use simplemenu to give a menubar near the top of the page, this in and of itself is whatever, easily sacrificed, but having submenu access to drill down thru all the drupal admin menus is immensely time-saving. i remembered back when i first set up the module, and styled it to my liking, that i ran into a similar problem, and had spent a fair amount of time researching it. welp, not having taken any notes, and not being able to get it working thru brief alterations of it's css, i was ready to kill something.

either simplemenu or my theme had to go. this judgment was premature, but it eventually held up. the problem was that in ie6, the menu did not appear as a horizontal bar, but line wrapped or whatever and each item took up a full page width, wrapping down as many lines as there were menu items. more research indicated that it was a bug with the latest simplemenu, and that deleting a line in each of it's css files fixed it.

it was good that i had allready come to terms with starting over with my theme; i've learned a lot since starting it, there's a few techniques i'd allready ditched due to complications, but ultimately it was born out of vengeance and has long since run out of steam.

in the end it's all for the better, i'll be able to do a couple more fancyish things around here, and i aim to start completely fresh with the css, which will really open up the elbowroom, and the ability to use multiple themes either across site sections, or as a user selectable option.

that's wassup, i'm burnt and need snooze before proceeding.