[theme-reviewers] Grandfather Themes?

Tue Jun 25 18:20:16 UTC 2013

A granted exception to the guidelines is not equivalent to
"grandfathering". For something written two years ago, that response
remains remarkably germane today.
On Jun 25, 2013 2:15 PM, "Philip M. Hofer (Frumph)" <philip at frumph.net>
wrote:

>   There was; unfortunately those emails we used to have on my mail server
> are all gone now for me to refresh your memory on the discussion, I will
> sum it up for you though,  Bruce in the past, specifically June 27th, 2011
> Bruce made the same email to the thread that he just now did.
>
> This was your response back then:
>
> http://lists.wordpress.org/pipermail/theme-reviewers/2011-June/006081.html
>
> When we had a group discussion in private, both Cais and myself brought up
> that themes need to have backwards compatibility for their users and it was
> unjustified in requiring a plugin to be made specifically for minor things
> that a theme can handle sufficiently.   We all agreed that it would be case
> by case at that point, hence grandfathering.
>
> my 2cents.
>
> The shortcodes and everything else that is ‘plugin’ based in your opinion
> makes the theme unique, not derivative; and there are quite a few people
> who have been creating themes for a long time which utilizes functionality
> in themes that do no harm.
>
> The decision to ‘reject’ themes based on this and make it a requirement is
> really not something that is wanted, I can speak for myself and you read
> the messages from other’s who state the same thing.
>
> I believe I read that the backing idea is to make all themes compatible
> with all of the other themes on the repository.    IF that is the case,
> then create a theme that everyone can make a design off of and require us
> to use that; because there’s no sense anymore for anyone to make something
> custom/scratch.
>
> To summarize:
> There is nothing wrong with having a theme that has it’s own features as
> long as the core component calls are up to date.
>
>
>   *From:* Chip Bennett <chip at chipbennett.net>
> *Sent:* Tuesday, June 25, 2013 10:43 AM
> *To:* [theme-reviewers] <theme-reviewers at lists.wordpress.org>
> *Subject:* Re: [theme-reviewers] Grandfather Themes?
>
>
> There has never been a "grandfather" provision. All Themes have always
> been required to conform to all guidelines as current at the time the Theme
> is submitted for review.
> On Jun 25, 2013 12:16 PM, "Bruce Wampler" <weavertheme at gmail.com> wrote:
>
>>       I just submitted a revision for my theme, Weaver II. This theme
>> has been in the repository for several years, and met all the theme
>> recommendations when it was first submitted. It has since become one of the
>> more popular themes available from the repository and has, as far as I can
>> track, many thousands of users.
>>
>> I am certain there are many other themes that are in the same category -
>> originally approved long ago, but containing features or other aspects that
>> would not meet the current theme standards. In my case, the theme contains
>> very minimal SEO support, as well as a number of shortcodes to support the
>> presentation of content in various ways. At the time my theme was
>> developed, it was not uncommon for themes to have integrated shortcodes.
>>
>> Now, I think I am being asked to remove the shortcode/SEO support, and I
>> think it was by Chip.
>>
>> "Pushing this version live. Please look to remove Plugin territory
>> features
>> (SEO, post-content shortcodes, etc. as applicable) in the next revision."
>>
>>
>> This seems to me a radical change in how existing themes have been
>> treated, and is extremely disturbing. While I understand and even agree
>> with the new "plugin" territory guidelines, I am quite taken aback at the
>> consequences of such a new requirement on what I had understood to be a
>> grandfathered theme.
>>
>> Here are the issues:
>>
>> 1. It is important to keep up with new WP features (e.g., 3.6 post
>> types), fix bugs, and even add new features to keep the theme up to date
>> and modern.
>>
>> 2. It is essential to keep these grandfather themes backward compatible.
>> Imagine the total disaster it would be for the user base (and it just as
>> important to a small user base or a user base in the thousands or more) if
>> they update their site's theme only to have the site totally break because
>> all the plugin territory features of the theme had been removed?
>>
>> 3. The alternative is to allow the existing theme to become static and
>> out of date. Not reasonable, either.
>>
>> I just don't understand how it is reasonable, fair, or even good for the
>> reputation of WordPress to force thousands and thousands of end users to
>> suffer a radical disturbance to their site, or go through some conversion
>> process to keep their site from breaking. (And yes, I know it is that exact
>> issue that removing all plugin territory stuff from a theme prevents - but
>> that was not a requirement or even a recommendation 2 years ago.)
>>
>> So, if it is going to be the new official policy to force previously
>> grandfathered themes to undergo possibly radical surgery to meet current
>> guidelines, then this needs to be done is a more formal and well planned
>> out way. Time frames for conversion. Possible exceptions to some rules to
>> ease transition (e.g., allowing auto load and inclusion of a theme
>> accessory plugin at least for a significant transition period).
>>
>> But personally, I just can't see how one can reasonably avoid
>> grandfathering themes. Certainly there are some standards that don't really
>> affect how a theme works that could be required to be updated (e.g.,
>> security issues), but there are also many (and plugin territory is
>> certainly an obvious example) that would create major theme breakage for
>> the end user.
>>
>> But whatever, being told to totally change a theme's operation before
>> being allowed to submit a new revision is not the way to handle
>> grandfathered themes.
>>
>> Bruce Wampler
>> Weaver II theme
>>
>> _______________________________________________
>> 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/20130625/324b7ef9/attachment.html>