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

Sat Jul 2 12:46:40 UTC 2011

Actually, I rarely use passive-aggression. If I think you're full of crap, I
just say so. I'm going to ignore the condescending flame-bait, and address
only the germane parts of your email below.

Saying that output buffering is required in order to remove content hooked
into wp_head is simply untrue. Anything hooked in via wp_head can just as
easily be unhooked. Every add_action() can be undone with a remove_action().
Every wp_enqueue_style() or wp_enqueue_script() can be undone with a
wp_dequeue_style() or wp_dequeue_script().

Core WordPress functionality provides everything necessary for
adding/removing styles, scripts, and/or meta tags hooked into wp_head, for
rearranging their order of output, and for editing their content.

By using output buffering to accomplish the same thing, you're adding
needless complexity and processing, for zero gain. End users can do all of
those things using core functionality and files. All you're doing is adding
a hook layer on top of an existing hook layer. You've basically rewritten
the functionality of wp_print_scripts and wp_print_styles. Congratulations!*

As for your real-world examples:

   - The front end of a site should never enqueue multiple versions of the
   same jQuery script. That's just asking for conflicts. IMHO**, Themes and
   Plugins should only ever be using the core-bundled version of any given
   jQuery script (including jQuery itself), because *other Themes and
   Plugins will rightfully assume that the core-bundled version is the version
   available for their use*, so if another Theme or Plugin enqueues a
   different version, they can cause potential breakage.

   - If developers are hooking in HTML-comment attribution via wp_head, then
   those attributions can be un-hooked via wp_head just as easily. Also, just
   FYI: there are no "GPL compliance" issues with HTML-comment attribution.

   - Duplicate rel=canonical links hooked in via wp_head can be unhooked via
   wp_head just as easily.

   - Removing core scripts such as comment-reply.js and l10n.js, that are
   added via filter, can just as easily be removed via filter. Also: doing
   something like this is not the jurisdiction of a publicly released Theme.

   - Favicon links that are hooked in via wp_head can just as easily be
   unhooked via wp_head. (Are you noticing a pattern here?*)

   - Scripts and styles that are enqueued can all be rearranged however one
   prefers, using nothing other than functionality available in core. The Hooks
   API provides a convenient *prioritization* method.

As for your rebuttals:

   - If a Plugin developer is that obtuse, then sure. But such Plugin
   developers are the exception, not the rule. And even so, the existence of
   such Plugin developers does not refute the fact that correcting such
   behavior in the Plugin itself is far more efficient and effective than
   making end users correct the behavior themselves. And in this case, there is
   nothing subjective about the "right way". Scripts and styles (and anything
   else custom-added to the document head) should be hooked in via wp_head, at
   an appropriate hook within wp_head.

   - Again: Themes should not be outputting multiple versions of the same
   jQuery script. Doing so is just asking for problems.

   - Any end user still using WordPress 2.8 has enough other problems and
   issues to worry about. Such a user either needs to update to the latest
   version, or else be responsible for any such problems/issues incurred by
   choosing to use out-of-date software.

Chip

* Note: that's *sarcasm*, not passive-aggression

** Note: this statement is my opinion only.

On Fri, Jul 1, 2011 at 11:21 PM, Darren Slatten <darrenslatten at gmail.com>wrote:
>
> *Without output buffering:*
>
> <head>
>     <meta charset="<?php bloginfo( 'charset' ); ?>" />
>     <title><?php wp_title( '|', true, 'right' ); ?></title>
>     <link rel="stylesheet" type="text/css" media="all" href="<?php
> bloginfo( 'stylesheet_url' ); ?>" />
>     <?php
>         *wp_head();*
>     ?>
> </head>
>
> *Result:* theme's user has no control over wp_head() output--in other
> words, no control over the content that plugins insert into the page's
> <head> section.

