Follow-Up: Theme Obsolescence Guideline
I haven’t yet seen any discussion of this point in Phil’s post below, so I wanted to highlight it again:
Some of the review team have brought it up that there should be a time limit for non-updated themes, our general consensus is 2 or 3 major revisions of WordPress before suspension for not keeping themes updated. What this means that currently we’re on WordPress 3.0 previous to that was 2.9, 2.8 which is 2, 2.7 being 3 revisions previous, all themes that are prior to 2.7 (or 2.8) should be suspended as being currently obsolete.
To be clear, the Theme Review Team is formally proposing an obsolescence Guideline, that any Theme not updated within 2 (perhaps 3) major releases of WordPress be automatically suspended, until a current version is submitted and approved.
For example, if this guideline were put into place with a timeline of 3 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.8 (i.e. since June 2009) would be blanket-suspended.
Or, if this guideline were put into place with a timeline of 2 major WordPress releases, when WordPress 3.1 is released, all Themes not updated since before the release of WordPress 2.9 (i.e. since December 2009) would be blanket-suspended.
We very much want input and feedback on this proposal. Would this guideline generally help or hurt – improve or worsen – the Theme Repository? Is the proposed timeline (2 or 3 major WordPress releases, which translates into, generally speaking, 6 or 9 months) reasonable?
Chip Bennett 3:30 pm on January 24, 2011 Permalink
(Test Comment)
miklb 4:09 pm on January 24, 2011 Permalink
Maybe have somewhere that these potential obsolete/abandoned themes could be listed, giving others the chance to adopt them and bring them up-to-date.
I think that 2.9 support should be the minimum, with 2 releases going forward. Far too many features (post-thumbnail anyone?) that if not supported, seems to be doing users an injustice.
Edward Caissie 5:01 pm on January 24, 2011 Permalink
Ideally we will have a relatively current list available from this site … to start. I have been lobbying within the WPTRT to recommend a (second?) repository for these themes to no avail.
Chip Bennett 9:48 pm on January 24, 2011 Permalink
I think I’ve just had an epiphany, and now understand what you’ve been trying to suggest.
I think I could buy a “Themes For Adoption” repository, provided it has some sort of web interface, so users could see adoption-eligible Themes.
Dre 4:11 pm on January 24, 2011 Permalink
I think this would help with themes and plugins, but If removing them altogether isn’t reasonable, what about segregating them into a specific listing after xx amount of releases without an update?
Justin Tadlock 4:27 pm on January 24, 2011 Permalink
Generally, I like this idea. The only way I would oppose it would be if WP didn’t add anything that themes would need to use. For example, when the
comment_form()function came out, themes needed to update to use that function. I don’t think there’s anything in WP 3.1 that themes need to switch over to.WP typically adds something like this at least in every two or three versions though, so it shouldn’t be a problem.
Edward Caissie 5:03 pm on January 24, 2011 Permalink
Under this basic premise, using the
comment_form()example, I would imagine we could make the “cut-off” time a little more fluid if necessary.Chip Bennett 5:18 pm on January 24, 2011 Permalink
On the other hand, there is benefit and value to the end user, knowing that the developer of his chosen Theme is at least paying enough attention to the Theme to document that it still works with the most current version of WordPress.
Has there ever been a Theme developed that is so perfect that it doesn’t need to be updated, modified, or tweaked – at *all* – for six to nine months?
Edward Caissie 5:57 pm on January 24, 2011 Permalink
I think “need” is rather subjective in this case when we are discussing requirements that will have to be taken into consideration. Personally I have a “need to update, modify, or tweak” my themes every three to four months but these edits are not always required to be made … sometimes they’re just nice to do.
Chip Bennett 6:05 pm on January 24, 2011 Permalink
Oh, I’m speaking entirely subjectively here. It is, in part, about the “warm fuzzy” users will feel, knowing that the Theme they currently use is actively being tended to by its developer.
And if a developer isn’t bothering with even the “nice-to-do” updates, he certainly isn’t bothering with the “must-do-to-keep-current” updates, either.
Peter Westwood 6:18 pm on January 24, 2011 Permalink
Default
Frumph 12:55 pm on January 25, 2011 Permalink
Let’s try that question again
“Is there a theme developed that is so perfect that it doesn’t need to be updated to the current revision of WordPress that was created pre 3.0 release?
Devin 6:21 pm on January 24, 2011 Permalink
I think this is an excellent idea that will bring up the quality of all themes in the repository.
I’m also wondering if there’s a way to help out theme developers with this process. Here’s some thoughts:
1) Develop a way for themes to be adopted.
2) Give SVN access to themes and allow other developers to submit patches
3) Would there be any way to programmatically suggest patches? For instance, when a function is deprecated and replaced- perhaps a patch could be automatically created for every theme that needs the update so the author could more easily commit it.
4) Failing #3, perhaps an automated e-mail could be sent out to the theme author letting them know which functions in their theme have been deprecated or certain functionality that has changed. This might even just be updating the theme checker with the new data, running all the themes through it, and sending out the automated e-mails.
Chip Bennett 8:24 pm on January 24, 2011 Permalink
I don’t think core developer or WPTRT resources would be well-spent trying to automate something that the Theme developers really should be responsible for.
All the tools are there, and available for use: Theme-Check, Log Deprecated Notices, Debogger, Admin Debug Bar, etc. These tools will be kept up-to-date, and all a developer has to do, then, is to keep the Plugins updated, and test their own Theme with them.
As for Theme adoption: I’d love to get some kind of program like that going. There are a lot of Themes in the Repository that *look* great, but just need to be updated under the hood.
Theme-SVN commit access: yes, please! (But I don’t think it should be rolled out to every Repository-hosted Theme developer. That kind of access/power needs to have some form of trust/meritocracy structure built into it.
I like the patch idea, though: let Theme developers submit patches for their Themes, and then someone with commit access (e.g. the WPTRT members) can commit the patch. (Of course, updating already-approved Themes is a fairly quick and painless process now, anyway (hopefully).)
jeherve 11:33 pm on January 24, 2011 Permalink
I like the idea. Such practice would help having higher quality themes in the repo for sure.
I am a little worried though: do you have a way to estimate how many of the themes in the repo have not been updated since 2.9 went out? Having too few themes in the repository would have a really bad image for WordPress in general, since the available themes is probably one of the first things the newbies have a look at before totry the software. What do you think?
Chip Bennett 11:42 pm on January 24, 2011 Permalink
I can tell you exactly (well, approximately) how many Themes will be left.
Right now, there are 88 pages of Themes, with 15 Themes per page, for a total of about 1,300 Themes in the Repository. Blanket suspending Themes not updated since before WordPress 2.9 was released would suspend everything after about page 30. So, that would leave about 450 Themes in the repository.
That’s a significant change, but:
1) 450 Themes is still a TON of Themes
2) Any one of the suspended Themes could be made live again, simply by being updated.
jeherve 9:28 am on January 25, 2011 Permalink
Ok, that’s a lot of themes, I expected much less!
I am all for the idea then!
esmi 10:36 am on January 25, 2011 Permalink
Since so many have now commented, I’ll try to keep this short.
1) Yes to the removal/suspension of themes that haven’t been updated for at least 2 major releases. Users probably expect Repository themes to support the latest & funkiest features in WordPress, so let’s not confuse them by housing older themes that don’t even come close to that.
2) I was also going to suggest an adopt-a-theme project. It could be a great resource for newer developers who don’t yet feel confident enough to build their own themes from scratch.
Lance Willett 9:09 pm on January 27, 2011 Permalink
What about not removing any themes but adding a big notice to the theme page near the download link that explains that the theme is not up to date? People who really want it can still access it; I think it’s valuable to have older themes around if nothing else than for posterity sake.
Of course having the out-of-date themes in a separate listing or repository would work, too—but we should be able to access them forever, even if they go extinct.
I love the “adopt-a-theme” ideas presented above, that would be a great solution to abandoned themes.
Chip Bennett 9:31 pm on January 27, 2011 Permalink
My primary concern with keeping them active on the main repository is the tie-in with the WordPress Add Theme UI. If there were some way either to hide obsolete-flagged Themes from this UI, or else to prevent their one-click installation, then perhaps they could avoid being suspended.
If the best answer is to provide a second repository, and a separate listing in Extend/Themes, then let’s go that route.
The intent certainly isn’t to eliminate those Themes forever, but rather to stop facilitating the installation and use of clearly obsolete Themes. (A secondary intent, at least for me, is to raise the reputation of the Repository with respect to the quality of the hosted Themes, and to instill the expectation that developers need to continue supporting and to keep their Repository-hosted Themes current.)
Which, of course, brings us back to the adopt-a-Theme idea.
Frumph 5:49 pm on January 28, 2011 Permalink
I was thinking this exact same thing this morning on what we could do sooner then later. I don’t suppose the bbpress code is up anywhere where we could submit patches ?
I’m not a fan of a second repository. I think we can accomplish this by removing the outdated themes from the regular search queries and having a second search available for outdated themes so the can still be viewed.
This will help keep the themes still being available for people to look back and adopt as well as keeping them from the regular search/download. Also to mention it won’t be a torment of a job to incorporate in comparison to a whole new extend section
Ian Stewart 7:51 pm on January 28, 2011 Permalink
There may be older themes in the repo that are perfectly fine and not in need of any update at all (humor me). Has notifying authors of out-of-date themes been discussed? And instead of simply removing themes that are old, how about automatically running theme check on older themes periodically. If an older theme fails, the results could be sent back to the author in an automatic notification. After 3 notifications and no updates, suspend the theme.
If we were doing that I’d be inclined to voting for decreasing the difference in versions and doing this yearly.
Chip Bennett 9:41 pm on January 28, 2011 Permalink
I would wager real money that you could not find one such Theme… but for the sake of argument: yes, we’ve made initial attempts at contact authors, based on a recent audit of the oldest 200 (or so) Themes. The response was, to put it bluntly, abysmal. Several defunct email addresses, a couple requests to pull Themes, one response agreeing to let Themes be “adopted”, and the rest failed to respond.
Granted, we only attempted to contact developers of Themes that were found to have particularly egregious issues (non-GPL-compatible license or restrictions, spam links, etc.) – but the rest represent, at a minimum, a demonstrated lack of interest in keeping the Theme updated (we only looked at Themes last updated in 2008).
Again: “suspending” isn’t permanent. All it means is that a Theme isn’t visible in Extend until it is updated. (We are also exploring alternate implementations that would allow such Themes to be searched separately and downloaded manually, but not available for direct install in the WP-Admin Add Themes UI, and not visible in the default searches in Extend.)
Ian Stewart 2:17 am on January 29, 2011 Permalink
So you will be contacting authors before suspending themes? I’m not worried about the suspension so much as the notification. As noted above, I think you could do this more often if you were contacting authors first and limiting to known broken-ish themes. Basically, I’d hate to see perfectly good themes drop out of circulation just because the author changed his email or stopped developing on the theme.
Essentially, I’d rather see this be feature/guideline-compliance-based rather than date/version-based.
Chip Bennett 3:56 am on January 29, 2011 Permalink
I would assume that an attempt to contact would be made before suspension.
That said, I disagree in one regard: I think that a developer stopping development of a Theme to be a perfectly valid reason for suspension. I think that the privilege of having a Theme hosted in the repository brings with it a responsibility and expectation to continue developing and supporting that Theme.
Ian Stewart 2:45 pm on January 29, 2011 Permalink
Right. I agree with your disagreement. Except I’d like to see the criteria be for compliance rather than age. I’m thinking (hypothetically) of an older theme that’s perfectly fine, if you uploaded it today it’d pass a review with flying colors, but it’s going to get suspended because it hasn’t been updated in 2 versions and the author is nowhere to be found? That would seem silly to me.
Suspend dormant themes left and right if they couldn’t be uploaded today. But if they’re still OK I’d vote to leave them alone.
Edward Caissie 12:26 pm on January 29, 2011 Permalink
I like the idea of contacting the author multiple times. Which makes me think if this was done with an Automattic (or WordPress.org) email address as an automated process it would be much more relevant to the reader.
Also, some authors may still potentially not be aware of the WPTRT or its members; and, one of us sending these notices from a “personal” email may not be received with the appropriate importance, aw well. Access to an appropriate email address for the WPTRT may also be a good thing to have …