Themes (custom/derived/new) are disabled at random intervals

I'm having the exact same issue. Some explanation as to what particular part of the 'design' spontaneously disables the theme would be appreciated.

Themes being randomly disabled isn't by design, but I think the problem needs to be narrowed down so it can be reproduced.... I've certainly never seen this happen before in Drupal 7. What are the steps to reproduce? Does it only happen when a particular contrib module is enabled, for example?

After a fresh Drupal install I've fiddled around with a couple of themes by copying them and removing them from the "sites/all/themes" directory.

I'm not sure what this means exactly, but if you temporarily remove a theme from the filesystem then I think it will become disabled eventually. (Drupal can't use a theme that isn't there, so it treats it as disabled.)

I am getting this problem, but only on certain environments including production :(

It is impossible to reproduce, but one way I can *almost* consistently reproduce it on my environment is to

(1) run cron
(2) wait 45 minutes with no traffic on the site
(3) visit the site.

My client's security advisers asked us not to drush to run cron (don't ask), and running cron via http runs into timeouts simetimes, so I devised this little script, which seems to trigger the problem in the steps above:

$_SERVER['HTTP_HOST'] = 'localhost';
$_SERVER['REMOTE_ADDR'] = '127.0.0.1';
$_SERVER['REQUEST_METHOD'] = 'GET';
$_SERVER['SERVER_SOFTWARE'] = 'Apache/2.2.2 (CentOS)';
define('DRUPAL_ROOT', '/path/to/drupal' );
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
drupal_cron_run();

I actually need to include a closing php tag in this script, or else some php tracking software on the client's system breaks. I noticed a few hours ago that there was a space after the closing tag, and I removed it. Haven't had the problem since.

FWIW: I'm seeing this behavior, along with some other similar behavior (views style plugins become unavailable, nodes rendered via nodeblock are empty), but it doesn't seem to be triggered by cron as such (though it will be triggered by elapsed time, and the elapsed time required is definitely greater than 45m). The problems clear up when certain caches are cleared, but it's not the same cache for each problem. For nodeblocks, it's the Class Registry cache; for the views plugins, it's the 'Page and Other' cache; for the themes, I haven't isolated which specific cache needs to be cleared.

as with alberto56, i'm only seeing this on some installs, which share a webserver and database server with installs that do not show this behavior.

EDIT: May be a cron relationship. It looks like every other cron (but only every other cron, not every cron) was failing due to an 'invalid key' error. so it's possible it's related to FAILED cron jobs on this system. Need to wait to see.

EDIT2: I believe that in our case this was being caused by a failed cron run. we had a legacy cron job that didn't use a key; removing that caused this and other similar problems to stop. I haven't determined why the error was thrown only every other run, though I conjecture it was due to the initial failed cron triggering a Poor Man's Cron run, and that about half the time the PMC run would get initiated before the system cron call was executed. So I expect to find, based on this, that where I'm seeing it I've got a legacy cron job running without a key.

Look at the system database, especially the 'variables' and 'system' tables, before and after the error. They might offer a clue. Also I assume you didn't find any useful error messages under admin/reports/syslog.

sorry, missed this before i edited my original comment.

No, useful errors were not forthcoming, except for the cron error - which, hopefully, is telling me (hopefully us?) where the proximate cause was.

I was mistaken; this problem was not resolved on our dev site after all (though a similar problem -- disappearing views formatting plugins -- does seem to have resolved itself.)

I'm not sure what I'm looking for in the variables and system tables. I can see that the theme is definitely getting set to 'disabled', which is consistent with the fact that I haven't been able to restore it by clearing caches.

I'm now testing to see if it will disable any theme that's been enabled, or if it's just themes in this family.

