Easy, conditional JavaScript for WordPress admin pages

There are many ways to load conditional JavaScript for WordPress admin pages. When your plugin needs to run JavaScript on multiple admin pages, code can get messy and complicated very quickly. Here are a few examples of how to queue up scripts for different screens for a post type called ‘foo’.

Server-side Conditional Examples

admin_print_scripts-$hook

This granular action saves a step when loading only on a specific page as it’s baked right into the action name itself.

 //Add a script for the posts edit screen add_action('admin_print_scripts-edit.php', 'queue_foo_edit'); function queue_foo_edit(){ //Check for post type 'foo' if('foo' === get_query_var('post_type')){ //wp_enqueue_script... } } //Add a script for the single post edit screen add_action('admin_print_scripts-post.php', 'queue_foo'); //Don't forget new posts! add_action('admin_print_scripts-post-new.php', 'queue_foo'); function queue_foo(){ global $post; //Check for 'foo' post type if('foo' === $post->post_type){ //wp_enqueue_script... } } 

-or-

admin_enqueue_scripts

With this action, we have to conditionally check the $hook variable within the callback. This just adds unnecessary lines to the codebase.

 //Add a script for the posts edit screen add_action('admin_enqueue_scripts', 'queue_foo_edit_1'); function queue_foo_edit_1($hook){ //Bail out if we're not on the edit screen if('edit.php' !== $hook) return; //Check for post type 'foo' if('foo' === get_query_var('post_type')){ //wp_enqueue_script... } } //Add a script for the single post edit screen add_action('admin_enqueue_scripts', 'queue_foo_1'); function queue_foo_1($hook){ global $post; //Bail out if this is not a single post edit page if('post.php' !== $hook || 'post-new.php' !== $hook) return; //Check for 'foo' post type if('foo' === $post->post_type){ //wp_enqueue_script... } } 

You can see how a complex plugin can bloom into a large abstraction of JavaScript files for different admin pages and post type edit screens. Using server-side loading and abstraction of JS files is an accepted practice and some might call it a best practice. However, I prefer to use client-side conditionals.

Client-side Conditional Example

I typically enqueue only one custom admin Javascript file to save on HTTP requests.

This is clean server-side code and doesn’t send future developers searching down a rabbit hole.

add_action('admin_enqueue_scripts', 'queue_my_admin'); function queue_my_admin(){ //wp_enqueue_script... } 

WordPress Contextual Variables

WordPress has done some heavy lifting in wp-admin by defining contextual JavaScript variables. We can use these to conditionally run code client-side. Here is a list of what’s available client-side:

• pagenow – nice context name with post type included – (Example: edit-foo)
• adminpage – literal file context (Example: edit-php)
• typenow – current post type

jQuery Example

Here’s a sample using jQuery to run JavaScript only where it’s needed within the admin panel.

jQuery(document).ready(function($){ //Isolate everything related to the 'foo' post type if('foo' === typenow){ //Single post edit screen if('foo' === pagenow){ //Do something } //All posts edit screen if('edit-foo' === pagenow){ //Do something } } //Isolate settings page else if('settings_page_foo_settings' === adminpage){ //Do something } }); 

This method allows me to focus on the client-side code rather than worry about which file is loaded where on the back-end. It also reduces the complexity of the enqueue|print_scripts actions.

Caveat

I do realize some plugins/themes rely heavily on JavaScript and need to have quality abstraction. I use the above method only when it reduces complexity. If abstraction reduces complexity, then I will go that route.