How do I update Drupal7's file list ?
I keep hitting this problem: I update or move a module and everything breaks. Most of the time the issue is to do with Drupal’s cache of files, objects and includes. How do I update this list ? Unfortunately Drush is even more sensitive to this issue than core, so a drush script is probably not the best way to go. Any ideas on how to re-build the file list ? Peter
I will now answer my question: The object registry is in the bootstrap cache. Clear that and things should work. I would have had some success earlier had I been running my queries on the correct database. Thwak! On 24 January 2011 16:50, Greenman <greenman@the-organization.com> wrote:
I keep hitting this problem: I update or move a module and everything breaks. Most of the time the issue is to do with Drupal’s cache of files, objects and includes.
How do I update this list ? Unfortunately Drush is even more sensitive to this issue than core, so a drush script is probably not the best way to go.
Any ideas on how to re-build the file list ?
Peter
Sorry for the spam. The registry is not just in the cache_bootstrap, it's also in the main registry tables. I have only been able to get around this issue by disabling modules in the db, running "drush updatedb", and then re-enabling my modules. Fun with registries! On 24 January 2011 17:32, Greenman <greenman@the-organization.com> wrote:
I will now answer my question:
The object registry is in the bootstrap cache. Clear that and things should work.
I would have had some success earlier had I been running my queries on the correct database. Thwak!
On 24 January 2011 16:50, Greenman <greenman@the-organization.com> wrote:
I keep hitting this problem: I update or move a module and everything breaks. Most of the time the issue is to do with Drupal’s cache of files, objects and includes.
How do I update this list ? Unfortunately Drush is even more sensitive to this issue than core, so a drush script is probably not the best way to go.
Any ideas on how to re-build the file list ?
Peter
This is what I have learned, a little bit of "good practice" for drupal 7: If you use any classes in your own modules, always put them in an include file. Drupal will autoload them when they are needed. Using the autoloader protects you from WSOD should the ancestor class move to a new file, because it will not attempt to set up the classes the moment the module is enabled in the bootstrap. On 24 January 2011 17:51, Greenman <greenman@the-organization.com> wrote:
Sorry for the spam.
The registry is not just in the cache_bootstrap, it's also in the main registry tables.
I have only been able to get around this issue by disabling modules in the db, running "drush updatedb", and then re-enabling my modules.
Fun with registries!
On 24 January 2011 17:32, Greenman <greenman@the-organization.com> wrote:
I will now answer my question:
The object registry is in the bootstrap cache. Clear that and things should work.
I would have had some success earlier had I been running my queries on the correct database. Thwak!
On 24 January 2011 16:50, Greenman <greenman@the-organization.com> wrote:
I keep hitting this problem: I update or move a module and everything breaks. Most of the time the issue is to do with Drupal’s cache of files, objects and includes.
How do I update this list ? Unfortunately Drush is even more sensitive to this issue than core, so a drush script is probably not the best way to go.
Any ideas on how to re-build the file list ?
Peter
Using the autoloader protects you from WSOD should the ancestor class move to a new file, because it will not attempt to set up the classes the moment the module is enabled in the bootstrap.
This is not true, actually it's the exact opposite - which happens to be the topic of this thread. Try moving around modules and files in D7. Try early alpha versions of Entity module and update to later ones. Just try it. And see how Drupal blows up and leaves you with an almost unrecoverable state. The root of this problem is that Drupal requires a full bootstrap to flush all caches and/or to rebuild the class registry. However, a full bootstrap means that all .module files are loaded. Loading all .module files may contain classes already: class Foo extends Bar { } In case Bar was previously contained in sites/all/modules/bar/includes/controller.inc and now got moved into sites/all/modules/bar/bar.controller.inc, PHP is unable to find/autoload Bar, so you get a fatal error upon the class definition of Foo. Once you manually resolved the class registry problem, you still won't be able to bootstrap, due to http://drupal.org/node/996236 sun
Thanks Sun. Damn tricky stuff. My experience was with upgrading organic groups to the new entity release. In this case, moving the class to a new file helped because the bootstrap did not attempt to define the group class. Maybe I was lucky this time round. Hope your patch makes it ! This is going to cause some troubles. On 24 January 2011 18:47, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Using the autoloader protects you from WSOD should the ancestor class move to a new file, because it will not attempt to set up the classes the moment the module is enabled in the bootstrap.
This is not true, actually it's the exact opposite - which happens to be the topic of this thread.
Try moving around modules and files in D7. Try early alpha versions of Entity module and update to later ones.
Just try it. And see how Drupal blows up and leaves you with an almost unrecoverable state.
The root of this problem is that Drupal requires a full bootstrap to flush all caches and/or to rebuild the class registry. However, a full bootstrap means that all .module files are loaded. Loading all .module files may contain classes already:
class Foo extends Bar { }
In case Bar was previously contained in sites/all/modules/bar/includes/controller.inc and now got moved into sites/all/modules/bar/bar.controller.inc, PHP is unable to find/autoload Bar, so you get a fatal error upon the class definition of Foo.
Once you manually resolved the class registry problem, you still won't be able to bootstrap, due to http://drupal.org/node/996236
sun
So Daniel... What would be the canonical recovery with the Drupal 7 code the way it is? We probably need to have a big page that explains this. Thanks, -Randy On Mon, Jan 24, 2011 at 11:47 AM, Daniel F. Kudwien <news@unleashedmind.com>wrote:
Using the autoloader protects you from WSOD should the ancestor class move to a new file, because it will not attempt to set up the classes the moment the module is enabled in the bootstrap.
This is not true, actually it's the exact opposite - which happens to be the topic of this thread.
Try moving around modules and files in D7. Try early alpha versions of Entity module and update to later ones.
Just try it. And see how Drupal blows up and leaves you with an almost unrecoverable state.
The root of this problem is that Drupal requires a full bootstrap to flush all caches and/or to rebuild the class registry. However, a full bootstrap means that all .module files are loaded. Loading all .module files may contain classes already:
class Foo extends Bar { }
In case Bar was previously contained in sites/all/modules/bar/includes/controller.inc and now got moved into sites/all/modules/bar/bar.controller.inc, PHP is unable to find/autoload Bar, so you get a fatal error upon the class definition of Foo.
Once you manually resolved the class registry problem, you still won't be able to bootstrap, due to http://drupal.org/node/996236
sun
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
participants (3)
-
Daniel F. Kudwien -
Greenman -
Randy Fay