I also deleted some very out of date Gallery installs, so there are likely now some pages on this site that will have some broken links or images.
Just did a little site work today. I now have my microblog hosted on this site instead of a subdomain. I also integrated Own Your Gram to start importing my instagram pictures. I don’t have all of them, and I will look into that, but for now this is configured to get anything new.
I’m starting to dig the #indieweb movement.
Some time in the last 6 months I was finding that cron would get stuck and not complete in the hour. Another would get started and block. Eventually my webhost stopped spawning processes for my user which lead to weird errors on my web page (page not found errors).
I was logged in as me, not the uber administrator when I started messing about. I cleared the cache tables, including the cache_menu table. I was planning on rebuilding the cache table, then the menu system. I was logged in with the wrong account, and I couldn’t remember the administrator account. Since I had thrown out the menu system, I couldn’t navigate to the lost password page.
I had royally messed up my site.
I fixed it by going into the DB and copying the known password from one user to that of the administrator account. I logged in as administrator, ran cron.php manually, then hit up the page to rebuild the menu system.
So far so good. The next day I ran into this tip: How to reset the password of user 1. A little DB query action to set the administrator account password.
I am still having the weird cron blocking issue though. Every couple days I just log in to my web host and kill the running processes and then everything runs fine for a bit. Bandaid solution that is labour intensive.
I can’t figure out how to debug cron issues in drupal though. I’ve read some tips that running update.php can reset things, but that didn’t work for me. I’ve read this page that suggest modifying core files to add more logging about which module is running cron. I think that will be my next step.
Changing this in the database proved daunting and fraught with danger. While I was reading the Using Drupal book I discovered the views bulk operations module.
This module provided the ability to change the owner of a node. A light bulb went off and I quickly realized what needed to be done.
I set up a view to see all nodes (content) on my site. I then configured the view to allow bulk editing, and chose the “Change the author of a post (node_assign_owner_action)” operation. I tested this a bunch before enabling this view. The main issue I found was that I couldn’t target content for a specific userid. Instead I targeted content for the currently logged in user.
I then created a new_gfox account, and then when I was logged in as my first account started using the view to assign the content to my new account. A few minutes later I was done.
It was pretty easy to do this once I had the missing piece of the Views Bulk Operations. After the assigning was all done I renamed my first account, then renamed my new account.
The only unfortunate side effect was that the notification or subscription module went berserk with all the changes and sent out a ton of email to people who were subscribed. Woops, should have disabled that for a few minutes.
More strangely, I am using the image module to store the photoblog I created for project 365. That image gallery is not showing the images any more. The image tags are missing from the html. Very weird.
Also, I had some customs views using the views module. Those are gone too, but I did export them from the version 5. Importing fails 🙁
The one that will take the most work is my custom module for showing posts on this date in previous years. I rely on the archive module, which has changed, and has thus broken my module 🙁
Happy to have this site at drupal 6 though
I turned off all the extra modules, changed the site theme to the default, then pointed my domain to another Drupal directory I had with Drupal 6 in it. The actual upgrade was smooth, but I ran into a snag with the image module.
I then backed out of the upgrade. I pointed my domain back at the Drupal 5 install then did a DB restore. This is where it went bad.
The DB restore I chose said it was from 9 hays ago but I had read 9 hours ago. I waited for the restore to complete but I panicked when it seemed to take a while. I started another restore from the next oldest restore point, only to find my database completely empty. It was late at night on a weekend. I made a basic html page for my site and entered a support request.
The next day as I was preparing to head up island for Thanksgiving I checked my DB and saw that it had been restored. Loading my site I found that everything was there. Sure enough, Dreamhost support had come through and restored my DB.
Turns out the restore I had originally attempted was named incorrectly. I still don’t know why it didn’t work when I tried it.
The lesson I learned: back up the DB first! The dreamhost wiki has some information regarding this. I’ve instituted the nightly db backups for almost all my databases. With the script, I can run it just before an upgrade so I have a convenient way to revert.
I haven’t been to interested in Twitter since I don’t really get the point, but I thought I would try it out anyway. So far I can see how it would be more useful if I had a cellphone to post with. For now I will rely on the web, and a couple powershell scripts that I found and modified.
This was a more complicated than usual upgrade, but now that it is done, I am liking it. Hopefully everything made it across just fine. I had to update two of my custom modules (easy), and update my theme, and tidy up a few things.
Excellent. Fun Fathers Day project.