Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | install system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
reasoning
I came upon this idea while discussing the following patch regarding installation automation : #524728: Refactor install.php to allow Drupal to be installed from the command line
The problem the patch is facing, is the same problem that Aegir faces. Because the install profile is capable of inserting anything into the main install process, there is no general case we can use to automate the installation of all install profiles. With this patch in core, it would mean that we would have to start handling all of the special cases that install profiles can have right inside core.
How the installer works at present, is that it has it's own entry point that gathers all the necessary information, installs core and the profile specific modules and then passes the process over to the hook_profile_tasks implementation, which acts as a state machine tracking your progression through the wizard.
Now here's the thing, the special cases only occur once the process has been handed over to the install profile. At this point it is impossible to predict what the install profile will be doing (whether asking for user input, connecting to servers via ajax, running batches etc). Even if the install profile API has the meta-information necessary to know what the task is doing, it still requires knowledge of exactly what fields to pass to the forms and how their validation works.
Another wrinkle is that these profile specific tasks are also running inside install.php with only limited access to the standard Drupal API in a way that's not easy to discern. This actually leads to many 'hacks' being made to work around the limitations of install profiles.
proposal
I propose that we modify the install process to happen in 2 phases instead of the single one we have presently.
Phase 1 :
Select language
Select install profile
Set database credentials
(install drupal)
Configure the first user account
These steps are used in all Drupal sites / installation profiles and rarely differ.
Therefor these steps are very easy to automate as they have a known input and well defined output.
Phase 2:
Once phase 1 is completed, the user is then redirected to the site itself , logged in as UID1.
The site is operating in a special "install mode"
Install mode is similar to site offline mode, as the site is not actually live yet, however the user will now
continue with any install profile specific configuration.
Because install mode is a fully bootstrapped Drupal site, that allows install profiles access to the whole Drupal API.
Instead of implementing hook_profile_task and hook_profile_task_list, the install profile instead uses hook_menu to
implement any post install pages.
Before we do this, we will already have introduced .install files for install profiles, so any tasks that do not need to
have user interaction could be handled by the hook_install of the profile. If there is no post install configuration the user
is just taken to their new site.
Any menu items that are part of the 'install/*' tree will be displayed to the user in order, and we can implement a
very simple 'pager' type mechanism that will allow the user to move through this list. The previous patch hoped to
find meta-information about the pages being displayed by marking up the tasks list, but all the information necessary
is already present in the menu hook.
Result
From the perspective of a system like Aegir, instead of trying to automate every possible case you would be able to automate
what you can and pass the user to a user friendly wizard to automate what you can't.
This could also allow modules to add configuration to the install process (which may or may not be what we want).
From the perspective of profile developers, they are able to build a friendly user interface to their application that will deploy easily programmatically in most cases, without needing to learn complex new functions that only occur in install profiles and nowhere else.
We will be removing one of the biggest roadblocks for install profile development, and replacing it with a well understood and well tested core API.
This also ties into my goal to make install profiles simpler :
#509404: Fix some conceptual problems with install profiles and make them actually usable
Pre-requisites for this are :
#509398: Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x)
#509400: Introduce .install files for install profiles
Comments
#1
Can we do away with install profiles then, except possibly as a list of modules/themes to install?
I like, the idea of every module .install being able to kick the site into 'install' mode to force the admin to configure it. This is really a major missing feature in core.
#2
Pwolanin : install profiles primary use is as a packaging / distribution mechanism.
Open Atrium would be impossible to do in the way that you described, for instance.
This patch is the last step in removing almost all differences between install profiles and modules.
Profiles would have no more 'special apis' that are only used by them, and the only remaining difference would be
that profiles are
a) stored in a difference place
b) are called .profile instead of .module
c) can contain their own modules and themes directories.
We will also need to enhance our packaging scripts to take advantage of the new meta-info provided by .info files.
#3
Subscribing. This sounds like a great plan in the long run, since in addition to improving the site installation process, it could also eventually allow modules to have configuration wizards that run whenever the module is installed, etc -- see also #230059: Can we create a configuration hook for contrib modules?.
Regarding the installation, this could get tricky in the case of hook_form_alter() -- currently, install profiles can add info to the standard "configure site" form if they want to. This would break the assumption that the initial Drupal installation always has a well-defined set of inputs.
#4
Lovely plan. I am happy to forego the ability for profile to alter the basic install forms. Such drastic profiles can do their own install. This plan will bring profile authoring to a very comfortable spot. JUst author a .info and menu callbacks. Wow, nice.
#5
I think this is won't fix in favor of #524728: Refactor install.php to allow Drupal to be installed from the command line. reopen if i am wrong.
#6
@moshe, the approaches are a bit different.
Here's my suggestion:
PHASE 1:
PHASE 2:
The reason I like my idea better is that with my idea, as much stuff as posssible happens in fully bootstrapped Drupal. All install profiles are currently minimal + something else, but minimal is all that's needed for a full drupal, so the installer can install just minimal's modules, and then install the install profile on top of that.
What Adrian had against my selection was that it would be harder for David's use cases in #524728: Refactor install.php to allow Drupal to be installed from the command line to install. What they need is to set stuff up to step 2.2, and the user would take it from there. Part 1 is harder to automate, because it's not actually Drupal, but David has a solution for that, and for part 2, we have drupal_execute. We should be able to wrap both those in a function and come up with something like David did.
#7
What is the plan for the basic site configuration page? One of my frustrations with the current (D6) install profile setup is that the site configuration is pretty much hardwired into the installer, and there may be some cases where someone wants to skip that page with their profile. Currently there is a manual invocation of a hook_form_alter for this form, but this wouldn't really allow skipping it.
It seems if we really want to make this flexible all the configuration forms beyond DB configuration should be moved into the "Phase 2" along with all other forms. Is there a compelling reason to keep this page in the first phase?
#8
@mikey_p, that's what my solution provides.
#9
Ok, Adrian convinced me of his solution. Let's wait for #524728: Refactor install.php to allow Drupal to be installed from the command line to land (it's going pretty fast), and we can pick this up after that's done.
#10
That patch mostly landed.
#11
Too bad this is past the freeze... (and +1)
#12
#605880: Settings and menus broken after install due to faulty caching and #1082328: Provide a proper no-op cache.inc also are related: the first installation phase happens to install the core framework and base modules, while this is being done, some AJAX queries happens to hit the partially installed site and create stalling outdated cache entries. All code that would need the full API during install, or that would need to bootstrap the site in order to work should be deported to a second phase which happens in the site itself, and not in the install.php anymore: it would safely rule out this kind of bugs that are really hard to solve.