In WordPress 2.7.1 (and probably previous versions), the admin page that allows for theme activation has some behavior that you might find sub-optimal in certain conditions.
Today I was setting up a site and wholesale replaced the default ‘wp-content/themes’ directory with a ‘wp-content/themes’ directory checked out of our SVN. This removed the default theme (Kubrick) and left only the theme I was working on for the site.
For some reason, the theme admin page did not show any themes – it took me about 20 minutes to trace the code to figure out what was going on.
The wp-admin/themes.php file has code at line 139 that checks to see if more than one theme is present:
if ( 1 < $theme_total ) {
If more than 1 theme is found, then the grid of themes is shown so that you can choose between them. However, in my situation I had deleted all other themes leaving just 1 theme but had not yet activated that theme. With this edge case, no theme is active, and there is no way to select the 1 theme that is in the 'wp-content/themes' directory.
A workaround is to change that code to:
if ( 1 <= $theme_total ) {
or to upload another theme. Then you can select the theme you need, and you're good to go.
I've opened a bug for this here, so I'm sure this will be fixed in the near future. Hopefully this information will be helpful to someone else who runs into this situation in the interim.
UPDATE: I did search Trac, but apparently not well enough. Original bug here for those wanting to review.
Ahhhh…. thank you! Did that a couple of weeks ago and thought I’d gone mad.
Yeah, thanks for submitting a trac update. I’ve known this for some time (I think it was the same case in 2.6) but never really looked at core to see why, instead I just kept the default theme in the directory.
aha…tks.I can do something in my blog.
What if the one theme had been named ‘default’? Would that make a difference?
Of course the problem with that is that a future upgrade could wipe the custom theme out.
If the theme had been named “default” it may have tried to activate it as the fallback.
That would be my guess (haven’t tried it). But still, not a really acceptable work-around except as a short-term bandaid. A patch covering the ‘no default theme’ case is definitely in order. 🙂
That is good to know. I have got myself in similar binds being a little too frisky in FTP or the db.
I always leave a default theme in every site in case things go ‘a foul’ (or is it fowl?).
I label the extra theme as “recovery”. Some recent WP sites I have made are SO complicated that I had to have an alternate theme to help in the debugging.
Thanks for dropping the bug in the system.
Best practice is to leave the default theme. It is always handy to be able to check problems with plugins by a quick install on the default theme versus your own custom theme.
Checking for problems with plugins should be done on a local environment or on a dev server – not on a live web site.
I had this problem myself and also found the same work around. I’m baffled why WordPress haven’t thought of implementing this.
Actually, this behavior has been changed and is worked into 2.8. You can see the change here: http://core.trac.wor[...]ngeset/11008
BTW, I agree – this was long overdue. I’ve had my own issues with it previously. It’s nice to have a fix so I don’t have to modify every WP install I have 🙂