<div>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></div><div><br></div><div>        $theme_page = add_theme_page(<br>                __( &#39;Theme Options&#39;, &#39;twentyeleven&#39; ),   // Name of page<br>

                __( &#39;Theme Options&#39;, &#39;twentyeleven&#39; ),   // Label in menu<br>                &#39;edit_theme_options&#39;,                    // Capability required<br>                &#39;theme_options&#39;,                         // Menu slug, used to uniquely identify the page<br>

                &#39;twentyeleven_theme_options_render_page&#39; // Function that renders the options page<br>        );</div><div><br></div><div>$theme_page is the hook suffix, this can then be used like this:</div><div><br></div><div>add_action( &#39;admin_print_styles-&#39; . $theme_page, &#39;twentyeleven_admin_enqueue_scripts&#39; );</div>

<div><br></div><div>There&#39;s no need to &quot;guess&quot; or hard code the hook suffix this way, and if for some reason it changes, you&#39;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&#39;s a potential issue.</div>

<div><br></div><div>Unfortunately, the TwentyEleven theme hard codes it, so I can&#39;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&#39;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></div>

<div><br></div><br><div class="gmail_quote">On 27 September 2011 23:26, Chip Bennett <span dir="ltr">&lt;<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Good morning, reviewers,<div><br></div><div>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.</div><div>

<br>
</div><div>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?</div>


<div><br></div><div>I would like to get your thoughts on requiring the use of the <a href="http://adambrown.info/p/wp_hooks/hook/admin_print_scripts-%7B$hook_suffix%7D" target="_blank">admin_print_scripts-{$hook_suffix}</a> for such scripts.</div>


<div><br></div><div>For example, assuming the Theme uses add_theme_page(), for which the fourth argument is $menu_slug, this hook would be constructed as follows:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">


<div><div>Base: admin_print_scripts-</div></div><div><div>Context: appearance_page_</div></div><div><div>Page: $menu_slug</div></div></blockquote><div><br></div><div>Or, put all together:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">


<div>admin_print_scripts-appearance_page_$menu_slug</div></blockquote><div><br></div>For example, in Oenology, my $menu_slug is &quot;oenology-settings&quot;:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">


<div>admin_print_scripts-appearance_page_oenology-settings</div></blockquote><div><br><div>So, the entire thing would look like:</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><div>function oenology_enqueue_admin_scripts() {</div></div><div><div>    wp_enqueue_script( &#39;some-arbitary-script&#39;, get_template_directory_uri() . &#39;/js/script-name.js&#39; );</div></div><div><div>}</div>


</div><div><div>add_action( &#39;admin_print_scripts-appearance_page_oenology-settings&#39;, &#39;oenology_enqueue_admin_scripts&#39; );</div></div></blockquote><div><div><br></div><div>I would like to propose this implementation as a &quot;best practice&quot; 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&#39;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.</div>


<div><br></div><div>So: what are your thoughts?</div><div><br></div><font color="#888888"><div>Chip</div></font></div>
<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" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br>