Preparation & Data Preservation For WordPress .gz rRestoration

1 Views

I have encountered a “problem” (fussy client) with a WordPress site and I will be restoring it back to a downloaded .gz database from two months ago. Now, in my work since then, I’d installed a new theme and created custom post types. The new theme has a number of custom CSS settings, and the custom post types have a number of files.

Since I’m doing a database restore to a snapshot before the new theme and custom post types existed, I have a few questions:

Read More

-Will this restore all setting to how it was configured at the time (general, reading, discussion)?
-Will the plugins that were added later just be deactivated?
-I’m guessing the new theme will still exist since its files are physically there. Will any settings on the new theme get erased with the database restore or will they stay and the theme just gets deactivated?

It’s a messed-up situation and I basically want to restore back to August but archive my work on the new theme and custom posts if possible. Thanks!

Post Views: 1

Related posts

Leave a Reply

1 comment

  1. If you restore the WordPress database, you will change all of your settings back to the way they were at the time of the backup. The reason for this is the wp_options likely contains your theme options and definitely contains most WordPress settings menu options (permalinks, reading, etc).

    The plugins that were added later will be deactivated – there is a record in wp_options called active_plugins which is an array of your active plugin. Overwriting this value will disable new plugins, but as long as they are in the /wp-content/plugins directory, you can re-activate them, albeit with their settings missing. The same goes for your theme – as long as the files are there you can re-activate, but the missing options values will mean the settings are gone.

    Now for something for helpful. First, definitely make a backup of your site as it exists now before you do anything else. Once you have a backup, rather than dropping the tables, etc, you can try renaming this schema so that it won’t conflict, and then restore your backup to a new schema that contains the original name (the one WordPress is configured to use now). With two schemas on the same server, you can now run queries to compare the current database values and the restored database values as well as insert them where necessary. Assume your restored schema is called restored and your current schema is called current, the following cross scheme query would show you any settings that don’t exist in the restored schema:

    SELECT co.option_id, co.option_name, co.option_value, co.autoload  
FROM current.wp_options co
WHERE co.option_id NOT IN 
    (SELECT ro.option_id FROM restored.wp_options ro)

    Add in some WHERE co.option_name LIKE 'key_% type queries to extract certain sets of values if you wanted to copy them into your restored schema. You might want to take a look at the wp_postmeta values in a similar way, or even compare values from the wp_options table where the ID/key exists, but the values don’t match to see what changed.

    Good luck!