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

Sun Jul 3 18:13:25 UTC 2011

The single biggest problem that I see with themes stepping *out of bounds* and trying to tackle things outside the scope of a theme goes back to a previous discussion we had on themes using custom post types and/or an abundance of shortcodes. It simply creates more problems for end users in the long run. I saw a poll (can't remember exactly where), but I remember the numbers quite well. Close to 50% of the people polled switched their themes as often as once a month and as seldom as once every year, leaving 50% never to change. That number is staggering. Keeping this in mind, it clearly shows the inarguable point that when these 50% of user who switch their themes actually do switch, they will inevitably be dealing with issues because of the *extended features* of the theme they were using, rather than correcting problems such as what you (Darren) claim.
If a shortcode is coded into a theme for an information box and the user switches themes, the pretty little info boxes all turn into [info_box]Some information here[/info_box] creating a very large problem for the end user who, in most cases, does not have even a basic grasp of HTML or CSS. The same holds true for post types, as well. 
I think the point that everyone who disagrees with you is trying to make is that any move closer to *locking* a user into theme is a step in the wrong direction. In fact, what you may think is helping could quite possibly be putting them in a more difficult situation down the road. If your theme *fixes the problems of other plugins*, then what happens when the user switches from your theme, or do you just not care at that point? I'm curious to hear your answer here as, after reading the entire thread, the responses from Otto and Chip have been extremely logical, despite your claims to the contrary. 
Creating your *fix* in a plugin, rather than the theme. would allow a user to change themes and still have the fix implemented, so I am failing to see why you're grasping at this? You asked the question about whether you are supposed to *accept* less than optimal code because WP is outputting it. The quick answer is this:
As a theme developer: Yes, you are, because a theme has no business altering this because of the aforementioned issues that can arise as a result. As a plugin developer: Not so much, because a plugin can run within many themes, making it more of a *universal* change/application.
It appears to me, based on this thread, that you are trying to create the concept that WordPress isn't perfect and you're the guy to "swoop in" and fix it. That's fine....good job....way to go....*pat on the back*, but you need to do it within the guidelines set by both WordPress and WPTRT, or just simply host your theme elsewhere...just sayin...
Take a look at some other major CMS platforms and what do you see? Looking at some Joomla and Drupal themes and you will notice that even in these cases the theme is simply appearance based. In fact, there are many Joomla themes that require only xml/css/js files and don't include a single php file! 
You keep bringing up *your argument* but I can't really figure out what it is. If your argument is that your theme *should* be allowed to implement these fixes/changes/whatever, then your DEAD WRONG. If your argument is that WordPress may output some less than optimal code from time to time in order to achieve multiple goals for the masses of people who use this platform every day, well then I would agree but also point out that when a platform such as WP is used by millions of sites, which it is, *good enough* is pretty damn hard to beat. *Perfect* doesn't exist in this industry. If it did, you would be coding a theme for that platform this email thread would never exist....right?
If you truly want to address these areas which you (and apparently only you) find to be inadequate, then perhaps your efforts should be spent on contributing to the core or developing plugins that address these issues for all themes, not just your own. :D
In addition, I fail to see your point about not taking the word of 8 experts simply because they're experts. Sure, definitive facts are nice, but not always realistic when speaking of web development where several methods *work* and accomplish the same goal, but with different possibilities and consequences as a result. If I am a brand new user and I see an argument where 8 experts, including some that have been with WP since inception, are on one side of the fence, and someone who I have never heard of is on another, it's not too difficult to decide which side is the "safer bet". These guys have been working within and on this platform for a number of years and have probably been faced with more scenarios than any one developer can contemplate. That alone, is good enough reason to give thought to their suggestions, and I am confused as to why you don't believe that.
The bottom line is that, as a theme, you should keep it as a theme. Keep everything else a plugin....in the long run it will make development easier on your end as well and allow you to roll out more themes. Keeping this *fix* you claim within a plugin will allow you to more easily update it later without having to update all of your themes, if you develop multiple themes. Things change in this industry rather quickly and keeping up development on a plugin in far easier than adding any updates to a bunch of different themes, IMO.
The way I see it, this is not opinion, it's fact. If you move towards locking your users into your theme, then your theme should not be in the repository. Perhaps output buffering alone won't lock a user into a theme but if we begin allowing these theme-specific *fixes*, then it opens the door to other problems and, before you know it, the themes in this repository end up with as many custom post types or shortcodes as a theme on say...themeforest. Then the end user is the one who feels the pain when they realize they can't change themes easily, if at all. I can certainly tell you that if I review a theme trying to implement these things I will close it as not approved and I and I am sure that most others would too. Like it or not, it's about the end user and what you claim to be helping them could actually end up hurting them when or if they choose to switch themes.
...for what it's worth,
Shawn
From: edward.caissie at gmail.com
Date: Sun, 3 Jul 2011 12:15:35 -0400
To: theme-reviewers at lists.wordpress.org
Subject: Re: [theme-reviewers] Question about ob_start and ob_get_clean	(Vicky Arulsingam)

Although I have read this entire thread (OK, I skimmed a few parts) IMO, in the simplest of terms: a Theme is a Theme and should generally be dealing with the general look and feel of a web site (NB: This is not just a WordPress thing.); it is not a Theme's concern or obligation to manage plugins or their functionality. Given this, and my understanding or the ob_* functions, they really have no place (as described and argued for) in a theme being hosted on the WordPress Extend Themes repository. Perhaps their is a niche group that is being argued for, but that niche group can easily be served from another distribution network as one of the major premises of the Extend Themes repository, as I see it, is to serve the over-all or majority of the WordPress user base.

Cais.

On Sun, Jul 3, 2011 at 9:09 AM, Darren Slatten <darrenslatten at gmail.com> wrote:

p.s. if you're going to admonish others for their passive-aggression, 
you should probably try to use less of it yourself. Glass houses and 
all...

Revisit the beginning of the thread. I didn't admonish anyone for passive-aggression, Nacin did. I only took issue with the fact that Nacin called me out for something most of us are guilty of. If anything, I defended passive-aggression.

On Sun, Jul 3, 2011 at 7:39 AM, Chip Bennett <chip at chipbennett.net> wrote:

This is probably the point where I say that, for me at least, this thread has run its course, and as it currently stands, I don't think I'll have anything else constructive to add.
I don't look at Otto's mention of 8 rather disparate people all agreeing on an issue as being an appeal to authority*, but rather a matter of 8 out of 9 voices discussing this particular topic all agreeing. It could be that everyone else on the mail list has simply ignored this thread, and thus are not speaking in agreement with your position; alternatively, it could be that the majority actually disagrees with you.

In other words: 89% of the people participating in this thread disagree with your position.
And speaking for myself personally: with respect to consideration of WordPress "best practices": I defer strongly to Nacin, Otto, Scribu, and Dion. They eat, drink, sleep, and breathe the WordPress codebase. I respect their opinions and expertise on such matters. There are certainly times that I disagree with them on WordPress issues, but their arguments simply carry more weight. (Here's where the concept of meritocracy applies.)

As far as this list goes, and the WPTRT in general, all input is welcomed. This list exists in order to solicit input from the Theme developer community. But you'll find that the WPTRT operates within certain principles that, while not entirely immutable, are only likely to be changed with extremely persuasive arguments and extensive agreement within the Theme developer community.

One such principle is that Themes and Plugins serve different purposes, and that some functionality is appropriate for one or the other, but not both. While the exact differentiation is certainly subject to interpretation, any Theme functionality that deviates considerably from presentation of content is going to come under heightened scrutiny. Further, functionality that involves site administration, security, optimization, etc. - and especially such functionality that should persist regardless of what Theme is currently in use - is generally going to be deemed to be "Plugin territory".

Thus, Otto's comment about recognizing that a "Theme is a Theme" is both valid and relevant.
Another such principle is that what is acceptable/appropriate for private Themes may not be appropriate for a Theme intended for general, public distribution. Again: the exact differentiation is subject to interpretation.

Thus, Otto's statement that Themes should not use ob_cache does not apply to Themes in general, but rather is made in the context of what is appropriate for Themes intended for general, public distribution.

I should also point out: most of what you see on this list represents the opinion of the speaker only. Nothing you read becomes matter of "official" WPTRT policy until you see such statements in conjunction with the terms "Guidelines" and "required", and followed up by related posts on the make.wordpress.org/themes site, and changes to the Theme Review Codex page. So, don't interpret academic/theoretical discussions or personal opinions as declarations of Theme Review requirements.

Thus, statements made in this thread, by me, Otto, Nacin, Scribu, Dion, Justin, Simon, and Ryan merely represent opinions, and personal contributions to an ongoing discussion.

Chip
* Though, if you knew the history and the wildly disparate experience, involvement, and viewpoints of the particular 8 people, and the nature of past disagreements, you would likely be equally amazed at such conclusive agreement on this issue.

p.s. if you're going to admonish others for their passive-aggression, you should probably try to use less of it yourself. Glass houses and all...

On Sun, Jul 3, 2011 at 6:41 AM, Darren Slatten <darrenslatten at gmail.com> wrote:

Look, if you can't even agree on the simple fact that a theme is 

supposed to be a *theme*, then this discussion is getting into the 
"pointless" territory pretty darned fast. 

Invalid and irrelevant. 

The only person I see being "pretentious" here is you. Nothing but long 
endless diatribes about how your code is right and everybody else who 
disagrees with you is wrong. 

I've cited sources where necessary and relied on simple principles of 

logic to rebut invalid arguments. I believe I am right, but I do not 
assume I am right, and I do not build my arguments on assumptions that I 
am right. It is for these reasons that I am not pretentious. 

My responses are only as long as is necessary to adequately explain my 

views. This requires considerably more effort than, say, expressing 
one's opinions as facts and providing no explanation or reasoning. 

I would point out that the people disagreeing with you are core 
developers, admins of the theme review system, design experts, and 
people like me who are just plain all-around-general-know-it-alls (thank 
you very much), but then you'd probably just take that as some kind of 

appeal to authority or something. 

Your argument is a textbook example of invalid reasoning based on a 
logical fallacy that's been understood and documented for hundreds of 
years. It's not like I'm making this stuff up. And don't forget: I'm not 

saying "everyone is wrong"--I'm only saying "Yes-huh...you can even go 
ask Andrew Nacin!" is not a valid argument. 

At some point, you're simply going to have to sit down and say to 
yourself "hey, why are all these people, who really do know things and 
are widely considered to be experts, disagreeing with me?" 

I disagree. Solving problems requires facts and logic. The people 
involved are irrelevant. 

Maybe it's because you haven't explained your reasoning properly. That's 
a possibility, certainly. I would have to say that nothing you've stated 
makes sense to me, even though you continually state that you've 

explained something already. 

I don't want to waste everyone else's time recapping what's already been 
said, but if you'd like, I can email you privately and try to get you up 

to speed. 

On the other hand, perhaps you're just going to have to accept the fact 

that, you know what? You might just be wrong. I know, shocker there, but 
it is a possibility that you're going to have to face up to at some 
point. 

(Reducing this issue to terms of "I'm right and you're wrong" feels 

selfish and primitive, but I'll humor you anyway.) 

I don't mind being wrong. I actually appreciate being proven wrong, 
which is why I constantly offer specific examples (easiest to disprove). 
I went as far as to write example code--essentially handed everyone a 

loaded gun--and yet all I got in return was a bunch of limp excuses, 
invalid reasoning, and best practices straight from the "in a perfect 
World" cookbook.

At this point, I'm not even sure what you're arguing 

for or against. As far as I can tell, you're just butthurt that the new 
guy spoke without paying his respects to your circle-jerk of 
"collaborators" and you need to vent. But who knows, maybe you've got a 

secret stash of valid arguments that you've been withholding. If 
so, please use them to "prove me wrong."

Here's a reminder of what's (supposedly) being argued. You can add to 
the discussion by providing information that supports the first set of 

claims or refutes the second set of claims: 

Otto et al:
Themes must not use output buffering.There is no reason for a theme to use output buffering.Themes should not allow users to modify the behavior of plugins.

Darren:
Themes should be permitted to use output buffering.There are some cases where output buffering is the only solution.There are some cases where theme-implemented output buffering is the best solution.

However, whenever I see a thread where Me, Nacin, Chip, Dion, scribu, 

Justin Tadlock, Simon, and Ryan Hellyer are all actually *agreeing* 
about something, then I'd have to say that that is pretty darned 
unusual. So, it's a point that you just might have to consider. 

That's not a point. That's an irrelevant observation. Unsupported 
opinions, conceived under rare conditions, are still unsupported 
opinions. Do you really expect me to intentionally remove functionality 

from my theme, because 8 people (I don't personally know) share the same 
unsupported opinion? 

Your solutions don't even solve the problem, as I see it, they only
create new ones. Output buffering? I mean, come on. Do you really
think it's better to delay sending content to the page so you can run

a bunch of string manipulation code to modify it, as opposed to simply
creating the content you want correctly in the first place?

This has all been addressed already. Please stop polluting this thread 

with more of the same invalid arguments I've already addressed. You're 
making it difficult for others to follow the real issues. 

Look, running a website, and especially optimizing one, involves more
than just changing the source code of the page. If you're going to
serve things up to the public, there's more to it than *just*
WordPress. Being a webmaster is a full time job for some people. There

is arcane knowledge that you have to learn. And sometimes, that
knowledge lies outside your sphere.

Cool story, bro.

If you don't know to set caching headers properly, then you should
learn it instead of trying to do optimization in other places that
won't even help you nearly as much.

Cool.

This is kinda like all those CSS-compression things I continually see

people trying to do. If you haven't even gotten the browsers looking
at your website to cache the data properly, then compressing your CSS
doesn't make a lick of difference if they're still downloading it

every single time. You're optimizing the wrong things. Focus on the
basics first. You only have to resort to the silly ideas like CSS
compression once you've exhausted the traditional, and
tried-tested-true, options.

For a site like ottopress.com, which takes more than 10 seconds to load, 

the benefits of minifying CSS may be difficult to see. For a site like 
seomofo.com, which loads in under 2 seconds, the benefit would 

be relatively more significant. Some webmasters just have higher standards
than others, and as a theme developer, I try to accommodate the needs of 
both types.

_______________________________________________

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

-- 
-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/20110703/bbe2253d/attachment-0001.htm>