drush @PROD pm-list
	PHP Fatal error:  Class 'ctools_export_ui' not found in /srv/www/PROD/sites/all/modules/contrib/facetapi/contrib/current_search/plugins/export_ui/current_search_export_ui.class.php on line 11
	Drush command terminated abnormally due to an unrecoverable error.                                        [error]
	Error: Class 'ctools_export_ui' not found in
	/srv/www/PROD/sites/all/modules/contrib/facetapi/contrib/current_search/plugins/export_ui/current_search_export_ui.class.php,
	line 11

reading

Fatal error: Class 'ctools_export_ui' not found (during installation)
https://drupal.org/node/1139732#comment-4547668

After updating to Drupal 7.2 Fatal error: Class 'ctools_export_ui' not found
https://drupal.org/node/1170312#comment-4547662

drush @PROD dl registry_rebuild
ls -al /root/.drush/registry_rebuild
	total 44K
	drwxrwxr-x+ 2 root    root  4.0K Nov  5 07:22 ./
	drwxrwxr-x+ 5 blakers users 4.0K Nov  5 07:22 ../
	-rw-rw-r--+ 1 root    root   18K Nov  5 07:22 LICENSE.txt
	-rw-rw-r--+ 1 root    root  2.7K Nov  5 07:22 README.txt
	-rw-rw-r--+ 1 root    root  6.4K Nov  5 07:22 registry_rebuild.drush.inc
	-rw-rw-r--+ 1 root    root  4.0K Nov  5 07:22 registry_rebuild.php

drush @PROD rr
	PHP Fatal error:  Cannot redeclare lock_initialize() (previously declared in /srv/www/PROD/includes/lock.inc:68) in /srv/www/PROD/sites/all/modules/contrib/memcache/memcache-lock-code.inc on line 19
	Drush command terminated abnormally due to an unrecoverable error.                                        [error]
	Error: Cannot redeclare lock_initialize() (previously declared in
	/srv/www/PROD/includes/lock.inc:68) in
	/srv/www/PROD/sites/all/modules/contrib/memcache/memcache-lock-code.inc,
	line 19

EDIT settings.php

	$conf += array(
-		'lock_inc' => './sites/all/modules/contrib/memcache/memcache-lock.inc',
+	//	'lock_inc' => './sites/all/modules/contrib/memcache/memcache-lock.inc',

drush @PROD rr
	The registry has been rebuilt.         [success]
	'drush' cache was cleared              [success]

EDIT settings.php

	$conf += array(
+		'lock_inc' => './sites/all/modules/contrib/memcache/memcache-lock.inc',
-	//	'lock_inc' => './sites/all/modules/contrib/memcache/memcache-lock.inc',

drush @PROD pm-list
	Package                    Name                                              Type    Status         Version
	Administration             Actions permissions (actions_permissions)         Module  Not installed  7.x-3.0
	Administration             Administration Development tools (admin_devel)    Module  Enabled        7.x-3.0-rc3
	Administration             Administration menu (admin_menu)                  Module  Enabled        7.x-3.0-rc3

Comments

omega8cc’s picture

omega8cc commented
Issue summary: View changes

Fixed formatting.

kitt’s picture

kitt commented

Any update on this?

Firemyst’s picture

Firemyst commented
Project: Registry Rebuild » Memcache API and Integration
Version: 7.x-1.x-dev » 7.x-1.0
Priority: Normal » Major

This is a problem with Memcache not using a proper namespace and colliding with core.

omega8cc’s picture

omega8cc commented
Status: Fixed » Active

@Firemyst - No, this is not a Memcache problem, and Memcache does have to use the same namespace to be able to provide drop-in cache backend replacement, like any other module of this kind.

The problem is sadly on the Registry Rebuild side, because it hardcodes Drupal native locking.

We would have to introduce a workaround like this one, but it is a bit hard, since we don't know for sure where the memcache module is located. We could, however, assume at least standard sites/all/modules location as a sane default. And fix the same issue for Redis integration.

omega8cc’s picture

omega8cc commented
Project: Memcache API and Integration » Registry Rebuild
Version: 7.x-1.0 » 7.x-1.x-dev
Status: Active » Fixed

Fix committed: http://drupalcode.org/project/registry_rebuild.git/commit/254030c

Note that we check both sites/all/modules and sites/all/modules/contrib space for best results.

Status: Active » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

pobster’s picture

pobster commented
Status: Closed (fixed) » Active

This is nowhere near a foolproof way of getting the include location. For instance, we have ours in /sites/all/modules/patched/memcache.

You have access to various bootstrap functions here (even the entire database), why not use a loop around;

$cache_lock_path = $include_dir . '/lock.inc';
$lock_files = array(
  'memcache' => 'memcache-lock.inc',
  'memcache_storage' => 'includes/lock.inc',
  'redis' => 'redis.lock.d6.inc',
  'redis' => 'redis.lock.inc',
);
foreach ($lock_files as $module => $file) {
  $path = dirname(drupal_get_filename('module', $module)) . '/' . $file;
  if (file_exists($path)) {
    $cache_lock_path = DRUPAL_ROOT . '/' . $path;
    continue;
  }
}

Although you're completely overlooking that someone may have all three of these modules present in their infrastructure (as what both has been put in and what I've done above check for whether the lock file is actually in use)...

Pobster

pobster’s picture

pobster commented

Okay I wrote that without 1. testing it, 2. really putting much thought into it. Of course, as the bootstrap goes as far as the database then you have access to the variables.

Both what has been committed and what I've suggested can be replaced by simply using;

$includes = array(
...
..
.
DRUPAL_ROOT . '/' . variable_get('lock_inc', 'includes/lock.inc'),

What do you think?

Pobster

pobster’s picture

pobster commented

Incidentally, seeing as no-one has replied, this works fine while using memcache_storage and its own lock.inc file.

Pobster

omega8cc’s picture

omega8cc commented
Status: Active » Closed (duplicate)

@pobster Please read (and test) the follow-up (we have in progress) in #1971684: Registry rebuild does not work with non core lock.inc

omega8cc’s picture

omega8cc commented
Issue summary: View changes

Clearing some noise.