The WordPress themes and plugins market is huge these days. With all that wide range of products available, we sometimes stumble into situations where we’d like to change our mind, i.e. use a different plugin or theme instead of the one we’re currently using.
Eventually we figure out that it’s incredibly tough to replace some of the themes and plugins, because as soon as they’re deactivated, all (or part) of our data is lost, and the new theme or plugin that was supposed to replace the old ones, doesn’t see the data we previously had. So we say that we’re locked in.
This post describes the lock in effect, shows you some methods to identify such themes and plugins. Plus, if you really do have to use one such theme or plugin, we’ll cover some tips on escaping or locking yourself out.
The Lock in Effect and why it Matters
The lock in effect is not a WordPress thing, it’s been around the software industry for ages. A good example is Microsoft Excel versus OpenOffice.org Spreadsheet. The two are somewhat compatible but you’ll still notice that not all Microsoft spreadsheets will open and render fine in OpenOffice, that’s because Microsoft locks you in.
Take Adobe Photoshop and the open source Gimp package. It’s quite difficult to read PSD files in Gimp because of the layers madness, effects and a bunch of other stuff that only Photoshop can read. That’s because Adobe locks you in. Sometimes you’ll have a hard time opening a CS4 file in CS3 or earlier, that’s a lockin as well.
Although Microsoft and Adobe are trying really hard to provide backwards compatibility and compatibility with other software where possible, we should understand that it’s not entirely possible especially with complicated software like that. In each new release new features are introduced which are not easily portable to other packages and older versions.
WordPress has been known for its backwards compatibility for ages. In fact, you’ll not loose your content when you downgrade (provided that you’re using the core features only,) plus WordPress provides several export options that can easily be read by other software and services. WordPress gives you control over your data so you’re never locked in to using WordPress itself. WordPress does not lock you in.
Plugins and themes are somewhat different though, mainly because developers are overlooking the WordPress API and a bunch of features which already ship with WordPress, and tend to reinvent the wheel. Another situation is where plugins or themes introduce some brand new features unavailable in WordPress so they store your data in a unique way which is not what other themes and plugins can understand. If not treated well, the lock in effect can cause loss or corruption of your data, but there are ways to escape it, which we’ll discuss later.
Identifying Themes and Plugins that Lock You in
It’s somewhat tough to identify such themes and plugins. You’d have to sit all day long browsing the different repositories, reading the code, forums and comments, testing each plugin out. Obviously we don’t have the time to do that, so here are a few tricks to speed up the whole process.
Custom Post Types
Let’s say we need a new portfolio website, we’ll go looking for portfolio themes in the WordPress repository or marketplaces. Now, “portfolio” is not a core part of WordPress (while posts and pages are) so a theme like that can create a new post type called portfolio with the title, description, permalink, gallery and other features. Although this is perfectly fine when using the theme itself, in a couple of months we decide to look for a different one.
The new theme is also a portfolio theme with a custom post type too, but registers the custom post type as portfolio_items and as soon as you activate the new theme, you’ll see that all your old items are gone. Bad!
You can easily identify if a theme creates a custom post type by looking at what’s available in the main menu in your admin panel. If you see a new entry, note that it might be available with that theme only and not portable to others.
Post Meta Data
Custom fields are not new to WordPress and many themes and plugins take advantage of that to store additional data associated with a post (or any other object.) While it’s a good technique, keep in mind that there are no naming conventions for meta data keys.
Suppose a theme gives you the additional option to “hide the title for this post” and stores it in the meta table with the hide_title field, cool! But as soon as you deactivate the theme and use a different one, your hidden titles are now all shown. You start looking for a plugin and find one that hides the titles and it works. Unfortunately though, it stores its data under the hide_post_title meta key so you’ll have to edit all your 2,000 posts and hit those checkboxes again. What a nightmare!
New Database Tables
This is one of the worst lock ins, and a good example in this field would be a gallery plugin that creates its own table(s) in the database to store the images data, and what’s worse, its own folder in your wp-content directory to store the image files. Escaping such lock ins is pretty tough, even for experienced developers since they’ll have to deal with SQL and the filesystem.
You’ll easily identify such plugins by looking at the list of tables in your database and comparing it to the standard WordPress database schema. Note that there are exceptions though where additional tables are necessary. A good example is BuddyPress.
There are other things to look out for, like custom shortcodes (very popular in the themes market) and buttons in your visual editor, data stored in text or XML files. Although I consider all of the mentioned above a “bad idea”, I understand that sometimes there’s simply no other way than to use such a theme or plugin. Do look for alternatives though, before making your final decision.
It’s impossible to find an alternative to BuddyPress, or to that super cool events registration plugin that you’ve found. Or a portfolio theme that you really really loved.
But it’s fairly simple to find an alternative gallery plugin that would leverage the native WordPress galleries and use the already existing functionality and build on top of that. Try deactivating it and see if you can still see your images in the media library.
It’s fairly easy to find (or create) a plugin that would bring a set of new shortcodes to your WordPress setup so you won’t have to worry about loosing them when you switch themes, although it will lock you in to using this new plugin.
In any case, plugin lock ins are more loyal than theme lock ins, because you won’t change your set of plugins once every x days/months/years, but you will look out for other themes. So when looking for a theme try and find something that doesn’t ship “with everything”, especially things like SEO options, etc., because that’s the stuff you’ll want to take along with you after you switch to a new theme.
This is why you should prefer a WooCommerce plugin with a compatible theme, rather than a theme that comes with all the shopping features built-in. It’s easier to find another theme that’s compatible with the WooCommerce plugin than it is to find a theme that implements the exact same features in the exact same way. WooCommerce will lock you in to using WooCommerce though, but that’s something you should be able to live with.
Avoiding plugin lock ins is more difficult, but if you do find a couple of suitable ones, do compare the two, see how they store and handle your data. See if they have an export option and see if you’re skilled enough to liberate the data if they don’t.
Locking Yourself Out
Okay this part is quite geeky. I believe that’s it’s possible to lock yourself out of any theme and plugin in 99.9% of the cases, but you’ll need some PHP and SQL skills to do that. Keep in mind that if you have deactivated a theme or plugin, it doesn’t mean your data is all gone, it’s probably still in the database (or wherever) but WordPress just doesn’t see it.
Get familiar with the SQL syntax and make sure you backup everything before trying to escape a lock in. Next, experiment, experiment experiment. If your old plugin has used hide_title and your new plugin uses hide_post_title, you can easily run an SQL UPDATE statement on the post meta table to rename the existing keys. If your old theme was using a portfolio post type while your new theme is using portfolio_items, you can run an SQL UPDATE on the posts table and change the post type of all your old portfolio entries.
Escaping things related to files (like that gallery plugin) is more difficult, you’d have to create a php script that would run through all your existing gallery images and copy or move them into the correct directory, creating an attachment entry for each. Then run through all the posts that reference the old directory and replace the broken links. This is quite difficult and can easily get messy, but that doesn’t mean it’s impossible.
In any case, you’ll have to read through the code of the old and new themes and plugins file to figure out what they’re doing differently, then try adapt the existing data to the new ones. But, again, make sure you always have a complete backup of your files and database, because things can go wrong any time.
That’s all folks! I guess that’s enough information to think about and be more careful when choosing WordPress themes and plugins. Use the comment form below if you have anything to say and feel free to ping me on Twitter too!