I'd really like to move past the "blogging"/"non-blogging" consideration as relevant to the discussion of special-use Themes. I think the impasse between our opinions is that you appear to place far more importance/relevance on "blogging" functionality than I do. Again: the codebase is 99% the same between a given Theme with and without blogging functionality. It is a trivial difference.<div>
<br></div><div>Regarding my my assertion that the primary difference between a "personal blogging" Theme and a "business" Theme is front-end design rather than underlying code/functionality: pretty much any "personal blogging" Theme can, with only changing the CSS, be transformed into a "business" Theme (and vice versa). What functional/code changes to the Theme do you envision as contradictory to that assertion?</div>
<div><br></div><div>Chip<div><br><div class="gmail_quote">On Sat, Oct 29, 2011 at 2:00 PM, Kirk Wight <span dir="ltr"><<a href="mailto:kwight@kwight.ca">kwight@kwight.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Can this be done by parsing the tags listed in style.css? To me, they would serve double-duty: identifying features/elements of themes in the repo, and providing a context to Theme Check and the uploader of what to test for. For example, the current Theme Check and uploader rules would be the equivalent of the "blog" context, to be used against submitted themes with the "blog" tag. (I couldn't resist.)<div>
<br></div><div>I disagree with Chip that it's design that differentiates types of themes - I think it's the developer's intended audience and functionality that differentiate, stated by the developer in the theme tags (ratings and downloads will decide how successful they are at it). The fact that so many of them have similar designs is a result of, not because of, their differentiation. To me, using front-end design to determine what constitutes certain types of themes is just constraining designers, and will start to fail as popular design continues to evolve and change.</div>
<div><br></div><div>Either way, improving the Tag Filer system as Chip suggested above would be a great help to users, especially as we start to accept more themes beyond the traditional format (could the current Subject column just be turned in to a Category column?).</div>
<div><div></div><div class="h5">
<div><br></div><div> <div><div class="gmail_quote">On 29 October 2011 13:49, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems we are closing in on a potentially easy flag method ... much like setting custom template name in the page template header block, could we be looking at adding something to `front-page.php` that can be parsed and then recognize the theme as a niche-Theme? This can be done solely in the upload check / Theme-Check to start and further implemented into the WordPress Administration Panels / WordPress.org as it gains momentum.<br>
<br>It's just another idea to add to the list, but follows from Chip's point: "... because what differentiates a "business" Theme from a "personal" or
"blogging" Theme is not the presence or absence of blog-post
functionality support, but rather the *front-end design* of the Theme."<br><br><br clear="all">Cais.<div><div></div><div><br>
<br><br><div class="gmail_quote">On Sat, Oct 29, 2011 at 1:11 PM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Not sure I agree with this:</div><div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>I guess my point is that by considering accepting "niche" themes, we are, in effect, considering accepting themes that do not support the blog use-case (Launch Effect doesn't even have a loop, let alone paginate_links).</div>
</blockquote><div><br></div></div><div>Maybe, and maybe not. A "landing page" is just ONE potential "niche" use case. What about the support-ticket system Theme? It could conceivably still have/use blog posts. And that doesn't even get into the myriad ideas I'm sure that clever Theme developers will come up with.</div>
<div><br></div>But here's the thing:<div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>I think a lot of WordPress users and developers out there now just don't see a blog as a requisite part of a WordPress site. I think it would be great if a user could go to the repo, look at the tags and say, "hm, I don't need a blog, I'll just go with this GenericSimpleBiz theme", and get a theme that doesn't have unnecessary code.</div>
</blockquote><div><br></div></div><div>The amount of code that differentiates static-Page output from blog-post output is <i>trivial</i>. Off the top of my head, I'd say that 99% of the codebase is identical. Not using a blog isn't a separate *use case*, it's merely a *setting change*. There is really nothing special or "niche" about using a given WordPress Theme to display only static Pages versus using that Theme to display blog posts.</div>
<div><br></div><div>While I see great benefit in eradicating the blogging-vs-CMS thinking regarding WordPress, I see no benefit to end users in hosting Themes in the repository for which the only extraordinary "feature" is that they don't support blog post output.</div>
<div><br></div><div>What might be far more beneficial would be to improve the Tag Filter system, and allow tags for "Blogging", "Personal", "Business", etc. - or whatever, so that developers could indicate the target user audience for their Themes - because what differentiates a "business" Theme from a "personal" or "blogging" Theme is not the presence or absence of blog-post functionality support, but rather the *front-end design* of the Theme.</div>
<div><br></div><div><font color="#888888">Chip</font><div><div></div><div><br><br><div class="gmail_quote">On Sat, Oct 29, 2011 at 11:55 AM, Kirk Wight <span dir="ltr"><<a href="mailto:kwight@kwight.ca" target="_blank">kwight@kwight.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I guess my point is that by considering accepting "niche" themes, we are, in effect, considering accepting themes that do not support the blog use-case (Launch Effect doesn't even have a loop, let alone paginate_links). I don't consider this a bad thing at all, it's awesome - they're all WordPress themes. I'd love the theme repo to reflect that, with simple placeholder and specialty themes right beside everything else; it just has to be evident when browsing the repo (hence the Blog tag).</div>
<div><br></div><div>I think a lot of WordPress users and developers out there now just don't see a blog as a requisite part of a WordPress site. I think it would be great if a user could go to the repo, look at the tags and say, "hm, I don't need a blog, I'll just go with this GenericSimpleBiz theme", and get a theme that doesn't have unnecessary code.</div>
<div><br></div><div>Of course, I'm playing devil's advocate a bit here; I know it's not a tonne more effort or a tonne more code to support blog functionality. I also recognize that a pile more work would be required by Otto, theme reviewers and lots of other busy people to accept and evaluate this much wider scope of themes. I just really like what we're saying about WordPress: you can have any sort of website you want with WordPress, and here are some themes we stand behind that can help you do it.</div>
<div><br></div><div>And yes, I totally agree with your frustration in the use of the term "CMS"; whoever's responsible for spreading this "its-a-blog-or-a-CMS" mentality should be sent to bed without dinner.</div>
<div><div></div><div>
<br><div class="gmail_quote">On 29 October 2011 11:19, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't agree. A site that doesn't have a blog doesn't constitute a "niche"; rather, it is a use-case that is built-in to core. Using WordPress "as a CMS" (nb: I detest this phrase; WordPress IS a CMS, no matter *how* it is used - and it is almost always intended to mean "without a blog") requires nothing more than creating a static Page to serve as the Front Page, changing the "Front Page Displays" setting to "static page", assigning the appropriate static page, and then NOT assigning a posts page. Easy peasy.<div>
<br></div><div><div><span style="background-color:transparent"> </span><span style="background-color:transparent">We don't need special handling for this use-case. Every Theme in the repository should handle it without problem. </span><span style="background-color:transparent">By default, repository-hosted Themes are expected to handle this use case; that's why we have Guidelines related to display of post metadata and "no comments" type text on static pages.</span></div>
<div><br></div><div>I see no practical reason for a publicly distributed Theme NOT to account for the blog use-case. If we've not adequately covered the non-blog use case in the Guidelines, we can always revisit them.</div>
<div><br></div><div>As for the definition of "niche" Themes: they really do need to be an extraordinary use. At this point, it's probably a "know it when we see it" kind of thing. I think the "landing page" use case and the "ticket system" use case are good, instructive examples.</div>
<div><br></div><div><font color="#888888">Chip<br></font><div><br><div class="gmail_quote"><div><div></div><div>On Sat, Oct 29, 2011 at 9:42 AM, Kirk Wight <span dir="ltr"><<a href="mailto:kwight@kwight.ca" target="_blank">kwight@kwight.ca</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
<div>What distinguishes "niche" themes from "regular" themes is often one thing: only partial or no implementation of blog functionality. As far as I can tell, most of the checks from Theme Check and the uploader rely on the theme being usable as a blog.</div>
<div><br></div><div>This summer, we found out from the user survey that a lot of developers use WordPress for sites that don't even have a blog component (just a "CMS", for lack of a better term) . To me, niche themes are simply themes that, for whatever reason, choose not to implement full blog functionality.</div>
<div><br></div><div>We could add a tag filter under Features that is just "blog". If this tag exists, the uploader and Theme Check plugins check according to the current criteria. If not, a simpler context can be used (presence of readme.txt, etc). Obviously this would require rewriting the uploader and theme eval plugins to react conditionally, but it would seem simpler and more elegant to me than getting in to theme slugs, white-listing specific users, and trying to create specific tag filters for each non-standard use-case.</div>
<br></div></div><div>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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><br>
</div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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><br></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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><br>
</div></div><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">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><br></div></div>
</div></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><br></div></div>