<div dir="ltr">The "after_setup_theme" name for that hook has always been a bit misleading, to be sure. But, it's really the only one available to the Theme to say even somewhat semantically, "this is where I'm going to define things related specifically to me". And even though $content_width is a global, it is still *entirely* Theme-dependent. It has no real use or context outside of the presentation layer. (Even if used in the admin area, it is used in the context of previewing the presentation layer.)<div>
<br></div><div style>In the ideal world, another semantic hook, such as "configure_theme", would be available for the Theme to define all of its add_theme_support() calls, etc.</div><div style><br></div><div style>
But, as it currently stands, we have the hooks you referenced:</div><div style><br></div><div style>plugins_loaded</div><div style>functions.php</div><div style>after_setup_theme</div><div style>init</div><div style><br></div>
<div style>So, the most semantic hook for a Theme to define its configuration (including $content_width, since it is Theme-dependent) is after_setup_theme. That's why I say that defining $content_width directly at functions.php execution is "arbitrary".</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 5:43 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com" target="_blank">otto@ottodestruct.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jan 21, 2013 at 4:00 PM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> By the same token: by Themes always hooking into after_setup_theme to define<br>
> $content_width, a Plugin would always know that it is defined at that hook,<br>
> and would not have to rely on the somewhat-more-arbitrary plugins_loaded<br>
> (IIRC?) when functions.php executes.<br>
<br>
</div>No, you have the order wrong.<br>
<br>
1. Plugins load<br>
2. do_action( 'plugins_loaded' );<br>
3. Theme's functions.php loads (child first, then parent)<br>
4. do_action( 'after_setup_theme' );<br>
<br>
After that, the only thing left as part of startup is the init action,<br>
basically.<br>
<br>
So if the theme hooked to after_setup_theme, and set its globals at<br>
that time, then a plugin needing that information would need to hook<br>
to after_setup_theme with a very high number for the priority (1000,<br>
say), to be sure that the theme has actually done its job already.<br>
<br>
One could reasonably argue that the plugin could hook to init to do<br>
this, but this seems like an somewhat improper (aka, lazy) use of init<br>
to me, from the plugin's perspective. The init action is overloaded<br>
already for lots of things.<br>
<br>
Also, "after_setup_theme", in it's very name, implies that it is run<br>
*after* the theme has been setup. Having the theme do setup related<br>
stuff on it (at least, setup related stuff that deeply affect other<br>
parts of the system, such as global variables), strikes me as a misuse<br>
of the hook. So I'd say that any "setup" that the theme needs to do<br>
which really affects the whole system should actually be outside of<br>
functions in the theme's functions.php file. For example, add_action<br>
calls and such are often outside of functions, to hook functions into<br>
other hooks. Setting up hooks is something that affects everything.<br>
Similarly, globals kind of affect everything too.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Otto<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>