About the "Lock in Effect" in WordPress Themes and Plugins
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.
Choosing Alternatives
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!
58 thoughts on “About the "Lock in Effect" in WordPress Themes and Plugins”
This problem is even more pervasive than articulated here. The theme options of many commercial themes create functionality unique to that theme and then if you want to make a change, boy are you screwed. We see this problem with clients all the time.
Correct, and that is why companies like WooThemes are building frameworks or platforms, which gives you a much wider choice on themes, but you’re still locked into using their collection, which is good for them, but not too good for the end user. Yet, end users tend to pick themes with the largest amounts of theme options and features, shortcodes, page templates and custom post types.
Yet again, if you remove all those possibilities from theme developers they’ll have less “marketing material” to promote their themes, which is good for the end users, but not for the theme developers. I personally think that theme developers should focus their brains on theme design rather than features, or start building portable solutions, maybe as plugins that would work with other themes.
It’s a good scenario but hard to achieve. I had a talk with a few folks about theme standards a couple of weeks ago, and turns out that it’s still a huge problem in the commercial themes market, and that definitely is a bottleneck or as they like to refer to it “blocker” :) Thanks for your comment Diane!
This is just the topic that arrose when Yoast created his WordPress SEO plugin. At first it was not compatible with the Thesis theme and it’s custom SEO settings. Then someone made a plugin to “liberate”/transfer data between plugins.
It would be neat of, if ever you purchased such a custom theme, to at least have some fallback support to custom functions.php if you ever decided to change your mind. I think such a simple compatibility service could create a lot of good will, even if it would mean you’re betting against your own theme store.
Stijn, didn’t know about that situation, thanks for the heads up! As for fallback support to custom functions.php, you probably missed my earlier post called Plugins vs. “without a Plugin” which has some really good discussion in the comments (if you have time.)
I do agree though that everybody who takes theme and plugin development seriously should consider creating ways to liberate the user’s data and use it elsewhere, preferably not as an SQL dump, because that we can do ourselves :)
Thanks for your comment!
Great post (as usual) Konstantin!
I just wish that theme/plugin authors to not being too smart :) I mean, why would anyone create hundreds of DB rows for a single theme/plugin? Oh, and I’ve seen a plugin that adds like 3 new tables when they’re clearly not needed and should’ve used posts and postmeta tables.
I guess many of us are just too lazy to go through the core source code. I rarely visit the Codex these days (unless I need some example codes) because for me the inline docs are very clear and more than enough.
And about Woocommerce, why would they create those additional pages without my permission? It would be nicer if they just give us the option to chose which page to use for checkout, etc without having to create new ones. Think about existing site that need to add new ecommerce section/feature…
Anyway, what happened with theme.fm Konstantin? :)
Dzikri, I agree that the inline docs are very useful if you can find your way through, but the Codex is something we all have to contribute to, improve it and make it easier for everybody else to use and understand.
I’m not experienced enough with WooCommerce to answer your question, but I think there was a good reason behind that decision. You can’t expect everybody to be a code monkey. I might be wrong :)
Theme.fm has been paused for the time being. I can’t say much about it yet, but I do believe that somebody’s gonna do something awesome with it. Thanks for stopping by and have a good day!
The "Lock in Effect" for themes and plugins | WPCandy
Sure it’s bad to try ‘lock’ someone in purposefully.
But at some point the user has to give up that right once his programming knowledge is depleted.
Foxinni, right, but then again, my programming knowledge is okay but I’m still trying to figure out the best way to escape the NextGenn Gallery plugin which adds database tables and files and folders in an external directory, plus uses a shortcode to display the galleries.
I’m not saying it’s impossible, I’m just saying that figuring out a good solution can be time consuming and quite tricky, and the plugin author could have saved some of that time for me. Thanks for your comment!
Hi @Konstantin:
I think you are being too hard on the theme vendors like WooThemes.
One of the reasons Woo and others must do what they do is because WordPress core has the “decisions not options” and “that’s plugin territory” culture. Since there is often no internal API support for more advanced features, especially when those features are requirements of the customer, the theme vendors are left with little choice but to include the functionality in their themes. It would otherwise be impossible to provide the features that their customers want and need.
You argue that theme developers should focus their brains on theme design rather than features but I’m reminded of an early dotcom-era IBM commercial where the web designer was showing the older business man how “I can make it spin and change colors” and the frustrated old guy asked “But can it manage my company’s inventory?!?”
You also argue that themes could create plugins that people could continue to use if they swapped themes but there again WP core doesn’t provide support for a theme to seamlessly load a plugin and thus splitting extra functionality off into a plugin provides a poorer UX which AFAIK is contrary to the WordPress ethos too.
In other words, damned if they do, damned if they don’t. Until WordPress core cares addressing some of the issues it’s not going to get better. FWIW.
Hey Mike, thanks for your comment! I don’t think I’m being too hard on companies like WooThemes, in fact:
So what I was trying to say is that WooThemes is actually going in the right direction with their e-commerce solution and the Woo Framework, it standardizes some of the things making themes compatible with others. They do lock you in into using their products, extensions and themes, but they also give you choices. It’s not like that one theme you purchased from a marketplace.
The React theme from The Theme Foundry is a good example of a portfolio theme that does not lock you in. In doesn’t use any additional post types, meta, etc., it functions on post formats, so if you switch to a new theme, all your Gallery posts are still there, and if the new theme does not support the Gallery post format it’ll display them as regular posts, but not loose them like other themes do. Nice quote from the IBM commercial :)
Themes can easily run a check for
function_existsor even better apply a filter unique to a plugin to check whether a certain plugin is activated. If not, ask the user to install and activate it, a good example is a WooCommerce theme and the WooCommerce plugin powering the theme. If the user can’t or doesn’t want to install the dependency plugin, you can always keep the theme working by not using the features provided by the plugin. I know this isn’t the best user experience, but think in the long run.Thanks again for stopping by, hope my comment makes sense. Cheers!
Thanks for the clarification; sorry that I misunderstood your take on WooThemes.
After reviewing your comments though I think maybe instead of being too hard on people maybe you are being too idealistic. People add plugins or use themes because they given them the features they need.
To focus on ensuring there can be no lock-in is also to focus on there can be no features that WordPress core does not provide. In the US some of us have a saying that relates “Besides that Ms. Lincoln, how was the play?” (for those non-US people, this[1] link might make the saying more clear.)
Continuing the thought, I think the real culprit for plugin and theme lock-in is a WordPress core that doesn’t offer the features needed to enable themes to implement features without such a negative UX and feature that can set any data free.
Anyway, I hope my comments add to the discourse.
-Mike
P.S. BTW, what’s the problem with “plugin lock in?” Since we can use more than one plugin why do you see it as issue if a plugin has it’s own data? Actually, how could any plugin that persists any data achieve the standards you are setting?
[1] en.wikipedia.org/wiki/Abraham_Lincoln#Assassination
Mike, no problem, thanks for your input! As for your plugin lock in question I agree and, as I mentioned in the post, it’s not a big deal often times, because, as you said, you can run several plugins at once. However there still are times when you want a different one and a good example is the gallery one I referenced in a previous comment. It’s not that it’s not working for me, I just don’t like it anymore and don’t want to use it, I’d rather go for native WordPress galleries if you understand what I mean.
Sounds like we agree on much! So, I think the question is “How do we resolve that issue without ‘throwing the baby out with the bathwater’, and who best to tackle it?” I know what I think we need, but would like to hear your thoughts first, if possible?
I’ll reply to your comment below as I believe the context would be better.
I recently saw an interesting development on lock-in. Alex King/Crowd Favorite are developing an Admin user interface for using post formats. It defines custom fields for some of the post formats and makes it easy to create posts using post formats. This creates a lock in, at least it would, if they didn’t also develop a fallback plugin that pulls out the custom fields and displays them in post for themes that don’t support custom post formats.