[theme-reviewers] Question about ob_start and ob_get_clean (Vicky Arulsingam)
Angelo Bertolli
angelo.bertolli at gmail.com
Sat Jul 2 04:43:25 UTC 2011
On Sat, Jul 2, 2011 at 12:21 AM, Darren Slatten <darrenslatten at gmail.com>wrote:
> 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.
>
> How do you ensure that this doesn't mess up plugin functionality when
you're wrong about the necessity of the code a plugin is using? Also, I'm
curious if you really save anything by buffering and processing it this way
(given the sophistication of the filter).
> 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.
>
> It's true they won't likely just change that, but how is it that the plugin
authors are unable to code around your filter then? So does this just end
up being a code war between the theme developers and the plugin developers
both trying to code around each other to get links in? Do you put a link in
your theme to an external site?
>
> - *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.
>
> I agree with the point you're basically making with these two bullets that
expecting plugins to be cleaned up is unrealistic, and there are legacy
issues. But the question is really if the solution is to code around that
in the theme. I understand your point of view, but at the bigger picture
what needs to happen is if this stuff is coded around at all, it needs to be
coded around via WP itself. More likely the plugin developers just need a
stricter set of standards.
I think you can make a case for allowing this kind of thing temporarily when
there isn't a solution for you or your theme users, but ultimately it
shouldn't stay that way.
My 2c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110702/8dac94c5/attachment.htm>
More information about the theme-reviewers
mailing list