I have a plugin that is conflicting with some default wordpress functions. In the post and page creating/edit areas. I only need my functions on my settings pages. I have the js file loading in admin, no problem.

Can I tell the script not to load unless I'm viewing the settings pages for my plug?


You need to use a plugin page-specific script enqueue hook.


Best-practice method is to use admin_enqueue_scripts-{hook}, rather than admin_print_scirpts-{hook}. But, because you're targeting your own Plugin's admin page specifically, either one is perfectly fine.

The hook to avoid is the "global" admin_print_scripts.


The call would look like this:

    /* Using registered $page handle to hook script load */
    add_action('admin_print_scripts-' . $page, 'my_plugin_admin_scripts');

And you define the $page hook like so:

$page = add_submenu_page( $args );

Answer copied directly out of the Codex:

add_action( 'admin_init', 'my_plugin_admin_init' );
add_action( 'admin_menu', 'my_plugin_admin_menu' );

function my_plugin_admin_init() {
    /* Register our script. */
    wp_register_script( 'my-plugin-script', plugins_url('/script.js', __FILE__) );

function my_plugin_admin_menu() {
    /* Register our plugin page */
    $page = add_submenu_page( 'edit.php', // The parent page of this menu
                              __( 'My Plugin', 'myPlugin' ), // The Menu Title
                              __( 'My Plugin', 'myPlugin' ), // The Page title
              'manage_options', // The capability required for access to this item
              'my_plugin-options', // the slug to use for the page in the URL
                              'my_plugin_manage_menu' // The function to call to render the page

    /* Using registered $page handle to hook script load */
    add_action('admin_print_scripts-' . $page, 'my_plugin_admin_scripts');

function my_plugin_admin_scripts() {
     * It will be called only on your plugin admin page, enqueue our script here
    wp_enqueue_script( 'my-plugin-script' );

function my_plugin_manage_menu() {
    /* Output our admin page */
  • I actually prefer admin_print_scripts-{hook} over my own posted solution, but as noted in the link in my Answer, it's apparently "incorrect" (also according to Codex). But I think the Codex is referencing the aforementioned link (and it's poorly written, to boot). – akTed Jan 17 '13 at 19:54
  • There's nothing wrong with using admin_print_scripts-{hook}, though it would be better to put the scripts in a .js file, and enqueue them, via admin_enqueue_scripts-{hook} instead. – Chip Bennett Jan 17 '13 at 20:18
  • See updated answer. You want to avoid the "global" admin_print_scripts hook. But by targeting your own Plugin's admin page specifically, via the {hook} suffix, either enqueue or print is fine. Though, if you're actually enqueueing a script, obviously you'd want to use wp_enqueue_script-{hook} to do that. If you need to print an ad hoc script, there's nothing wrong with using admin_print_scripts-{hook}. – Chip Bennett Jan 17 '13 at 20:23
  • 1
    There isn't an admin_enqueue_scripts-$hook_suffix (same for wp_*) in core. In admin-header.php, lines 63-69, are the relevant enqueueing hooks (for admin). – akTed Jan 17 '13 at 20:24
  • Please refer to wp-admin/admin-header.php, line 63. – Chip Bennett Jan 17 '13 at 20:27

To make your life easier and coding faster (no core file search needed), we've written the "Current Admin Info" Plugin.

This way you can easily see what you get back from the admin globals or the get_current_screen() function, which you then can access using the properties you see in the additional contextual help tabs.

// See dump
var_dump( get_current_screen()->property );

# @example
// Get the post type
$post_type = get_current_screen()->post_type;
// Get the current parent_file (main menu entry that meets for every submenu)
$parent = get_current_screen()->parent_file;

enter image description here

enter image description here


I don't yet understand why, but according to Codex, you should only use admin_enqueue_scripts to enqueue styles/scripts in the admin. I have an open Question asking why, but haven't yet received a satisfactory answer. The Codex entry might be in reference to this core dev's post.

Here's how to do it the "correct" way (note: the admin_enqueue_scripts hook should only be called from another hooked function, e.g., as I've done in the second code block with admin_menu. If you try to hook admin_enqueue_scripts too early, you'll get errors):

add_action('admin_enqueue_scripts', 'YOUR_ENQUEUEING_FUNCTION');
function YOUR_ENQUEUEING_FUNCTION($hook_suffix) {
    global $my_menu_hook_akt;

    // exit function if not on my own options page!
    // $my_menu_hook_akt is generated when creating the options page, e.g.,
    // $my_menu_hook_akt = add_menu_page(...), add_submenu_page(...), etc
    if ($hook_suffix != $my_menu_hook_akt) return;

    $handle = 'my_js';
    wp_register_script($handle, 'http://example.com/path/to/my-javascript.js');

Below is a fully functional plugin to play around with; it does nothing except inject your javascript file into the <head> of only your options page -

// Plugin Name:0-Menu Test
global $my_menu_hook_akt;

add_action('admin_menu', 'create_menu_akt');
function create_menu_akt() {
    global $my_menu_hook_akt;
    $my_menu_hook_akt = add_menu_page(
        'My Cool Plugin\'s Title',
        'My Cool Plugin\'s Name',
    add_action('admin_enqueue_scripts', 'enqueue_only_on_my_page_akt');
} // function create_menu_akt

function enqueue_only_on_my_page_akt($hook_suffix) {
    global $my_menu_hook_akt;

    // exit function if not on my own options page!
    // $my_menu_hook_akt is generated when creating the options page, e.g.,
    // $my_menu_hook_akt = add_menu_page(...), add_submenu_page(...), etc
    if ($hook_suffix != $my_menu_hook_akt) return;

    $handle = 'my_js';
    wp_register_script($handle, 'http://example.com/path/to/my-javascript.js');
} // function enqueue_only_on_my_page_akt

function draw_options_page_akt() {
    // draw your options page
} // function draw_options_page_akt
  • 3
    Please note that admin_print_scripts and admin_print_scripts-{hook} are not the same thing, and that the latter does not bear all the caveats of the former. But it is certainly best practice to use enqueue hooks to enqueue, and print hooks for when you need explicitly to print. – Chip Bennett Jan 17 '13 at 20:24
  • They are all three identical in execution, though. except admin-print-scripts-$hook_suffix is called one line after admin_enqueue_scripts and one line prior to admin-print-scripts in core (admin-header.php). Hence my confusion as why admin_print_styles is listed as the wrong way to do it in Codex. – akTed Jan 17 '13 at 20:38
  • Indeed they are - which is why I disagree with the assertion that it is any better or worse to use any of the three, when one is careful to ensure that {hook_suffix} is used to output only on the Plugin's specific admin page. :) – Chip Bennett Jan 17 '13 at 20:41
  • I completely agree! My only concern is that since a core dev had metioned to use admin_enqueue_scripts (in link in my Answer) future WP versions might change when the various hooks are executed. Or, that post could've been re: a then-core usage that's been "fixed" in a version after that post. – akTed Jan 17 '13 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.