Recently installed themes not available in /wp-admin/themes.php

After purchase, I downloaded boldr-pro

Since this is a paid theme, your best bet would be to contact the theme vendor/developer.

contact the theme vendor/developer.

I started with that… But as I described this is not a theme issue: it occurs with any new theme I add to my setup.

it occurs with any new theme

What happens if you switched to the default TWENTY TWELVE theme?

What happens if you switched to the default TWENTY TWELVE theme?

Twenty Twelve was the default theme in the empty blog. I switched to Twenty Eleven and then back to Twenty Twelve – works fine.

Another admin on this host downloaded a new plugin to the wp-content/plugins directory and found that the aforementioned behaviour affects plugins too: existing ones work well but new ones are not visible in wp-admin/plugins.php

So the issue is not directly theme-related…

After purchase

After purchasing what? These forums do not support commercial products.

After purchasing what ?

After purchasing the Boldr Pro theme – which is GPL licensed by the way, but I felt like paying the author.

These forums do not support commercial products

Of course – and I am sure that you have read the entire thread and that you are therefore aware that this is not a problem with the BoldR Pro theme but with every theme and every plugin newly downloaded in their respective directories.

The architecture that you describe is highly unusual and I suspect that the issue lies within that. It’s certainly not an approach that could really be supported here as you are trying to use WordPress in a manner in which it was never meant to be used. Why not just use Multisite?

We began using WordPress as distributed by Debian in 2004 – Multisite did not exist at that time and we setup the WordPress farm according to what was at the time a good Debian practice. We have been very happy with the setup ever since. If we began anew nowadays, we would certainly consider Multisite… But we don’t have that luxury: our communal host is volunteer-run and we cringe at the thought of taking apart a ten-year old infrastructure that has proved itself. Of course I understand that this does not make it easy for anyone to help us !

We’ll keep poking at our problem… Ideas welcome – we’ll keep that thread posted !

I might be stating the obvious, but have you checked through the error logs for clues?

I might be stating the obvious, but have you checked through the error logs for clues ?

As I mentioned:
– No errors are logged by Apache when loading /wp-admin/themes.php
– When activating define(‘WP_DEBUG’, true); in wp-config, no error message related to themes is seen in /wp-admin/themes.php

I’m now going to deploy a pristine WordPress from the upstream www.ads-software.com distribution. Its behaviour regarding themes will let us know whether the culprit is our WordPress setup or the LAMP stack underneath. Attempting to initiate a WordPress instance in our farm with the invisible theme already in place might be interesting too… I’ll let you know the results later tonight ! But first, let’s feed my five girls…

Attempting to initiate a WordPress instance in our farm with the invisible theme already in place

Setting up a new instance from scratch, same behaviour as observed before: the recently put in place theme is not available in /wp-admin/themes.php

Deploying a pristine WordPress from the upstream www.ads-software.com distribution

Setup WordPress 3.6 in an empty and gave it a wp-config.php pointing to an empty database. Loading the administration interface got me a “PHP Fatal error: Call to undefined function nocache_headers() in /wp-admin/admin.php on line 32” in error.log… So I commented out the offending line 32 “nocache_headers();”… Reloading then gets me “PHP Fatal error: Call to undefined function get_option() in /wp-admin/admin.php on line 34”. So WordPress 3.6 seems to be unhappy with the PHP environment. I tried with a fresh WordPress 3.5.2 – same result. Strange – our PHP environment is not that bad, by far.

Something I have always done is reusing old wp-config.php files. Let’s try something different and let the WordPress setup generate one for us ! Surprise: it works. Added themes are detected too – both with 3.6 and 3.5.2

I copied the 3.5.2 generated to /etc/wordpress with the proper conventional name for the desired vhost… And it works: new themes and plugins are detected, I can switch to Boldr Pro, scantily clad nymphs gallop accross the rainbows on pink unicorns… Perfect !

And the morale of the story is: good old wp-config.php that has lived a decade across many WordPress versions may not be good anymore nowadays… Let WordPress generate a new one for you ! Might some higher power want to mention that in documentation somewhere – or even make wp-config.php verification and update part of the upgrade automation ?

Thanks to everyone who suffered through my troubleshooting process – esmi, Tara, iceable along with my pals Saturnin & Vador by mail: you may not have brought the solution, but having people to bounce ideas against helps immensely.

Meanwhile, I’m happy to see that though burnished by the ages, our Debian WordPress architecture is still as valid as ever !

Now let’s catch some sleep…