Adding Custom Hooks in WordPress: Custom Actions

One of the cornerstones of building custom solutions in WordPress is having an understanding of hooks. In and of themselves, they aren't terribly difficult to understand, and we'll be covering a short primer on them in this tutorial.

But if you're looking to get into more advanced WordPress development, it's worth knowing how to implement your own hooks as well.

In this two-part series, we're going to review the WordPress hook system and how it's implemented, and we're going to take a look at how to define our own actions and filters.

Getting Started

Before getting started, this tutorial assumes that you have a local development environment set up that includes the latest copy of WordPress. At the time of this writing, this is WordPress 6.0.1.

If you need guidance on setting up your development environment, please see this tutorial. It will provide you with everything you need to know to get set up with a web server, a copy of PHP, a database, and WordPress.

If you're looking for even more, then the series in which that tutorial is included provides even more information such as how to install WordPress, walkthroughs of themes and plugins, and more.

But in this tutorial, we're focusing on hooks and actions. So once you're all set up, let's get started.

What Are Hooks?

Before taking a close look at WordPress hooks, it's worth understanding the event-driven design pattern (which is also referred to as an event-driven architecture).

If you've worked with existing WordPress hooks or with front-end web development or with JavaScript in any capacity, you're likely familiar with this pattern even if you didn't know it had an official name.

Regardless, this is how it's defined in Wikipedia:

Event-driven architecture (EDA), also known as message-driven architecture, is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.

If you're just now getting started with design patterns or development, this may sound complicated, but another way to think of it is like this:

• The software has certain points in which it broadcasts a message that something has happened.
• We, as developers, are able to write code that listens for this message and then respond to it with custom code.

Notice that the definition talks about the production of events, as well. When we move into talking about defining our own hooks, we'll be revisiting this topic. For now, let's look at two events that are common in web development.

Using JavaScript

First, imagine you're working in front-end development. You have a button with the ID attribute of add_action() function to specify the callback function that will be executed when the action hook is run. In our case, it tells WordPress to execute a function named admin_menu action hook is fired.

The add_submenu_page() function determines where the menu option would appear. The first option is the parent slug, which is set to tools.php and our new submenu will start appearing under Tools. Here are the screenshots:

You can visit the Codex to read more about the init hook that exists in WordPress. The init action hook fires early in the WordPress lifecycle and is a good time in which to register a custom post type.

Next, we need to define the function.

<?php <br>function tutsplus_register_post_type() {<br>  <br>}<br>

The key to understanding the signature of this function is simple: We've named it init hook, we need to make sure that our hook is fired during the init hook:

<?php <br>add_action( 'init', 'tutsplus_register_custom_post_type' );<br>function tutsplus_register_custom_post_type() {<br><br>  // Set the action at priority of 10 and note that it accepts 2 arguments.<br>  do_action( 'tutsplus_register_custom_post_type', 10, 2 );<br><br>}<br>

Note in the code above we're specifying two additional parameters for do_action()<code>do_action(). The first parameter is 10, which indicates the priority in which this hook will fire.

This can be any number where the higher the number, the lower down the list of priorities it will fire. In other words, a lower value means that the callback function will be executed earlier. A higher value means that the code will be executed later.  The second parameter is how many arguments the custom hook will accept. In our case, there is one for the singular version of the post type, and there is one for the plural version of the post type.

After that, we need to give functionality to that hook. Here, we'll refactor the code for registering a post type so that it accepts two arguments, and those two arguments will be used in the array passed to WordPress's register_post_type<code>register_post_type function.

<?php <br><br>function tutsplus_register_post_type( $singular, $plural ) {<br><br>  $args = array(<br>      'label'  => $plural,<br>  	'labels' => array(<br>  		'name'          => $plural,<br>  		'singular_name' => $singular,<br>  		'add_new_item'  => 'Add New Traveler',<br>  		'edit_item'     => 'Edit Traveler',<br>  		'new_item'      => 'New Traveler',<br>  		'view_item'     => 'View Traveler',<br>  		'search_items'  => 'Search Travelers',<br>  		'not_found'     => 'No Travelers',<br>  	),<br>  	'description' => 'A post type used to provide information on Time Travelers.',<br>  	'public'      => true,<br>  	'show_ui'     => true,<br>  	'supports'    => array(<br>  		'title',<br>  		'editor',<br>  		'excerpt',<br>  	),<br>  );<br><br>  register_post_type( 'time_traveler', $args );<br><br>}<br>

Notice here that we've also removed this function from being added to a particular hook. Instead, we'll call it from within the definition of a function that's hooked to our custom action.

<?php <br>add_action( 'tutsplus_register_custom_post_type', 'tutsplus_register_time_traveler_type' );<br>function tutsplus_register_time_traveler_type() {<br>  tutsplus_register_post_type( 'Time Traveler', 'Time Travelers' );<br>}<br>

In the code above, we're able to make a call to the function responsible for registering the custom post type, all the while passing it our own arguments so that we can add a little bit of custom functionality to the code.

Conclusion

Defining custom hooks isn't complicated, and it also lends a lot of power and flexibility to us as developers. Arguably, the most confusing thing about the code above is how we're defining a hook within the context of another hook (that is, we're defining tutsplus_register_custom_post_type<code>tutsplus_register_custom_post_type within init<code>init).

I've opted to give this as a final example because there are times in which you may want to register a custom hook and it needs to fire before a pre-existing hook is completed.

Registering a hook to stand on its own is easy: You simply don't hook it to a pre-existing hook, and you make a basic function call as we saw with the code hooked to admin_notices<code>admin_notices.

In the next post in this series, we'll take a look at filters and what they can do for us in terms of modifying data. We'll also look at how to define our own filters so that we're able to introduce custom functionality much as we've done in this tutorial.

This post has been updated with contributions from Nitish Kumar. Nitish is a web developer with experience in creating eCommerce websites on various platforms. He spends his free time working on personal projects that make his everyday life easier or taking long evening walks with friends.

The above is the detailed content of Adding Custom Hooks in WordPress: Custom Actions. For more information, please follow other related articles on the PHP Chinese website!