Main theme lost

I have a similar issue occurring, but I'm not sure this is dependant on the cron-job.

But I get from time to time the exact same Warnings and the custom theme is broken. Flushing all cache helps.
On the administration page with the list of themes also the checkbox for my main theme is not set, although it is the default theme.
Also the link for configuration of this theme is not present until I check the box for theme activation and save.

I use Drupal 6.14 with the module administration theme. The admin-theme is set as Garland and the theme selected for frontend is a custom theme based on ninesixty.
The custom theme is pretty simple so far. Since the code on line 1771 theme.inc is dealing with regions, I already checked the correct settings in my info file and page.tpl.php and that seems to be o.k.

Having the same problem. Is anyone looking into this?

It's possible that at least one of the theme's .info file is not declaring the regions array properly.
eg

regions = footer

instead of

regions[footer] = footer

Look at all the themes, not just the enabled ones.

I looked at all themes, except the core-Themes.
If there were regions declared in the info-file, the declarations were syntactically correct.

The only contributed themes installed in sites/all/themes were ninesixty and zen.

Since the site is running still in a non public environment, all caching is disabled. BUT clearing all caches(via the menu entry in administration menu) solves the problem until it comes back again after e few days.

The last two occurences were October the 7th and 10th, so there is 3 days in between, what can possibly be executed 3 days time apart only?

What type of error causes the checkbox and the configuration link of an active theme to be deactivated, although a theme is set as default?

my theme disapeared as well without any apparent reasons. i have to upload to Drupal 6.14 though i don't know whether i should not first fix this theme issue before upgrading.
Having gone to the admin/theme menu, the page shown is completely different from what it should be..

If anyone can help, it will be much apreciated.
Thanks.

Hi again,
it looks like it is linked with the region menu.
When accessing the blocs menu through admin panel the following error msg comes up:
Fatal error: Unsupported operand types in /..../modules/block/block.admin.inc on line 39

Thanks for any help, i am fully confused.

subscribe

@asimmonds: That's not the case.

And the problem seems to appear randomly, not only when cron is run.

I don't think that 419 wanted to be assigned to solve this issue, so I reset this.

Could some of you please tell, what themes you are using, may be that will be a lead?!

Right now I am using 0-point, but I have also tried with Zen, Adaptive Theme, Genesis, and some others - the problem still remains.

I turned off "Update status" and the problem seems to have disappeared... Strange...

o.k. disabling the Update Satus module is a workaround also for me, but after reenabling the problem with the broken theme is reappearing.
I have a duplicate of a site on a testserver and only on the duplicated site(made with backup/migrate and a copy of the files) the problem is occuring.
What i notice, is that on the original functioning copy of the site, the are update status entries in the update status page for both the base theme (ninesixty) and my custom theme based upon it.
On the duplicate site where the theme always breaks, there are no entries in the update status page for these themes.....
Also the fact that the custom subtheme used as default by the site is not checked as enabled on the theme list page is a hint...

Somehow the themes are not correctly "registered"?

Maybe something on the other server is different in terms of apache or file attributes or the database import by backup/migrate failed to create all inserts correctly, but I did not notice anything so far?
Any of you used also backup/migrate to import the DB?

Same issue here occurring several times a day on 6.15

Subscribing - same issue with 6.15

I am having the same problem with 6.16. At first I thought it was related to the cron, but I disabled cron for a few days and the problem still occurred. I see scattered notes about update.php causing this, but that wasn't the case for me either.

I did notice that anytime I ran the Update Status function, the theme would be fine as long as all modules were up to date. If anything needed to be updated, the theme would disappear.

I've disabled the Update Status module for now. Hope it works...

subscribe

It's just a hunch, but I noticed I hadn't placed an email address in my status update settings page. Hoping this will correct the problem. I have to wait until cron fires... as self running NEVER causes the problem..

Subscribing

we're having the same issue. when i try to fetch the update status information manually then i end up redirected to an error 500 page.

the only module that i'm using that i usually don't use is flashvideo. anyone else using this?

Hello!

Just wanted to weigh in with some of our findings on this; we've observed this issue for awhile now on several of the sites we host, and although we haven't pinpointed the problem yet, we have lots of technical details on symptoms :) Here are the facts (in our situation):

