[theme-reviewers] Admin Script Enqueueing

[Chip Bennett]

I like that, Dion!

Note that, for any Theme in the repository, the hook suffix is ALWAYS going
to be appearance_page_$menu_slug (because we require use of
add_theme_page()); however, any time we can suggest fail-safe code (such as
your recommended implementation), I'm all in favor of it.

Chip

On Tue, Sep 27, 2011 at 8:46 AM, Dion Hulse (dd32) <wordpress at dd32.id.au>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/53d91bea/attachment.htm>