On 3 July 2011 14:27, Darren Slatten <span dir="ltr"><<a href="mailto:darrenslatten@gmail.com">darrenslatten@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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/" target="_blank">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/" target="_blank">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/" target="_blank">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></blockquote><div><br></div><div>A substantial number of those running PHP4 have the ability to change to PHP5.2 in their hosting control panel, Those on PHP 5.1 are the ones that will most likely be affected, as they're using hosts which probably use the original php incuded with the distribution (many redhat/centos servers default to php 5.1). </div>
<div>The graceful failures mean's that they get a message about requiring PHP5 rather than getting a fatal error which they got in previous RC's.<br></div><div><br></div><div>Not only that, but IIRC, the number of installs which were running on incompatible versions of PHP correlated with those running older WordPress releases, so the number of users to be impacted is also significantly lower, those running WP 2.8 and lower are highly unlikely to upgrade to 3.2, most of those installs are installs which are left to rot, or do their job. (Themes shouldn't try to support these users either, they're running old versions for a reason, because they don't change their environment, they use the same theme they did on day 1)</div>
<div><br></div><div>Just to throw a few cents in here on the topic being discussed though:</div><div>Themes should never use ob_* functions. The header case mentioned here included, it should be relegated to a plugin which wants to offer it if it's absolutely necessary. The plugin would simply hook in at priority 1, and start buffering, and hook in at priority 1000 or similar, and stop buffering there, do it's thing, and output; Those who "need" it, can have it, and those that don't, don't need to worry about performance issues or the possibility to use it wrong, and the theme remains as clean (as it should)</div>
<div><br></div><div>Themes shouldn't try to correct plugins, Themes should display what WordPress tells it to, and style it according to the users & plugins wishes, If you see a plugin doing something stupid, stop using the plugin or get it fixed, putting some wallpaper over the hole in the wall hides it from view, but doesnt fix the actual problem.. Filtering the head output is similar, you're just getting it out of the way, rather than fixing it.. not only this, but non-professionals will do it knowing no better, and left wondering why the wall broke so easily again when they'd "fixed" it.</div>
<div><br></div>