Jump to:
| Project: | Memcache API and Integration |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I was running pressflow 6.19, the latest 6.x-dev version of this module, and the php memcache (not 'd') library v3.0.1. Today I deployed some new code, including some new hook_theme() entries, and the theme registry wouldn't load them. I cleared the cache several times, confirmed that the module was running, etc. The exact same database and code on a local setup worked fine, so I concluded it was probably memcache related.
Reading through all the confusing documentation about the memcache and memcached plugins for php, and seeing that the *d variant was recommended with this module, I decided to switch. (That was a pain in itself, I'll write a separate blog post about that.) I finally got that working, cleared the drupal cache, and the theme registry was fixed.
I don't know what the root cause was, but switching extensions seems to have done the trick. Maybe it's related to #616282: Fatal error opening required theme.inc in content.module. I'd be curious if anyone else has a similar issue with the memcache (non-d) extension. Presumably it wouldn't be limited to the theme registry, since that's just one arbitrary cache item out of many.
Comments
#1
Should anyone need to do the same, a post on how I swapped the extensions: Switching PHP memcache.so extension to memcached.so
#2
I am currently using Memcache 6.x-1.5 and I see similar issues with problems with the themes registry. I am currently working with Drupal and third-party themes that, while memcache is enabled in settings.php and caching _IS NOT_ enabled in Drupal, does not allow me to change any of the configuration options inside of my Themes, including Global Settings. I am currently using Memcached on the servers and as I said before memcache 6.x-1.5 (using memcache.inc extension) and using Drupal 6.19; however not PressFlow.
It seems that either in Memcache, or in the Drupal Application there is an improper clearing of themes registry. At the moment, the only way to fix this for me is the following:
- comment out all references to memcache in settings.php
- stop the memcached server
- change the theme configurations to *exactly* how I want them
- uncomment all references to memcached in settings.php
- start the memcache server
Does anyone know the roots of this problem or have any suggestions? I have tried multiple times to clear memcache upon setting changes, and not once has it worked with memcache uncommented nor with the memcached server not running. This is getting very frusturating
#3
After further investigation and trials, I have been able to figure this much out...
Environment:
PHP 5.2.17
Memcached 1.4.5
Drupal 6.20
memcache module 6.x-1.5 (tried on 1.6-1.8 as well)
Settings:
Drupal Caching is turned -OFF-
use memcache is included in the settings.php
TESTED-- I have tested the settings changes without the memcache in settings.php, and it appears to work just fine.
When adjusting a theme, regardless of global settings or individual, upon saving this configuration change the settings will not show. To make these changes appear, immediately after the change one must go to the Performance in Site Configuration and clear cache without adjusting anymore of the Theme. This same issue does not appear to be showing up when adjusting blocks or adjusting the Modules enabled/disabled.
When memcache statistics are turned on, it shows through the GET that when adjusting the theme, the theme_registry is still grabbed (GET) through Cache. It is not resetting the theme_registry, which leads to the settings not taking effect until one clears the cache (which once again only happens if you immediately go to the Performance page and clear cache after a settings change).
Is there a reason why changing a Theme vs enabling/disabling act differently, or even block assignment? Why isn't the cache being properly cleared upon changing the theme settings?
#4
Subscribing...i've just hit this issue.
#5
I can confirm this is still an issue even with memcached.
#6
Updated title per #5.