Plug-in compatibility Coding

  • Okay, here is a big piece of feedback to TPTB.

    The plugin process needs a version checker, something that says “this plug in test only until version x.x”, and when you go past that version, the plug in is either disabled or a large warning comes up on the main dashboard about potential incompatible plugins.

    First off, this would eliminate about 50% of all the support posts here. Many of the posts in the support reflect problems because wordpress’s methods have changed and plugins are not up to date.

    Secondly, this would encourage plugin creators to stay current. It wouldn’t be hard as a result to have lists of plugins by version, so that people don’t try to implement plugins that either are not compatible with their wordpress install or worse are way out of date and no longer supported.

    Third, it would be a step in reigning in the posting, deleting, and maintenance procedures of wordpress. Too many plugins get in the way of these very basic functions and turn wordpress into an even larger resource pig than it can already be.

    In my mind, many of the things that are being done with plugins during the post, maintain, or delete functions are not needed and just cause system resources to get wasted. Many of these procedures would be better done as background tasks, rather than as foreground tasks that make the authors wait significant amounts of time to get things done. Perhaps in the future having a background launch system that triggers once per day to allow certain types of maintenance or updates to be done, rather than doing them over and over again for each post, edit, or deletion?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Michael Torbert

    (@hallsofmontezuma)

    WordPress Virtuoso

    We already have that. The author includes the highest compatible version in their readme.txt, and is also displayed on the WordPress plugin page. It isn’t the responsibility of the WordPress developers to hold someone’s hand if they don’t pay attention and/or read before installing something.

    If a plugin author hasn’t updated his plugin to be compatible with the latest version of WordPress, email them. You can’t expect people with jobs and lives to constantly monitor whether some free software they wrote is no longer compatible with the latest version. They may have written it for a specific purpose at a specific time and no longer update it, or they may simply have no clue that it doesn’t work with a later version.

    Your third point doesn’t make sense. If a plugin does something during the post, delete, maintain, then presumably that’s when it needs to happen. If you don’t want the plugin, don’t install it.

    For your last paragraph, I doubt you’ll see that anytime soon. I’m not sure you really understand what you’re suggesting. For one thing, it couldn’t happen on certain servers, depending on their configuration. Also, most plugins that execute code during delete, maintain, post take up a fraction of the processor/RAM compared to what WordPress itself during those functions takes up. Anything that you’re using a plugin for that would be doing something during these times, it wouldn’t even make sense to have it done later. I’m not really sure what specific “maintenance or updates” you’re wanting to have done in the background anyway.

    Thread Starter rawalex

    (@rawalex)

    Okay, let me try it from the top:

    Including the highest compatible version in the readme.txt is nice, but wouldn’t it be MUCH better (and more secure) if when a major upgrade comes (say going from 2.3.3 to 2.5.x) that wordpress flags (and potential even disables) plugins that are not compatible or have not shown compatiblity with the new version? Perhaps even a simple pre-upgrade checker that would run through and let you know which plugins you will have issues with, so you can decide to move forward or not? Look through the troubleshooting forum, and you will see a ton of posts by people who got tripped up moving to 2.5.1 and incompatible plugins in the way, making the wordpress product all but die during the posting process (the issue was the sitemap generator). Had that been flagged as “not compatible” or “not up to date”, perhaps more people would have found the answer directly.

    I don’t expect people who have lives to keep their free plugins up to date, that is EXACTLY why I suggested a simple system for checking compatiblity or “up to date-ness” of plugins. There are still plenty of links out there to plugins that haven’t working since version 1.7 or so, that is a pure pain.

    My problem with plugins during the post / edit / delete procedure is that many of them are not optimized or are using wordpress functions in a manner that really slams the server hard, especially on larger blogs. It is easy enough to make things work on a blog with 100 posts and 3 categories, but when you get to larger blogs (I have a couple that are past 10,000 entries) many of these plugins burden the system. There is enough code in wordpress that doesn’t scale well (I manually add a couple of indexes to all 2.5.1 installs to make it run better), and these plugins just add to the pain. It is especially annoying to have something run on each edit that could easily be run once per day and generate very similar results. A sitemap isn’t something you should have to wait to see run while you are posting (and on bigger blogs, this one can almost time out (60 or 90 seconds depending on your server settings). A true question of scale.

    I can go mysql and delete a post (from even the largest db I have) in about 2 tenths of a second. If I delete a post using the wordpress interface on a larger blog, it can take a full minute. Is it a plugin? It is the code in wordpress? Is it a failure to properly index the posts database? Is other maintenance (such as category lists, parents, etc) being carried out with each post? It’s not clear, because the lines between what wordpress does and what the plugins do it blurred.

    Another plugins example of something that was a pain was a tagger function that added one click links for things like blogger, technorati, my yahoo, etc. I though it would be a very useful plugin, until I realized that the method it was using to add those tags to the posts also added them to the RSS feeds, with no method to remove them from the feed. They weren’t in the wp_post data fields, but rather added for each post as it was called.

    Unlimited access is all cool and fun, but it also means that many people writing plugins are either unknowingly using resource hungry procedures to achieve their desired result, or they are purposely bypassing what API exists to directly access databased and such, which in the end means they will likely fail at the next upgrade.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Plug-in compatibility Coding’ is closed to new replies.