The composer autoloader is not registered when the menu (routing) system performs an access callback. This is caused by the fact that these callbacks are executed before hook_init() is called and we rely on hook_init() to initialize the autoloader. The attached patch introduces a new access callback trough which all access callbacks are routed in order to initialize the autoloader before the actual callbacks are invoked.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

legolasbo created an issue. See original summary.

legolasbo’s picture

This can be reproduces by requiring drupal/mailchimp. It depends on GuzzleHttp/Client and performs a class_exists() as part of the access check. Whenever you try to manage mailchimp signup forms, it will fail the access check because the class can't be loaded. Even if you require it's package using composer.

legolasbo’s picture

FileSize
1.08 KB

We are using netresearch/composer-patches-plugin to manage patches in our project. The patch in the OP gets applied multiple times when updating the project. This new patch is only different in where the code is positioned to aid in the detection of previously applied patches.

davidwbarratt’s picture

What happens when you put something like this in your settings.php and disable this module?

require_once DRUPAL_ROOT . '/../vendor/autoload.php';

(adjust the path accordingly).

legolasbo’s picture

If i manually require the autoloader in my settings file everything works without a hitch. However, I do not want to require the autoloader in my settings file as I am trying to keep that file very clean.

legolasbo’s picture

FileSize
1.43 KB

I came across a bug where implementations of hook_menu_alter would be invoked after composer_autoloader_menu_after() and cause some notices. This has been solved in the attached patch by changing the module weight to ensure it is always run last.

legolasbo’s picture

Also added an update hook to ensure the module weight is also updated on existing installations.

travismiller’s picture

It appears there may be as many as 10 hook implementations that are handled before hook_init().
https://www.lullabot.com/articles/drupal-exposed

Requiring vendor/autoload.php in settings.php works without using this module.

However, since this composer_autoloader_init hook is essentially only requiring a non-drupal file with some basic existence checking and error reporting, is it reasonable to just call the init function directly from the composer_autoloader.module file? Seems to work for me.

function composer_autoloader__init() {
  // …
}
composer_autoloader__init();

I came across this issue hacking on a 7.x version of the flysystem module, which does an initial check for the existence of auto-loaded classes in flysystem_stream_wrappers, which seems to be the very first hook implemented.

artur.poninski’s picture

Wouldn't implementing hook_boot instead of hook_init, resolve those issues?

davidwbarratt’s picture

FileSize
1.05 KB

If I change it to hook_boot() I get this error:

Error: Call to undefined function path_is_admin() in composer_autoloader_boot() (line 26 of sites/default/modules/composer_autoloader/composer_autoloader.module).

However, I can just not use that function and always trigger the error, which should respect the user's display error settings which should be better anyways.

Please test the attached patch and see if it resolves your issue.

artur.poninski’s picture

The patch works correctly and I believe adding error to watchdog is sufficient. Any chance this update will get into the stable version?

  • davidwbarratt authored 6decfa9 on 7.x-1.x
    Issue #2727279 by legolasbo, davidwbarratt, artur.poninski, travismiller...
davidwbarratt’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.