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

[Shawn Grundy]

I would agree with everything Chip is saying here with exception to the using only core-included versions of jQuery, or any other script for that matter. I can easily designate the version by first deregistering the included jquery and then registering the newer version. As long as it's registered as 'jquery' and not something like 'jquery.new'. This way when a plugin enqueues jquery (the right way) they will get the newer version and there still will only be one version included....something like the following:
wp_deregister_script( 'jquery' );wp_register_script( 'jquery', '/path/to/new/jquery.js', false, '1.6.2' );
now whenever a theme or plugin uses the standard wp_enqueue_script( 'jquery' ); they will get the specified version above....not the included "core" version.
This is example btw is available right on the codex -> http://codex.wordpress.org/Function_Reference/wp_enqueue_script

Date: Sat, 2 Jul 2011 07:46:40 -0500
From: chip at chipbennett.net
To: theme-reviewers at lists.wordpress.org
Subject: Re: [theme-reviewers] Question about ob_start and ob_get_clean	(Vicky Arulsingam)

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





_______________________________________________
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/fd11f8ec/attachment-0001.htm>