Themes that remove the wp_head() call are outright broken, as are themes that do not provide some way of addressing each post via DOM whether it's on the H3 or the DIV. I would prefer the DIV, but then we'd be changing the way it's done from the Default theme.
Someone needs to provide a serious review service for themes so that these things aren't overlooked. I think there is a sad disparity between designers and developers in this arena. Designers are often very concerned about what the site looks like and whether it renders properly in every browser, but often overlook or aren't aware of hooks that developers are using to implement plugins or other features.I recently received a "bug" notice for one of my plugins that said the plugin wasn't behaving correctly. It turns out that the plugin expected a tag to be IDed a certain way if it was going to contain the post date. The theme that was in use on the concerned site did not use this ID. It also did not wrap the post content in its own <div>, preferring to let paragraphs of the actual post intermingle with the meta information (date, post author, etc) for the post. It's not semantically incorrect, and I'm sure it validates, but I know this would break a few plugins that rely on DOM or ob_start() and regexes to execute.
Should I be expected to alter my plugin to work with this other theme? I'm going to say no. I told my plugin user to add some code to his theme that would re-integrate support for my plugin. Thankfully, he was programmatically inclined and it worked out. Those who are not programmatically inclined would simply have to go without. I did leave a message on the theme author's site explaining the situation and the easy remedy, but I have seen many sites already using this theme and wonder if they will bother to upgrade if the author decides to make this change.
Plugin authors should be expected to work with only what the core WordPress provides. It's too much to ask of plugin authors to modify their plugins to work with other themes. If there are features of themes in the core, then theme authors should provide them if they expect plugins to work with what they've created.
Perhaps Codex should document required features for themes to work correctly with published plugins? There is already a plugin hook list, why not something similar for common output features? Plugin authors could also use this to determine what they can expect from a theme, so if it's decided that posts are not required to have IDs attached, they can come to expect and design for this drawback.
I ask that theme designers please be aware of what parts they're omitting from their themes because although you might not need them, other people may. Otherwise, I'm going to have to start up a list of themes that my plugins do not work with, and I don't want to do that.
I agree. I'd also like to see this review service (whatever it ends up being) take note of which WP features are supported "out of the box." For example, some themes support the new "pages" feature, while others require modifications to the theme to make this feature work (not difficult, but a little annoying). Perhaps a good start would be to compile a list of common theme attributes...and use this as the basis for designing a searchable themes database.
I agree too, but I would have to add that there's a need for more complete and simplified tutorials on theme building that are more friendly on their perpective developers. I for one have been looking into WordPress for the past 2-3 weeks and have had a great deal of crossreferencing and searching to find (and most of the time only partial) answers to some of my questions. I am part of the more graphical design aproach type of developper (even tough I don't mind getting my hands dirty in the code), but I would like to make my tinkering with WordPress in line as much as possible with what as been developped already.
Thx for your insights, at least now I have a few pointers on what I need to consider while customizing my blog.
Thank you for writing this. It's often difficult for theme developers to get feedback on what they need to include and why they need to include it (the theme competition rules, for example, make no mention of plugin or i18n compatibility, though to my mind they're at least as important as cross-browser checking).
I'm still somewhat unclear on what you mean by 'addressing each post via DOM' (do you simply need each post to have a unique id?) but another look at the code in the classic and default themes should clarify that.
Yes, each post needs to reference the post ID, preferrably exactly how the default and classic themes do it - on the heading tag used for the post title. This provides a method for addressing that post via javascript and the DOM, something like this:
It also makes it possible to reference posts inline via bookmarks, like http://example.com/index.php#post-13
Now you're just talking bullshit. No one should ever use permalinks like that, ever! I see the point in providing a method for addressing posts via JavaScript and the DOM, but that argument is just bad-ass.
Well, nobody said that "you should do this this way", or that this link was a "permalink". I just said it was possible. And there are reasons for wanting to do this, such as if you use the CSS3
:targetpseudo-class. (It worked in Firefox last I checked.)But yeah, you're right- Bookmarks are not the best reason to do this.
100% agreeing; your 'Comment Quicktags' plugin had a hardtime working with the theme I am using (but worked with other ones), but I was stuborn enough to make it work without changing theme. The issue was that the 2 <script> tags weren't even included, so I thought: this is definitely in the header section. And voilà , no <?php wp_head ?> ; the second I added it, the second it was working. Of course, this happened this way because I am "programmatically inclined" (sic), but even I had my instants of considering to just give up and make the visitors time the tags themselves.
I know the problem is not yours, but rather the themes', but why don't you consider including a "<?php wp_head ?> required" warning in your plugin's (or plugins') documentation?
I don't consider it because themes are supposed to have certain features, this included. Theme authors need to be aware of what they're doing enough not to break existing code - I shouldn't have to put warnings on my plugin. That's kind of the whole point of this post.