Problem/Motivation
We've been struggling to get a version of Drush that will work with both 8.2.x and 8.3.x once the Symfony dependencies have been upgraded to 3.x.
Recently @catch and @timmilwood reported that the site-install command was working for them. However it is not working for me. The error I'm getting is:
Error: Call to undefined method Drupal\Core\Config\ConfigCollectionInfo::setDispatcher() in /Volumes/devdisk/dev/sites/drupal8alt.dev/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php on line 94 #0 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/lib/Drupal/Core/Config/ConfigManager.php(370): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('config.collecti...', Object(Drupal\Core\Config\ConfigCollectionInfo))
#1 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/lib/Drupal/Core/Config/ConfigInstaller.php(115): Drupal\Core\Config\ConfigManager->getConfigCollectionInfo()
#2 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/lib/Drupal/Core/ProxyClass/Config/ConfigInstaller.php(75): Drupal\Core\Config\ConfigInstaller->installDefaultConfig('core', 'core')
#3 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/includes/install.inc(622): Drupal\Core\ProxyClass\Config\ConfigInstaller->installDefaultConfig('core', 'core')
#4 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/includes/install.core.inc(1037): drupal_install_system(Array)
#5 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/includes/install.core.inc(660): install_base_system(Array)
#6 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/includes/install.core.inc(538): install_run_task(Array, Array)
#7 /Volumes/devdisk/dev/sites/drupal8alt.dev/core/includes/install.core.inc(115): install_run_tasks(Array)
#8 /Volumes/devdisk/dev/drush5/includes/drush.inc(726): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#9 /Volumes/devdisk/dev/drush5/includes/drush.inc(711): drush_call_user_func_array('install_drupal', Array)
#10 /Volumes/devdisk/dev/drush5/commands/core/drupal/site_install.inc(80): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array)
#11 /Volumes/devdisk/dev/drush5/commands/core/site_install.drush.inc(226): drush_core_site_install_version('minimal', Array)
#12 /Volumes/devdisk/dev/drush5/includes/command.inc(422): drush_core_site_install('minimal')
#13 /Volumes/devdisk/dev/drush5/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#14 /Volumes/devdisk/dev/drush5/includes/command.inc(199): drush_command('minimal')
#15 /Volumes/devdisk/dev/drush5/lib/Drush/Boot/BaseBoot.php(73): drush_dispatch(Array)
#16 /Volumes/devdisk/dev/drush5/includes/preflight.inc(93): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#17 /Volumes/devdisk/dev/drush5/drush.php(11): drush_main()
#18 {main}
Proposed resolution
The error is because the autoloader is loading \Symfony\Component\EventDispatcher\Event
from drush's symfony 3.x codebase and not Drupal 8.2.x's symfony 2.x codebase. So why is this happening? When composer registers the default autoloader it uses ->register(true)
which prepends the autoloader. When composer bootstraps Drush it's autoloader is registered first. The Drupal's autoloader get's bootstrapped and registered first. However, if you have APCu then \Drupal\Core\DrupalKernel::initializeSettings()
will come along and move Drupal's autoloader to after Drush's. This results in the different behaviour experienced by me and @catch/@timmilwood.
I propose the \Drupal\Core\DrupalKernel::initializeSettings()
does not change the order of autoloaders.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#5 | 2843828-8.3-5.patch | 5.28 KB | alexpott |
#5 | 2843828-8.3-test-only-5.patch | 4.15 KB | alexpott |
#5 | 2843828-5.patch | 5.35 KB | alexpott |
#4 | 2843828-8.3-3.patch | 1.13 KB | alexpott |
#4 | 2843828-3.patch | 1.2 KB | alexpott |
Comments
Comment #2
alexpottComment #3
timmillwoodManually tested, the patch fixes the issue for me!
Comment #4
alexpottMaking the comments a bit easier to understand.
Comment #5
alexpottAnd here is a test. The test is a bit hacky but given the importance of ensuring that booting the kernel does not change the order of autoloaders I think it is worth it.
Comment #7
catchI was a bit borderline on whether to test this, but given the semi-unreproducable nature of the original bug let's add it. Leaving RTBC in case of comments from others, but will try to commit later today.
Comment #9
catchCommitted/pushed to 8.2.x and 8.3.x, thanks!