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

Thu Mar 6 19:20:54 UTC 2014

Where was this discussion weeks ago,when we posted it to Make/Themes?

This change will not "break" users' sites, and there's nothing that says
that developers of current Themes can't propose a migration path to reach
compliance. That's the way we've handled such things in the past, and I see
no reason that we can't do the same thing here.

On Thu, Mar 6, 2014 at 1:42 PM, Otto <otto at ottodestruct.com> wrote:

> If the guideline is actually going to cause a situation where unwitting
> users will have their sites broken by our actions, then we cannot implement
> the guideline in this manner.
>
> We don't break sites. Not if we can find a better way.
>
> So, slow down a bit here. We can say existing themes should not implement
> such things, and require stringent security checks if they do. We can say
> existing themes cannot implement such things as new features. We can say
> that brand new themes must not implement such things. We can recommend
> methods of migration.
>
> But what we cannot do is say that theme authors must change things in a
> way that will break user's sites. That's a non-starter, and it's simply not
> going to be a realistic guideline to set or enforce.
>
> Over the long term, as things migrate towards what you want, then you make
> the rules more stringent to round up the stragglers. Phased deployment, in
> other words. You can't go from 0 to 60 in one swift burst without getting
> whiplash. :)
>
> -Otto
>
>
> On Thu, Mar 6, 2014 at 12:29 PM, Chip Bennett <chip at chipbennett.net>wrote:
>
>> If Bruce wants to discuss a *migration plan*, that's perfectly
>> acceptable. He and other developers have used them before.
>>
>> But the potential "site breakage" is already inherent in the Themes
>> impacted by the change, if they've been facilitating users to put
>> Theme-unrelated (i.e. arbitrary) scripts in the site header and footer via
>> Theme options. So, a blanket exception? No, I don't think that's the right
>> approach.
>>
>>
>> On Thu, Mar 6, 2014 at 1:26 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>
>>> Site analytics have been Plugin Territory for some time now.
>>>
>>> And a migration path isn't what the premise here; a grandfather
>>> exception is what was requested.
>>>
>>>
>>> On Thu, Mar 6, 2014 at 1:02 PM, Otto <otto at ottodestruct.com> wrote:
>>>
>>>> I'm kinda with Bruce on this one, this seems a bit strict to push
>>>> entirely in one change.
>>>>
>>>> I would say that a theme is allowed to do this sort of thing *if* it
>>>> has proper safety checks surrounding it. User must have unfiltered_html,
>>>> and if not, then the data has to be run through kses (much like core does
>>>> in posts/comments and such).
>>>>
>>>> I would also say that it is recommended for themes to not have that
>>>> sort of functionality at all, in favor of plugins that do this sort of
>>>> thing, so that a user using those fields for, say, Google Analytics doesn't
>>>> lose them when changing themes. Which is, of course, the point. Themes
>>>> should not have things that leads to a de-facto lock in when used for
>>>> obvious purposes. Theme authors that already have them should transition
>>>> users to using plugins and other non-theme dependent items for same.
>>>>
>>>> In the end, we need to focus on what's best for the users, and while
>>>> it's definitely better for them to not have these in themes, it's not
>>>> acceptable for us to enforce a system that will break sites because we
>>>> think it's somehow good for users as a whole. Even if we're right, we have
>>>> to be backward compatible here, and migrate to such rules over time, not
>>>> all at once.
>>>>
>>>>
>>>> -Otto
>>>>
>>>>
>>>> On Thu, Mar 6, 2014 at 11:48 AM, Bruce Wampler <weavertheme at gmail.com>wrote:
>>>>
>>>>> I know how to do it for future users, but I don't know any way to get
>>>>> people to read a notice to install the plugin BEFORE updating the theme.
>>>>> And unless the plugin is there first to capture those settings, the
>>>>> Settings API will will wipe out previous settings the instant they try to
>>>>> change any other options. Users: screwed. Sure it is their own fault for
>>>>> not reading the instructions, but that is just how people are.
>>>>>
>>>>> And, and as I've said before, only a tiny tiny tiny fraction of WP
>>>>> users can or even want to know squat about doing anything involving PHP. I
>>>>> seriously don't understand why you keep saying that we should
>>>>> expect/hope/want an average WP theme user to want to do anything involving
>>>>> PHP. That is just not a reasonable expectation.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 6, 2014 at 10:29 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>>
>>>>>> "Screwing" you users is only dependent on you not properly
>>>>>> transitioning theme settings to your plugin.
>>>>>>  On Mar 6, 2014 12:27 PM, "Bruce Wampler" <weavertheme at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> So, in other words, I'm forced to screw thousands of my theme users.
>>>>>>> So be it.
>>>>>>>
>>>>>>> Right now, users with raw html capability can insert whatever they
>>>>>>> want, including JavaScript, into <head>, the header, and the footer.
>>>>>>>
>>>>>>> They've been able to do this since I introduced by theme in 2010,
>>>>>>> and there are thousands and thousands of users who've been using that
>>>>>>> capability with no know issues for all that time.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 6, 2014 at 10:22 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>>>>>>
>>>>>>>> Any arbitrary script/stylesheet that hooks into wp_head or
>>>>>>>> wp_footer (or that can/should do so) is exactly the focus of the guideline
>>>>>>>> change. Allowing a grandfather exception would defeat the purpose.
>>>>>>>>
>>>>>>>> If you're talking about markup at template locations, that's
>>>>>>>> possibly worth discussing.
>>>>>>>> On Mar 6, 2014 12:16 PM, "Bruce Wampler" <weavertheme at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm trying to avoid specifics on this general group, but, to
>>>>>>>>> generalize...
>>>>>>>>>
>>>>>>>>> Using the WP Settings API runs all settings through validation
>>>>>>>>> checks which often filter the content, possibly deleting part of a
>>>>>>>>> particular setting through the filter (think JavaScript). So, my existing
>>>>>>>>> validation/filters allow one kind of content to be accepted (for those with
>>>>>>>>> raw html capability only). The new guidelines prohibit that kind of content
>>>>>>>>> in some places, so to comply with the new guidelines, I would have to
>>>>>>>>> simply change the validation filter to remove that content. But that same
>>>>>>>>> filter will then also remove that content from any users who had previously
>>>>>>>>> had the now prohibited content. So their sites will now be broken just by
>>>>>>>>> updating to the new version and opening the admin page - the previously
>>>>>>>>> valid settings will be filtered out.
>>>>>>>>>
>>>>>>>>> A plugin (which has been suggested as a way around this
>>>>>>>>> requirement) is not a solution in this case because they would have to
>>>>>>>>> install the plugin before updating to a new 3.9 compliant version of the
>>>>>>>>> theme, and then simply deactivating the plugin would revert to removing the
>>>>>>>>> settings which is not very user friendly behavior. So the only solution I
>>>>>>>>> can see to not screw my exiting users is to ask to get this one thing
>>>>>>>>> grandfathered for my existing themes.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 6, 2014 at 9:51 AM, Derek Herman <
>>>>>>>>> derek at valendesigns.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Bruce,
>>>>>>>>>>
>>>>>>>>>> I just read the WordPress 3.9 proposal and didn't see anything
>>>>>>>>>> about settings being erased - could you please elaborate on what would
>>>>>>>>>> cause that?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Derek Herman
>>>>>>>>>> http://valendesigns.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>>
>
> _______________________________________________
> 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/21681d89/attachment-0001.html>