entity module and registry rebuild

Could you try the same with registry_rebuild-7.x-1.x-dev version?

tried devbuild

Please add updates in comments and don't edit the initial request, or you are introducing more confusion.

Could you try the new option - but create a backup of the database first!:

drush rr --fire-bazooka

It will truncate registry and registry_file tables to build them from scratch.

This could be still a Ctools fault.

Could you provide some additional info?

1. Drupal core version used.
2. Entity API module version used.
3. Ctools module version used.
4. Drush version used.
5. PHP version used.

This could help in attempts to reproduce the problem, since I don't have an access to any Windows machine.

Closed due to lack of feedback for a long time. Feel free to reopen when ready for the follow-up.

identified file source as part of entity api

likely totally unrelated; but it is the same error so figured i would just post here.

to start with i think your instructions on project page are incorrect:

2. Make a directory for the php file, probably sites/all/modules/registry_rebuild (or for a multisite, sites/mymultisite/modules/registry_rebuild.
3. *If* your modules are not in sites/all/modules, you will probably have to edit registry_rebuild.php to set DRUPAL_ROOT to what it should be.
4. Copy the registry_rebuild.php from the package into that directory.

- technically, steps 3 and 4 should be switched, its better to copy the file over and then edit it :)
- but main issue i think is that you state if modules not in sites/all/modules to redefine DRUPAL_ROOT, i am pretty sure you want to redefine $module_dir, not DRUPAL_ROOT, correct?

so, moving on, after i have done that, simply redefined:

$module_dir = DRUPAL_ROOT . '/sites/mysite/modules';

i now get this:

DRUPAL_ROOT is C:\wamp\www\Squared\umd.

Fatal error: Call to undefined function module_load_include() in C:\wamp\www\Squared\umd\sites\arch.umd.edu\modules\entity\entity.module on line 8

which would seem to suggest that i am not bootstrapping.

hmm.. yea, not sure how that is supposed to work; but you have an early include for entity.module which runs module_load_include() but that is called before you bootstrap.

that won't work will it?

hmm.. yea, not sure how that is supposed to work; but you have an early include for entity.module which runs module_load_include() but that is called before you bootstrap. that won't work will it?

This is by design that we load some of the core code w/o doing a full bootstrap, so we don't hit WSOD and can rebuild or re-create registry. However, I personally didn't review all of those older commits to make sure we don't indirectly call some APIs available in higher bootstrap phases, but since it normally works on Linux w/o issues, I tend to suspect it is some Windows specific problem? See for example #2170505: drush rr does not work

but main issue i think is that you state if modules not in sites/all/modules to redefine DRUPAL_ROOT, i am pretty sure you want to redefine $module_dir, not DRUPAL_ROOT, correct? so, moving on, after i have done that, simply redefined: $module_dir = DRUPAL_ROOT . '/sites/mysite/modules';

No, no. You are confusing core /modules with contrib. It must fail if you override it like this.

Maybe this is a different problem, but:
If the entity module is not inside sites/all/modules (or in a further subfolder like /contrib), the above error happens.

I had this problem when I took over a client project and some bad boy had put entity Module inside /modules where all the core modules are.

The reason could be the following lines in registry_rebuild.php

$module_dir . '/entity/entity.module',
$module_dir . '/entity/entity.controller.inc',

This appears to make sure entity is only loaded from the modules directory. While I do not really understand this, because the module directory given here is /modules, not /sites/all/modules for the contrib modules.

But nevertheless: The minute I just moved entity module to /sites/all/modules, I could run registry_rebuild.php and it worked, rewrote the paths to the module inside the systems table and everything works.
So be bold and just move it to the right place.

Hmm.. these two lines are Drupal 8 specific, and while it is an edge case to have a site with contrib module dropped in the core modules directory in D7 or D6, we should make these lines conditional. It was added in #1328718: D8 port

Plus, I just realized it is exactly the same edge case as in the original report here:

D:\xampp\htdocs\compuceg\modules\entity\entity.module on line 8

Fix committed: http://drupalcode.org/project/registry_rebuild.git/commit/1915fd0

I'm also downgrading this to support request, as it was not really a bug of any kind. It only exposed awful practices ;)