WordPress 4.0.1 Exposes Bad Development Practices Used in Some Plugins

Plugins Broken Featured Image
photo credit: David Glovercc

With the release of WordPress 4.0.1 less than 24 hours old, we’ve received reports of plugins breaking due to the update. For example, Cool Video Gallery is broken because of the way it handles custom shortcode attribute parsing instead of using the Shortcode API built into WordPress. Mika Epstein, who is a support forum volunteer, published a post in the support forum that explains the problem and the best way to fix it.

If you’ve upgraded to WordPress 4.0.1 and a feature using shortcodes has broken (like a slider, or a visual composer), the reason is that code wasn’t properly using the WP Shortcode API.

Code that parsed shortcodes themselves, instead of using the normal add_shortcode handlers and such, may be surprised by the new behavior of texturize, because the quote marks in what WP thinks isn’t a shortcode get texturized now like everything else. So their filters, which probably come after texturize, don’t get the expected quote marks.

For users, the best way to fix this is upgrade. Many plugins have already released fixes, more are on the way. While it is possible to downgrade to WP 4.0, we really hope you don’t because of how serious the security fixes were. If you absolutely MUST downgrade, please nag your plugin/theme devs a lot to fix this STAT. Or stop using their stuff. It’s that big.

For developers, if you’re making shortcodes, use the Shortcode API instead of rolling your own.

Ticket 29557 in Trac describes the issue in detail. Unfortunately, some users have downgraded to WordPress 4.0 in order to fix plugin’s they rely on. Considering that 4.0.1 is a critical update filled with security and bug fixes, it’s strongly recommended that you don’t downgrade to 4.0. Instead, use the plugin’s support forum and notify the developer of the issues you’re having.

But Point Releases Are Not Supposed to Break Anything

The biggest concern users have with auto updates is the fear something will break. By default, WordPress 3.7 and above is configured to automatically update WordPress for point releases which generally contain security and or bug fixes. These kind of updates normally don’t break anything but in this case, several of the plugins were already broken and the update exposed bad development practices used by plugin authors.

All it takes is one bad experience during an auto update to lose trust in the system. With over half of WordPress installs tracked using 3.6 or earlier, we can ill afford to have anymore users disable automatic updates.

