[theme-reviewers] Grandfather Themes?

Philip M. Hofer (Frumph) philip at frumph.net
Tue Jun 25 18:26:12 UTC 2013


Did Nacin or Otto write someplace that shortcode’s were bad to use in a theme?





From: Chip Bennett 
Sent: Tuesday, June 25, 2013 11:20 AM
To: [theme-reviewers] 
Subject: Re: [theme-reviewers] Grandfather Themes?

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 
  Sent: Tuesday, June 25, 2013 10:43 AM
  To: [theme-reviewers] 
  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




--------------------------------------------------------------------------------
_______________________________________________
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/13e7427a/attachment-0001.html>


More information about the theme-reviewers mailing list