Using wp.ajax for Async Requests in WordPress

Over the years WordPress has provided a myriad of tools to make ajax requests in WordPress a little easier. After the new media modal was introduced in WordPress 3.5, a new set of tools went in to WordPress core. The javascript object wp was extended with many things, including wp.ajax. This combined with the wp_send_json_success() and wp_send_json_error() helper functions can help make performing ajax requests with the admin-ajax.php processor very straight forward.

If you are not already familiar with the admin-ajax.php processor, it’s worth learning a little more about. It is not and should not be the only way you work with Ajax in WordPress, but it’s a very useful tool to have at your disposal and should not be overlooked.

Let’s start by defining what wp.ajax is and does. It contains two methods currently, wp.ajax.post() and wp.ajax.send(). I’m going to focus this article on wp.ajax.send() because wp.ajax.post() is really just a wrapper around the send method that ensures the request is sent as a POST request. Beyond the request type, both .send and .post work almost the same.
Continue reading

Ajax Async Requests in WordPress

Ajax can be a confusing topic. I’ve spoken with developers who didn’t have a grasp of where Javascript ended and Ajax began. So before we dip into Ajax with WordPress, lets take a look at ajax itself.

Ajax is a request to your server

At it’s heart, Ajax is nothing more than an http request. It is a single request to a server which then sends back a response. This is very similar to typing in an address in your browser and hitting enter. It makes a request to a server which then sends back a response.

The magic of Ajax is that this is done without unloading the current page and loading a new one.
Continue reading

Add Plugin Hooks on plugins_loaded

The way the plugin system works in WordPress, plugin files are included in whatever order they happen to be in when the list of active plugins is saved to the database. There are plugins to control the load order of your plugins, but these are somewhat glorified hacks. There is certainly nothing wrong with them, but it is a bit bothersome to me that they are needed at all.

Whenever I write plugins, I make an effort put off the set up of everything, including adding any actions or filters, until the plugins_loaded hook. This action happens immediately proceeding including the plugin files themselves, which in my mind makes it the perfect time to run set up.

Nothing else has run yet, but everybody’s been invited to the party.

If all plugins are written this way and one plugin needs to make a modification before another plugin sets up, or needs to load earlier than other plugins, or needs to make sure it loads after other plugins, it’s a simple matter of setting the correct priority on the add_action() call that registers the setup function.

By this same token, I wait to do any theme setup until the after_setup_theme hook. All theme files have been included, nothing else has run. This is somewhat less important since you’re not often running more than one theme, but in a child theme situation I still find it can be worthwhile.

Understanding when your code runs in relation to when other code runs can be very valuable. This little change in mindset when authoring code can help you keep your code just a bit more organized. It may also help another developer down the line when they need to get a bit of code running before yours does.

Register Widgets with a Static Method

Registering widgets in WordPress is annoying.

All of the functionality is bundled up nicely in the WP_Widget class, but you can’t use an object method for the registration. Most PHP classes I see used in the WordPress space are pseudo namespace singletons. They have a helper for registering methods to hooks, and then the object is instantiated and the helper called. The various class methods are hooked in with something like add_action( 'init', array( $this, 'method_name' ) );. There is nothing inherently wrong with this approach. It provides a nice pseudo namespace for code that is PHP 5.2 compatible. When it comes to widget registration, though, that pattern just doesn’t work.
Continue reading

© 2024 Luke on Everything

Theme by Anders NorénUp ↑