FAQ
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110124/3f8c40fd/attachment.html

Search Discussions

  • Greenman at Jan 24, 2011 at 5:32 pm
    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 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20110124/28b1f0a5/attachment.html
  • Greenman at Jan 24, 2011 at 5:51 pm
    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 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 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20110124/12e63858/attachment.html
  • Greenman at Jan 24, 2011 at 6:27 pm
    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 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 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 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20110124/37c3bfdb/attachment-0001.html
  • Daniel F. Kudwien at Jan 24, 2011 at 6:47 pm

    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
  • Greenman at Jan 24, 2011 at 9:41 pm
    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 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20110124/407c9643/attachment.html
  • Randy Fay at Jan 24, 2011 at 10:03 pm
    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
    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 at randyfay.com
    +1 970.462.7450
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20110124/2f7feaf4/attachment.html

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdevelopment @
categoriesdrupal
postedJan 24, '11 at 4:50p
activeJan 24, '11 at 10:03p
posts7
users3
websitedrupal.org
irc#drupal

People

Translate

site design / logo © 2022 Grokbase