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

Thu Mar 6 21:52:43 UTC 2014

While I won't argue either or... Let's not drive in reverse here.

We already went over this on several occasions and pretty much all* authors
responded in a very positive manner and moved or removed what falls into
plugin-territory.

Making more exceptions is fine, however the time-frame should not be
measured in months
at least not for the updates without required changes.

On Thu, Mar 6, 2014 at 3: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.
>
> 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
>>
>>
>
> _______________________________________________
> 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/d8f868d6/attachment.html>