Hello all,
I have a curious situation on my hands, one that I'm worried will come back to haunt me when I update the Drupal core. I'm hoping more experienced Drupal users out there can offer advice so I can avoid finding myself up the creek without a paddle.
I'm presently running Drupal core version 6.22 and need to run updates (current version is apparently 6.26). My site is running in a shared hosting environment. Back a while ago the server I was on (a Windows server) was becoming so slow that I couldn't even flush my caches without running into timeout errors. The host agreed to move my account to another server (affecting the files and the server only, not the MySQL database), which solved that problem. The response time is much better. The trouble is, the environment on both servers was not the same. The server admins had to do a bit of quick tweaking (bringing back mod rewrites for the URLs, changing my application pool from 64 bit to 32 bit or some such thing) before the site would even function properly.
Currently everything is working fine--almost. In the Drupal console, when I try to view blocks (i.e., navigating from site building -> blocks -> block viewing page), the page blanks with a 500 internal server error. I've been getting around it by simply updating my block content directly in the database (and am fortunate that I don't have to do it often).
What I'm wondering is the following:
1) Does anyone have any idea what server setting might be amiss if simply trying to view blocks in the Drupal console results in a 500 internal server error? It was working fine on the old server, so I'm assuming it's not a programming problem, but one resulting from a setting. I don't believe I have any special modules installed that interact with blocks, specifically, that might explain this conflict.
2) I've noticed that the security update for 6.22 affects the blocks module. I'm worried that, if I try to run the upgrade, that 500 internal server error will cause the update to die at a critical point, and I'll end up with a corrupted Drupal installation. (Yes, I know--I will back up the site files and database, but if I can somehow avoid the sickening conundrum of having to redeliver the site from backups, that would be preferable).
3) Are any of my fears founded? Or am I worrying without reason, since it's an update?
Any help, advice and reassurance would be welcome. Thanks!
Comments
Unlikely the update will be a
Unlikely the update will be a problem. Usually a good idea to back up code and database before updates. It is odd about the server error and there is more than one possible reason. If it is corrupted code the update might actually help.
I have recent experience of a database update or move disabling a key module 'automatically' so if you are sure there is no code missing that is something to check. There is often a clue to this type of problem in the Drupal Reports > Recent Log Messages, or in the server error logs.
As for fears, it is 'unprofessional' to update a live site without running the updates on a test site first. I sometimes do it (depending on how mission critical the site is, whether the client prefers to cut corners to keep costs down, and knowing in advance my available recovery methods in the event of a crash). Choosing to live dangerously by updating a live site without testing first always involves well-founded fear, since you ask :P
Digit Professionals
Thanks for the advice, John
Thanks for the advice, John B--I greatly appreciate it!
Yes, I have a client that works on a shoestring budget, so I'll confess I have been living on the dangerous side (at least with module and minor core updates). I have looked in the logs, and haven't seen any errors that hint at missing code or failed functionalities (even after I trigger the 500 server error).
I'm also thinking it would be wise to make a test site via a fresh install, especially in this case where I'm on a different server. I'm compelled to believe that if the installation is done fresh on this new server, then the install script itself might "sense" what led to the 500 error and tweak some setting that avoids the issue completely. Your advice has given me the incentive to do that :)