<div dir="ltr"><div><div><div><div><div><div><div>Chip, let me try to summarize what I think you said:<br><br></div>1. There are two kinds of non-theme-originated JavaScripts: "real" scripts, and script "widgets". Real scripts manipulate the DOM and don't usually directly generate html output (perhaps an oversimplification, but I hope that is the main point). Script Widgets generate HTML output (like a Google Search bar, a map, a music player, etc.). This is a really significant distinction, and I think the cause of all the miscommunication. In the most general case, a script is a script. In practice, a "Script Widget" is a widely available technique used to allow people to add interesting features to their sites via copy/paste, and the use case I've been pleading to keep in my theme.<br>
<br></div>2. Real scripts not part of the theme can be added only via a plugin using the wp_head and wp_footer actions.<br><br></div>3. Script Widgets can be treated just like any other HTML allowed to be injected into whatever content regions the theme supports. But I would add the unfiltered HTML capability restriction. But this is the feature used mostly by my users - an easy way to add functionality to the non-content portions of a site.<br>
<br></div>If this is the reality of the new guideline, then the migration process is significantly easier since it only affects two places. References to header.php footer.php aren't really relevant to the standard - it is the area between <head> and </head>, and wherever scripts get emitted from wp_footer().<br>
<br></div>So I think I will use the phase-out suggestion - show the relevant wp_head/wp_footer region options if set, don't let new use of them, and phase out completely to the support plugin.<br><br></div>About versions: I 100% agree that each version can contain critical upgrades, but plenty of software marketers have worked very hard over the years, and spent lots of money to drive home that a new integer version is the time to fork over the money for wonderful new features. That user expectation trickles down to all software - including WordPress. I don't think it is in our power to overcome all that marketing power.<br>
<br></div>As long as WordPress follows its current versioning practice, people will expect that going from 3.x to 4.x is a big deal. (And why is 4.0 after 3.9 anyway - why not 3.10? Because we've all been programmed to think that way.) I think that is partly why Chrome and Firefox abandoned the major integer version once a year or so approach, and we are now on Chrome 30-sometihng. I've noticed some plugins following a non-integer versioning practice as well. WP as gone from fairly infrequent tenths versions to a much more frequent update cycle. This faster update cycle warrants a reexamination of the backward compatibility of themes, I think. Right now themes can only go back two versions (e.g., 3.6 while 3.8 is out). But 3.6 was not that long ago. My theme strictly follows this guideline (because I believe in that principle) and won't load for 3.5. This has drawn complaints from my community, so perhaps this should slip back to more than 2 versions?<br>
<div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 7:17 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">In an important aspect: yes, we're talking apples and oranges. For instance:<br></div>_______________________________________________<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></div></div></div></div>