Autoload fails if a module implements hook_boot and relies on a class autoloaded by registry_autoload [#2870868]

Issue

When rebuilding the registry, if bootstrap_invoke or bootstrap_invoke_all is called, and one of the modules in the bootstrap list depends on a class defined in another module, drupal_load fails due to not finding the namespaced class.

Analysis

The module_implements_alter hook is setting this module to run last, but this module should be run first so that the registry has the autoload classes in the DB before any other module performs any actions that may rely on the autoloaded classes.

Comment	File	Size	Author
#2	autoload_bootstrap_dependency_issues-2870868-2.patch	779 bytes	jfalkner

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

18 April 2017 at 21:00

jfalkner created an issue. See original summary.

Comment #2

jfalkner CreditAttribution: jfalkner at Phase2 commented 18 April 2017 at 21:04

Issue summary:

View changes

File	Size
autoload_bootstrap_dependency_issues-2870868-2.patch	779 bytes

See attached patch which resolved the issue in my environment.

I did not see anything in the module's hook_registry_files_alter that would be problematic to run before other modules, but I would like to hear from the module maintainer regarding this change.

If it is necessary that this hook run last in all cases, then perhaps a submodule is needed that consists of a hook_boot(), hook_module_implements_alter, and a hook_registry_files_alter that does nothing more than ensure the DB is updated before any other module, and then let the main module continue to handle ensuring the $files array is altered by registry_autoload last, but without altering the DB during that module's call.

The attached patch goes the simpler route of altering the module_implements to run before other modules.

Comment #3

jfalkner CreditAttribution: jfalkner at Phase2 commented 18 April 2017 at 21:05

Status:

Active

» Needs review

Comment #4

jfalkner CreditAttribution: jfalkner at Phase2 commented 20 April 2017 at 18:16

Title:

Autoload fails if a module implements hook_boot, relies on autoloaded class of module not implementing hook_boot

» Autoload fails if a module implements hook_boot and relies on a class autoloaded by registry_autoload

Comment #5

Fabianx CreditAttribution: Fabianx as a volunteer commented 21 April 2017 at 13:52

I think we should do that, in theory we could add another function not named correctly with hook_module_implements_alter() so that we can run before other modules _and_ afterwards.

Still have to think about this for a bit.

I think the original idea I had to have it run last was that other modules could add files to auto load as well.

I am however pretty sure that this was never actually used in practice (and the approach from this patch would also solve reported ctools problems especially with regards to registry rebuild) and probably a better approach would be to just add a new hook that modules that want to interface with registry_autoload could implement - if any would like to do so.

Obviously changing the order is a harder BC break, but on the other hand it fixes a bug that is not solvable otherwise.

Tricky ...

Comment #6

jyraya CreditAttribution: jyraya at European Commission and European Union Institutions, Agencies and Bodies commented 11 July 2018 at 11:47

Hello,

This patch fixes some troubles for me; especially with the upgrade of entity cache module.

Concerning adding an additional function that can run be before and after other modules, is the hook_registry_autoload_registry_alter not enough to do the job?