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 <n...@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
>
>
