[theme-reviewers] Admin Script Enqueueing

[Dion Hulse (dd32)]

Some insight from a developer: The best location to get the Hook suffix for
an added page, is from the add_*_page() call itself, For example:

$theme_page = add_theme_page(
__( 'Theme Options', 'twentyeleven' ), // Name of page
__( 'Theme Options', 'twentyeleven' ), // Label in menu
'edit_theme_options', // Capability required
'theme_options', // Menu slug, used to uniquely identify the page
'twentyeleven_theme_options_render_page' // Function that renders the
options page
);

$theme_page is the hook suffix, this can then be used like this:

add_action( 'admin_print_styles-' . $theme_page,
'twentyeleven_admin_enqueue_scripts' );

There's no need to "guess" or hard code the hook suffix this way, and if for
some reason it changes, you're guaranteed that WordPress will give you the
right one. This is incredibly useful if you use the add_theme_page()
wrappers, as if the appearance page moves to a different location/parent for
some reason one day, you know the new slug returned will point to the new
location - I doubt any developer wants to break backwards compatibility of
that, it's a potential issue.

Unfortunately, the TwentyEleven theme hard codes it, so I can't give that to
you as a reference, just the above 2 changes and this codex page on how to
add a Plugin page, and enqueue scripts only on it, it uses the same method
as above (Remember, Plugin pages and Theme pages are a like in every way
aside from the file it's in):
http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Load_scripts_only_on_plugin_pages


On 27 September 2011 23:26, Chip Bennett <chip at chipbennett.net> wrote:

> Good morning, reviewers,
>
> I thought this morning would be a good time to start a discussion on the
> guidelines/best-practices regarding enqueueing arbitrary scripts in the
> WordPress Admin area.
>
> As you know, current review generally focuses on ensuring that scripts
> intended for the front-end are not enqueued in the admin area, generally by
> wrapping the wp_enqueue_script() calls in a if ( ! is_admin() ) conditional.
> However: what about Themes that *do* need to enqueue scripts in the admin
> area, e.g. for their Theme settings page?
>
> I would like to get your thoughts on requiring the use of the
> admin_print_scripts-{$hook_suffix}<http://adambrown.info/p/wp_hooks/hook/admin_print_scripts-%7B$hook_suffix%7D>for such scripts.
>
> For example, assuming the Theme uses add_theme_page(), for which the fourth
> argument is $menu_slug, this hook would be constructed as follows:
>
> Base: admin_print_scripts-
> Context: appearance_page_
> Page: $menu_slug
>
>
> Or, put all together:
>
> admin_print_scripts-appearance_page_$menu_slug
>
>
> For example, in Oenology, my $menu_slug is "oenology-settings":
>
> admin_print_scripts-appearance_page_oenology-settings
>
>
> So, the entire thing would look like:
>
> function oenology_enqueue_admin_scripts() {
>     wp_enqueue_script( 'some-arbitary-script', get_template_directory_uri()
> . '/js/script-name.js' );
> }
> add_action( 'admin_print_scripts-appearance_page_oenology-settings',
> 'oenology_enqueue_admin_scripts' );
>
>
> I would like to propose this implementation as a "best practice" as a
> minimum; however, given the known issues regarding interaction between Theme
> and Plugin scripts in the Admin area (Plugin developers - rightly so -
> generally don't appreciate Themes outputting their scripts on every single
> admin page, because it often results in breakage of the Plugin if it relies
> on certain scripts being loaded/not loaded), I believe this is worthy of
> consideration as a requirement. But for now, I just want to get the
> discussion started.
>
> So: what are your thoughts?
>
> Chip
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110927/e30c9d70/attachment.htm>