In #2354475: [meta] Refactor the installer, (multi)site management, and pre-container bootstrap a refactoring of the pre-container parts of Drupal 8 is being discussed.
One big part of that is going to be the installer.
Currently the installer is a big intransparent state machine, built around the $install_state array. Every installer step can read and write to this array, making it really hard to track what is going on.
As if this wasn't enough, these functions also initialize the Settings:: singleton, the Database:: singleton, some Drupal:: static variable stuff, and it creates a half-complete container somewhere.
Solution: MiniContainer
A first idea to refactor this was to turn the $install_state into an object.
Then I realized that a MiniContainer as in #2354475: [meta] Refactor the installer, (multi)site management, and pre-container bootstrap would be a perfect fit, seeing that there are some dependencies between $install_state parts.
The MiniContainer approach allows to have the values be lazy-initialized, instead of carefully having to actively initialize them before they are being used.
This also allows to kick out a huge number of installer tasks which do nothing but initialize those values.
A MiniContainer can be used for services, but it can also be used for any kind of values with depencies. And there can be as many different containers as we need. No need to stuff everything in the same container.
One challenge is that MiniContainer is designed for things that no longer change during a request after their first (lazy) initialization. Some installer steps may change values in the install state. So either these values are not part of the MiniContainer, or these steps need to create new mini containers.
The remaining steps could be turned into objects, to get rid of yet another nested array structure.
There are basically two types of steps left: Those that build a form, and those that run a batch process.
----
I will keep update this issue when I find out new things.
Comments
Comment #1
donquixote commentedBogus code detected!
install_verify_config_directory() calls config_get_config_directory() for no reason.
It already has the $config_directories, there is no need for this call and catching the exception.
Comment #2
dawehnerJust be sure while thinking about it, the amount of steps needs to be adaptable from inside install profiles. Stuff like commerce kickstart etc. are really using it.
Comment #3
donquixote commentedYes. Not really a problem.
However, the install profile task callbacks can alter the entire $install_state array, which I want to get rid of.
I hope this is not considered an API breakage.
Another funny thing is that install_tasks() is recalculated in every round of install_run_tasks(). This does make sense for install_tasks_to_perform(), but for install_tasks() it seems a waste. And again it would allow for ugly hacks in install profiles that let install_tasks() return a different result in the nth loop.
Also it seems that installer steps are expected to alter $install_state['parameters']. I hope that install_select_profile() which sets $install_state['parameters']['profile'] is really the only case we need to support. Because luckily this can be done without altering.
Comment #4
donquixote commentedComment #5
steamx commentedComment #19
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #20
smustgrave commentedWanted to bump 1 more time as the related issues are open.
Comment #22
smustgrave commentedWill put back but probably could close