post-page

The Legacy Plugins Leave Behind

44
responses
by
 
on
November 29th, 2010
in
WordPress Discussions

Over the course of time, I imagine that most of the needs and wants of end users change. For example, after performing a fresh install of WordPress, you realize that you need a way to conduct polls, have the poll data reflected in the post, etc. Then, a year later, you find out that polls are no longer a necessary item to have on the site so you decide to remove the plugin. However, you notice that after you deactivate the plugin, the data disappears along with it. This is precisely what happens with the WP-Polls plugin. Once the plugin has been deactivated (not removed) instead of the polling data shown within the post, it’s replaced with the poll ID shortcode which is used to display the poll.

This one example has me wondering how many users out there are experiencing something similar with a WordPress plugin? In the example I described above, I could take screenshots of the polls that contain the poll data and substitute that for the poll ID but that’s too much of a hassle. I could also not care about the loss of polling data but that would end up making a handful of posts which have a great discussion surrounding the results irrelevant.

Over the course of 2 years, I’ve managed to have 32 activated plugins on my website, each with a particular role. Some add features, others work in the background to make things easier. Yet, I use a few plugins that either alter the way my content is displayed or enables additional content that if those plugins were removed, the content would be removed as well.

I’m all for plugins being able to have an uninstall feature that removes them entirely from WordPress, including the database but in this instance, I want to keep the content associated with the plugin while removing everything else. Any suggestions on how to do this? Better yet, what would a plugin author have to do to make sure that the content generated by the plugin is stored in WordPress and not somewhere else? It seems to me that the last-ditch option and the one that may be most convenient is to not do anything at all. Pretend the polling plugin is not there and hope it continues to work into the future as I continually upgrade WordPress. This leads me to my next question.

How many of you have come to rely on a particular plugin for your website. A plugin that you considered to be a crucial part of the way your site functions only to see that plugin disappear, stop working, or development ceased. What did you end up doing? I realize there are a ton of WordPress plugins in the repository but some plugins are harder to replace than others. Let me know in the comments.

heading
44
Responses

 

