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

Sat Jul 2 04:21:06 UTC 2011

Hi Andrew,

*It's Otto and Chip. Responses don't get more logical.
> *

Actually, the responses from Otto and Chip have definite room for
improvement, with regards to their logical merit. Their arguments rely
heavily on assumptions derived from personal experiences, opinions, and
philosophies that are neither documented nor mutually understood by all
participants of this mailing list.

Their arguments also contain contradictory assertions that fluctuate between
topics to support the opinion du jour. The most obvious example in this
thread is the variation in assertions about the extent to which a theme
developer should concern himself/herself with WordPress plugins. For
example, consider the following (highlighted) snippets, which I've extracted
from Chip 'n' Otto responses in just the past week:

*So there probably are some shared sites that don't work that way, and
> create accounts with apache/nobody as owners. From my perspective,
> forcing themes to use the unfriendly WPFilesystem instead of fopen is
> the wrong solution for several reasons...*[for example]*...it totally
> ignores the possibility of the unrestricted plugins that can use fopen
> as freely as they like.
> *

*Irrelevant. Can we stop bringing up what Plugins can do, and how they
> behave? It's just simply not going to be an entertained argument,
> because we have absolutely NO control over Plugins.
> *

*A much better approach would be to make the solution a bit more global -
> one that would help protect sites that use plugins as well as themes.
> One that would educate the end users, and help web security as a whole.
> *

*A laudable goal, but one that is outside the scope of the Theme Review
> Team. We are tasked with reviewing and approving Themes submitted for
> inclusion in the WPORG repository.*
>

*Until then, the Theme Review Team must operate on the playing field as it
> currently exists.
> *

*Now we have a solution that helps everyone. Plugins that use fopen are
> now safer. Theme writers can use methods that lead to an optimal user
> experience. And we don't waste anybody's time on servers that aren't
> affected by a problem that should handled at that level anyway.
> *

*Again: a laudable suggestion - but one that is entirely outside the
> scope of the Theme Review Team. Bring it up on the Hackers list. Open
> some core Trac tickets, and submit some patches. Start the discussion at
> the *core* level.*
>

*Fixing problems in unrelated code is out of scope for a theme to do
> in the first place. Themes control how the site looks, not what's on
> the site or how plugins work.**
> *

*The best-case solution, IMHO, is better education of Plugin developers.
> Rather than spend time building into your Theme "correction" code for a
> Plugin, why not ping the Plugin developer, and submit a patch for the
> Plugin itself? That way, every single user of the Plugin benefits from
> the effort.
> *

*Fixing a plugin directly gets the fix to everybody that uses the plugin.
> It promotes collaboration. You can help out other people, even people
> who may not use your theme.
> *

*Wouldn't it be better to simply fix the plugin to not have the problem
> in the first place? To make the plugin smarter and able to do what
> you're suggesting in a better way?
> *

*Contact every plugin author and provide them suggestions as to how to
> correct their code. It is the preferable solution.
> *

*If you're going to apologize for not explaining things adequately,
> backhanded remarks like that aren't necessary.
> *

First of all, I wasn't apologizing, and I apologize for being unclear about
that.

Second of all, I'd argue that backhanded remarks--or more generally, passive
aggression and insults--are not only a perfectly-acceptable means of
communication in this mailing list, but that they're the defining
characteristic of most of Otto's responses (and occasionally Chip's). For
example:

*Your hacky workarounds to perceived problems may end up causing other
> people problems in other ways.
> *

*To put this into perspective, if I found a theme intentionally messing
> with the output of one of my plugins, then both the theme and the [theme]
> author would enter my permanent blacklist. I'd probably consider adding
> code to my plugin to disable your code that breaks it, and then add
> comments that display to the user saying something about what a jerk you
> are.
> *

*It is not your place to attempt to fix all the code in the world by
> putting half-baked hacks into your theme.
> *

*Collaboration. Try it sometime.
> *

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

Unfortunately, I don't know you any more than I know Otto and Chip. If
there's a prerequisite to joining this mailing list--for example, an
understanding of the social hierarchy of WordPress contributors--then that
should be made clearer during the subscription process. Until then, I will
continue to participate in these discussions under the assumption that each
issue should be judged by *the facts presented* and not by signals
such as *Andrew
said so*. Even if said prerequisites were made clear, *Appeal to Authority*and
*Appeal to Celebrity* are logical fallacies--invalid reasoning that
shouldn't be promoted in any debate.

Now then...

Assuming we're all done arguing over *nothing*, I'd like to propose a
specific example of using output buffering.

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