I thought looking at the system table would help determine if it is a cache problem. Since the database shows the theme as disabled it is not likely. Make sure all the theme .info files in your chain of themes(base, sub-, etc.) is syntactically correct. Many .info file errors are never flagged but will produce errors during processing. For example, leaving out the NAME element will not be flagged but will later produce an 'index' error.
Also, theme entries are never removed from the system table. You can delete the files but the entries are still in the table. Adding, then deleting, and then adding either the same theme or a new theme with the same name can produce mixed data.

I tested to see if the random disabling would happen to another theme by enabling Garland and waiting. After that, neither Garland nor the new theme were disabled. So I disabled Garland, and waited, and now it seems to be leaving the theme alone. So I'm conjecturing for the time being that the act of enabling another theme that was not a child or sibling theme caused some change(s) to theme variables.

Your suggestion re. .info variables may get to the cause (though I'll never be able to tell, now): When I first forked this subtheme, I had neglected to change the "name" value in .info.

One thing I had not tried through this process (because getting failures was so time-consuming) was to just delete the database record for the new theme; I now suspect that would have resolved the issue.

still haven't found a resolution for this. I've deleted records for the new theme from the system table; theme is still getting disabled periodically.

I can't see any errors in the .info. It's a direct copy of another .info, with the theme name replaced by search & replace (i.e., it was replaced in a uniform fashion throughout). I've read through it and can't see any problems.

Also, I can confirm that it's not happening on my local dev system -- only on the dev/staging site on our production server.

Getting bad. The site will disable the base theme and, in the process, lose all block settings for that theme.

Still seeing only on one (dev) site. Will probably have to rebuild that site from scratch before I figure out what the cause is, so may have to leave this unresolved.

Same problem here on our first install on an IIS server owned by a client (Drupal v7.23). To mimic CRON we asked our client to create a scheduled task for WGET to request the CRON over HTTP every 3 hours. This often results in the site forgetting which theme was enabled, visiting admin/appearance repairs this fortunately.

As a test our client disabled their scheduled task and we created scheduled tasks on a W7 workstation for as well the local as the online dev site. The CRON scripts were executed successfully every 3 hours for a week, the theme settings always stayed in tact. Today we disabled our local scheduled tasks and asked our client to enable theirs and later today the theme was disabled again!

This so does not make any sense.... Does it?

No resolution found after all

I thought I would join this discussion since I'm experiencing the same issue on a site that we just launched... No clue what is happening, but this thread made me feel good that I'm not alone here. Anyone have any updates, solutions, discoveries? I'll keep looking into this as well.

UPDATE:
I found the issue, at least for my case... This was occurring because I had my multi-site sites.php file with incorrect options. Since one of the site options was incorrect, Drupal would look for the theme for that incorrect site and wouldn't find it, thus disabling the theme, before rendering the page.

@rp121: Were the incorrect site options specific to your setup? Maybe others could learn from them.

In hindsight in our case it could have had something to do with incorrect writing rights of a sites/all/translations folder. A scheduled task executed CRON which updated the site, downloaded translations and failed at saving them in this folder. I remember there was something about this in the logs at times the theme was forgotten (always check your logs!), so this might have been the problem, but I am not sure at all.

We moved to a CentOS server (which our client already had running) and this problem and other troubles were solved. Best of luck to all others!

@lmeurs at least in my case, the sites.php file had sites defined as:
$sites['www.mysite.com'] = 'mysite';
$sites['dev.mysite.com'] = 'mysite';

However, the site was also accessible through mysite.com without www, and I believe that is where the issue was occurring for me since mysite.com was not defined in sites.php. I added some code to the .htaccess file where it will always redirect mysite.com to www.mysite.com and I have not yet experienced this theme issue again (knock on wood).

Hope this helps.

Same problem here.
Site disables the them after some time, but it still is listed as the default theme (just in the disabled row). Problem started when I moved the theme from the /all directory to the /site directory.

Anybody any idea's?

Found out I had misconfigured my cron jobs (did not adjust it going from 6 to 7, so no key). After making sure that worked ok, no more problems. Strangely I could see cron ran at some points before on the status page.

Hope it helps somebody

A similar Drupal 6 issue existed: #305653: Themes disabled during update. I suspect that multisite installs / installations with lots and lots of modules (longer time in _system_rebuild_theme_data()) may be more prone to experiencing this, but that's easy to say - any site with more modules has a higher chance of experiencing bugs ...

I am guessing it's triggered by calling cron twice (or more) simultaneously on the one site. If it's still a race condition then other factors (eg high load, backups running) will also come into play.

EDIT: The instance that our client saw this issue, cron was being called from Drush and there was a second alias pointing to the same site root but with an incorrect and invalid uri. The second alias used a URI which had the directory but no settings.php. I suspect that theme discovery may have used the (incorrect) sites directory without a settings.php, and this resulted in the themes being disabled.

+ drupal
   + sites/default/
     + settings.php
   + sites/example.org
      + (no settings.php)

Probably not going to look further into that, since bad configurations aren't a supported use case :)

Cross linking:

1. #1272328: Theme is randomly disabled
2. Stackoverflow: "Drupal Themes getting “unselected”"

In a multisite environment we had not installed the default site at first. Because of this Drush occasionally generated warnings or errors, so we added a settings.php file to the default site's directory with database credentials of a test site's database. Since we installed the default site with it's own database, the problem fortunately has not occurred anymore. :-)

It might have had something to do with multiple crons being executed on the same database at the same time...?

Not sure this will be relevant to the overall problem, but this popping up in my email reminded me that I figured out the source of the problem on my site: We had two codebases hitting the same databases. There were modules that weren't at the same version level, and that was breaking some settings in the database as soon as cron ran on the legacy codebase.

That doesn't sound like a likely cause for the originally posted problem, but it could be something similar.

This happened in our Drupal multisite project. On site A the main theme was being disabled randomly. The problem was that we had a symlink from one site folder to the default site folder. Site folder had following sites

• default
• A (settings.php symlink to default/settings.php)
• B
• C

The A site had a settings.php symlink to default/settings.php. Unlinking the symlink and creating own settings.php to site A resolved the issue.

I am following this too.

I have created a new theme and added and enabled as a default theme. As far as theme is concerned I have created from scratch adding one thing at a time (i.e. .info first, then page.tpl.php with only available variable display only then to a html layout, then added style.css followed by template.php. All added one by one.)

Every time I come back to this site in the morning I get this error too:

    Notice: Undefined index: {mytheme} in drupal_theme_initialize() (line 100 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _drupal_theme_initialize() (line 146 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_load_registry() (line 335 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_load_registry() (line 319 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Trying to get property of non-object in _theme_save_registry() (line 343 of /var/www/drupal-7.31/includes/theme.inc).
    Notice: Undefined index: {mytheme} in theme_get_setting() (line 1431 of /var/www/drupal-7.31/includes/theme.inc).

And this theme is deselected. I do not think cron runs at midnight everyday on this server I am working on, but I do run clear cache and update script, cron etc. during the day. Someone was saying this too, and I also think a moment of inactivity seems to matter to this too. I really want to rectify the issue but I have not got a practical way to recreate the issue as granting the condition to recreate the issue is so narrow.

Can one of the affected admins please update the issue summary with steps to reproduce?

Ok, I followed up this morning a bit more about what happens before I load the first page of the day. Looking at this error message:

Notice: Undefined index: {mytheme} in drupal_theme_initialize() (line 100 of /var/www/drupal-7.31/includes/theme.inc).

And the error is generated at line 100 in includes/theme.inc, which is:

_drupal_theme_initialize($themes[$theme], array_reverse($base_theme));

I believe the error generated on:

$themes[$theme]

Which is in my case:

$themes["mytheme"]

Because $theme variable eventually obtains "mytheme" as a value. I can see from printing the variable in this initialising function that it certainly was "mytheme". Then what I can look at was what contains in $themes. I kept following up on how the variable get assigned and I see that it goes like this in the initialising function:

$themes = list_themes();

Then in function list_themes:

$themes = system_list('theme');

function system_list comes from includes/module.inc and seeing the function definition for system_list, I can see it runs and returns the result for the following query:

$result = db_query("SELECT * FROM {system} WHERE type = 'theme' OR (type = 'module' AND status = 1) ORDER BY weight ASC, name ASC");

And it does not contain "mytheme" in the result. Clearly, if there is no entry for "mytheme," this does not provide any details when $themes["mytheme"] was called.

By this point, I reload my first page of the day, and I can see that the SQL query above now contains "mytheme", which normalises this particular error I receive every morning. If I remove this entry, I can re-create the error. (However, the entry does not return anymore in system table after then. Maybe, something to do with caching?)

I have no idea how the entry gets removed or added in system table. So, I can't really tell why the entry is removed at some point.

@kotoponus +1 for all the information. That should really help.

I looked through the issue queue at some similar issues and I wonder if you can check over the theme info files on your system for anything "odd".

And could you post the theme files of the new custom theme on pastebin or gist?

@cilefen Ok, let me see what I can do. I will make this as small as I can as there are rather a few files and I only want to make this error with the smallest set of file(s) possible. I may need a few days to do this, as my window is only once in a morning. Bear with me and will get back to you just as soon as my examination is fruitful.

@cilefen
Here are the info and page.tpl.php files:
https://gist.github.com/kotoponus/2d50bac61ced76938e66

I can confirm that this theme with these set of pages again removed the entry from the system table over night. Hence, when I loaded the first page of the day (front page), it gave me the same error message. (I also have the icon file too although it is not in the gist.)

I made info file based on:
https://www.drupal.org/node/171206

Then added custom regions I wanted for my purpose.

Then constructed page.tpl.php using all the variables mentioned here:
https://api.drupal.org/api/drupal/modules!system!page.tpl.php/7

And then added more relevant HTML to my theme on top.

Also, from my observation yesterday, I have established that clearing cache, from admin/config/development/performance, reinstates the theme even there is no entry in the system table, which suggests that reloading page first thing in the morning would do something similar to clearing cache.

BTW I am on version 7.31.

@kotoponus Are you aware that 7.32 is an important security release?

1. Is the theme installed in sites/all/themes or in a site-specific folder like sites/example.org/themes?

   If the latter, and if the site is accessible at more than one URL (such as example.org and example.com) then if a visitor to example.com happened to trigger a theme rebuild that could certainly cause the theme to be disabled (that seems to be what happened in #27).

   A custom cron script would be particularly susceptible to this because a cron run clears caches and could sometimes trigger a theme rebuild, plus the fact that custom cron scripts sometimes use a non-standard URL to hit the site (e.g. http://localhost).

2. Otherwise, does the theme have the same machine name as a module on the site? This can cause all sorts of problems (https://www.drupal.org/node/143020) - I've heard of it causing the module to be disabled so it wouldn't surprise me if the theme could be too.

Checkout if https://www.drupal.org/project/subprofiles is used. I stopped using it because I found other issues and this can be related. In (an older version of the module) during drush up etc. the parent profile including all it's module and theme dependencies under it's profile folder are not found. Sme goes for all hooks o the parent profile. Possible that this is fixed for the latest version of subprofiles but for me it's out of interest already.

@cilefen
Thanks, I am aware that there are higher versions available although I was not aware that the latest ones were serious security updates. I am only proving a concept to see if I can port the current D5 site to D7 on my PC behind the corporate firewall, so I am not too worried about the security at the moment. But thanks.

@David_Rothstein
Thank you for your comment.

1. The theme is at sites/all/themes/mytheme/. I have not got a domain name to go with this site. So, essentially I am either using localhost or a static IP to refer to the site. I have not yet got a custom cron, as far as my own customisation is concerned. (Should there be something I should be aware of for crons in terms of contributed modules?)
2. The theme name does not over wrap with any module names. It stands unique on its own.

@mvonfrie
Thanks for your input.
I have not got that module set, and this is not a sub theme either. It is a theme set on its own right, intended to be developed from a scratch.

Thanks for following up on my questions. In that case, unfortunately, I am out of ideas :(

Just came back from my holiday. I started the holiday from the 10th. No one saw the site as you can see from the log that there was no visible request. On the 11th in midnight, it runs mid night and from there on the cron only runs on the midnight only. By the midnight cron on the 12th, the theme is lost. I presume that the theme was lost on the 11th midnight cron. I will follow what happens in the mid night cron a little more.

kotoponus, out of interest, two questions:

• How are you calling cron? eg /etc/cron.d/example-org contains

  0  0  * * *  www-data  curl http://example.org/cron.php

• What path is your theme installed to? eg ...
  

  /themes/mytheme
  /sites/default/themes/mytheme
  /sites/example.org/themes/mytheme
  /sites/all/themes/mytheme
  

If it's not in the last position (placed in sites/all/themes), would you try moving it there and see if the issue persists?

I've got a hunch this feels like either a race condition in the rebuild function (because this rings a bell) or that your cron is rebuilding themes from a location that doesn't "see" the theme, causing it to be disabled. (Eg cron fires using config from sites/default, theme is in sites/example.org, theme is excluded from list of themes when rebuilt.)

Haven't seen this bug in years myself.

See my question in #36 and the answer in #38 - it's in sites/all/themes/mytheme. (Worth confirming there is no other copy of the theme somewhere else though.)

It also sounds from that answer like cron is being run via the built-in core feature, e.g. every few hours or so when someone visits the site (not via the command line)? Worth confirming that too.

It also sounds from that answer like cron is being run via the built-in core feature, e.g. every few hours or so when someone visits the site (not via the command line)? Worth confirming that too.

Actually based on #40 I guess not - there must be a command line cron script running somewhere.

Hi, xurizaemon, David_Rothstein,

Thank you both for your reply.

In order to eliminate likely factors which can cause this abnormal issue, today I have done the following actions (apologies in advance that there are some oops as I went about doing this):

1. Upgraded the Drupal to 7.38
2. Rebuilt the database to the fresh install state
3. Everything stayed as a vanilla install, retaining all the default themes and just added my theme so no added contributed modules to affect any behaviour.
4. Cleaned up other instances of Drupals (e.g. set aside copies and other versions) so that Drupal 7.31 is the only Drupal in /var/www/ as well as /home/me/public_html. (I am the only user on this box.)

Here is the oops part:

1. Reviewed the cron jobs and realised that we have under root:
   0 0 * * * curl -s http://localhost/drupal-7.30/cron.php?cron_key={old key}
   So updated to:
   0 0 * * * wget -O - -q -t 1 http://localhost/drupal-7.38/cron.php?cron_key={the current key}

So, the cron job which is running at mid-night is running a wrong version of the cron.php after all as it existed in the curled location and I was on 7.31. Thanks xurizaemon for getting me to check this very fundamental point.

I can see that "mytheme" still in system table in after running the correct cron. As far as I am concerned all the factors which can contribute to abnormal behaviours are eliminated, I will leave it as it is over night and see what happens tomorrow morning. If this does not delete, I should blame myself for keep running the old cron. If it is removed, we now definitely know that the problem relates to how my theme is set up. I would like to believe that the problem is the earlier. I shall keep you posted.

Hi, cilefen, mvonfrie, xurizaemon, David_Rothstein,

Thank you very much for all your help in trying to find out what causes an issue. It seems the issue is now resolved i.e. cron at mid-night no longer deletes mytheme. Hopefully, it will continue to be so as I add more contents to mytheme. :)

I am glad to hear it!