<div class="gmail_quote">On Tue, May 24, 2011 at 4:55 PM, Ryan Frankel <span dir="ltr"><<a href="mailto:ryan.frankel@gmail.com">ryan.frankel@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
--<br>
I don't disagree with any of your points of view and appreciate the input. We have quite a few of these 'application' type WordPress themes that are GPL in development so it is a bit disheartening that they can't be included in the General Repo. Maybe one day there will be an 'Application Repo' that clearly states they use Custom Post types and are not Regular blog, magazine, news, portfolio, etc, etc (sweet WordPress), themes. In my view, sites like Trac, FogBugz, Bugzilla etc wouldn't be a plugin as much as the Core of the site. There is no other content but the tickets.<br>
<br>
I see what you are saying about data lock-in. Even with a plugin and a custom post type the data would be locked into that post type. As I think about it, if you add any Custom Taxonomy you have already automatically locked-in that data too. It seems to me that creating a plugin that adds this functionality doesn't really solve the problem with the data being 'stuck' except that a user can switch their theme. They would still be stuck to our plugin so it just pushes the problem deeper down.<br>
</blockquote><div><br></div><div>Note that - at least as far as *I'm* concerned - there is nothing inherently wrong with "locking in" data to a specific Theme or Plugin. To place such a restriction on Themes/Plugins would be to deprive them of the huge potential of the extensibility of WordPress. The vast majority of the most interesting and innovative uses of WordPress require such lock-in, based solely on the development philosophy of WordPress (light core, infinitely extensible).</div>
<div><br></div><div>The primary issue here is the appropriateness of hosting such Themes in the Repository. Especially given its tight integration with the WordPress admin backend, the Repository must consider end user experience as paramount. For better or for worse, users generally expect a relatively seamless transition when switching from one Theme to another Theme in the Repository. Otto has explained well the infrastructure issues with the Repository that are the primary limiting factor for such "niche" Themes as yours.</div>
<div><br></div><div>Again speaking for myself: once the Repository is able to handle such Themes well, I don't think the Theme Review Team will in any way whatsoever want to stand in the way of approving such Themes.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hopefully, I haven't wasted to much of your and everyone else's time on here.<br></blockquote><div><br></div><div>To the contrary; such discussions are exactly why this mail list exists.</div><div><br></div><div>
Chip</div></div>