<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think we really losing track of two important things here. The first is the reason for the guidelines. The WordPress repository is the business card of WordPress. And as such, a consistent quality is of utmost importance. Whether developers agree or not, it is. <div><br></div><div>The second one is more important, because y'all talk about them, but I see only one real life user -me- participating in the discussion. AND THE USERS ARE THE BIGGEST PART OF THE WORDPRESS COMMUNITY!!!!!!!</div><div><br></div><div>There are things important to users, backward compatibility, or actually it is forward compatibility, is one of the most important ones. As a user I actually care if I can switch themes, if I can rely on the quality of themes (and plugins, but that is an aside) and if I can rely on the fact that there will be support for themes I use in the future. </div><div>Just read that sentence again, and and again, and then ponder on the implications.</div><div><br></div><div>It boils down to a couple of things. The first. If themes that are currently available in the WP repository use things that in the past years have moved into the realm of plugins, I would most certainly not like it if that was suddenly stopped. It would break my sites, and the sites I administer. Losing data would be out of the question, as would losing the ability to display the data, as I have done in the past. And there are ways to educate us users, about incompatibilities and such. Plugins that do that, nag me to death in the admin screens, about steps I need to take to retrieve the lost functionality. I see no reason themes couldn't do that.</div><div><br></div><div>The second, user experience should be paramount. Not the ideas of developers, not the ideas of review teams, the user experience should be the number one concern, for developers and all involved. Themes that use their own, say private, functionality, outside the main functionality of displaying, seriously decrease the satisfaction of the users. It locks us in, into the theme. And, as a matter of fact, it has been one of the main reasons in businesses I work with, in the past not to use WordPress, because of the intertwining of themes and functionality. (Yes I am a user, so yes I am allowed to be irrational, as this statement seems to contradict the first one I made about us users).</div><div><br></div><div>Now, there is however a solution to the dilemma the developers face. And it is built in into WordPress. I can see the urge, and the conviction and dedication that goes into developing themes, it is the way great themes are born. But why don't we try to get to a solution, one that might not be perfect, but can be pragmatical, and actually can be done within the guidelines -which actually should be guidelines, not law carved into stone- but asks a little more fantasy from developers as well as reviewers, and still keeps the users satisfied.</div><div>What would be, the conceptual problem, with layering themes. I mean the following:</div><div><br></div><div>Suppose you have theme with 'propriety' functionality, that defines shortcodes for instance, and thereby falls short of approval by the review team. My solution would be, build the theme without the offending functionality, but deliver it with a child theme, that actually incorporates the functionality. From my point of view, as a user remember, it would be ideal. You give me the choice, use the theme with, or without the functionality. You force me to make an informed decision, . A click on a checkbox is not really informed decision making. The main theme still falls within the guidelines, they actually force you to make themes that support child themes anyway. So turn it around and use the requirement.</div><div><br></div><div>Now I realize, it puts an extra burden on the developer, but realize that developers -without intent I am sure- now put that burden on the user and the review team. But if you are a disciplined developer, you built it modular already, right? </div><div><br></div><div>Ironically, the idea of vendor lock in, is one argument I often use for open standards and open source, but in the mean time, open source developers are creating vendor lock in themselves. </div><div><br></div><div>I inflated my prices by the way, it my is my 2 euro's worth by now.<br><div>
Sincerely,<div><br></div><div>Jasper Kips<br><br></div>
</div>
<br><div><div>Op 27 jun. 2013, om 00:18 heeft Srikanth Koneru <<a href="mailto:tskk79@gmail.com">tskk79@gmail.com</a>> het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>A new tag perhaps for all these "incompatible under new rules" themes like "Advanced" or "use at own risk" or similar name? <br><br></div>Put all these themes in that tag, exclude them from tag filter searches, Recently updated, new themes, popular lists on <a href="http://wordpress.org/themes/">wordpress.org/themes/</a> ( so only experienced users and current users can find them )<br>
Themes under this tag to have a big bold disclosure saying they are meant only for experienced users and maybe be locked in or will have trouble migrating etc.<br><br>That way their current user base who are happily using the existing functionality can keep getting updates and no new user of WordPress will be inconvenienced when they switch from these advanced themes and loose all their data. If any new theme wants to add plugin functions, they can add this new tag and they can be used by experienced users. <br>
<br></div><div>Support responsibility for these themes to be on the theme authors and they should actively provide support, so current support warriors won't be burdened?<br></div><div><br></div><div>We can have the best of both worlds this way, Directory can host advanced themes too and new users won't complain WordPress is hard to use.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 27, 2013 at 3:26 AM, Philip M. Hofer (Frumph) <span dir="ltr"><<a href="mailto:philip@frumph.net" target="_blank">philip@frumph.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks! .. sadly no, it's not that simple; there are still roughly 25k'ish users out there (that can be counted with services like Comic Rocket+backlinks+etc) that still haven't migrated to Comic Easel - which only counts to a modest (/grin) 150ish sites using it right now.<br>
<br>
It's rather unfortunate that I have to point people to the github to download the updated ComicPress that keeps it compatible with the recent releases of WordPress. - even then, I have seen some version 1.6's out there of ComicPress running wordpress 2.0 something's heh.<br>
<br>
-----Original Message----- From: Otto<br>
Sent: Wednesday, June 26, 2013 12:05 PM<div class="im HOEnZb"><br>
To: <a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
Subject: Re: [theme-reviewers] Formal Request for Change of Methodology.<br>
<br></div><div class="HOEnZb"><div class="h5">
On Wed, Jun 26, 2013 at 12:31 PM, Philip M. Hofer (Frumph)<br>
<<a href="mailto:philip@frumph.net" target="_blank">philip@frumph.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My ComicPress theme the same way, it's completely embedded with options that<br>
are specific to the code required to run it, while there's an addon<br>
available in plugin that plugin will only work for the theme. It's useless<br>
otherwise.<br>
</blockquote>
<br>
Is that still around? I thought you'd ported most users over to Comic Easel.<br>
<br>
Comic Easel is a better choice all around, I'd say. That's more of a<br>
doing-it-right approach.<br>
<br>
-Otto<br>
______________________________<u></u>_________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/<u></u>mailman/listinfo/theme-<u></u>reviewers</a> <br>
______________________________<u></u>_________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/<u></u>mailman/listinfo/theme-<u></u>reviewers</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>theme-reviewers mailing list<br><a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>http://lists.wordpress.org/mailman/listinfo/theme-reviewers<br></blockquote></div><br></div></body></html>