Professional WordPress Plugin Development. Brad Williams

All plugins installed in the wp‐content/mu‐plugins directory. All Must‐Use, or MU, plugins are loaded automatically. The only way to deactivate an MU plugin is to remove it completely from the directory.

       Drop‐ins: Core functionality of WordPress can be replaced by Drop‐in plugins. These plugins are specifically named PHP files located in the wp‐content directory. If WordPress detects one of these files, it will be automatically loaded and listed under the Drop‐in filter on the Plugin screen. Currently ten Drop‐in plugins are available.advanced‐cache.php: Advanced caching plugindb.php: Custom database classdb‐error.php: Custom database error messageinstall.php: Custom installation scriptmaintenance.php: Custom maintenance messageobject‐cache.php: External object cachesunrise.php: Advanced domain mappingblog‐deleted.php: Custom blog deleted messageblog‐inactive.php: Custom blog inactive messageblog‐suspended.php: Custom blog suspended message

The last four Drop‐in plugins are specific to the WordPress Multisite feature. A standard WordPress installation will have no use for these plugins.

      When developing a new plugin, determine what type of plugin you want to create before you start the development process. Most plugins will be standard WordPress plugins, but occasionally you might need to create a Must‐Use or Drop‐in plugin.

SUMMARY

      In this chapter, you learned about plugins and how they can interact with WordPress using the available APIs. The major advantages to using plugins and why plugin functionality shouldn't always be included in a theme were discussed. Installing and managing plugins in the WordPress Dashboard was covered.

      Now that you understand how plugins work in WordPress, it's time to create the plugin foundation!

2 Plugin Framework

      WHAT'S IN THIS CHAPTER?

       Creating a solid plugin foundation

       Determining directory and URL paths

       Creating activation and deactivation functions

       Cleaning up during the uninstall process

       Writing code following coding standards

       Properly documenting plugin code

      CODE DOWNLOADS FOR THIS CHAPTER

      The code downloads for this chapter are found at www.wiley.com/go/prowordpressdev2e on the Downloads tab.

      When creating a plugin for WordPress, it's important to start with a solid foundation. This means getting your plugin folders and files organized and coming up with a naming scheme that you can use consistently throughout the plugin. The setup is the most essential piece of the puzzle. By nailing down these basics, you'll be well on your way to building your first WordPress plugin.

REQUIREMENTS FOR PLUGINS

      The WordPress plugin system is flexible and allows for plugins to be either a single file or a folder with many files. In this section, you'll learn the basics of creating a plugin.

      Naming Your Plugin

      The most important thing when naming your plugin is for it to be something unique. It's also good practice for the name to reflect what the plugin actually does. For example, you wouldn't want to name a forum plugin “Joe's Plugin” because that doesn't tell potential users anything about what your plugin does.

      You also need to consider whether your plugin name is too generic. It's possible that the name has already been taken by another plugin developer. You can check existing plugins in the WordPress Plugin Directory (https://wordpress.org/plugins).

      Because there are thousands of existing plugins, some developers prefix their plugin name with their business name. For example, if your business name is “Super Duper,” you might name a potential forum plugin “Super Duper Forums.” This allows you to better attach your brand to your plugin and keep the name unique.

      Using a Folder

      While WordPress does allow plugins to be a single file, it is generally not good practice to use this method. Instead, it is standard practice to use a folder to contain your plugin. The vast majority of plugins will contain multiple files, such as PHP files, CSS and JavaScript assets, and other build files.

      When creating a plugin, it should ideally match your plugin name. Plugin folder names should be hyphenated and lowercase. It should not contain spaces, underscores, uppercase letters, or nonalphanumeric characters. The plugin folder name must also match the plugin text domain when preparing your plugin for translations (see Chapter 11, “Internationalization”) if you plan to submit it to the official plugin repository.

      Using the previous “Super Duper Forums” plugin as an example, its folder name should be super‐duper‐forums.

BEST PRACTICES

      With any code base, developers should follow a common set of best practices. This is no different with WordPress plugins. By strictly following the practices laid out in this section, you'll have a solid foundation for your plugin. You'll also learn how to organize your plugin files and subfolders.

      Namespace Everything

      If you have a function named get_post(), it will conflict with WordPress’ own get_post() function and result in a fatal error. That's not a good user experience. Writing good code means making sure that your code doesn't conflict with other developers' code. The best way to ensure that is to prefix or namespace all your classes, functions, and anything else within the global namespace.

Throughout most of WordPress’ existence, it has supported versions of PHP versions earlier than 5.3, which is the version of PHP that standardized namespaces. This meant that it was standard practice to use a faux namespace by prefixing classes and functions. Prefixes should be unique to the plugin. The WordPress coding standards recommend naming classes and functions using snake case. Therefore, a function named get_post() would become prefix_get_post(), and a class named Post would become Prefix_Post.

      WordPress 5.2 changed its minimum PHP requirements to PHP 5.6. This means that plugin authors who want to support the same PHP versions as WordPress are no longer tied to the old practice of using prefixes. For this reason, it's probably best to look at other standards for naming, such as those outlined in the PHP‐FIG standards (https://www.php-fig.org).

      For the purposes of this book, the recommendation for namespacing your code will be to use the built‐in method of namespacing in PHP. Namespaces allow you to group your code under a unique name so that it doesn't conflict with other developers' code. Using the “Super Duper Forums” plugin example, your namespace would be called SuperDuperForums.

      Namespaces must be the first code, excluding the opening <?php tag and inline comments, in a PHP file. In the following example, see how a custom class named Setup is handled. Because it is under the SuperDuperForums namespace, there's no need to prefix it.

      <?php namespace SuperDuperForums; class Setup { public function boot() {} }

      Class and function names are not the only consideration when namespacing code. There are other times when you'll have things in the global namespace that might conflict with other plugins running in WordPress. Such cases may include storing options in