Search box gets disabled after arbitrary amount of time

Make sure the search box is enabled in the theme settings: admin/build/themes/settings/zen_classic

You know what I mean?

Actually, no. :-) Can you try again without the run-on sentence and the typos?

If you are getting different results for anonymous users versus logged-in users, check the "search content" permission on admin/user/permissions.

I second this. We had some weirdness. Four separate sites, all using Zen. Three of them had the search box on by default, the other one did not. Couldn't tell you how or why - it's almost like it's arbitrary - AFAIK we followed the exact same install steps each time. Not a big deal, just caught us out for a few minutes... ;-)

one more vote for search box weirdness using Zen 6.x-1.0-beta3.

After enabling Zen search box (in the configuration section of my Zen sub-theme) I need only to wait a while I guess an hour or so and the search box disappears! When I go back and check the Zen configuration section I find that search box has been deselected...

Turning off the "Rebuild theme registry" feature stops the search box from disappearing as I described above.

I have the same issue as #6. After enabling the search box in zen theme (or any of it's sub-themes), the search box appears, but then after what seems to be an arbitrary period of time (1 min up to 20 min) the search box disappears. When you check the settings for the theme the search box has been disabled.
I really need some help with this.
An additional piece of information is that the css classes for the search box seems to change before it disappears, which I noticed since it lost some of the styles I applied to it.
And turning off "Rebuild theme registry" doesn't make it better.

Zen 6.x-1.0-beta3
Drupal 6.9

Problem persists after upgrade to 6.x-1.0 version of Zen.

No one who can point me in the right direction on this one? I'm only a beginner when it comes to php, and in this case I don't know where to start looking. Zen is great and I'd really would like to get my search box functioning.

Changed the title to be more informative.

Same problem here. I select "Search Box" in my subtheme. When I logout and log in, the search box disappears.

Turning off the "Rebuild theme registry" feature stops the search box from disappearing.

I'm am logged as admin, then I don't think that is a permissions problem.

Changing category.

I though I was experiencing the same thing as you guys. But turns out #3 is right. Check your permission settings for search.

What was happening in my case is I was logged in as Admin and would select the search box and save.
It would show up as I thought it should and then after several page reloads would disappear.
I changed to garland and it seemed to work just fine. But after reading this post then checking my permission settings I realized this was the case. Now everything works fine with my Zen subtheme.

I would really, really like to get this fixed. But right now I don't have enough information to reproduce this problem. And each person’s report seems slightly different and points to a different direction on where the problem may lie. :-(

I need people who are experiencing this problem to verify:

1. their search module permissions are set correctly
2. verify they have modified their template.php and theme-settings.php files correctly per step 7 of the “How to build your own sub-theme” instructions
3. tell me how often cron.php is run
4. tell me if Zen's "rebuild theme-registry" feature is on
5. tell me if they are enabling the "search box" on admin/build/themes/settings (Global settings) or on admin/build/themes/settings/mysubtheme (your sub-theme's settings). (Note: the admin/build/themes/setting toggle won't work due to a known core bug/design flaw), and
6. tell me any other hints about what you were doing or what was happening or anything when the search box became disabled.

Zen 6.x-1.1 will be released next week soon, so the sooner the better! :-)

I'm not sure of when exactly this is happening, but I thought I'd mention that I'm having the same problem with the search box becoming disabled after a period of time. Cron is being run every 24 hours on this site. I'm pretty sure this happens in between the cron runs, so I don't think it's related to cron. I'm enabling the search box on both the global settings and the sub-theme's settings, but the box only becomes unchecked on the sub-theme's settings page. I also DO have the "rebuild theme-registry" feature turned on for the sub-theme.

I just posted in a different issue thread about this — http://drupal.org/user/29391

I can verify 1 though 5. It seems that after an undefined amount of time, the search box disappears. On next viewing of the site. the check box is unselected in the zen sub-theme only.

As for #6, I am unsure though it might be triggered when the admin account logs out.