Comments

  1. John P. (3 comments.) says:

    My entire web site (not just the blog portion) relies very heavily on the EventCalendar3 plugin. It uses a separate table for event schedules but requires WordPress for data entry. I probably have a couple dozen scripts which query the table for event data (including the main web site page) so if the plugin breaks in a subsequent WordPress release, I’ve got a lot of remedial work to do.

    Development and support for the plugin ceased about 2 years ago but it hasn’t broken as WordPress evolves. If/when it breaks, I’ll deal with it but it’s always in the back of my mind when I see there’s a new WordPress update available.

    • Jeff Chandler (171 comments.) says:

      heh, talk about playing with fire. I know the feeling though. It’s a bit cool though to see that even after two years, the plugin is still kicking.

  2. Andrew Nacin (11 comments.) says:

    I’ve always advocated that plugins should be using uninstall hooks to remove options, not data. My data is curated and should be respected. Be considerate of my data! etc.

    That said, this plugin used a shortcode to show polls. The plugin would still need to be activated for the shortcode to be active, parse the data that is stored, and display a poll. While shortcodes make sites particularly vulnerable to being overly dependent on a single plugin, this is beyond shortcodes. There’s no way around that.

  3. Jesper (3 comments.) says:

    I’ve been wondering about this issue lately.

    I use Geo Mashup plugin on every post with the use of shortcode tags for displaying a map and location info.

    What if the plugin stops working I have to remove all those shortcode tags from my posts? I wish I had considered the use of a Template Tag in my single.php instead of the shortcode tags!

    • Tim (1 comments.) says:

      You could try just doing a mySQL query to find and replace all the short codes in your posts, when the time comes.

      • Jesper (3 comments.) says:

        Thanks,

        I’ve experimented with query’s on a test database. With the use of this post:

        http://digwp.com/2010/03/remov.....-database/

        It workes, but still a bit scary to run it on the actual db :-)

        • Jeff Chandler (171 comments.) says:

          That search and replace feature would work but it is still cumbersome when the shortcode has a different ID as the ID references the number of the poll that was generated. In effect, I would not be able to perform a blanket search and replace. I’d have to replace each instance of the shortcode in a way that matched the data for that poll.

  4. that girl again (41 comments.) says:

    The obvious answer here would be for the developers of currently maintained plugins to add an import feature for data from any formerly popular but now outdated plugins they have superseded. Or… well, just fork the old plugin.

    You can’t really demand that dynamic content created via plugin should still be accessible when the plugin is deactivated or removed. It’s a bit like uninstalling wordpress and expecting your blog to still be there. You need the software in order to process the data.

    • Jeff Chandler (171 comments.) says:

      Understood. But I was just wondering if a polling plugin can be used where the data that it creates is saved on the WordPress side of things, not within the plugin.

  5. Otto (215 comments.) says:

    IMO, the best thing to do is to just not use plugins that create “content”.

    This goes back to the whole layer of separation between content and presentation, sort of thing. Your content should be in the post. By using shortcodes, you make the post reference some content that is generated by the plugin. Thus, you make the content dependent upon the presentation layer (which is the specific WordPress installation with that plugin, in this case).

    Of course this isn’t a perfect world, so there’s always going to be compromises. But when evaluating a plugin, then shortcodes *as a requirement* should be considered a negative. They are indeed very handy, but when you use them, you become dependent on them. Best to try to find another solution instead.

    If I was going to make polls, for example, I’d probably look for a poll service like PollDaddy. Then I’d realize that it has oEmbed support, meaning I can go there, create a poll, and just put the link to that poll right into my posts. WordPress will auto-magically go get the embed code and show my poll. No plugins needed. If the embed code fails for whatever reason, then at least I have a bare-bones link instead of a meaningless shortcode.

    A plugin that adds something to the content works better on the backend, when it’s actually adding something to the content and not just putting a basic shortcode in. For example, a theoretical plugin could insert the HTML needed to display the results of the poll (assuming poll data is stored as meta info or some such thing). Then it could use Javascript or something to replace that box with the poll-question box. If the plugin wasn’t there anymore, at least you’d still have the results. While this is trickier to do, it would give a method for allowing the plugin to be deactivated gracefully.

    • Jeff Chandler (171 comments.) says:

      But with the limiting factor of PollDaddy unless you pay up, not to mention the data is not stored locally on the site, I don’t think PollDaddy is a viable option. If you close your account or something happens, the poll data still disappears and your links will most likely point to something that doesn’t exist.

      I guess this is one reason why PollDaddy actually has an import/export service. I’ll need to play around over there to see how it works.

      • Otto (215 comments.) says:

        Well, I was just using PollDaddy as an example, since you talked about Polls.

        But generally speaking, I prefer to rely on outside services than on plugins which create content internally. For one thing, upgrades tend to work better. For another, you don’t have something messing with the internal workings of your site. Also, services tend to stick around longer than plugin authors do, as they have more investment into those services.

      • Chip Bennett (63 comments.) says:

        But you’re going to have a limiting factor somewhere: whether that limiting factor is a free Plugin or a free hosted service.

        So, really, it’s a choose-your-poison scenario.

  6. scribu (42 comments.) says:

    In the case of shortcodes, I think it would be good if plugins had an export feature, i.e. permanently substituting the shortcode with it’s content.

    • rightidea says:

      Good idea scribu. Sort of the same idea as copying a spreadsheet full of formulas, then pasting only the VALUES generated by those formulas back in the same place! After that, the formulas (or shortcodes in this case) are gone, but you can still see all the same information the formulas presented.

    • Jeff Chandler (171 comments.) says:

      This definitely sounds like a good answer to the problem

    • Flick (28 comments.) says:

      I third the good idea brigade :)

  7. Eric (3 comments.) says:

    I could see one possibility where a plug-in, when uninstalled, gives you the option to permanently parse shortcodes. I’ve used plug-ins in the past that use shortcodes merely as placeholders for other HTML elements. When I remove these plug-ins, I usually go in and hand copy the HTML so that I don’t lose the look and feel of a particular post, even though I know I won’t use it in the future.

    But some systems (I’ve written at least one) make use of external options or DB tables to store the data parsed by that shortcode. In those cases, we should have a clear distinction between “deactivate” (disable the ability to change options but keep existing settings in place), “disable” (turn the plug-in off without deleting data, but none of it will be used on the site), and “delete” (remove the plug-in, its settings, and its data entirely).

    These three paradigms allow you to remove unneeded/unused plug-ins (I don’t use Hello Dolly on my personal sites, for example) when you want to delete them entirely – call it a nuclear option. They would also allow you to “turn off” a plug-in – keeping it installed and retaining its data but not using any of the code. Finally (and I would love to see this), they would allow you to “archive” a plug-in – it’s still installed, your polls still show up, but the backend UI is disabled and you can’t add new polls or make *new* use of the plug-in’s exposed API.

  8. Caleb Withers (1 comments.) says:

    There are plenty of plugins (take this one for example: http://wordpress.org/extend/pl.....d-replace/ ) that will let you search and replace/delete anything, and through use of wildcards, you should be able to either replace the shortcode with a placeholder or remove it entirely.

  9. Todd Lahman (4 comments.) says:

    A SQL query can update the content by removing the short code, and leave only a whitespace, or none.

    I would prefer developers start charging a small fee for crucial plugins they know a lot of people depend on. That way the plugin development can continue, and the plugin can also be improved over time.

    Free plugins are great, but not every developer can afford to give away their work forever.

    • Jeff Chandler (171 comments.) says:

      I wouldn’t mind if the shortcode was removed if the data that shortcode represents, takes its place. I don’t want my polling data to disappear into a blank space.

      As for charging for plugins. Sure, the money may be more motivational to the plugin author, but there is no guarantee that the plugin will last a long time. What benefits are there to a charged plugin versus a free one other than motivational development?

      • Todd Lahman (4 comments.) says:

        Paid for plugins have a business model that keeps development ongoing.

        Free plugins are made with donated time, so when the bills come due paid work always takes priority over donated work.

        • Jeff Chandler (171 comments.) says:

          Out of curiosity, do you think it’s a bigger risk to work with and depend on a free plugin versus a commercial one? I think the risks are about the same.

          • Todd Lahman (4 comments.) says:

            http://alexking.org/blog/2010/.....otivations

            Alex makes another great point about the free plugin versus commercial plugin model.

            The risk is far less when the plugin is popular and commercial, which is true in any market. What I am saying is if you like a plugin and pay for it, and want it to continue to be developed, encourage others to buy it so the developer will continue working on the project.

            Let’s take a band for an example. How many bands play music as a full-time job when they aren’t getting paid to play?

  10. Nicholas Teo@Feng Shui since 1988 (37 comments.) says:

    I used to use a shortcode based adsense plugin and after I removed that, I had to removed every shortcode on my blog post manually and that took days.

    • Jeff Chandler (171 comments.) says:

      Well, if the shortcode you used was the same throughout all of the posts you used it on, the search and replace plugin mentioned a few comments before yours would have saved you a lot of time.

  11. Peter Knight says:

    In some cases custom post types are suitable for storing the data a plugin creates (it would work for polls). Sidenote, I do think WP should have a built in interface for managing custom posts & taxonomies included in the core rather. Preserving the custom posts means you can display/access the data using alternate means, like shortcodes. There is an easy to use find and replace plugin that has come to the rescue for me many times.

  12. Marcel (10 comments.) says:

    Great post!
    My Lazyest Gallery plugin also uses shortcode(s) to display content, because the Gallery could be anywhere in the text. One thing I learned from this post is that I have to add a shortcode remover in the uninstall file ;-) and I’ll investigate the use of custom post types.

    • Jeff Chandler (171 comments.) says:

      A better alternative would be a way for your shortcode to be parsed so that it turns into content that is added to the WordPress database within the post.

  13. David Perednia says:

    One thing that could be done is require all plugins that use shortcode to have a test to see if the plugin that uses the shortcode is active. If it is active then the shortcode is executed and if not the shortcode is disregarded. This would only occur when the shortcode for that plugin is encountered.

  14. Tom Coburn (67 comments.) says:

    I think an uninstaller for all plugins is a good idea, but there should be an included option to say “yes or no” to deleting its content or not. Most of the time when I delete a plugin, I want the relevant database schema deleted also, but not always, like you said sometimes you want to keep its content, other times you want to delete everything including its databases, content, the whole bit.

    I’ve said this for many years, I think there should be guidelines for plugin development.. like for instance, required for ALL plugins that they have to have an uninstaller, for example. ya know kinda like windows programs they all come with uninstallers now as part of the development process.

    I also think all Theme’s should come with an options page required to even be a WP theme in the first place. I think both plugins and themes should have set guidelines like that, without the mess if different plugins we have now where some work and some don’t, and then PHP programmers complain that WP is bloatware, as if the plugins are! lol

  15. Flick (28 comments.) says:

    Jeff has hit the nail on the head (again) in terms of a possible pitfall (?) or issue facing users after the de-activation of a key content plugin.

    I use (and love) WP-Tables Reloaded, WP-Polls and a few other plugins that use short codes to insert data: insert it in any post and just edit one table/poll etc. which is definitely the freedom and flexibility provided by plugins that use shortcodes imho?

    Solution wise I really like scribu’s idea of having a plugin option that enables the permanent export of content/substitution of short codes with actual data.

  16. Jessi says:

    This plugin was recently released. Works like a charm:

    http://wordpress.org/extend/pl.....collector/

  17. Ed (5 comments.) says:

    I would like to see some sort of core addition that allows for overall shortcode management. Plugins and theme functions have the register shortcodes. Why not have a place within the WordPress core that allows users to manage the shortcodes that are registered. Possibly allowing the addition or editing of the shortcode so that when a plugin fails, we can let the core change the “unsupported” shortcode with what we determine should be there, or possibly just ignore the code.

    • Otto (215 comments.) says:

      If you want to make an old shortcode go away, then a simple one-liner will do the trick:

      add_shortcode( ‘oldshortcode’, ‘__return_false’ );

      • Ed (5 comments.) says:

        Otto,
        I was not just referring to the removal of a shortcode. I know you can unregister the shortcodes. Similar to what @scribu described. When the plugin is removed, the shortcode text remains. If we can have the power to attach something else to this (the power being for the avg user) then we can have actual text or something besides [shortcode] showing up in the pages and posts.

        Lets say I am using [shortcode] from a plugin, and then the plugin dies. So with an option to reassign the orphaned shortcode, instead of [shortcode] showing on my post, I could add a Google Ad or a funny saying… or whatever I wanted to do.

        This could be an alternative if what scribu suggested can not be done.

        • Otto (215 comments.) says:

          I know what you meant. Notice that that one-liner I gave you basically makes the shortcode not show up in posts, even though it’s there.

      • Ed (5 comments.) says:

        Ok, I just re-read that. In other words, you are saying that if could use that line to basically IGNORE the [shortcode] that would be left in the post… now, why didn’t I think of that?!?!? (Partly because I am not as smart as Otto)

        So if there was only a way to pull together the orphaned shortcodes so the avg user could have such powers!

  18. shizn says:

    I try to avoid any plug that i would need in order for the page to display correctly. I go as far as adding html into widgets to make them look like the old tables rather than messing with the framework and css.

    I am a n00b to wordpress but cannot afford to have my page break just because of some plug. Some plugs, however, you cannot avoid if you are a n00b, like some of the mail forms. Ask a total n00b to style a form and you will get a blank stare.

    I truly think some sort of minimal mail function should be built into wordpress because almost everybody uses mail on their site and there are lots that rely on plugs for this functionality.



Trackbacks/Pingbacks

  1. The Legacy Plugins Leave Behind « Weblog Tools Collection…

    Over the course of time, I imagine that most of the needs and wants of end users change. For example, after performing a fresh install of WordPress, you realize that you need a way to conduct polls, have the poll data reflected in the post, etc…….

Obviously Powered by WordPress. © 2003-2013

page counter
css.php