WordPress 4.0.1 Exposes Bad Development Practices Used in Some Plugins

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.