Jean-Marc Liotier

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 ww.wp.xz.cn 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…

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 !

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…

Found the answer… My YARP Experiments plugin was still at 1.0 – I updated to 1.1 and this problem is now solved.

I guess that this topic will provide good search engine fodder for people with the same problem…

http://codex.ww.wp.xz.cn/Template_Tags/trackback_rdf explains that wrapping the tag in an HTML comment tag is needed to avoid issues with validation.

But that does not make it much clearer to me : either trackback_rdf() is not evaluated, of the HTML code generated is not interpretated… Either way makes little sense to me. Or is the generated RDF read by its users applications even if it is inside comments ?