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

Bruce Wampler weavertheme at gmail.com
Fri Mar 7 17:52:45 UTC 2014


Chip, let me try to summarize what I think you said:

1. There are two kinds of non-theme-originated JavaScripts: "real" scripts,
and script "widgets". Real scripts manipulate the DOM and don't usually
directly generate html output (perhaps an oversimplification, but I hope
that is the main point). Script Widgets generate HTML output (like a Google
Search bar, a map, a music player, etc.). This is a really significant
distinction, and I think the cause of all the miscommunication. In the most
general case, a script is a script. In practice, a "Script Widget" is a
widely available technique used to allow people to add interesting features
to their  sites via copy/paste, and the use case I've been pleading to keep
in my theme.

2. Real scripts not part of the theme can be added only via a plugin using
the wp_head and wp_footer actions.

3. Script Widgets can be treated just like any other HTML allowed to be
injected into whatever content regions the theme supports. But I would add
the unfiltered HTML capability restriction. But this is the feature used
mostly by my users - an easy way to add functionality to the non-content
portions of a site.

If this is the reality of the new guideline, then the migration process is
significantly easier since it only affects two places. References to
header.php footer.php aren't really relevant to the standard - it is the
area between <head> and </head>, and wherever scripts get emitted from
wp_footer().

So I think I will use the phase-out suggestion - show the relevant
wp_head/wp_footer region options if set, don't let new use of them, and
phase out completely to the support plugin.

About versions: I 100% agree that each version can contain critical
upgrades, but plenty of software marketers have worked very hard over the
years, and spent lots of money to drive home that a new integer version is
the time to fork over the money for wonderful new features. That user
expectation trickles down to all software - including WordPress. I don't
think it is in our power to overcome all that marketing power.

As long as WordPress follows its current versioning practice, people will
expect that going from 3.x to 4.x is a big deal. (And why is 4.0 after 3.9
anyway - why not 3.10? Because we've all been programmed to think that
way.) I think that is partly why Chrome and Firefox abandoned the major
integer version once a year or so approach, and we are now on Chrome
30-sometihng. I've noticed some plugins following a non-integer versioning
practice as well. WP as gone from fairly infrequent tenths versions to a
much more frequent update cycle. This faster update cycle warrants a
reexamination of the backward compatibility of themes, I think. Right now
themes can only go back two versions (e.g., 3.6 while 3.8 is out). But 3.6
was not that long ago. My theme strictly follows this guideline (because I
believe in that principle) and won't load for 3.5. This has drawn
complaints from my community, so perhaps this should slip back to more than
2 versions?


On Fri, Mar 7, 2014 at 7:17 AM, Chip Bennett <chip at chipbennett.net> wrote:

> In an important aspect: yes, we're talking apples and oranges. For
> instance:
> _______________________________________________
> 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/bca9b03b/attachment.html>


More information about the theme-reviewers mailing list