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

[Gmail]

So...a better approach would be what? Rewrite all plugins that don't follow best practices?

That still wouldn't address issues like client-side load order (e.g. to optimize page load times).

A real example where wp_head filtering is useful is in conjunction with the Contact Form 7 plugin. By default, enabling that plugin would insert a CSS file and script into the head of every page. With a custom filter and a conditional statement, I can make sure only the contact form page loads those resources.

In many cases, this can also be achieved "more elegantly" by removing hooked functions, but filtering the output buffer (i.e., working with regex) is much faster/easier than digging through plugins, searching for the custom function code that hooked into wp_head.

-Darren Slatten

On Jun 29, 2011, at 1:44 PM, Chip Bennett <chip at chipbennett.net> wrote:

> I think you have that approach exactly backwards. Plugins should be looking after themselves, by hooking properly into appropriate hooks. Theme and Plugins should mostly stay out of one another's way.
> 
> If Theme and Plugins all enqueue jQuery properly, then there will *never* be duplicate jQuery scripts enqueued.
> 
> Chip
> 
> On Wed, Jun 29, 2011 at 11:45 AM, Gmail <darrenslatten at gmail.com> wrote:
> I use output buffering on wp_head() and wp_footer(), in order to give my theme complete control over them. Since most plugins hook onto these, they can become cluttered with scripts and CSS file links. By using OB and a custom filter, I can do things like (1) remove duplicate jQuery scripts, and (2) optimize the order that CSS and scripts are loaded in. Essentially this gives my theme the final say in what resources are loaded into the page, allowing me to "clean up after" plugins.
> 
> -Darren Slatten
> 
> On Jun 29, 2011, at 10:12 AM, Vicky Arulsingam <vicky.arulsingam at gmail.com> wrote:
> 
> > I've asked the theme author to explain the usage. If there's a valid
> > use for it then it should be allowed but I haven't a clue how.
> >
> > On 6/29/11, Ryan Hellyer <ryan at pixopoint.com> wrote:
> >> There are many reasons to use output buffering (ob_start etc), but
> >> they would rarely be used within a theme. I've seen themes which use
> >> buffering as a way to dynamically minify the markup, but that's a
> >> horrid way to do it - much better incorporated within a caching plugin
> >> IMO.
> >>
> >> There may be a practical use for output buffer in a theme, but I'm
> >> darned if I can think of a good example. I wouldn't want to see it
> >> banned outright, as someone may come up with a cunning use for it that
> >> none of us have thought of.
> >>
> >> Perhaps the theme check plugin could check for output buffering
> >> functions and leave a request for the theme developer to provide a
> >> reason for using it? That way they'll know it's non-standard and
> >> provide a reason (good or bad) for the theme reviewers to read. Could
> >> potentially save a little to and fro'ing in the future. Just an idea.
> >> _______________________________________________
> >> theme-reviewers mailing list
> >> theme-reviewers at lists.wordpress.org
> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >>
> >
> >
> > --
> > -----
> > Vicky Arulsingam
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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/20110629/90c41eb2/attachment-0001.htm>