+1, my search box auto-disables after some period of time.

1) Search module permissions are correct. The box works fine when the "search box" toggle is on in the theme.

2) Yes

3) 45 minutes. Here's my cron line:
45 * * * * /my/path/scripts/drupal.sh --root /my/path/ http://www.mysite.com/cron.php

4) This is set as follows in my .info file:
settings[zen_rebuild_registry] = 0

5) I have it enabled in the global settings, and also in the theme-specific settings. The problem is that it is becomes disabled in the theme-specific settings page. The global flag always stays on.

6) There's no rhyme or reason that I can see. It must be happening on a cron run but I don't know what would cause it.

Any ideas for additional debugging steps? Perhaps adding some additional php code, wrappers around specific functions, etc?

So far I know it does not uncheck the search box on every cron run - it has been a few hours since my last post and it is still enabled. For kicks I also ran an update.php but that did not impact it either. It has to be something to do with cron.

Thinking out loud - are there different cron actions that take place once per day or once per week? Perhaps that is somehow part of it.

Just a thought ... but I think Zen's variables are getting deleted sometimes and I don't think it's a Zen issue. I think it's core. Look at the settings code in template.theme-registry.inc:

/**
 * Return the theme settings' default values from the .info and save them into the database.
 *
 * @param $theme
 *   The name of theme.
 */
function zen_theme_get_default_settings($theme) {
  $themes = list_themes();

  // Get the default values from the .info file.
  $defaults = !empty($themes[$theme]->info['settings']) ? $themes[$theme]->info['settings'] : array();

  if (!empty($defaults)) {
    // Get the theme settings saved in the database.
    $settings = theme_get_settings($theme);
    // Don't save the toggle_node_info_ variables.
    if (module_exists('node')) {
      foreach (node_get_types() as $type => $name) {
        unset($settings['toggle_node_info_' . $type]);
      }
    }
    // Save default theme settings.
    variable_set(
      str_replace('/', '_', 'theme_' . $theme . '_settings'),
      array_merge($defaults, $settings)
    );
    // If the active theme has been loaded, force refresh of Drupal internals.
    if (!empty($GLOBALS['theme_key'])) {
      theme_get_setting('', TRUE);
    }
  }

  // Return the default settings.
  return $defaults;
}

If list_themes() returns nothing then Zen will use defaults from the .info file which would set search back to off again. I have noticed now in many D6 installations that occasionally (and I have never worked out exactly what causes this) D6 "forgets" which themes are enabled. Somehow all the theme variables seem to get wiped arbitrarily. I also see very occasional PHP warnings regarding duplicate keys in theme tables, etc. It's all rather concerning, but I don't think it's Zen.

Anyone else seen these strange things? I had ignored them to date, but I saw the same problems in my Drupal "sandbox" the other day and it got me thinking, because Zen is not even installed there. What's odd is no one else seems to be talking about these funny theme-related errors D6 seems to throw up sometimes. As if the whole community is thinking "I wonder what that is? meh..."

Thanks - that is very helpful. What do you think about adding some custom logging statements into that function in the event that list_themes comes back with nothing? It may be worth knowing if that is happening. On my infrastructure that would be a strange event as I have 100% uptime for the OS and database so it should never fail. I'm also in 'test mode' so there is no load on my system other than a few DB queries for the test site and two users. It would be very unlikely to be related to performance.

I just enabled the syslog module to make it easier to parse through the logs. I'll see what comes naturally in case I am missing something in the UI.

It might be worth dropping some timely watchdog() calls in to list_themes() as a temporary hack. See what comes back. Problem is, I've never been able to reproduce it. Only observe it and think "that's odd, it happened again..." Means you'd have to run a D6 core with a hacked list_themes() for a while and wait for the problem to manifest.

Robert, thanks for the detailed response.

Greg, thanks for the interesting hypothesis.

I'm still watching this issue closely. So keep up with the data and theories! I want this fixed. :-)

