Problem
install_begin_request()contains arbitrary bootstrap and state checking logic.install_tasks()contains arbitrary bootstrap and state checking logic.- Every install task needs to check on its own whether it is available.
- Every install task needs to check on its own whether it is required.
- Every install task needs to check on its own whether it can run.
- Every install task needs to account separately for the non-interactive vs. interactive installer.
- Various install tasks have inter-dependencies to/from other install tasks.
- Less than a handful of people understand how the installer works.
Proposed solution
-
Introduce a
Graph-based install task/step manager:install.php ∟ DrupalKernel ∟ InstallerServiceProvider ∟ InstallerTaskManager ← Graph ∟ InstallTask (already installed?) ∟ InstallTask (distribution profile) ∟ InstallTask (language) ∟ InstallTask (translation download) ∟ InstallTask (profile) ∟ InstallTask (database settings) ∟ InstallTask (filesystem settings) ∟ InstallTask (core base system installation) ∟ InstallTask (kernel reboot/rebuild into production environment) ∟ InstallTask (module installation) ∟ InstallTask (theme installation) ∟ InstallTask (extension translation download + import) ∟ InstallTask (profile task X) ∟ InstallTask (final installer cleanup) -
All available install tasks are instantiated immediately, in order to
- Resolve dependencies
- Check (task) availability
- Check requirements
- Auto-resolve task parameters from current
Requestand/or currentState - Resolve the next task to be executed
Install tasks no longer have a hard-coded order. Dependencies define execution order.
Plugins?
-
global $install_state→\Drupal::state()->get('installer')As soon as available, the current installer state is loaded from persistent state storage instead of being rebuilt from scratch on every request.
Notes
-
This probably can and should be abstracted for re-use (e.g., update.php, same drama), but intentionally ignoring that topic for now.
Comments
Comment #1
sunComment #2
larowlanYes, love this design.
There is a similar proposal for update tasks at #2222593: Implement better hook_update_N()s for concurrent development
Comment #3
sunComment #4
andypostComment #14
andypost