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

Thu Mar 6 18:26:38 UTC 2014

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140306/949e0801/attachment-0001.html>