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

Thu Mar 6 21:47:19 UTC 2014

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.

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:

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

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.

Which makes this conclusion untrue:

 If it can't be handled by a general plugin (and it can't - really...),
then it has to be a theme issue

Plugins can hook into wp_head and wp_footer, just as easily as a Theme can.
The only thing that a Plugin *can't* do is universally hook into template
locations to output markup, because there are precious-few standard
template-location hooks.

 So it isn't in the theme directly, the *only* alternative is a *theme
specific *plugin to do it, and that seems intellectually dishonest to me.

Actually, the most user-friendly approach is for a user-defined,
site-functionality Plugin for such one-off, arbitrary scripts that control
site functionality independent of the active Theme. A Theme-functionality
Plugin gets part of the way there, and has the benefit of helping users
understand the proper segregation of functionality and presentation.

Sorry to bring this up again, but Chip asked why this wasn't discussed in
the make site, and it was.

You're welcome to discuss it on the list. Please continue to do so. I was
asking why Otto hasn't weighed in with such an opinion until now.

So, I'm just asking for some kind of grandfathering so I people's sites
won't break immediately.

If you're talking about a *migration plan*, you don't have to ask. Just
communicate it, in-ticket, with whomever reviews the next version of your
Theme. But "grandfathering" means "exception", which is not warranted.

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

> Thanks, Otto, for a more rational approach to this.
>
> 1. I can guarantee that there will be sites broken if I have to
> immediately implement this requirement. There even is a popular child theme
> that uses the scripting features in question that will break. Lots of
> side-effects. There may not be that many themes with this kind of option,
> but disabling the feature without some kind of phase-in will give serious
> grief to many of my users. And this is kind of unexpected when going from
> say 3.8 to 3.9. I think users are more willing to put up with grief for
> what is traditionally a bigger step - like to 4.0. But causing serious
> breaks in a decimal change just encourages users to not upgrade - and that
> is a really bad idea!
>
> 2. I tried to argue my case on the make site, and lost that argument,
> 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, and that there is a need for users to insert script in those
> areas (e.g., scripts from small, perhaps unknown, but important to users,
> to add various critical site functionality). If it can't be handled by a
> general plugin (and it can't - really...), then it has to be a theme issue.
> So it isn't in the theme directly, the *only* alternative is a *theme
> specific *plugin to do it, and that seems intellectually dishonest to me.
> I wish there were more hooks/filters to handle this, but there simply is
> nothing when it comes to dealing with the header area - including content
> surrounding the header image and menus - which are usually defined in
> header.php, or site copyright and credit information, found in footer.php.
> Sorry to bring this up again, but Chip asked why this wasn't discussed in
> the make site, and it was.
>
> 3. So, I'm just asking for some kind of grandfathering so I people's sites
> won't break immediately. I don't know if there ever will be a way to force
> people to update to a plugin properly - maybe several months of a warning
> on the admin panel. And the ability to work both ways for at least a while
> - saving the options via a plugin, or using the existing setting.
>
> Thanks for listening...
>
> Bruce
>
>
>
>
>
> On Thu, Mar 6, 2014 at 1:08 PM, Philip M. Hofer (Frumph) <
> philip at frumph.net> wrote:
>
>>   Make no mistake, if I were able to have updated the theme itself and
>> fixed bugs and kept it code compliant with core it would have been far
>> better for the users and myself.   Along with having the plugin/comic easel
>> as something to migrate to when the users were ready, not being forced into
>> it.
>>
>> As it stands, I lost more money then I made in this last year helping
>> people fix their sites, regardless of how many video's, tutorials and tools
>> I made to help them migrate.
>>
>> ...and it still goes on and on;  that and WordPress doesn't have all of
>> the functionality available for common things to co-sync custom post types
>> as regular post types, so functionality was lost between theme and
>> plugin.
>>
>> Yeah, .. I was and always am in favor for the 'anything new needs to
>> adhere to the requirements' - but if it's a theme that's been in
>> circulation for a number of years; don't force it - let it work it's way up.
>>
>>  *From:* Otto <otto at ottodestruct.com>
>> *Sent:* Thursday, March 06, 2014 11:03 AM
>> *To:* Discussion list for WordPress theme reviewers.<theme-reviewers at lists.wordpress.org>
>> *Subject:* Re: [theme-reviewers] How to request "grandfathered"
>> exception to WP 3.9 Theme guidelines?
>>
>>  I thought you migrated people to the plugin for that one. The plugin
>> route is a much better experience for your case, I think.
>>
>> Regardless, migration takes time. 3.9 is coming out in 6 weeks, so that's
>> realistically not enough time for theme authors to migrate users to a
>> better way. 4.0 in August or 4.1 in December might be a better timeframe to
>> start that level of enforcement. Require authors to start building in
>> plugin-migration, sort of thing. Maybe provide a plugin that will handle
>> the case for them if necessary, and code to add to a theme that eases that
>> migration.
>>
>> -Otto
>>
>>
>> On Thu, Mar 6, 2014 at 12:49 PM, Philip M. Hofer (Frumph) <
>> philip at frumph.net> wrote:
>>
>>>   ^ yay otto.   Little too late in my case with ComicPress, but yay for
>>> this now.
>>>
>>>
>>  ------------------------------
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20140306/5400740d/attachment-0001.html>