<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_default">While I won't argue either or... Let's not drive in reverse here.</div><div class="gmail_default">
<br></div><div class="gmail_default">We already went over this on several occasions and pretty much all* authors</div><div class="gmail_default">responded in a very positive manner and moved or removed what falls into plugin-territory. </div>
<div class="gmail_default"><br></div><div class="gmail_default">Making more exceptions is fine, however the time-frame should not be measured in months</div><div class="gmail_default">at least not for the updates without required changes.</div>
<div class="gmail_default"><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 3:47 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">It appears that you're lumping WAY too much into the scope of what you're asking, and way overstating the impact of the guideline. Your issue seems to jump around from scripts hooked into wp_head/wp_footer, to markup hooked into the template, to Child Themes that use their own scripts.<div>
<br></div><div>First: how would this change impact a Child Theme? If a Child Theme enqueues a script and hooks that script into wp_head (or an appropriate sub-hook), then this guideline has no impact on it. A Theme-defined script used for presentational purposes is unaffected by this change, whether that script is used by a stand-alone Theme or by a Child Theme. The guideline only applies to *arbitrary* scripts - that is, scripts that impact site functionality and/or are Theme-independent, and are defined by the end user.</div>
<div><br></div><div>Second: the "step" from 3.8 to 3.9 is *exactly the same* as the "step" from 3.9 to 4.0. All three are MAJOR versions of WordPress. As developers, we owe it to our users to ensure that they understand the WordPress versioning system, so that we don't enable/facilitate users still to be using WordPress 3.0, because they mistakenly (and dangerously) believe that versions 3.1 through 3.9 are just "decimal" releases.</div>
<div><br></div><div>Third: this statement is absolutely false:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">...although I </span><b style="font-family:arial,sans-serif;font-size:13px">still</b><span style="font-family:arial,sans-serif;font-size:13px"> contend that the idea that this particular feature (JavaScript in the site header and footer area (not <head>, but in the header.php and footer.php) can </span><b style="font-family:arial,sans-serif;font-size:13px">not</b><span style="font-family:arial,sans-serif;font-size:13px"> be handled by an independent plugin of any sort...</span><br>
</div></blockquote></div><div><br></div><div>Plugins have equal access to the wp_head and wp_footer hooks, and can hook anything into those hooks that a Theme can hook into them.</div><div><br></div><div>Which makes this conclusion untrue:</div>
<div class="">
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px"> If it can't be handled by a general plugin (and it can't - really...), then it has to be a theme issue</span><br>
</div></blockquote></div><div><br></div></div><div>Plugins can hook into wp_head and wp_footer, just as easily as a Theme can. The only thing that a Plugin *can't* do is universally hook into template locations to output markup, because there are precious-few standard template-location hooks.</div>
<div class="">
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px"> So it isn't in the theme directly, the </span><i style="font-family:arial,sans-serif;font-size:13px">only</i><span style="font-family:arial,sans-serif;font-size:13px"> alternative is a </span><i style="font-family:arial,sans-serif;font-size:13px">theme specific </i><span style="font-family:arial,sans-serif;font-size:13px">plugin to do it, and that seems intellectually dishonest to me.</span><br>
</div></blockquote></div><div><br></div></div><div>Actually, the most user-friendly approach is for a user-defined, site-functionality Plugin for such one-off, arbitrary scripts that control site functionality independent of the active Theme. A Theme-functionality Plugin gets part of the way there, and has the benefit of helping users understand the proper segregation of functionality and presentation.</div>
<div class="">
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:arial,sans-serif;font-size:13px">Sorry to bring this up again, but Chip asked why this wasn't discussed in the make site, and it was.</span><br>
</div></blockquote></div><div><br></div></div><div>You're welcome to discuss it on the list. Please continue to do so. I was asking why Otto hasn't weighed in with such an opinion until now.</div><div class=""><div>
<br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><span style="font-family:arial,sans-serif;font-size:13px">So, I'm just asking for some kind of grandfathering so I people's sites won't break immediately.</span><br></div></blockquote></div><div><br></div>
</div><div>If you're talking about a *migration plan*, you don't have to ask. Just communicate it, in-ticket, with whomever reviews the next version of your Theme. But "grandfathering" means "exception", which is not warranted. </div>
<div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 4:32 PM, Bruce Wampler <span dir="ltr"><<a href="mailto:weavertheme@gmail.com" target="_blank">weavertheme@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"><div><div><div><div><div>Thanks, Otto, for a more rational approach to this.<br><br></div>1. I can guarantee that there will be sites broken if I have to immediately implement this requirement. There even is a popular child theme that uses the scripting features in question that will break. Lots of side-effects. There may not be that many themes with this kind of option, but disabling the feature without some kind of phase-in will give serious grief to many of my users. And this is kind of unexpected when going from say 3.8 to 3.9. I think users are more willing to put up with grief for what is traditionally a bigger step - like to 4.0. But causing serious breaks in a decimal change just encourages users to not upgrade - and that is a really bad idea!<br>
<br></div>2. I tried to argue my case on the make site, and lost that argument, although I <b>still</b> contend that the idea that this particular feature (JavaScript in the site header and footer area (not <head>, but in the header.php and footer.php) can <b>not</b> be handled by an independent plugin of any sort, and that there is a need for users to insert script in those areas (e.g., scripts from small, perhaps unknown, but important to users, to add various critical site functionality). If it can't be handled by a general plugin (and it can't - really...), then it has to be a theme issue. So it isn't in the theme directly, the <i>only</i> alternative is a <i>theme specific </i>plugin to do it, and that seems intellectually dishonest to me. I wish there were more hooks/filters to handle this, but there simply is nothing when it comes to dealing with the header area - including content surrounding the header image and menus - which are usually defined in header.php, or site copyright and credit information, found in footer.php. Sorry to bring this up again, but Chip asked why this wasn't discussed in the make site, and it was.<br>
<br></div></div>3. So, I'm just asking for some kind of grandfathering so I people's sites won't break immediately. I don't know if there ever will be a way to force people to update to a plugin properly - maybe several months of a warning on the admin panel. And the ability to work both ways for at least a while - saving the options via a plugin, or using the existing setting.<br>
<br></div>Thanks for listening...<span><font color="#888888"><br><br>Bruce</font></span><div><div><br><div><br><br><div><div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Mar 6, 2014 at 1:08 PM, 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">
<div dir="ltr">
<div dir="ltr">
<div style="font-size:12pt;font-family:'Calibri'">
<div>Make no mistake, if I were able to have updated the theme itself and fixed
bugs and kept it code compliant with core it would have been far better for the
users and myself. Along with having the plugin/comic easel as
something to migrate to when the users were ready, not being forced into
it.</div>
<div> </div>
<div>As it stands, I lost more money then I made in this last year helping
people fix their sites, regardless of how many video’s, tutorials and tools I
made to help them migrate.</div>
<div> </div>
<div>...and it still goes on and on; that and WordPress doesn’t have all
of the functionality available for common things to co-sync custom post types as
regular post types, so functionality was lost between theme and
plugin. </div>
<div> </div>
<div>Yeah, .. I was and always am in favor for the ‘anything new needs to adhere
to the requirements’ – but if it’s a theme that’s been in circulation for a
number of years; don’t force it – let it work it’s way up.</div>
<div style="font-size:small;font-style:normal;text-decoration:none;font-family:'Calibri';display:inline;font-weight:normal">
<div style="FONT:10pt tahoma">
<div><font face="Calibri" size="3"></font> </div>
<div style="BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title="otto@ottodestruct.com" href="mailto:otto@ottodestruct.com" target="_blank">Otto</a> </div>
<div><b>Sent:</b> Thursday, March 06, 2014 11:03 AM</div><div>
<div><b>To:</b> <a title="theme-reviewers@lists.wordpress.org" href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">Discussion list for WordPress
theme reviewers.</a> </div>
<div><b>Subject:</b> Re: [theme-reviewers] How to request "grandfathered"
exception to WP 3.9 Theme guidelines?</div></div></div></div>
<div> </div></div>
<div style="font-size:small;font-style:normal;text-decoration:none;font-family:'Calibri';display:inline;font-weight:normal"><div><div>
<div dir="ltr">I thought you migrated people to the plugin for that one. The
plugin route is a much better experience for your case, I think.
<div class="gmail_extra"> </div>
<div class="gmail_extra">Regardless, migration takes time. 3.9 is coming out in 6
weeks, so that's realistically not enough time for theme authors to migrate
users to a better way. 4.0 in August or 4.1 in December might be a better
timeframe to start that level of enforcement. Require authors to start building
in plugin-migration, sort of thing. Maybe provide a plugin that will handle the
case for them if necessary, and code to add to a theme that eases that
migration. </div>
<div class="gmail_extra">
<div> </div>
<div>-Otto</div><br><br>
<div class="gmail_quote">On Thu, Mar 6, 2014 at 12:49 PM, Philip M. Hofer (Frumph)
<span dir="ltr"><<a href="mailto:philip@frumph.net" target="_blank">philip@frumph.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div dir="ltr">
<div style="FONT-FAMILY:'Calibri';FONT-SIZE:12pt">
<div>^ yay otto. Little too late in my case with ComicPress, but
yay for this now.</div>
<div> </div></div></div></div></blockquote></div></div></div>
</div></div><p>
</p><hr><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>
</div><p></p></div></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></div></div></div></div></div></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">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>