27 Comments


  1. The headline says “some”, but you only mentioned one. I followed a couple of your links and they didn’t mention any others either.

    Report


    1. There were only a handful, and most of them put out quick fixes inside a few hours. A few themes not on WordPress.org, which include lots of shortcodes (and the kitchen sink) also had problems.

      The important takeaway here is to use plugins and themes by developers who are active and can quickly react to change and push updates to their users. Most all of the problems found have been solved already, so all a user has to do is to get the plugin or theme updates, if they’re using one that had an issue.

      To plugin and theme developers, I would suggest not reinventing the wheel, and while you’re at it, trying to reduce complexity. Of the problematic code I’ve examined, the specific issue isn’t one of “bad code” or even using this or that API. It’s making shortcodes into something they were never intended or designed for. Users don’t need what amounts to a whole programming language built out of shortcodes. If you find yourself building nested shortcodes within nested shortcodes which can contain HTML fragments and if/then options and other seriously arcane levels of complexity… then maybe you should just rethink the problem from the beginning, eh? Just my opinion.

      Report


      1. Thanks for the links, Jeff. I even learned a new word – “hackery”.
        Note the double binding definition – ingenious AND inelegant techniques together.

        From Wiktionary:

        hackery
        2. (slang, computing) The use of hacks (ingenious but inelegant techniques).

        Quotation:
        2012, Seymour Bosworth, ‎M. E. Kabay, ‎Eric Whyne, Computer Security Handbook (page 57)
        All without any of the subterfuge and hackery required to do it with Java.

        Report


  2. It seems all of the sites I’ve designed with the Skeleton framework have cracked with this wordpress update.

    Report


    1. Let me clarify.. the css snippet that I use to make Youtube videos responsive is acting wonky since this update.

      So it has nothing to do with Skeleton.

      Report


  3. It’s a shame that Mika’s forum post is closed since it doesn’t give others a chance to comment.

    I have shortcode examples that were broken by WordPress 4.0.
    Now they’re even more broken with 4.0.1

    But my pragmatic workaround still applies.

    remove_filter( ‘the_content’, ‘wptexturize’ );

    I have reopened my original TRAC https://core.trac.wordpress.org/ticket/29608

    BTW. I believe WP engine has implemented something similar.

    Report


    1. It’s closed because every time we leave those open, people post in them asking for help instead of listing broken things. So while I’d love to leave it for people to comment, it makes it harder for anyone who wants a quick ‘This is what happened, this is why, this is what we know.’

      I do welcome improvements on how to phrase it better though I would actually suggest you use this instead: http://codex.wordpress.org/Plugin_API/Filter_Reference/no_texturize_shortcodes

      Just tell WP not to texturize your code :) Then you don’t mess up wptexturize for everything else that needs or relies on it.

      Report


      1. Hi Mika, unfortunately the problem cannot be fixed by no_texturize_shortcodes. It was associated with the parameters, not the embedded content.

        Report


      2. I read the ticket and miqrogroove’s blog post. Bleah. Yeah in your case that really is a mess. I think the long term fix in 4.2, using no_texturize_shortcodes to cover shortcode code as well as content would be a better fix than the absolute overkill of your pragmatic solution. It does work, but it’s like using a laser to melt butter.

        Report


      3. Not aware of the trac that proposes this but i have replied with my proposal to defer wptexturize until after shortcode expansion. See #29608

        Report


  4. Easy fixes… it’s been a busy time though. I couldn’t wait for those plugins to update, so I provided a fix for quite a few clients. Thanks for posting this… shared to All About WordPress on Facebook as well.

    Report


  5. I agree that it’s better to have a broken site than a hacked site.

    But be careful in your phrasing – “a visual composer”, which as far as I know, Visual Composer is a brand name not a generic term.

    I use the latest version of that plugin and had absolutely no issues.

    Report


  6. Lisa. Many have used the term ”Visual Composer”. I have a old Avid manual about the ”Visual Composer”. Intel have used it, and you got SAP NetWeaver Visual Composer, AdLib Visual Composer from 1987, Java Visual Composer and so on… I seen the term used for the Visual editor when it first was released.

    But ok, in the WordPress world, Visual Composer is a pretty known plugin (non GPL, and in my opinon a plugin that causing more problems than solving them in the long run).

    Report


  7. I’ve run into such plugins. It’s especially annoying when making a custom theme and discovering that do_shortcode() doesn’t work because some smartalec plugin author thought he knew better than the core WP devs. I don’t think the latter can be blamed here. We know what happens when users of a platform come to rely on old bugs: it’s called Windows.

    Of course, it’s the end users who end up suffering here. And that’s another reason why they should have the option to not upgrade.

    Report


  8. Only a fool runs software that can’t be tested before being put into production and after pitching a fit I finally let you talk me into being that fool. Thankfully nothing is broken here, except my rule.

    I keep forgetting that this is complete amateur hour over here. Your finger pointing at the WP ecosystem and its customers just drives the point home a bit deeper — you do not understand how this business works. You might want to do an exchange program with a major database or crm company for a while.

    I’d advise anyone of this basic take home lesson that amounts to little more than what you were sent into the real world for a summer to pick up when you interned in college: Snip the auto-update feature, don’t update until the first point release is out and you have had the next version running real production data in the test environment. It is not really a lesson. It is the way people do things when their company/job depends on it.

    We had side bets on this among the owners. Somebody gets free drinks tonight.

    Good luck!

    Report


    1. Sorry, didn’t have another way to contact you, but the site you linked to had at least one broken link on it (the link at the bottom to NginXpress). I looked, but there wasn’t any way to contact you on that site either.

      Report


  9. The update changed my theme from Twenty Thirteen to Twenty Fourteen, and now nothing is visible on the site. I also have error messages saying the stylesheets for 2012, 2013, and 2014 themes are missing. I tried to ‘reinstall’ 2013, but since I already have 2013, I can’t do that. Where do I get stylesheets, and where should I store them for WP to see them? Unfortunately, I am brand new to WordPress (user for about a week). If anyone has a suggestion, please dumb it down appropriately. Thanks.

    Report


    1. No, the plugin author simply needs to use add_shortcode instead of filtering the_content themselves, or use the no_texturize_shortcodes filter to remove their custom shortcodes from the texturize process. Either method works. The content isn’t altered in the database, it’s just being parsed differently. Users should not need to change anything.

      Report


  10. I agree that best practice is to only use plugins and themes that are updated regularly and that use the correct coding techniques, but actually doing that is easier said than done. Sometimes the only plugin that really does what you need ceases to be updated, and on sites that have been active for a year (or 5) it’s hard to track which plugins have ceased to be updated for the latest releases.

    Report


  11. “All it takes is one bad experience during an auto update to lose trust in the system. With over half of WordPress installs tracked using 3.6 or earlier, we can ill afford to have anymore users disable automatic updates.”

    Yup. I do not use auto-updates for exactly this reason. WP needs to be gentle if it expects updating. Things like this break down should have incurred a warning: “You have plugins X, Y and Z which use bad practices which will be broken in an upcoming release” and then with the next release “You have plugins X, Y and Z which are not compatible with this release so should WP disable those plugins or abort the update process?”

    No update should go around just breaking web sites. Bad, WP, bad.

    Report


    1. Unfortunately, there is no sensible way to predict which plugin will break in such a squeeze of releases, that this is the only way to find out what works for sure.

      And nothing in the world is omnipotent enough, especially at its current state. To expect WordPress to police every plugin in existence and provide warning is just nigh impossible.

      Then again, provided the faulty codes can be identified, this could be possible. Not accurate, but it can be a start.

      Report


      1. I have not disabled auto-updates on any of my sites and am very supportive of the core teams intentions with auto-updates. BUT I have to agree that breaking any plugins on point releases is a very bad outcome. It will almost certainly lead to more people disabling auto-updates, which is a bad result for everyone.

        While I’ve never had a problem, we have had a few people reporting problems with auto-updates in the WordPress Linkedin Group for various different reasons.

        It was my understanding that people can and should let point releases run because it is very unlikely they will break your site.

        Maybe my interpretation was wrong. Maybe it’s just that auto-updates are very unlikely to break WordPress itself but with plugins and themes it can definitely happen, depending on coding practices.

        Report


  12. All of my commenting abilities are gone after the update. The count is still there, but I can not post new comments nor see previous comments. Any idea what happened there? Also, there are share buttons now at the bottom of each post that I can not remove. Please help — WP newbie with only about 6% experience.

    Report


  13. This kind of change should not have been an auto update IMHO. Sure you can fault the theme or plugin authors but site owners do not really care about the reason the site broke. Clients need their sites fixed ASAP and who is in the hot seat on some random day?

    Report

Comments are closed.