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

Gmail darrenslatten at gmail.com
Wed Jun 29 21:39:53 UTC 2011


Adding output buffering and a custom filter to wp_head and wp_footer requires...what, 4 extra lines of code? I'm having a very difficult time understanding why "contact the plugin author and ask them to change their code" would be the best approach.

Also, I'm not suggesting a hard-coded fix for specific plugins--I'm only suggesting that a theme provides that basic functionality for advanced users to take advantage of. This would require adding custom code to functions.php.

So...4 lines of code to give advanced users control of plugin output...or contact every plugin author and ask them to update their code?

-Darren Slatten

On Jun 29, 2011, at 4:18 PM, Simon Prosser <pross at pross.org.uk> wrote:

> Surely the contact form should ONLY be loading it js and css in pages
> and posts that have comments enabled, if not, thats poor coding for
> the plugin, and rather than coding a theme around the plugin, you
> should perhaps be hassling the author to change said plugin to use
> some logic in wp_head.
> 
> On 29 June 2011 22:13, Gmail <darrenslatten at gmail.com> wrote:
>> 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
>> 
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> 
>> 
> 
> 
> 
> -- 
> My Blog: http://www.pross.org.uk/
> Plugins : http://www.pross.org.uk/plugins/
> Themes: http://wordpress.org/extend/themes/profile/pross
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers


More information about the theme-reviewers mailing list