[theme-reviewers] Admin Script Enqueueing

[Dion Hulse (dd32)]

Ah, I still haven't managed to find the time to read all the guidelines :)

For me, it's also some standardization between Themes and plugins, teach
them the right way first, and they'll never do it wrong. It's not only for
existing themers, but also for the many people that are new to WordPress and
will start by hacking up a theme, then move onto writing their own theme,
then hopefully a plugin or 2, eventually giving something back to the
WordPress core itself.. If the same best practices are held at every step of
the way, hopefully we'll get a constant stream of awesome new developers
learning it the right way :)


On Sep 28, 2011 12:04 AM, "Chip Bennett" <chip at chipbennett.net> wrote:
>
> 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} 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
>>
>
>
> _______________________________________________
> 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/20110928/6efeeffc/attachment.htm>