3

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?

3 Answers 3

5

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

Edit

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.

Original

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:

<?php
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 */
}
?>
8
  • 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, 2013 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. Jan 17, 2013 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}. Jan 17, 2013 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, 2013 at 20:24
  • Please refer to wp-admin/admin-header.php, line 63. Jan 17, 2013 at 20:27
2

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

1

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');
    wp_enqueue_script($handle);
} // function YOUR_ENQUEUEING_FUNCTION

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 -

<?php
// 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',
        'manage_options',
        'my-cool-plugins-slug',
        'draw_options_page_akt'
    );
    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');
    wp_enqueue_script($handle);
} // function enqueue_only_on_my_page_akt


function draw_options_page_akt() {
    // draw your options page
} // function draw_options_page_akt
4
  • 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. Jan 17, 2013 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, 2013 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. :) Jan 17, 2013 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, 2013 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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