Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#10 | autoloader_is_not-2727279-10.patch | 1.05 KB | davidwbarratt |
Comments
Comment #2
legolasboThis 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.
Comment #3
legolasboWe 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.
Comment #4
davidwbarratt CreditAttribution: davidwbarratt as a volunteer commentedWhat happens when you put something like this in your
settings.php
and disable this module?(adjust the path accordingly).
Comment #5
legolasboIf 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.
Comment #6
legolasboI 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.
Comment #7
legolasboAlso added an update hook to ensure the module weight is also updated on existing installations.
Comment #8
travismiller CreditAttribution: travismiller commentedIt 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 thecomposer_autoloader.module
file? Seems to work for me.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.
Comment #9
artur.poninski CreditAttribution: artur.poninski commentedWouldn't implementing hook_boot instead of hook_init, resolve those issues?
Comment #10
davidwbarratt CreditAttribution: davidwbarratt as a volunteer commentedIf I change it to hook_boot() I get this error:
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.
Comment #11
artur.poninski CreditAttribution: artur.poninski commentedThe patch works correctly and I believe adding error to watchdog is sufficient. Any chance this update will get into the stable version?
Comment #13
davidwbarratt CreditAttribution: davidwbarratt as a volunteer commented