settings from plugins are stored in the database. some plugins can delete these settings when deleted, but none should do so on deactivation.
Yes you can deactivate one at a time, and as long as it’s not a combination of plugins this should work.
The alternate strategy is to create a backup site and test in there, that way you’ll not affect you main site
Here’s the backup and testing strategy that I use.
This lets you
know your backups work,
can test upgrades to theme, plugins and WordPress without affecting live site
Test new plugins and themes without affecting live site
Most (maybe all) host providers let you have sub-domains
I use this to create a testing.mysite.com
CREATE YOUR SITE and copy files/folders
If your hosting provider gives you one click WordPress, install this on the sub-domain.
If you don’t know what database this links to, then look in WP-config, this will give you the details.
Once created you’ll have a base WordPress install. Then if you copy your wp-content directory across from your live site this will give you all your themes, plugins and uploads.
If you cannot create a new WordPress automatically, then do a manual install and create your own database. You can copy across all the WordPress files and folders, but then you’ll need to edit wp-config to point to the new database. If you only have one database, if you look in wp-config this will give you database prefixes, so you can create duplicate tables using phpmyadmin with a different prefix to give your test area. However using two separate databases is far preferable as backup and restore are then painless.
COPY THE DATA
So now you have a testing domain with all the files and folders that you live site has, but you need to copy the data.
So do a phpmyadmin backup of your live site database to your PC – this is good practice to do each week in any case, and after any upgrade or serious alteration/addition to your site.
Then in your test database you can restore this. If this is a different database, then you can simply restore. If both sites share a database but have different pre-fixes, then restore needs much more care and attention to ensure you don’t overwrite your live site, which at best will mean you test site is wrong, but at worst can corrupt you site or take you back to previous backups.
CHANGE THE SITE REFERENCES
Now once restored, the test database with have the urls of your live site in the Wp-options table – you need to change this.
In you mysql enter the following command
UPDATE wp_options SET option_value = ‘http://testing.mysite.com’ WHERE option_name IN (‘siteurl’, ‘home’)
Where testing is your subdomain and mysite your site
That’ll get the site pointing correctly, but all the references for media will still be to the live site. So in your test site upload the velvet blues plugin – just search within plugins for it.
This gives you a tool where you can easily change all the urls in one easy move. Change the url from http://www.mysite.com to testing.mysite.com
TAKE OUT SEARCH ENGINES
Finally in dashboard>settings>reading change the serach engine visibility to discourage search engines from indexing your test site.
GREAT now you have a backup and testing site !
It mirrors your live site, so any changes can be done here first.
So can you can test upgrades to themes, plugins and wordpress without affecting live site, add new plugins and play with them and alter themes without affecting live site.
But alongside this, if you regularly backup you live site AND YOU SHOULD, you can do test restores to the test site. This means you can have confidence that your backups work, so stop the heart-thumping when that critical restores looks like it’s hanging.
This simple methodology should mean that you now upgrade with confidence, and can play with your site more boldly, doing everything in testing first, and only committing to live once you have satisfied yourself that it works !
Having a test site should be standard for any live site that the owner isn’t happy to see crash.