Delving deeper, there's a possibility this relates to database connectivity. Looking at list_themes() itself, it seems to revert to the info files if there is no database connection. Could it be that a temporary loss of database connection upsets the mechanisms for saving theme settings?

Attached patch to theme.inc might gather some data about this. At least we'd see if a database-less theme settings load occurs directly before the search box disappears.

Thanks Greg. I had this happen again last night, which was roughly 48 hours after I last re-enabled the search box. I added the watchdog patch, cleared all caches, and re-enabled the search box. Hopefully this will turn up some log entries in the next few days.

The list_themes_watchdog.patch seems to lock up my site. Web requests hang and I finally wind up with a php "allowed memory size exhausted" error in the Apache log. I haven't looked into it yet but commenting out the watchdog lines fixes it and gets me back to normal.

I have tried all manner of watchdog calls at that spot, even boiling it down to this basic attempt to test the function -

watchdog('test', 'This is a test', NULL, WATCHDOG_NOTICE);

... and all of them completely hang up my Drupal to the point where it won't load a page. I am perplexed by this behavior. I just wind up with this in the httpd error log:

[Wed Jul 08 22:59:57 2009] [error] [client 1.2.3.4] PHP Fatal error:  Allowed memory size of 201326592 bytes exhausted (tried to allocate 52966 bytes) in /var/www/html/mysite/includes/database.mysql-common.inc on line 41

I'm a bit stumped but am still interested in debugging or capturing data if anyone has thoughts on this interesting behavior. This is on D6.13 if it matters.

Very odd. Patch works fine for me and there's no reason why it shouldn't. It just adds two calls to watchdog() (my logs are turning up fine, with the dumped array for debug in case we need it - got one of my sites running the patch to see if anything turns up).

You seem to be having wider issues with your system that are beyond the scope of this issue. Though I've never seen a watchdog call cause anything like that! Seems like it's trying to load something monstrous in the process, but can't think what it could possibly be doing. The only time I've seen *similar* behaviour is when I had the bright (read: dumb) idea of trying to send a video clip over web services. It didn't end well. =P

Sorry I can't be of more assistance. The only thing I can suggest is you set up a clean Drupal 6, install Zen and not much else, apply the patch and see if you get the same problems.

Alright, here's the issue I believe may be related - causes duplicate warnings in the system table:
#477550: "User warning: Duplicate entry ... " ... Themes

Now I don't know exactly what the knock-on effects of this, but I bet there ends up being duplicate sets of variables (or overwritten original variables with variables from the info file) when this occurs.

It is a duplicate of two further issues - this one fixed in D7:
#147000: Rewrite module_rebuild_cache() and system_theme_data()

And this one (back port of the same), still active:
#307756: Backport of #147000: Unify and rewrite module_rebuild_cache() and system_theme_data()

I am speculating, but I'll eat *everyone's* hats if these aren't related. =P

I've always experienced the search box disappearing issue only when going between maintenance mode and normal site mode in my zen sub themes. Don't know if that provides any additional hints as to the problem. It's pretty consistent though. Can anyone else verify this?

I've also noticed that the radio button selection (the one used to select the currently active theme) on the theme selection page sometimes disappears, though I've never been able to determine the cause or any discernible pattern.

Ditto - I think it's all related.

Well, I can now reproduce this every time on my side. The symptom is that the search box is disabled every time I clear my cache - be it through the admin UI or via drush. For now I have moved to 'drush cache clear' for easier troubleshooting.

I have traced it back to the template.theme-registry.inc file, and specifically the HOOK_theme implementation at the top. Here's the code:

