Extending WordPress with Plugins: The good thing about WordPress is its extensibility. Some of the WordPress lead developers have said that the most exciting WordPress features are the ones that don’t ship with the software. It is possible to make WordPress do just about anything you can think of with plugins.
The framework for this extensibility is made up of a very simple hook system. With hooks, plugin developers can change existing content and hypertext markup language (HTML) before it is actually rendered by the browser, or they can fire off actions when a certain event occurs.
Hooks are places in the WordPress code where plugins have the capability to “hook” into the core and add some bit of functionality. Hooks are an extensive part of the WordPress plugin architecture and are essential to the concept of modifying WordPress behaviour without modifying any core code.
This event-driven architecture gives plugin developers extreme flexibility. In fact, many core WordPress features are implemented through the hooks system, which means that plugins are not second-class functionality, but are on par with the WordPress core.
The WordPress core developers have not been hesitant to add more and more hooks to WordPress. It’s really generally only a matter of asking. Using this hook architecture, WordPress is able to remain small in size and lean in scope. It is not the intention to make WordPress everything to everybody by default.
It is about creating a lightweight blogging platform that has all the necessary framework elements to enable users to extend and modify WordPress to fit their specific needs.
Understanding WordPress Hooks
The bulk of the WordPress plugin application programming interface (API) is made up of two core elements, or hooks: actions and filters. They are conceptually different but very similar in practice.
Actions are event-driven. When specific events occur in WordPress, such as saving a post, loading an admin page, or sending HTML to a browser, plugins have the capability to “hook” into these events and create their own events.
As an example, a plugin might ping a server when a post is saved. Or it might update a social network profile using their API when a WordPress user profile is updated. Filters modify content. The content could be the text of a post, an author name, or an option pulled from the database.
Filters always take data and return data after processing it. An example of a plugin using a filter would be modifying a user avatar with a different third-party avatar solution.
In this scenario, a filter might replace the WordPress default Gravatar-based avatar and replace it with a user’s Twitter avatar. As the name suggests, filters are always Data in, Data out while actions are event-based and do not require any kind of data processing.
The anatomy of a hook
Hooks are generally called using the add_action() or add_filter() function. They can also be removed by using the remove_action() or remove_filter() function. You might consider doing this if there are undesirable (or conflicting) events with another plugin, or if you want to disable a WordPress core feature that is implemented through the hooks system. In their most basic form, these functions take two arguments.
The first argument is the hook name, such as save_post or the_content. The second argument is the callback you want to pass to the hook, such as insert_author_description or add_google_analytics. Generally, the second argument is a custom function provided in a plugin or theme functions.php file, but it can also be a core WordPress function or a class and method name.
If the callback is a function, the second argument will be a string that is the name of the function (for instance add_action(‘pre_post_save’,’function_name’);). If you are using object-oriented programming (OOP) and need to refer to a class and method, do so by making the callback an array with the first member the name of the class and the second member the name of the method (for instance, add_action(‘pre_post_save’,array(‘className’,’methodName’);)
Though most custom functionality comes via plugin files, you can also have code included in a file called functions.php inside a theme. Most themes will already have a functions.php, but if yours doesn’t, you can simply add one. This file exists so that theme authors can provide custom functionality specific to their theme, and it behaves exactly the same way that plugins work. The only difference is that you don’t have to manually activate this file in the same way that you do for a plugin.
It is included automatically when the theme is active. While most of the time it is only necessary to provide the hook name and the callback as two arguments when calling a hook, there are two other arguments that you can optionally use.
The first of these arguments (and the third overall) is the priority. Priority is an integer that designates which order the hook reference is called. The lower the number, the higher its priority, and thus, the earlier it is called. This is particularly useful when you have a number of other plugins or functions hooking to the same hook. The higher priority hook reference will be executed first. The default priority is 10.
WordPress hooks are scattered throughout the WordPress core. Before any HTML is returned to the browser on a page load, WordPress runs through a lot of code determining what the client (browser) needs to see. Throughout this process, hooks are “fired,” or executed.
Plugins and the theme functions.php file add all the necessary callbacks to each hook in a queue, based on priority order. When WordPress fires each hook, it iterates through every callback tied to that hook. All the resulting HTML and Cascading Style Sheets (CSS) in aggregate make up what is ultimately returned to the browser and seen by the reader.
The final argument is the number of accepted arguments you want to pass to the callback. In most cases, a hook only provides a single parameter and so this is not needed. However, some hooks can provide more than one parameter, and your callback might need that extra data. In this case, your hook reference would have an integer designating the number of additional arguments to pass.
It is becoming standard for theme authors to include hooks in themes. Themes like the popular Avada theme makes it a point of loading many custom hooks into the themes.
Not only does it benefit users to have a lot of different options in the theme they use, but also has a significant benefit of turning themes into extendable frameworks. However, themes are not required to have any extra hooks.
They can operate perfectly fine without them. Three hooks, however, are virtually required for inclusion in any theme because so many plugins use them. Two of these hooks — wp_head() and wp_footer() — actually look like function calls and not actual hooks, but buried beneath the function are action hooks. The third is a more standard-looking hook and is positioned in the comment form:
<?php do_action(‘comment_form’, $post->ID); ?>