Some web hosting accounts allow you to create subaccounts with separate Filespaces, i.e. – isolated from each other. If you have one, take advantage of it, and create your test WordPress system on a separate Filespace. You don’t even need another domain name as alternate access will be provided with a /~user/ type URL construct.
I am a huge, huge fan of Test Systems. But, in the wrong hands, without some careful attention to detail, you can end up changing your “real” WordPress system when you think you are on your test system. Something as simple as forgetting to change the Blog URL field in the Admin Panel, or forgetting to change the database name in the config file. Especially for those of us who create clone Test systems by simply backing up database and files of real system, and restoring it to the Test environment.
Shouldn’t there be a way to code (in the automatic upgrade) a way to check things like php and mysql versions and give a warning? Also, before the upgrade starts, either tell people to deactivate their plugins, or do it automatically?
“…WordPress 2.9 requires MySQL 4.1.2 or higher…” So this is checked before install according to some problem postst. I don’t know about checking of the minimum PHP version.
@adiant: thanks, it is always a choice between two evils 🙂
Great post, however i do see one problem, which i’ve not seen anyone address (and maybe it’s simply that not many users have considered it), is how do you keep hold of plugin settings if you disable said plugins.
What i’m getting at here, is that, in some instances, de-activation of a plugin instructs the plugin to also remove it’s existing settings from the database.
If you wish to maintain plugin configuration, and deactivation initiates a flush of settings, how can you then maintain plugin configuration whilst keeping inline with the suggested upgrade guidelines.
I’m also a supporter of plugin developers who clean house when you deactivate their plugin (i do it when i write a plugin now), but how can you maintain important configuration settings if you are advised to deactivate said plugin when performing an upgrade (which in effect deletes your plugin’s configruation).
Personally i leave my plugins enabled when updating. I only have self written plugins, which havn’t broken yet during any update process (lucky me)…
Be interested to hear your opinions on this..
I prefer the plugin to maintain settings even if deactivated … clean out db only when plugin is deleted.
I would think having an option in the plugin that gives you a choice of whether to remove or maintain settings on deactivation would be favorable. Of course this still relies on users remembering to check or uncheck that option in the plugins configuration page before doing an update and disabling said plugin.
I’m curious whether this scenario was taken into consideration when recommending users deactivate plugins inline with upgrading their WordPress installation.
Should plugins give the option, should plugins ever remove their own data? If they should, then doesn’t this mean you lose configuration settings every time you upgrade? ..
Good point t31os_
My plugins are “low” on Dashboard settings (only Shutter Reloaded) but heavy on site showing impact (commands worked into my theme files, like The Excerpt re-reloaded.) When that one breaks, half of my site is not showing, so I have to test beforehand. I am working on reducing plugins. Too much of a hassle when upgrading.
In general, deactivating should retain the settings. Deleting should clean up the database. This is from a WP/users view. Most plugins however don´t. I can see that in my wp/options table on the test/site.
The reason i brought it up was that i remember reading a discussion recently (hackers mailing list possibly) where community members/developers were discussing how useful it would be if plugins took some initiative in removing their data upon deactivation.
It did dawn on me that if authors were to start adding this ability to their plugins then it could become problematic when guidelines for updating suggests deactivation.
Not a problem to be worried about right now perhaps, but maybe one to take into consideration for the future.
Well, as a matter of old principle…always backup before ya do anything serious. 🙂
I’ve pretty much had a static site just serving images and some d/l’s for the last couple of years, but I’m considering getting back into things using WP.
The first thing I did? I created and downloaded a complete server backup from CPanel. All 809,830,400 bytes of it. At today’s connect speeds, that took just a few minutes to do, and only couple more to burn a DVD of it to be double sure.
Another thing ya can do if you have the space is simply dupe your whole home dir to say /home_bak or something and then if things go bad, just overwrite the mess with your backup. Ez Peezy.
Now, if drunken aliens (or drunken me) hose my install, it’s assured it can be fixed.
Cheers,
~DG
Oh, forgot…if ya do dupe your home dir, be sure to export and download a copy of your MySQL Db as well….Good files + Crap Db = Crap.