>
> *With output buffering:*
>
> <head>
>     <meta charset="<?php bloginfo( 'charset' ); ?>" />
>     <title><?php wp_title( '|', true, 'right' ); ?></title>
>     <link rel="stylesheet" type="text/css" media="all" href="<?php
> bloginfo( 'stylesheet_url' ); ?>" />
>     <?php
> *        // Start output buffering.*
>         *ob_start();*
>
> *        // Any plugins that use the wp_head hook to insert meta tags,
> CSS,
>         // scripts, etc. will still function as intended, the only
> difference here
>         // is that they'll print to the output buffer instead of echoing
> directly
>         // to the output stream.*
>         *wp_head();*
>
> *        // Stop the output buffering and store the buffer content (as a
> string)
>         // in $my_wp_head_content.*
>         *$my_wp_head_content = ob_get_clean();*
>
> *        // If a filter has been defined by the theme's user, run our
> buffer
>         // content through it and echo it. If no filter is defined, just
> echo the
>         // content like usual (in other words, execute wp_head default
> behavior).*
>         *echo apply_filters( 'my_custom_wp_head_filter',
> $my_wp_head_content );*
>     ?>
> </head>
>
> *Result:* theme's user has the ability to filter the output of
> wp_head()--in other words, theme's user can:
>
>    - Add or remove meta tags, CSS, scripts, etc.
>    - Rearrange the order of meta tags, CSS, scripts, etc.
>    - Edit the content of meta tags, CSS, scripts, etc.
>
> Real examples of things I've personally used this functionality to
> accomplish on my own sites:
>
>    - Remove redundant references to jQuery (for example, 2 plugins queue
>    the latest versions of jQuery that were available at the time of writing,
>    however both plugins will function with one or the other--removing the
>    redundant jQuery reference allows pages to load faster).
>    - Remove plugin author attribution HTML comments (in compliance with
>    GPL, of course).
>    - Remove duplicate rel="canonical" tag (caused by plugins incorporating
>    this feature before WP core...and then WP catching up, adding a second
>    occurrence).
>    - Remove WP core scripts (e.g. reply.js and l10n.js) because I've
>    already appended them to the end of a global custom .js file.
>    - Remove favicon references.
>    - Change order of CSS and JS to optimize page load speed and prevent
>    FOUC.
>
>
> Please note that my real examples rebut the following arguments:
>
>    - *Notify the plugin author or submit patches*--not a solution in cases
>    where plugin author has intentionally inserted a 4-line HTML comment into my
>    <head> section, essentially advertising his/her website. More generally, not
>    a solution for cases where "the right way" is subjective.
>    - *If Theme and Plugins all enqueue jQuery properly, then there will
>    *never* be duplicate jQuery scripts enqueued.*--not true in cases where
>    specific/multiple jQuery versions are referenced. Also, wp_enqueue_script is
>    @since 2.8, so backwards compatibility can't be ignored.
>
>
>
> Okay, I'm done. Fire away.
>
>
>
>
>
>
>
>
> On Fri, Jul 1, 2011 at 1:10 AM, Andrew Nacin <wp at andrewnacin.com> wrote:
>
>> On Thu, Jun 30, 2011 at 1:58 AM, Gmail <darrenslatten at gmail.com> wrote:
>>
>>> The illogical responses from you and Chip lead me to believe that I must
>>> not be explaining this adequately. I will return to this topic in a few
>>> days, when I have my computer up and running again, and I can insert code
>>> examples for clarity. Currently, I'm trying to respond via iPhone, and it's
>>> not doing this issue any justice. I'll be back.
>>>
>>
>> It's Otto and Chip. Responses don't get more logical.
>>
>> If you're going to apologize for not explaining things adequately,
>> backhanded remarks like that aren't necessary.
>>
>> I agree with them. You're doing it wrong. And approaching it wrong, too.
>> We're all quite approachable, but that comes with the caveat of doing so the
>> right way.
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
>
> --
> -Darren Slatten
>
>
> _______________________________________________
> 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/0499d9d5/attachment.htm>