Prefer video over text? We got you covered – here’s the whole article in a short video.
If you prefer, you can watch the video using vanced youtube.
Installing a plugin (or theme) means that you are entirely trusting your site into the hands of their developers. There are no restrictions on what the code you’re putting on the site can do. It can move all your buttons to the left by two pixels because of a CSS bug, but it can also purposely wipe out all your files and the entire database. Installing plugins from the official WP repository eliminates chances for the second scenario, but it still leaves you wondering – what changes did a plugin make to my site?
In practice, what changes do plugins make?
Before the realistic scenario, let me repeat the theoretical one, one more time. You are installing and activating a 3rd party piece of PHP code on your site. There are absolutely no limits on what the code can do as long as it’s in the realm of PHP and it’s capabilities and privileges on the server. It can certainly delete files, modify them or send them to a remote server. Same goes for the data stored in the database. You can’t stop any of that once the plugin is activated. So, don’t use nulled plugins or themes and if you’re installing sketchy plugins on a live site make a backup first.
Installing plugins & themes from sketchy sources like GPL dumps or any illegal sites is never a good idea. If you’re brave enough to install them on a live site, please, make a backup first. Or, be even smarter – test them locally, on a staging site or somewhere where they can’t do much damage.
Now, onto more day-to-day stuff. What do plugins do when you activate them? Bigger ones create custom database tables. Custom tables are common and expected when the plugin needs to store larger amounts of data or data that doesn’t fit the key-value scheme of WP options (or CPTs). Almost all plugins create new rows in the wp_options table by utilizing the WP options API. Completely expected and normal. What’s not expected or normal and it should never happen are modifications on the 12 core WP tables. Like WP core files, core tables should never be edited, either by plugins or by users. Plugins also add transients, create custom post types, add widgets and menus. They do all of that using various WP APIs, and the data gets stored in the core tables.
Why would I care what changes a plugin makes?
If you don’t care about plugins’ quality or the various ways they affect your site, including speed and availability, then there’s nothing to worry about. If you’re vetting a plugin that’s about to get installed on tens of sites you manage, then you’re probably interested in how it’s built and what it does “behind the scenes.” Doing a full code audit is the only full-proof way to know what’s going on but I know that’s not realistic in most scenarios.
Looking at changes that a plugin made gives you insights into how it’s using your server resources, how clean the code is and for instance how (or if) does the plugin clean after itself. It can also help you answer a frequently asked question: “I’ve recently installed plugin X, and I think my site is slower now, is it because of X?”
Last but certainly no less important reason to learn about changes is reverse engineering and learning. Maybe you want an installation procedure similar to the one you’ve seen on another plugin, or you’re just keen on knowing how it does something.
Database snapshots to the rescue
A database snapshot is a copy of currently used database tables stored in the same database that WP uses. Snapshots are very similar to backups but created with a different purpose. Backups mostly exist for “what if” scenarios. Snapshots, on the other hand, have a more eminent usage. When you create a snapshot, you’re likely to revert the system to it after doing some testing, or you’ll use it to compare two version of the database. A similar concept in Windows is called a restore point.
Please note that database snapshots, as the name implies, only deal with the database. Files are not backed up, saved, compared or touched in any other way.
Lets compare!
You don’t need a tool for making the comparison. It’s possible to do it manually by downloading two versions of the database and then comparing them. However, after doing that a few times it was such an unpleasant experience that I sat down and wrote WP Reset’s DB Snapshots. With WP Reset, the comparison takes just a few clicks and requires no technical know-how.
1. Install & activate WP Reset
The fastest way is via WP Admin – Plugins – Add New and type in “wp reset” in the search; it’ll be the first result. Alternatively, grab the latest version ZIP or head over to wordpress.org/plugins/wp-reset/.
2. Make a snapshot of the current state of the site
Open WP Admin – Tools – WP Reset, then switch to the DB Snapshots tab and click “Create New”. If you’re testing a new plugin, name it something like “before plugin X”.
3. Make some changes to the site
Install a new plugin; activate a new theme; make some changes in existing plugins or themes; create content; mess with widgets – nearly any change you do reflects on the site’s database, and you’ll be able to compare the before and after state.
4. Compare the new state with the saved snapshot
Go back to WP Reset snapshots and click the compare icon next to the saved snapshot. You’ll get a color-coded list of database tables.
Green tables are those that exist in the current database and the snapshot, and they didn’t change one bit. Red ones are those that are either missing from the snapshot (meaning they were just created) or are missing in the current database (so, they were just deleted). Orange ones are the ones that changed, either data wise or less often, scheme wise. Clicking on any table reveals more details about the changes.
5. Don’t like the changes you see? Revert them!
If you want to get the site back in the state it was when you created the snapshot, use the restore action next to the saved snapshot. It’ll get the database back in its previous state, and all changes are gone! Quick and painless.
More use-cases for database snapshots
Determining changes is just one of many ways database snapshots can help you in development and testing. By reverting to a snapshot, you can always get your site in the state it was before the (problematic) changes you made. And it’s done in two clicks and a few seconds of waiting. Whenever you need a complex testing environment that gets heavily modified after a certain action reverting to a prepared snapshot enables you to re-test within seconds. If needed you can also download snapshots as gzipped SQL dumps. Although their primary purpose is not to make backups on live sites – in a pinch, that can be done too. A detailed diff is available for modified table schemas and for data in wp_options table. Universal diff, for all tables, will be available in one of the next versions.
As a reminder – here’s the short video we made to showcase snapshots.