<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>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. </DIV>
<DIV> </DIV>
<DIV>This was your response back then:</DIV>
<DIV> </DIV>
<DIV><A
title=http://lists.wordpress.org/pipermail/theme-reviewers/2011-June/006081.html
href="http://lists.wordpress.org/pipermail/theme-reviewers/2011-June/006081.html">http://lists.wordpress.org/pipermail/theme-reviewers/2011-June/006081.html</A></DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>my 2cents.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>To summarize:</DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none"></DIV>
<DIV style="FONT: 10pt tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=chip@chipbennett.net
href="mailto:chip@chipbennett.net">Chip Bennett</A> </DIV>
<DIV><B>Sent:</B> Tuesday, June 25, 2013 10:43 AM</DIV>
<DIV><B>To:</B> <A title=theme-reviewers@lists.wordpress.org
href="mailto:theme-reviewers@lists.wordpress.org">[theme-reviewers]</A> </DIV>
<DIV><B>Subject:</B> Re: [theme-reviewers] Grandfather Themes?</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<P dir=ltr>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.</P>
<DIV class=gmail_quote>On Jun 25, 2013 12:16 PM, "Bruce Wampler" <<A
href="mailto:weavertheme@gmail.com">weavertheme@gmail.com</A>> wrote:<BR
type="attribution">
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV dir=ltr>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>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.<BR><BR></DIV>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.<BR><BR></DIV>Now, I think I am being asked to remove the
shortcode/SEO support, and I think it was by Chip.<BR><BR>"Pushing this
version live. Please look to remove Plugin territory features<BR>(SEO,
post-content shortcodes, etc. as applicable) in the next
revision."<BR><BR><BR></DIV>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.<BR><BR></DIV>Here are the issues:<BR><BR></DIV>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.<BR><BR></DIV>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?
<BR><BR></DIV>
<DIV>3. The alternative is to allow the existing theme to become static and
out of date. Not reasonable, either.<BR></DIV>
<DIV> </DIV>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.)<BR><BR></DIV>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).<BR><BR></DIV>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.<BR><BR></DIV>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.<BR><BR></DIV>Bruce Wampler<BR></DIV>Weaver II
theme<BR></DIV><BR>_______________________________________________<BR>theme-reviewers
mailing list<BR><A
href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</A><BR><A
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target=_blank>http://lists.wordpress.org/mailman/listinfo/theme-reviewers</A><BR><BR></BLOCKQUOTE></DIV>
<P>
<HR>
_______________________________________________<BR>theme-reviewers mailing
list<BR>theme-reviewers@lists.wordpress.org<BR>http://lists.wordpress.org/mailman/listinfo/theme-reviewers<BR></DIV></DIV></DIV></BODY></HTML>