<div dir="ltr"><div>To reiterate regarding the Options Framework: it's perfectly fine to use. Themes should use the library version, that is bootstrapped with the Theme, instead of the stand-alone Plugin version - because Themes must not rely upon Plugins for their basic functionality (and Theme options, when included in the Theme, do constitute "basic functionality").<br>
</div><div><br></div><div>On the question of bundling Plugins with Themes, there are several concerns:<div><br></div><div>First: what does "bundling" mean? Is it merely packaging the Plugin with the Theme, or is it integrating the Plugin wholesale into the Theme? </div>
<div><br></div><div>If the Plugin is merely being packaged with the Theme, the Plugin still stands alone as a Plugin, and would ostensibly get installed as a Plugin, separately from the Theme. But that introduces other issues: one, it is poor user experience - asking the user to FTP into the server, move files from the Theme's install directory to the Plugins directory, instead of merely recommending the Plugin(s) be installed, or providing a script to install them (such as the TGM script); and two, it forces the Theme Review Team to vet Plugin code. We are not Plugin reviewers; we are Theme reviewers. There is a separate review team that reviews and approves Plugins, using separate review/approval criteria.</div>
<div><br></div><div>If the Plugin is integrated wholesale into the Theme, then it must first ensure that it checks/accounts for the Plugin itself being installed as a Plugin by the end user. And whatever the purpose/functionality of the integrated Plugin, its integration into the Theme represents "lock-in", in that non-Theme functionality is tied to the Theme itself. And when the obvious/easiest solution is for the user to install the Plugin separately in order to retain that functionality, then the logical and appropriate philosophy is to keep the Plugin separate from the Theme from the outset.</div>
<div><br></div><div>(Let's be straight here: Themes are getting complex enough as it is - and that complexity is severely increasing the learning curve for new Theme Reviewers. Do we REALLY want to exacerbate that complexity - and the ensuing barrier-to-entry for Theme Reviewers - by allowing any arbitrary Plugin code in Themes? That will just further bog down the system we're trying to keep running as smoothly as possible.)</div>
<div><br></div><div>That presentation-vs-functionality philosophy is also consistent with the current guideline: "<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:22px"><i>Since the purpose of Themes is to define the presentation of user content, Themes must not be used to define the generation of user content, or to define Theme-independent site options or functionality.</i></span>"</div>
<div><br class="">Inherent in that guideline is the basic principle that it is the role and sole propriety of *Plugins* to extend/enhance core WordPress functionality. The role of Themes is to present user content, period. When Themes extend/enhance core WordPress functionality, that extension/enhancement should be limited to the presentation layer.<br>
</div><div><br></div><div>From a user perspective, this is not a restrictive guideline; rather, it is exactly the opposite - it is a guideline that preserves user freedoms to the greatest extent, because it ensures that users can change their Theme with the absolute-minimum impact on their content and on their site functionality. (And keep in mind: we're talking about functionality that is added via a separate Plugin, that we are discussing being bundled with the Theme. The functionality was never part of the Theme to begin with.)</div>
<div><br></div><div>So yes: I'm very much saying that the correct approach is, "thanks but no thanks" to enhancing/extending non-presentational core functionality via Themes. Theme developers can just as easily package core-functionality innovations as Plugins, and release them in the Plugin directory, where they belong. (Actually, given the differences in workflow between the Plugin and Theme directories, they can do so even *more* easily as Plugins than as part of a Theme.) </div>
</div><div><br></div><div>The drag-and-drop featured image functionality is a perfect example. It has zero impact on how the featured image is displayed on the front end, and the user would reasonably want (or not want) to have that functionality regardless of what Theme is active. That's a pretty clear-cut decision regarding whether it belongs in a Theme or Plugin.</div>
<div><br></div><div>There are no "jackboots" here, and we never take that approach with the application of any of the Guidelines. A hard line at the philosophical/ideological level? Absolutely. But we have always taken the approach that application/implementation can vary, and that we can and do consider exceptions to every rule.</div>
<div><br></div><div>There are several considerations:</div><div><br></div><div>1) The appropriateness of bundling Plugins with Themes</div><div>2) The appropriateness of LESS CSS functionality in a Theme</div><div>3) The appropriateness of Options Framework functionality in a Theme</div>
<div>4) The appropriateness of drag-and-drop featured-image selection functionality in a Theme</div><div><br></div><div>Every one of those considerations has a different answer.</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Sat, Jan 4, 2014 at 1:22 PM, Melissa Oveson <span dir="ltr"><<a href="mailto:missybunnie@gmail.com" target="_blank">missybunnie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div><span></span></div><div><div><span></span></div><div><div>I have to admit that as a strong believer in keeping plugins and themes separate I actually see no problem with these plugins being in the theme. The biggest reason to separate is to make it so that when a user switches themes they lose nothing. The options framework I believe is perfectly acceptable. It is designed to help theme developers create option pages. The less to CSS I think is very appropriate as it helps with editing the stylesheet. The drag and drop I think is possibly up for debate. </div>
<div>However I think in the debate on where it stands is adhering to the spirit of the rule which is the idea that the user can change themes without losing data or tracking (ie favicons, analytics coverage, entire posts made with custom post types). If plugin data doesn't cause the user to lose anything when changing themes including admin options not under the theme options pages, then it is something in the grey area of the rule and could possibly be considered into the repository with those functions. Just my opinion though.</div>
<div><div class="h5"><div><br>On Jan 4, 2014, at 10:49 AM, emin ozlem <<a href="mailto:eminozlem@gmail.com" target="_blank">eminozlem@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>
I'm not a member of the review team, but to express my opinion as a user and a theme dev; I agree the extent of plugin territory is too restrictive. But from what i see here this in particular is not a case of plugin territory but a different one. It's not about "providing functionality that falls into plugin territory" but about if we can "ship plugins bundled with theme". And I would really like a yes or no answer on this one.<br>
</div><br>Because there are certain functionalities that i would too like to provide with my theme that definitely fall into plugin territory (favoriting, sharing posts etc.) So are we allowed to ship plugins with themes, just like we do with widgets ?<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/4 Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The point is, I'm not really a fan of drawing that line ... if there is a black and white definition of what, without consideration, makes for "plugin territory" then let's have it posted. Then we can all put our jackboots on and kick anything and everything that even toes that lines to the curb. No appealing it, no discussing it ... those are the rules deal with it.<div>
<br></div><div>Just in case its not clear, I am very much against that ideology as I think we are taking it too far. In this particular case, the additional code (it's really not important that it already exists as a plugin) offers a "cool" feature via the theme that provides an end-user a reason to support that theme. Sure the code could be completely left out and the theme would provide the bare necessities of presentation output but I think it is much more important to keep the possibilities open if there is zero change impact involved with the code.</div>
<div><br></div><div>Basically you're saying, sorry theme authors, you are not allowed to enhance core functionality ... no matter what you might offer, or how good the idea is ... only plugin authors are allowed to do that, in a plugin only. Thanks but no thanks we don't want to see your innovation or creativity implemented with a theme, except of course if it is presentation related only.</div>
<div><br></div><div>There are certain kinds of functionality I do agree should best be implemented as a plugin, but not every functionality should be relegated to plugin territory ... otherwise, lets just point all the theme authors to a cookie cutter code template and Zen Garden for inspiration.</div>
<div><br></div><div>Like I wrote, I'm not here to argue the point ... I'm just expressing my opinions on the matter. Others can agree or disagree with these ideas and carry on with the discussion as a community to reach a common goal of improvement.</div>
<span><font color="#888888">
</font></span></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div>Edward Caissie<br>aka Cais.</div></font></span><div><div>
<br><br><div class="gmail_quote">On Sat, Jan 4, 2014 at 12:02 AM, 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 dir="ltr">But it's a valid discussion: where would you draw the line, if not at something that has zero front-end impact? What other back-end/site functionality would be permissible in Themes, merely because it doesn't present "lock-in"?</div>
<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 11:54 PM, 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"><div dir="ltr">I'm not going to argue the point ... I gave my opinion (even as an admin) and I still stand behind my initial thoughts on this.</div>
<div class="gmail_extra"><span><font color="#888888"><br clear="all"><div>Edward Caissie<br>aka Cais.</div></font></span><div><div>
<br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 11:43 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 dir="ltr">The presentation-vs-functionality line is not limited to "lock in". The feature has absolutely nothing to do with presentation of user content (in fact, the Plugin has zero front-end impact at all - something that should be a considerable red flag regarding its appropriateness within a Theme), and is something that, should the user decide to use for the site, would be expected to remain when switching Themes. </div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Jan 3, 2014 at 10:41 PM, Edward Caissie <span dir="ltr"><<a href="mailto:edward.caissie@gmail.com" target="_blank">edward.caissie@gmail.com</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 dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 6:58 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">Drag-and-drop featured image is clearly site (admin) functionality ... </blockquote></div><br>Although this may be true; and, it really does not affect the "visual" aspect of the theme in the sense there already exists a core functionality that can be used, but since there is no lock-in effect (one of the primary reasons code is pushed into "plugin territory") I see no problem with this as a theme "feature". If @Ulrich had not brought forward / recognized the existing plugin's code I would not have looked twice at allowing it through based on it enhancing the core functionality.</div>
<span><font color="#888888">
<div class="gmail_extra"><br><br clear="all"><div>Edward Caissie<br>aka Cais.</div>
</div></font></span></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>
<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></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></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>theme-reviewers mailing list</span><br><span><a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.wordpress.org</a></span><br>
<span><a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a></span><br></div></blockquote></div></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>