[theme-reviewers] How to request "grandfathered" exception to WP 3.9 Theme guidelines?

Fri Mar 7 14:17:42 UTC 2014

In an important aspect: yes, we're talking apples and oranges. For instance:

 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.

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:

1) What user-defined content is being added
2) What the appropriate place in the template is to add that content
3) Whether and how WordPress provides for that content to be added to the
template

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.

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.

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.

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).

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.

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:

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.

Adding <script> markup is handled entirely different from adding HTML
markup to the template. So let me try to untangle this:

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.)
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.
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.
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.

Let's make sure we're on the same page:

What do you mean by an arbitrary script?

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.

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?

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.)

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.)

See, we're not that far off from each other. :)

Side subject, but potentially important:

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.

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.

On Thu, Mar 6, 2014 at 7:50 PM, Bruce Wampler <weavertheme at gmail.com> wrote:

>
>
>
> On Thu, Mar 6, 2014 at 2:47 PM, Chip Bennett <chip at chipbennett.net> wrote:
>
>> 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.
>>
>
> 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.
>
> 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.
>
> 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.)
>
> 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.
>
>
>>
>> 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.
>>
>> 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.
>>
>> Third: this statement is absolutely false:
>>
>
> 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.
>
>>
>> ...although I *still* 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 *not* be handled by an independent plugin
>> of any sort...
>>
>>
> This is totally irrelevant to the point I made (although it does applies
> to the <head>...</head>, etc. blocks):
>
>>
>> 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.
>>
>
>
> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140307/f044a0e0/attachment-0001.html>