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

Sun Jul 3 04:27:24 UTC 2011

>
> *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 both of these options already have means within core
> functionality to be undone...
> *

If that were the whole story, then I would agree with you, but you left
out some important details that can't be overlooked.

Your assumption is that all functions that hook into wp_head are simple
echo statements, which isn't always the case. For example, I might have
a plugin that manipulates several elements in the <head>, builds them
into a multi-line string, and echos it. A real example might be an SEO
plugin that processes some Post-specific data, builds meta tags for the
description and keywords, and echoes them as a string. Now suppose the
site's Admin likes the description meta tag, but wants to remove the
keywords tag. In this case, simply unhooking the plugin's function is
not an adequate solution, because it would also remove the portion the
Admin wants to keep.

Similarly, the WordPress core itself hooks complex functions into
wp_head that do not provide enough granularity to accommodate certain
needs. The example that comes to mind is the localization script
(l10n.js) that appeared in my <head> sections after I upgraded my sites
to WP 3.1 (or it could have been 3.0--I don't remember exactly). From a
site-owner's perspective, I don't know what this newfangled localization
mumbo jumbo is supposed to accomplish, but I do know that (1) it slows
down my page loads, and (2) my site worked just fine without it.

Naturally, I'd like to remove it. Unfortunately, WP core doesn't have a
convenient function dedicated to the inclusion of this script tag, so
the task of removing it is prohibitively-burdensome to all but the most
dedicated/knowledgeable of Admins. My theme provides a simple mechanism
that allows non-programmers to achieve their desired results with
minimal effort and less complexity (i.e., fewer opportunities to create
new bugs or errors).

*To summarize:* WP APIs allow authors to unhook whole functions, but this
is inadequate for cases where the author wants to edit *only a portion* of
a function's output.

*Themes and Plugins hosted by WordPress.org absolutely should not be
> promoting, encouraging, or facilitating users to be using outdated,
> insecure versions of WordPress.
> *

I agree with that statement, but that statement doesn't rebut anything
I've said. In other words, you have provided a counterargument to your
own (skewed) interpretation of my argument. (see straw
man<http://en.wikipedia.org/wiki/Strawman>)

*Just FYI: the decision point regarding dropping WordPress official
> support for PHP4 was 10%. 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.
> *

I'm grateful for that information, however, it isn't directly relevant
to our current discussion. You are convoluding the definitions of
"support" and "decision point" to suit your argument.

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.
> *

On Sat, Jul 2, 2011 at 8:08 PM, Chip Bennett <chip at chipbennett.net> wrote:

> Somehow, we seem to be on completely different pages, and I am unsure why.
>
> 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:
>
> 1) Using *wp_enqueue_style()* or *wp_enqueue_script()*
>
> 2) Using *add_action( 'wp_head', 'some_custom_function' )*, where *
> some_custom_function()* prints a fully formed script or style tag, or
> whatever other content.
>
>
> 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 *both
> of these options already have means within core functionality to be undone
> *:
>
> 1) Anything hooked in using *wp_enqueue_style()* or *wp_enqueue_script()*can be undone by calling
> *wp_dequeue_style()* and *wp_dequeue_script()*, respectively.
>
> 2) Anything hooked in using *add_action( 'wp_head', 'some_custom_function'
> )* can be undone by calling *remove_action( 'wp_head',
> 'some_custom_function' )*
>
>
> Am I missing any options? Are there any other ways for Plugins to inject
> content into the HTML document head?
>
> On Sat, Jul 2, 2011 at 7:30 PM, Darren Slatten <darrenslatten at gmail.com>wrote:
>>
>>
>> According to the WP stats <http://wordpress.org/about/stats/>, the number
>> of sites using WordPress versions
>> 2.7 and older represents 9.4% of all WordPress users. You're saying that
>> any plugin that attempts to maintain backwards compatibility with those
>> (millions of) sites by hooking a jQuery reference directly to wp_head
>> (instead of using wp_enqueue_script) should be banned from the plugin
>> directory?
>
>
> 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.
>
> Just FYI: the decision point regarding dropping WordPress official support
> for PHP4 was *10%*. 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.
>
> How such repository-hosted Plugins get handled, I leave to others. But I
> would agree with a decision to suspend them.
>
> Chip
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110702/2bd0cbaa/attachment.htm>