<p>Ah, I still haven't managed to find the time to read all the guidelines :)</p>
<p>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 :)</p>
<p> <br>
On Sep 28, 2011 12:04 AM, "Chip Bennett" <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
><br>
> I like that, Dion!<br>
><br>
> 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.<br>
><br>
> Chip<br>
><br>
> On Tue, Sep 27, 2011 at 8:46 AM, Dion Hulse (dd32) <<a href="mailto:wordpress@dd32.id.au">wordpress@dd32.id.au</a>> wrote:<br>
>><br>
>> 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:<br>
>><br>
>> $theme_page = add_theme_page(<br>
>> __( 'Theme Options', 'twentyeleven' ), // Name of page<br>
>> __( 'Theme Options', 'twentyeleven' ), // Label in menu<br>
>> 'edit_theme_options', // Capability required<br>
>> 'theme_options', // Menu slug, used to uniquely identify the page<br>
>> 'twentyeleven_theme_options_render_page' // Function that renders the options page<br>
>> );<br>
>><br>
>> $theme_page is the hook suffix, this can then be used like this:<br>
>><br>
>> add_action( 'admin_print_styles-' . $theme_page, 'twentyeleven_admin_enqueue_scripts' );<br>
>><br>
>> 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.<br>
>><br>
>> 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): <a href="http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Load_scripts_only_on_plugin_pages">http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Load_scripts_only_on_plugin_pages</a><br>
>><br>
>><br>
>> On 27 September 2011 23:26, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
>>><br>
>>> Good morning, reviewers,<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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?<br>
>>><br>
>>> I would like to get your thoughts on requiring the use of the admin_print_scripts-{$hook_suffix} for such scripts.<br>
>>><br>
>>> For example, assuming the Theme uses add_theme_page(), for which the fourth argument is $menu_slug, this hook would be constructed as follows:<br>
>>><br>
>>>> Base: admin_print_scripts-<br>
>>>> Context: appearance_page_<br>
>>>> Page: $menu_slug<br>
>>><br>
>>><br>
>>> Or, put all together:<br>
>>><br>
>>>> admin_print_scripts-appearance_page_$menu_slug<br>
>>><br>
>>><br>
>>> For example, in Oenology, my $menu_slug is "oenology-settings":<br>
>>><br>
>>>> admin_print_scripts-appearance_page_oenology-settings<br>
>>><br>
>>><br>
>>> So, the entire thing would look like:<br>
>>><br>
>>>> function oenology_enqueue_admin_scripts() {<br>
>>>> wp_enqueue_script( 'some-arbitary-script', get_template_directory_uri() . '/js/script-name.js' );<br>
>>>> }<br>
>>>> add_action( 'admin_print_scripts-appearance_page_oenology-settings', 'oenology_enqueue_admin_scripts' );<br>
>>><br>
>>><br>
>>> 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.<br>
>>><br>
>>> So: what are your thoughts?<br>
>>><br>
>>> Chip<br>
>>><br>
>>> _______________________________________________<br>
>>> theme-reviewers mailing list<br>
>>> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
>>> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> theme-reviewers mailing list<br>
>> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
>> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
</p>