<blockquote style="margin: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(153, 153, 153);" class="gmail_quote"><i>If these are the only two options, then I stand by my assertion that <br>
adding an ob_cache layer on top of the core Hooks API is unnecessary, <br>because both of these options already have means within core <br>functionality to be undone...<br></i></blockquote><br>If that were the whole story, then I would agree with you, but you left <br>
out some important details that can't be overlooked. <br><br>Your assumption is that all functions that hook into wp_head are simple <br>echo statements, which isn't always the case. For example, I might have <br>
a plugin that manipulates several elements in the <head>, builds them <br>into a multi-line string, and echos it. A real example might be an SEO <br>plugin that processes some Post-specific data, builds meta tags for the <br>
description and keywords, and echoes them as a string. Now suppose the <br>site's Admin likes the description meta tag, but wants to remove the <br>keywords tag. In this case, simply unhooking the plugin's function is <br>
not an adequate solution, because it would also remove the portion the <br>Admin wants to keep. <br><br>Similarly, the WordPress core itself hooks complex functions into <br>wp_head that do not provide enough granularity to accommodate certain <br>
needs. The example that comes to mind is the localization script <br>(l10n.js) that appeared in my <head> sections after I upgraded my sites <br>to WP 3.1 (or it could have been 3.0--I don't remember exactly). From a <br>
site-owner's perspective, I don't know what this newfangled localization <br>mumbo jumbo is supposed to accomplish, but I do know that (1) it slows <br>down my page loads, and (2) my site worked just fine without it. <br>
<br>Naturally, I'd like to remove it. Unfortunately, WP core doesn't have a <br>convenient function dedicated to the inclusion of this script tag, so <br>the task of removing it is prohibitively-burdensome to all but the most <br>
dedicated/knowledgeable of Admins. My theme provides a simple mechanism <br>that allows non-programmers to achieve their desired results with <br>minimal effort and less complexity (i.e., fewer opportunities to create <br>
new bugs or errors). <br><br><b>To summarize:</b> WP APIs allow authors to unhook whole functions, but this <br>is inadequate for cases where the author wants to edit <i>only a portion</i> of <br>a function's output. <br>
<br><br><br><blockquote style="margin: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(153, 153, 153);" class="gmail_quote"><i>Themes and Plugins hosted by WordPress.org absolutely should not be <br>
promoting, encouraging, or facilitating users to be using outdated, <br>insecure versions of WordPress. <br></i></blockquote><br>I agree with that statement, but that statement doesn't rebut anything <br>I've said. In other words, you have provided a counterargument to your <br>
own (skewed) interpretation of my argument. (see <a href="http://en.wikipedia.org/wiki/Strawman">straw man</a>) <br><br><br><br><blockquote style="margin: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(153, 153, 153);" class="gmail_quote">
<i>Just FYI: the decision point regarding dropping WordPress official <br>support for PHP4 was 10%. It appears the IE6 support has been handled in <br>much the same way. So, officially not supporting the 9.4% of WordPress <br>
users who are using 2.7 and older versions of WordPress is, IMHO, <br>entirely reasonable. <br></i></blockquote><br>I'm grateful for that information, however, it isn't directly relevant <br>to our current discussion. You are convoluding the definitions of <br>
"support" and "decision point" to suit your argument.<br><br>If I pin the definition of "decision point" to "the acceptable <br>percentage of WordPress sites that would be adversely affected by our <br>
decision to change X," then I could cite the following information, <br>which suggests that your 10% figure is inaccurate: <br><br><div style="margin-left: 40px;">According to <a href="http://wordpress.org/news/2011/06/wordpress-3-1-4/">this announcement</a>, WordPress 3.2 bumped the minimum <br>
requirements to PHP 5.2.4 and MySQL 5.0. <br></div><br><div style="margin-left: 40px;">According to <a href="http://wordpress.org/about/stats/">WP stats</a>, the percentage of sites that fail to meet the PHP <br>minimum requirement is approximately <b>7.2%</b> <br>
</div><br><div style="margin-left: 40px;">According to <a href="http://wordpress.org/about/stats/">WP stats</a>, the percentage of sites that fail to meet the <br>MySQL minimum requirement is approximately <b>2.9% </b><br>
</div><br>Also, note this part of the announcement: <br><br><blockquote style="margin: 0pt 0pt 0pt 6.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(153, 153, 153);" class="gmail_quote"><i>So we’re also announcing the third release candidate for 3.2, which <br>
contains all of the fixes in 3.1.4; few minor RTL, JavaScript, and user <br>interface fixes; <span style="color: rgb(102, 102, 102); background-color: rgb(255, 255, 153);">and ensures graceful failures if 3.2 is run on PHP4</span>. <br>
</i></blockquote><br><br><br><br><br><div class="gmail_quote">On Sat, Jul 2, 2011 at 8:08 PM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net">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;">
Somehow, we seem to be on completely different pages, and I am unsure why.<div><br></div><div>Let's start with Plugins adding content to the HTML document head. As far as I understand, a Plugin has two primary options for injecting such content:</div>
<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>1) Using <b>wp_enqueue_style()</b> or <b>wp_enqueue_script()</b></div><div><br></div><div>2) Using <b>add_action( 'wp_head', 'some_custom_function' )</b>, where <b>some_custom_function()</b> prints a fully formed script or style tag, or whatever other content.</div>
</blockquote><div><br></div><div>If these are the only two options, then I stand by my assertion that adding an ob_cache layer on top of the core Hooks API is unnecessary, because <i>both of these options already have means within core functionality to be undone</i>:</div>
<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>1) Anything hooked in using <b>wp_enqueue_style()</b> or <b>wp_enqueue_script()</b> can be undone by calling <b><font color="#ff0000">wp_dequeue_style()</font></b> and <b><font color="#ff0000">wp_dequeue_script()</font></b>, respectively.</div>
<div><br></div><div>2) Anything hooked in using <b>add_action( 'wp_head', 'some_custom_function' )</b> can be undone by calling <b><font color="#ff0000">remove_action( 'wp_head', 'some_custom_function' )</font></b></div>
</blockquote><div><br></div><div>Am I missing any options? Are there any other ways for Plugins to inject content into the HTML document head? </div><div><br><div class="gmail_quote"><div class="im">On Sat, Jul 2, 2011 at 7:30 PM, Darren Slatten <span dir="ltr"><<a href="mailto:darrenslatten@gmail.com" target="_blank">darrenslatten@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div>According to the <a href="http://wordpress.org/about/stats/" target="_blank">WP stats</a>, the number of sites using WordPress versions <br>2.7 and older represents 9.4% of all WordPress users. You're saying that <br>
any plugin that attempts to maintain backwards compatibility with those <br>(millions of) sites by hooking a jQuery reference directly to wp_head <br>(instead of using wp_enqueue_script) should be banned from the plugin <br>
directory?</blockquote><div><br></div></div><div>Again here speaking based solely my opinion only: I agree with Otto. Themes and Plugins hosted by WordPress.org absolutely should not be promoting, encouraging, or facilitating users to be using outdated, insecure versions of WordPress. </div>
<div><br></div><div>Just FYI: the decision point regarding dropping WordPress official support for PHP4 was <b>10%</b>. It appears the IE6 support has been handled in much the same way. So, officially not supporting the 9.4% of WordPress users who are using 2.7 and older versions of WordPress is, IMHO, entirely reasonable.</div>
<div><br></div><div>How such repository-hosted Plugins get handled, I leave to others. But I would agree with a decision to suspend them.</div><div><br></div><font color="#888888"><div>Chip</div></font></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>