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

  • Resolved Jean-Marc Liotier

    (@liotier)


    10 years, 7 months ago

    I’m preparing to cower in shame as I realize I have forgotten something atrociously obvious, but for now I’m stuck and out of ideas…

    This is not a Multisite setup, but an install from the Debian package (WordPress 3.5.2 in Debian Wheezy). With this type of setup, users spawn a WordPress instance by dropping their wp-config in /etc/wordpress and specifying /usr/share/wordpress as DocumentRoot for the vhost. They all share themes and plugins – the distribution takes care of updating WordPress… The only limitation is that we don’t allow updating themes and templates from the Web interface, but we consider that a feature, not a bug. This is not the native WordPress way, but it has served use well on this host since 2004… Which makes the current problem even more vexing.

    After purchase, I downloaded boldr-pro.1.2.0.zip to /usr/share/wordpress/wp-content/themes – then:
    unzip boldr-pro.1.2.0.zip
    chown -R jim:www-data boldr-pro.1.2.0
    find boldr-pro.1.2.0 -type d | xargs chmod 755
    find boldr-pro.1.2.0 -type f | xargs chmod 654
    mv boldr-pro.1.2.0 boldr
    The usual…

    But at /wp-admin/themes.php the theme does not appear in the list of the available ones. This is especially strange since /wp-content/themes/boldr/style.css or any other of the theme’s files are available from the DocumentRoot of any of the WordPress instances on that host. No plugins are active.

    Two separate admins have reproduced the problem with two other randomly chosen themes among the popular ones on WordPress.org (Cazuela and Responsive) – so the problem higly unlikely related to packaging or unpackaging. I have checked that the resulting files do not contain artefacts such as DOS CR/LF. There are 41 themes in /usr/share/wordpress/wp-content/themes used by about half that number of instances – the only themes not available in /wp-admin/themes.php are the newly installed ones (boldr, cazuela and responsive)… This has been retried several times.

    Other symptoms:
    – Changing metadata in style.css in a theme that is recognized is well taken into account in /wp-admin/themes.php
    – 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
    – Copying a theme successfuly used by one of the instances and changing its style.css metadata to avoid conflict, the theme is not detected (just like a newly installed one)
    – When moving a theme successfuly used by one of the instances out of /usr/share/wordpress/ the theme is no longer available. Moving it back in place, it is correctly detected and available.
    – ‘find . -name style.css | xargs head -n 2 | grep “Theme\ Name” | grep BoldR | wc -l’ returns ‘1’ so there is no name conflict.

    We recently upgraded the host to Debian Wheezy and we suspect this may be related, but that may just be a coincidence.

    Is there something that escaped me in the sleep-deprived haze of the recent opening of my wife’s brick’n’mortar shop ? Some other users in other places seem to have encountered situations ressembling this problem, but it does not look like a FAQ… Three of us old farts here are left puzzled.

    I’ll try anything you suggest… I have the wife on my back !

Viewing 11 replies - 1 through 11 (of 11 total)
  • Moderator t-p

    (@t-p)

    10 years, 7 months ago

    After purchase, I downloaded boldr-pro

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

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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.

    Moderator t-p

    (@t-p)

    10 years, 7 months ago

    it occurs with any new theme

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

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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…

    esmi

    (@esmi)

    10 years, 7 months ago

    After purchase

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

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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.

    esmi

    (@esmi)

    10 years, 7 months ago

    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?

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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 !

    esmi

    (@esmi)

    10 years, 7 months ago

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

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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 wordpress.org 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…

    Thread Starter Jean-Marc Liotier

    (@liotier)

    10 years, 7 months ago

    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 wordpress.org 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…

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Recently installed themes not available in /wp-admin/themes.php’ is closed to new replies.