The WordPress update ready to drop this week will lack the flair and pomp that accompanies some of the more extensive updates. It will mostly feature a few UI enhancements in the Post Editor, a better theme preview, and a few stability and security improvements. But, if you’re a plugin developer, there are a couple of things to pay attention to in the update. Consider this a heads up.
PHP’s MySQL Functions Deprecated
As of PHP 5.5 the MySQL extension is officially deprecated, which means it will no longer be supported in WordPress. Instead, WordPress will be switching to the MySQLi extension whenever the WPDB class is used.
What does this mean for you? It’s pretty simple actually. If you’re using any of PHP’s built-in mysql_* functions, and your site is running on WordPress 3.9, you won’t be able to connect to the database. Instead, you should make a direct reference to the WPDB class. For instance, the $wpdb->get_results() function is a perfect replacement for the mysql_query and mysql_fetch functions. In general, using the WPDB class to query, select, or insert things into the database from a plugin will ensure future compatibility—so now is a great time to make the switch.
Fortunately, Gary Pendergast wrote a helpful post on which WPDB functions can be used to replace common PHP MySQL functions. Check there if you have any questions.
Symlink Plugins
As of release 3.9, WordPress will fully support symlinked plugins. Creating a symbolic link to your plugin folders allows multiple WordPress installs to reference a single WordPress plugin folder, and a single set of files. The most common use case for this is plugin developers that want to reference the same plugin files on various different installations for testing purposes. That way, when you make a change to any file, it’s available in all of your testing installs simultaneously, without any duplicated work. Symlinked plugins are also useful if you want to bundle important plugins along with themes, and need to change the path from “wp-content/plugins/” to “wp-content/themes/themename/pluginfolder” to use a plugin’s functionality in your theme, or to create a mirrored local and development environment.
Previously, functions such as plugins_url() and plugins_basename() would not allow for symbolic links, and would instead return an absolute path. But now, symlinked plugins are completely supported thanks to the introduction of the wp_register_plugin_realpath() function.
This function checks to see if the plugin is symlinked before it’s loaded, resolving issues with plugins_url() and other similar functions. Ryan McCue provided an excellent example of how this could work, but I’m open to any more examples out there.
<?php
$plugins = array(
'my-mu-plugin/my-mu-plugin.php',
);
foreach ( $plugins as $plugin ) {
$path = dirname( FILE ) . '/' . $plugin;
// Add this line to ensure mu-plugins subdirectories can be symlinked
wp_register_plugin_realpath( $path );
include $path;
}
This will register the plugin’s symlinked path for you, so that it can be referenced by multiple installs.
Presumably, this also means that you can have a local development environment reference plugin folders that are on your live server, so you don’t have to keep plugin files in sync between the two. If anybody out there knows how to get this up and running let me know. I’m sure it can be very useful.
Anyway, those are just a couple of updates coming with WordPress 3.9 that plugin developers should be aware of. Happy developing!
Let me know if you spotted anything else in the comments below!
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.
2 Comments