"Class 'views_handler_*' not found" on handler class discovery [#1824024]

See #1778952: Fatal errors caused by auto-registration in some environments - the same problem applies to handler classes. To summarize, in the presence of an enabled module such as field_collection which implements both Migrate and Views APIs, if Views is disabled, our attempt to discover handler classes by iterating over classes listed in the registry and instantiating a ReflectionClass to check their parentage generates a fatal error. To address this, we will implement a means of explicitly registering handler classes via hook_migrate_api(), and deprecate (and provide a way to disable entirely) auto-registration.

Comments

Comment #1

mikeryan

he/him

English

Murphysboro, IL, USA

CreditAttribution: mikeryan commented 26 October 2012 at 16:59

Component:

Code

» Documentation

So, a bunch of related changes to make this more robust:

1. Destination and field handler classes can (and should) be registered in hook_migrate_api(), by listing the names of any classes your module implements. Example:

/*
 * Implements hook_migrate_api().
 */
function example_migrate_api() {
  $api = array(
    'api' => 2,
    'destination handlers' => array(
      'MyNodeDestinationHandler',
      'MyUserDestinationHandler',
    ),
    'field handlers' => array(
      'MyCustomFieldHandler',
    ),
  );
  return $api;
}

2. The registration portion of the former "configuration" page has been split out to admin/content/migrate/registration, and allows you to enable and disable the code that does automatic registration of classes based on parentage. It had to be split out, because if you were broken with these missing class errors, you couldn't go to the page to disable it because the handlers section would be broken...

3. The handler configuration is now at admin/content/migrate/handlers.

So, the upshot is that

1. Going forward, people are encouraged to expressly register their migration and handler classes, rather than depend on them being automatically detected.

2. If you don't make any changes, in the absence of the scenario that triggered all this things will still work, although you will need to either click the Register button or issue a drush mar command to pick up Migration class changes (where formerly you needed to clear cache).

3. If you do run into this scenario, you can prevent it by disabling automatic registration at admin/content/migrate/registration. If you do this, of course, you will need to make sure your classes are all explicitly registered.

I need to document this well in the doc pages... This is significant enough for me to issue a new release candidate, I want to get some testing in the wild before the final 2.5 release. When I put out the rc2 release, I'll blog about these changes so people have some warning.

The daunting part here is that modules that have implemented migration handlers (such as, say, Date) need to add registration of their handlers - in the absence of explicit registration in hook_migrate_api(), their handlers will not be invoked when auto-registration is disabled.