<font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif">There's nothing much to add to @Dion :)</font></font></font><div><font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif"><br clear="all">
</font></font></font><div><strong><font face="arial, helvetica, sans-serif">----</font></strong></div><div><font face="arial, helvetica, sans-serif"><strong>Emil Uzelac</strong> | ThemeID | T: 224-444-0006 | Twitter: @EmilUzelac | E: <a href="mailto:emil@themeid.com" target="_blank">emil@themeid.com</a> | <a href="http://themeid.com/" target="_blank">http://themeid.com</a></font></div>
<div><font color="#999999" face="arial, helvetica, sans-serif">Make everything as simple as possible, but not simpler. - Albert Einstein</font></div><br>
<br><br><div class="gmail_quote">On Tue, Sep 27, 2011 at 8:46 AM, Dion Hulse (dd32) <span dir="ltr"><<a href="mailto:wordpress@dd32.id.au">wordpress@dd32.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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> __( '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> );</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( 'admin_print_styles-' . $theme_page, 'twentyeleven_admin_enqueue_scripts' );</div>
<div><br></div><div>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.</div>
<div><br></div><div>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" target="_blank">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"><div><div></div><div class="h5">On 27 September 2011 23:26, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
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 "oenology-settings":<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( 'some-arbitary-script', get_template_directory_uri() . '/js/script-name.js' );</div></div><div><div>}</div>
</div><div><div>add_action( 'admin_print_scripts-appearance_page_oenology-settings', 'oenology_enqueue_admin_scripts' );</div></div></blockquote><div><div><br></div><div>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.</div>
<div><br></div><div>So: what are your thoughts?</div><div><br></div><font color="#888888"><div>Chip</div></font></div>
<br></div></div>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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>
<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></div>