<div dir="ltr">In an important aspect: yes, we're talking apples and oranges. For instance:<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px"> I'm talking about injecting user defined/copied <script>code here</script> into the middle of the code produced by the standard theme functions header.php and footer.php.</span><br>
</div></blockquote></div><div><br></div><div>The header.php and footer.php files are nothing special; they are just that: files. They are called by the main template file (e.g. index.php), and have a certain amount of markup in them. They're really not relevant to this discussion, and really only add confusion. What is important:</div>
<div><br></div><div>1) What user-defined content is being added</div><div>2) What the appropriate place in the template is to add that content</div><div>3) Whether and how WordPress provides for that content to be added to the template</div>
<div><br></div><div>So, for user-defined <script> code, the appropriate place in the template to add such code is in the *document* <head> or in the *document* footer. WordPress provides a means to add such content, to both locations: the wp_head and wp_footer actions.</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">Other than calling wp_head() and wp_footer(), what do they have to do with the actions wp_head and wp_footer? I'm not talking about enqueuing scripts. I'm talking about injecting scripts, and my reading of the standard is that it applies to footer.php and header.php. Is that wrong? In all of my discussions, I've always said header.php and footer.php, and my understanding of the clarifications on the make site were that the no-script requirement applied to all of header.php and footer.php.</span><br>
</div></blockquote></div><div><br></div><div>The correct way to add <script> code to the document head is to enqueue a script, inside of a callback, hooked into an appropriate action (wp_enqueue_scripts, which fires at priority 0 at the wp_head action). The correct way to add <script> code to the document footer is to enqueue a script, inside of a callback, hooked into an appropriate action (wp_enqueue_scripts, using the $in_footer Boolean argument in the wp_enqueue_script() call). This is true for scripts defined by the Theme, that exist in Theme-bundled script files.</div>
<div><br></div><div>The correct way to add arbitrary <script> code to the document head is to echo that script inside of a callback, hooked into an appropriate action (wp_head, usually at the default priority 10). The correct way to add arbitrary <script> code to the document footer is to echo that script inside of a callback, hooked into an appropriate action (wp_footer, possibly with a priority of 11 or higher, depending on whether that script needs to output before or after other scripts output at wp_footer).</div>
<div><br></div><div>So, if the Theme is outputting <script> markup directly in the document <head> or the document footer, then it's already doing things incorrectly. Per long-standing guidelines, Themes *must* enqueue scripts and hook them, not drop "hard-coded" script markup in the template. Looking at the Weaver II header.php and footer.php, it appears that this is the case. That will need to be addressed in future revisions to the Theme.</div>
<div><br></div><div>But it is important to keep in mind that, thus far, we're talking solely about <script> markup (which also applies to <style> markup). We should be careful to avoid conflation of issues, such as below:</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">If that is wrong, and it is okay to inject actual <script> directly into <head>...</head>, plus in the html display portion of the header (e.g., surrounding the title, header image, and menus), or in the footer around the copyright and credits, then we've had a big misunderstanding. But I'm pretty sure I was crystal clear I was describing injecting JavaScripts in those sections. If it is understood that those are the content locations I'm talking about, then my statements about plugins not being able to do that is 100% accurate and true without any question.</span><br>
</div></blockquote></div><div><br></div><div>Adding <script> markup is handled entirely different from adding HTML markup to the template. So let me try to untangle this:</div><div><br></div><div>1) <script> markup in the document <head> and or document footer cannot be directly injected into the template, anywhere. Per long-standing guidelines, it *must* be enqueued at an appropriate hook, as detailed above. (Note: here, we're not talking about appropriate inline scripts, such as a slider instantiation.)</div>
<div>2) Because the appropriate hooks are known and available to Themes and Plugins alike, <script> markup in the document <head> or document footer can be added by Plugins just as easily as by a Theme.</div><div>
3) The above does not in any way whatsoever apply to HTML markup injected in the template. You are free to define Theme options, or dynamic sidebars, or template hooks (or probably other means) for users to add HTML markup to the site masthead, or to post footers, etc. </div>
<div>4) Because template markup is by-definition not standard, only the Theme can define injectible template locations (unless the Theme uses a standard, such as THA). So, unless a Theme is using a voluntary standard such as THA, its defined injectible template locations are unavailable to Plugins.</div>
<div><br></div><div>Let's make sure we're on the same page:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">What do you mean by an arbitrary script? </span><br>
</div></blockquote></div><div><br></div><div>An "arbitrary" script is one that is defined by the user, or otherwise agnostic to the Theme. Basically, it's any script not defined by the Theme. The Theme defines its scripts, which are bundled either as script files, or coded directly into a callback. The Theme uses these scripts for Theme-related and Theme-specific purposes. Such scripts pose no potential security issues, because they are static - they do not change from the moment they are reviewed during the Theme approval process until the moment they are used by the end user. Arbitrary scripts must rely on proper sanitization, validation, and escaping, because they are unknown/untrusted.</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">For example, my users want to add a custom webmaster generated Google Search script into the displayed header right above the menu, or in somewhere the footer area. The want to inject a script into one of those two places that will display a "Web Award" logo from an obscure web tracking site. All using copy/pasted JavaScripts. Are these presentational or content?</span><br>
</div></blockquote></div><div><br></div><div>These are "scripts", but they are basically third-party "widgets". They result in HTML markup being output in the template. They are not intended to be output in the document <head> or document footer, and as such, do not fall under the proposed guideline. (Note: they are also *exactly* the sort of thing that the Theme Hooks Alliance attempts to simplify for Theme developers and end users.)</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">Or, they want to temporarily add a <script> to the <head>...</head> section to verify ownership of their site, for example. (<b>Okay, THAT one could be done by a general purpose plugin using the wp_head action</b>, but we are still talking about breaking existing sites by eliminating adding scripts.)</span><br>
</div></blockquote></div><div><br></div><div>See, we're not that far off from each other. :)</div><div><br></div><div>Side subject, but potentially important:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><span style="font-family:arial,sans-serif;font-size:13px">And you may think there is no difference between 3.8 to 3.9, and 3.9 to 4.0, but if you polled everyday users, they will not agree. Going to a new integer version has traditionally been considered by the vast majority of computer users to be a BIG DEAL. That may be changing with the advent of frequent versions of Chrome, Firefox, etc, but I promise you the change from Windows 7 to Windows 8 was a big deal. It was a big deal when WP 3.0 came out.</span><br>
</div></blockquote></div><div><br></div><div>Then we, as a community and as developers of Themes used by end users whom we presumably care about, suck at educating our users - and dangerously so. It is part of our duty as responsible developers to help educate our users about the nature of WordPress versioning, so that our users understand, for example, that an update to WordPress 3.8 or 3.9 is every bit as important as an update to WordPress 4.0, because all are considered by WordPress developers to be major updates.</div>
<div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 7:50 PM, Bruce Wampler <span dir="ltr"><<a href="mailto:weavertheme@gmail.com" target="_blank">weavertheme@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Thu, Mar 6, 2014 at 2:47 PM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It appears that you're lumping WAY too much into the scope of what you're asking, and way overstating the impact of the guideline. Your issue seems to jump around from scripts hooked into wp_head/wp_footer, to markup hooked into the template, to Child Themes that use their own scripts.</div>
</blockquote><div><br></div></div><div>Maybe we're talking apples and oranges, but I don't think so. I'm talking about injecting user defined/copied <script>code here</script> into the middle of the code produced by the standard theme functions header.php and footer.php. Other than calling wp_head() and wp_footer(), what do they have to do with the actions wp_head and wp_footer? I'm not talking about enqueuing scripts. I'm talking about injecting scripts, and my reading of the standard is that it applies to footer.php and header.php. Is that wrong? In all of my discussions, I've always said header.php and footer.php, and my understanding of the clarifications on the make site were that the no-script requirement applied to all of header.php and footer.php. <br>
<br></div><div>If that is wrong, and it is okay to inject actual <script> directly into <head>...</head>, plus in the html display portion of the header (e.g., surrounding the title, header image, and menus), or in the footer around the copyright and credits, then we've had a big misunderstanding. But I'm pretty sure I was crystal clear I was describing injecting JavaScripts in those sections. If it is understood that those are the content locations I'm talking about, then my statements about plugins not being able to do that is 100% accurate and true without any question.<br>
<br></div><div>What do you mean by an arbitrary script? For example, my users want to add a custom webmaster generated Google Search script into the displayed header right above the menu, or in somewhere the footer area. The want to inject a script into one of those two places that will display a "Web Award" logo from an obscure web tracking site. All using copy/pasted JavaScripts. Are these presentational or content? I don't know. I do know the ONLY way to get them into those locations is by some kind of code injection, and my users have had that capability since 2010. These are not theme defined scripts - they are scripts users have found/created. Or, they want to temporarily add a <script> to the <head>...</head> section to verify ownership of their site, for example. (Okay, THAT one could be done by a general purpose plugin using the wp_head action, but we are still talking about breaking existing sites by eliminating adding scripts.)<br>
<br></div><div>And you may think there is no difference between 3.8 to 3.9, and 3.9 to 4.0, but if you polled everyday users, they will not agree. Going to a new integer version has traditionally been considered by the vast majority of computer users to be a BIG DEAL. That may be changing with the advent of frequent versions of Chrome, Firefox, etc, but I promise you the change from Windows 7 to Windows 8 was a big deal. It was a big deal when WP 3.0 came out.<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>
<br></div><div>First: how would this change impact a Child Theme? If a Child Theme enqueues a script and hooks that script into wp_head (or an appropriate sub-hook), then this guideline has no impact on it. A Theme-defined script used for presentational purposes is unaffected by this change, whether that script is used by a stand-alone Theme or by a Child Theme. The guideline only applies to *arbitrary* scripts - that is, scripts that impact site functionality and/or are Theme-independent, and are defined by the end user.</div>
<div><br></div><div>Second: the "step" from 3.8 to 3.9 is *exactly the same* as the "step" from 3.9 to 4.0. All three are MAJOR versions of WordPress. As developers, we owe it to our users to ensure that they understand the WordPress versioning system, so that we don't enable/facilitate users still to be using WordPress 3.0, because they mistakenly (and dangerously) believe that versions 3.1 through 3.9 are just "decimal" releases.</div>
<div><br></div><div>Third: this statement is absolutely false:</div></div></blockquote><div><br></div></div><div>THIS IS ABSOLUTELY TRUE. NO QUESTION - when considered in the specified context: the displayed content portions of header.php and footer.php. I don't understand how you can even challenge the truth of it. I know you've written a theme, so how can you say it is not true. You cannot change the content of the displayed header and footer areas with a plugin. It cannot be done. Show me how if you think it is possible. <br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><span style="font-family:arial,sans-serif;font-size:13px">...although I </span><b style="font-family:arial,sans-serif;font-size:13px">still</b><span style="font-family:arial,sans-serif;font-size:13px"> contend that the idea that this particular feature (JavaScript in the site header and footer area (not <head>, but in the header.php and footer.php) can </span><b style="font-family:arial,sans-serif;font-size:13px">not</b><span style="font-family:arial,sans-serif;font-size:13px"> be handled by an independent plugin of any sort...</span><br>
</div></blockquote></div></div></blockquote><div><br></div></div><div>This is totally irrelevant to the point I made (although it does applies to the <head>...</head>, etc. blocks):<br></div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>
</div></blockquote></div><div><br></div><div>Plugins have equal access to the wp_head and wp_footer hooks, and can hook anything into those hooks that a Theme can hook into them.</div></div></blockquote><div><br></div><br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<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></div><br></div></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></div>