function _zen_theme(&$existing, $type, $theme, $path) {
  // Compute the conditional stylesheets.
  if (!module_exists('conditional_styles')) {
    include_once './' . drupal_get_path('theme', 'zen') . '/template.conditional-styles.inc';
    // _conditional_styles_theme() only needs to be run once.
    if ($theme == 'zen') {
      _conditional_styles_theme($existing, $type, $theme, $path);
    }
  }

  // Since we are rebuilding the theme registry and the theme settings' default
  // values may have changed, make sure they are saved in the database properly.
  zen_theme_get_default_settings($theme);

  // If we are auto-rebuilding the theme registry, warn about the feature.
  // Always display the warning in the admin section, otherwise limit to three
  // warnings per hour.
  if (user_access('administer site configuration') && theme_get_setting('zen_rebuild_registry') && $theme == $GLOBALS['theme'] && (arg(0) == 'admin' || flood_is_allowed($GLOBALS['theme'] . '_rebuild_registry_warning', 3))) {
    flood_register_event($GLOBALS['theme'] . '_rebuild_registry_warning');
    drupal_set_message(t('For easier theme development, the theme registry is being rebuilt on every page request. It is <em>extremely</em> important to <a href="!link">turn off this feature</a> on production websites.', array('!link' => url('admin/build/themes/settings/' . $GLOBALS['theme']))), 'warning', FALSE);
  }

  // Return nothing.
  return array();
}

If I comment out everything in that function except for the 'return array();' at the end, I can clear my cache every time and the search box stays enabled.

Troubleshooting this function further, it's this specific line that is doing it.

  // Since we are rebuilding the theme registry and the theme settings' default
  // values may have changed, make sure they are saved in the database properly.
  zen_theme_get_default_settings($theme);

If I comment out only that line, the search box stays enabled during a cache clear event.

Now, I have no specific solution at this point for it. What I was thinking about is to determine a way to get the settings for the search box prior to running that bit of code, and then after running it restoring the state of the search box. I understand there may be a bigger problem here but I'm not inclined to try to solve it - I just need my search box to stop disappearing.

Thoughts or comments are welcome.

Looking further it looks like a core issue. zen_theme_get_default_settings() calls theme_get_settings() from includes/theme.inc, and on line 934 we have:

  // Only offer search box if search.module is enabled.
  if (!module_exists('search') || !user_access('search content')) {
    $settings['toggle_search'] = 0;
  }

It appears to be the user_access() call, because when I change the code above to:

  // Only offer search box if search.module is enabled.
  if (!user_access('search content')) {
    $settings['toggle_search'] = 12345;
  }

toggle_search gets set to 12345 in my variables table.

I'm not sure how this is ever getting to this point, as looking at user_access() it should always return true for uid 1 (which I am), but anyway, this looks like a core issue not a Zen one. I will try and do a bit more investigation and raise an issue in core when I have a working patch, but right now it's late and I'm off to bed!

Malc

I'm wondering if there has been any news on this issue? Has it been reported as a core issue? If so, where might I find that? Thanks for your help, Nancy

Actually, I did some more digging around and it does seem to be Zen specific, although I didn't get to the bottom of it.

I figured out the problem!

It's actually a core bug in theme_get_settings() that Zen is exposing. During a theme registry rebuild, Zen reads the theme settings using theme_get_settings() so that it can add in the default values from the settings lines in the .info file. And then it re-saves the values into the database. The problem is that theme_get_settings() returns a different value for toggle_search depending on the user that is viewing the page at the time of the theme registry build! Ugh.

The reason I never could re-create this bug is because I always allow anonymous users to search content. If you guys don't allow that, then when a theme registry rebuild occurs while an anonymous users is viewing the site (like, for example, during a cron.php run!) the search box gets disabled for all users. :-p

But there might be a work-around for it in the interim. I'll report back after I investigate this some more.

Nice work! I figured it might be a core bug, but I couldn't pinpoint it. We should raise a core issue, I guess. It probably still exists in D7, unless it's been fixed by accident.

Here's the patch against Drupal 6 core that should fix the problem. #605768: theme_get_settings() incorrectly changes returned value based on current user

John,

In the famous words of Mahir Cagri, I KISS YOU!!!!!

Great find! Thanks for the contribution!

Fixed in both 6.x-2.x and 6.x-1.x.

http://cvs.drupal.org/viewvc.py/drupal/contributions/themes/zen/zen/temp...