• When the issue occurs, all of the themes installed in "profiles/cws_d6/themes" are deleted from the system table. Technically, the "untskin" theme (which is installed in profiles/cws_d6_themes) is still set as the default theme (via the "theme_default" variable), but Drupal doesn't think it exists until after a cache clear forces it to re-discover all its .info files.
• The theme can be restored in one of two ways (that we know of):
  • Run "drush cc all"
  • Log in as an administrator and visit the "Site building > Themes" page.
• All of our affected sites are running Drupal 6.16.
• The issue almost has to be related to the update module's implementation of hook_cron; supporting facts:
  • We run cron every fifteen minutes; this problem always seems to occur at the 1:00 or 1:15 cron run, which takes about three seconds longer than most other cron runs. We've been able to duplicate the timing by clearing out the update module's caches and manipulating the update_last_check variable (however, we haven't reproduced the problem by this alone).
  • When the problem occurs, the mysql bin logs indicate two distinct runs of the core update_get_projects() function, which first runs module_rebuild_cache() and then runs system_theme_data(). The latter is where the bug occurs; on the first run, all system theme table entries are cleared and then regenerated properly; on the second run, all system theme table entries are cleared, but the entries for the themes in the profiles directory are NOT regenerated.
  • When we force update to run by manipulating update_last_check, the global $profile variable gets assigned a value during update's cron hook. This is interesting for a couple of reasons:
    • system_theme_data() populates the system table via a call to drupal_system_listing(); drupal_system_listing() would not scan the profiles directory iff the global $profile variable happened to be set to something other than the intended profile (however, even when $profile is assigned during the cron hook, it's assigned to the correct value …so this may not be relevant).
    • The global $profile variable, according to source comments in drupal_system_listing(), is only supposed to be set during the initial site installation process. However, it will also be set during any run-of-the-mill run of drupal_system_listing(). That could be important, especially if some other condition caused the "install_profile" variable to be set incorrectly…?

Sorry for the crazy brain dump, but I think these details are all relevant; the symptoms you all have described are very similar to what we're experiencing, so I thought these extra details might help.

One question, though …have any of you observed this problem happen for themes that aren't stored in the profiles directory?

Thanks!
Adam

I've applied the patch at http://drupal.org/node/307756#comment-2819478 to one of our problematic sites - haven't gotten any data back, as we only see themes get disabled once a night. (I work with jazzslider) I would be curious to hear if that patch helps anyone else experiencing this issue.

Update: the site @acrollet patched still got screwed up last night, so that patch isn't really a solution to this problem.

Just in case it helps anyone else - here's a link to the solution for the problem @jazzslider and I were experiencing, it was happening when drush updatedb (and update) were being run: #806190: drush updb removes themes under /profiles from the system table

we seem to have pinned this issue down to a combination of two things:
-on websites where we run cron via the CLI mode of PHP
-on websites where the update status module is enabled

only under these two situations we notice the problem to occur

We are experiencing exactly what is detailed in #25. While disabling Update Status solves the problem, it is a "band-aid" solution. I am currently looking into a better fix.

FTR some related issues:

• #806190: drush updb removes themes under /profiles from the system table
• #545452: Store install profile in the generated settings.php file

subscribe

Solution is to make sure following two variables are set with your install profile's name:

1. Drupal variable 'install_profile' (set in the database) with variable_set('install_profile', $value) or drush vset install_profile <value>.
2. global $profile in settings.php.

This has been bugging us for weeks, it turns out that just setting install_profile in the global $conf array in settings.php is not enough. Kinda feel stupid now :P

See links above for discussion about the wider drupal core issue.

Hope this helps

P.S props to hadsie and adrian for pointing this out :P

Is this still an active issue?

Hi

I am closing this issue to clean up the issue queue. Feel free to reopen the issue if there is new information and the problem still resides. If not please make sure you close your issues that you don't need any more.

Maybe you can get support from the local user group. Please take a look at this list at groups.drupal.org.

Hi there,
I was experiencing same issue with a sub-sub-fusion theme (an aim subtheme). I was debugging and looking for it on Internet, with no luck. Finally, I added this lines to index.php (just to debug sill more):

  error_reporting(E_ALL);
  ini_set('display_errors', TRUE);
  ini_set('display_startup_errors', TRUE);

You can accomplish the same by adding similar lines to php.ini.

I found I had a PHP bug on my modified theme (into a tpl file). Just corrected the error and all worked again. No more theme lost on some "drush cron". So may be your cases. Be sure to run all your templates and all hooks you've just added to themes or with modules with php debugging on.

Hope it helps.