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.
