Cancel

Jeff Chandler

WordPress 4.0.1 Exposes Bad Development Practices Used in Some Plugins

Plugins Broken Featured Image
photo credit: David Glover – cc

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.

Category: ,
Tags: , ,
27

27 responses to “WordPress 4.0.1 Exposes Bad Development Practices Used in Some Plugins”

  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.

    Create forum topic from comment

  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.

    Create forum topic from comment

  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).

    Create forum topic from comment

  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.

    Create forum topic from comment

  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!

    Create forum topic from comment

  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.

    Create forum topic from comment

    • 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.

      Create forum topic from comment

  11. 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.

    Create forum topic from comment

  12. “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.

    Create forum topic from comment

    • 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.

      Create forum topic from comment

      • 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.

        Create forum topic from comment

  13. 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.

    Create forum topic from comment

  14. 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?

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.