With tax season over, We’re now back to just one constant in life: Issues come up when upgrading ExpressionEngine. Many problems turn out to be a case of skipping a step in the documentation, but sometimes things go awry for other odd reasons. Here are my top 6 ExpressionEngine upgrade Gotchas: Things I have learned go wrong, the hard way.
1. Zero-Byte Transfer Ghost
I have run into this problem several times when transferring the latest Expression Engine upgrade files to the server. I usually use Transmit on a Mac to FTP files to our server. Every once in a while, a file will randomly transfer “correctly” but empty—with 0 bytes in the file. The upgrade works, but later, I’ll receive an error message somewhere inside EE and I’ll have to dig deep to find out that it is just a file transfer gone badly, wasting much time that could be spent doing anything else and having much more fun.
Solution: I now transfer the files in a compressed archive and uncompress them on the server side. I know that if the archive uncompressed properly, then all the files are there in full.
2. Active Database Deletion
I manage 50+ different ExpressionEngine sites on many different hosting platforms and servers, and I always set up (at least) two databases: eedb, and eedb_bak. When it’s time to upgrade, I copy the eedb to eedb_bak, then run the upgrade, so rolling back (when necessary) is a snap. Once, though, a new client had an existing EE install that was set up just like that… except the current database was the one called eedb_bak. Hilariousness ensued… not really.
Solution: Now I *always* double check the config.php file to make sure that I’m backing up the current database to the right place. Rush calls to get a database backup restored are not fun.
3. So Many Details
The most time consuming and tedious part of the upgrade is making sure that all of your third-party add-ons (Modules, Plugins, Extensions, Fieldtypes, Accessories and themes) are transferred and functioning properly. It is a little easier in EE 2.x since it you’ve got a single third_party folder in system and in themes, and most add-ons are now updated to use these; plus, you can move these folders now. But it’s still a significant part of the process, with lots of room for mistakes.
Solution: For now, just keep good track of add-ons. In the future, perhaps EllisLab will integrate more functionality into EE and make some common add-ons unnecessary.
4. Database Too Large
In upgrading from EE 1.x to EE 2.x, you may run into an edge case where your database changes are too large to be handled via the browser. If this happens, you may have to use ssh and run the upgrade on the server with command-line scripts. This leads to possible issues with file permissions, and is a detour that, while it works, takes you off-roading and slows you down considerably.
Solution: This *is* the official (and functional) EllisLab solution to a timing-out problem, it’s just a tricky, that’s all.
5. Upgrade Blindness
This happens when you go through an upgrade process for a client, run into errors along the way and then have to rollback, troubleshoot and repeat the upgrade again. This might happen a few times, depending on when the upgrade fails and how far you make it each time. Eventually, you stumble because you forget to reset something that needs to be done, or you skip a step because you think you’ve done it already (and you have, just no this time.) This might include forgetting to reset the database, the config.php file, resetting the file permissions, re-syncing the file manager directories…
Solution: Document carefully each step, and tick them off as you go backwards and forwards. Sometimes it’s the simple solutions that work best.
6. Turning the Site Back On
Last, and perhaps even least, is a tiny little oversight that I must sadly admit has happened more than once over the years—specifically on very small, simple sites. You turn off the site in the control panel early in the upgrade process, and then you run through your upgrade. Perhaps the upgrade runs into problems and takes longer than expected but you figure everything out and it goes overall quite effortlessly. At last, it’s all working perfectly on your end. You wipe your hands and tell the client it’s done. The client replies that the site is still down. Horrors! Suddenly, you remember that as a superadmin, you see the site regardless of whether it’s turned off or on, and you did all your testing while logged in.
Solution: Turn the site back on, dummy!
I hope this helps save you a spot of trouble, and I’d be interested in hearing what “gotchas” you’ve encountered!
Comments