Theme repository reviews

[Ryan]

It is my belief that if you don't like the implementation of said things like body_class post_class then you need to take it up with the core developers to make it more to your liking to be used in themes rather then disregard the requirement to have them.

I don't think Otto or anyone else here has issues with those functions being in core or even recommended for most themes. They just don't think they should be requirements in the theme repository as there are logical reasons why some themes may not wish to use them.

[Frumph]

Perhaps the theme review system should be pared down to nothing more than a check for spam links and other objectionable practices? Or perhaps themes should only be checked thoroughly on submission as opposed to on all updates? At least then the theme developer would only need to justify their variances from the "official" way of doing things once, rather than over and over again as they added new iterations.

That is currently the practice, yes. But it has to pass the theme review the first time *as of implementation of the review system*. Otherwise we look over the changeset for the theme is all really.

[Frumph]

I don't think Otto or anyone else here has issues with those functions being in core or even recommended for most themes. They just don't think they should be requirements in the theme repository as there are logical reasons why some themes may not wish to use them.

Name one logical reason not to use body_class() ... Really, I have no idea any reason not to have it. Although, I have no objection to it being regarded as optional as well, I am just interested in what reason someone would have in not having it.

[Frumph]

That's good to hear. Careful, clear, and concise wording is always important. Right now, it reads much more like a "here's all the things we require you to do and don't step outside these boundaries" guide.

Please read the http://codex.wordpress.org/Theme_Review guide that was reworked just 2 days ago. It addressed that issue and used better wording to describe clauses to situations where it wouldn't be a requirement; and the developer can and often does make notes as to why its implemented as such and it's read and understood.

[Ryan]

Name one logical reason not to use body_class() ... Really, I have no idea any reason not to have it. Although, I have no objection to it being regarded as optional as well, I am just interested in what reason someone would have in not having it.

Some people may not want to have extra markup in their theme that they are not using.

Theoretically it might also cause CSS clashes, although that's probably a sign someone should be more careful with their class names.

[Frumph]

Some people may not want to have extra markup in their theme that they are not using.

Theoretically it might also cause CSS clashes, although that's probably a sign someone should be more careful with their class names.

... HTML aesthetics is your logical reason? Okay. Really? .. Would you really consider that a good excuse not to use it? I mean sure, i'm not seeing it but i'm really not going to discount it, its plausible. Especially if I see the rest of the theme is like that, otherwise if not, then well.

sidenote on the clashes.

Let's take the clash of wordpress's own .post in the body class and the .post in the post_class(); The fact that class names are hierarchically able to be chosen for their position.

.column .post { }

is much different then

body.post { }

[Ryan]

I didn't mention anything about HTML aesthetics.

I just think that if someone wants to simplify their theme they should be allowed to.

[Otto]

Name one logical reason not to use body_class() ... Really, I have no idea any reason not to have it. Although, I have no objection to it being regarded as optional as well, I am just interested in what reason someone would have in not having it.

You're not hearing us.

I can think of no reason to not use body_class. I use it, and love it.

That's not a valid reason to make it a requirement, however.

Again, the difference between SHOULD and MUST is what is relevant here. If you're making every little stupid frickin' thing a MUST, then you're putting up a barrier that makes me not want to bother even trying. That is deliberately making it difficult, and that sort of behavior tears apart community.

Tell the developer why it's a good idea to use things like these.
Encourage. Assist. Help.
Don't just hit them over the head with a brick.

Given the current "guidelines", I would not even bother attempting to submit a new theme to the repository, because it's clear to me (from these codex documents you've linked to) that my contributions are not wanted. It's discouraging, in the extreme. The codex documents I've just read basically say "we don't want innovation, we want cut and paste code with only minor changes from what we have" in big bold letters, as far as I can interpret them.

I mean, for crying out loud, there's well over 30 requirements there and they're all MUST have features. WTF? The list of MUSTs should be no greater than 3. Maybe 4 things, maximum.

The only reason any item should be a MUST have item is if the core *requires* it to function properly. At the moment, the only thing I can think of that fits that bill is the align classes, wp_head and wp_footer, and $content_width. Everything else should be recommended only, not required.

Also, if you *really* want themes to get updated, then you have to make it easy for theme developers to push out updates. Plugins get updated all the time. Why? Because it's pretty simple for a developer to do it. What do we have with themes? You're looking at a week long review, minimum, with a high possibility of rejection. No wonder nobody updates their themes. I'm amazed anybody bothers to submit them in the first place.

If it takes me longer than half an hour to push out a simple fix to my users, then I'm just not going to bother doing it. It's faster for me to just tell them how to fix a problem themselves, and I don't have to go through some stupid approval process. This is the same reason people push jailbreak applications on the iPhone: Because you don't have to deal with getting your code change through a freakin' committee.

[Frumph]

@otto
I'm hearing you just fine, I find it difficult to believe that you would not want to have the repositories theme's up to a standard of representation and code use. The features are made by the core team to be utilized. Theme's can be distributed off the repository just fine, if they want them distributed by WordPress then I fully agree that there must be a level to the themes.

Several themes recently were suspended for backdoors with timthumb and etc, if those standards were not in place, wordpress sites utilizing that old code of timthumb would still be up there wreaking havoc with the end users

It's possible you haven't read the updated Theme_Review, if you have any suggestions or recommendations for changes, please; by all means make them.

If you want to talk about 'shutting the community' out of being involved, then let's talk about the dev crew who pushs people away if they don't agree with them.

Since you're argument about the methodology is 'not to your liking' your pretty much acting exactly like you're saying your trying to avoid

I'm currently of the opinion that the process is so fundamentally broken that it should be eliminated entirely. Theme review is not helping anybody, it's only hurting theming and driving developers to not use the repository.

This alone is making me think that the WordPress people don't want to get people involved. You're thinking that since we don't agree with you that it shouldn't exist at all.

[Otto]

No, I'm thinking that you're actively hurting the WordPress community by this process, and that it should be eliminated because it doesn't work.

Granted, I do realize that it's probably not intentional on your part, but that is still the end result.

The review process should eliminate spam, check for a very small number of requirements on very *basic* things, look for security issues, etc. That's fine and any of those may be a perfectly valid reason for rejection.

But if a theme developer submits a theme in good faith and it gets rejected because he didn't have the body_class in there, then something is horribly wrong with your process. If a theme developer of good record cannot get a quick fix pushed out to his users in under an hour, then the system is fundamentally broken.