[theme-reviewers] Question about ob_start and ob_get_clean (Vicky Arulsingam)

[Dion Hulse (dd32)]

On 3 July 2011 14:27, Darren Slatten <darrenslatten at gmail.com> wrote:
>
>
> If I pin the definition of "decision point" to "the acceptable
> percentage of WordPress sites that would be adversely affected by our
> decision to change X," then I could cite the following information,
> which suggests that your 10% figure is inaccurate:
>
> According to this announcement<http://wordpress.org/news/2011/06/wordpress-3-1-4/>,
> WordPress 3.2 bumped the minimum
> requirements to PHP 5.2.4 and MySQL 5.0.
>
> According to WP stats <http://wordpress.org/about/stats/>, the percentage
> of sites that fail to meet the PHP
> minimum requirement is approximately *7.2%*
>
> According to WP stats <http://wordpress.org/about/stats/>, the percentage
> of sites that fail to meet the
> MySQL minimum requirement is approximately *2.9% *
>
> Also, note this part of the announcement:
>
> *So we’re also announcing the third release candidate for 3.2, which
>> contains all of the fixes in 3.1.4; few minor RTL, JavaScript, and user
>> interface fixes; and ensures graceful failures if 3.2 is run on PHP4.
>> *
>
>
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).
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.

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)

Just to throw a few cents in here on the topic being discussed though:
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)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110703/3eb15d7c/attachment-0001.htm>