This doesn't directly fall under the purview of any particular official initiative, but I'm tagging it for them anyway because it's relevant.
We all know the installer is the red headed stepchild of Drupal, even among red headed stepchildren. There are many reasons for that. Mostly it boils down to:
1) Most of Drupal expects to be running in an installed state, and so we have to hack around that for a special case.
2) Core only supports database-based sessions, so we cannot use a session to store data. That means all sorts of grotesque contortions to pass data along a multi-step form without using any sort of data storage mechanism.
3) It was implemented before any good client-side storage mechanisms existed.
4) Let's be honest, given all of the above, no one has really tried to make the installer a *good* system, just a *working* system. That was hard enough.
However!
1) We now have this great new kernel, router, and http library in core courtesy of Symfony.
2) That includes a new session implementation that includes a PHP-native backend, which we can use at all times, even in an uninstalled state. (See #335411: Switch to Symfony2-based session handling → for where we're trying to use the new session code for core, too.)
3) That includes the ability to define "routes" (paths and controllers) without using the database.
4) All of our supported browsers for Drupal 8 support real client-side functionality, and arguably we can rely on Javascript, you know, existing.
That means... we can rewrite the installer to be its own Symfony-based micro-application. And in the process, greatly simplify and modernize the code.
The basic idea is this:
1) Implement a new kernel class specific to the installer, using all of the default Symfony components. No custom implementations necessary the way core will need.
2) Give the installer kernel a hard-coded set of routes. There's probably like a half-dozen here.
3) Implement each "step" in the installer as a separate controller at its own path, rather than chaining GET parameters out for a few miles. As a bonus, that makes it possible to actually test each step individually(!)
4) Use a PHP-native session or client-side sessionStorage or whatever to store data rather than throwing crap into the GET string.
5) Clean up a crapload of stuff along the way.
6) Profit!!1!
Note that we will almost certainly run into places where things are still ugly and cannot be made non-ugly just be working around them. That's fine. Anywhere that we find the installer cannot be done without ugliness is a clear sign that we need to refactor something. In a sense, we're using the kernel as a canary in the coal mine to help flush out the sort of refactoring and pulling-apart-of-things-that-are-wrongly-coupled we're going to have to do anyway.
And getting a much better and more maintainable installer out of it is good, too.
I have a preliminary stab at this in the kernel-installer branch of the WSCCI sandbox. It's barely started, but it starts to lay out the basic idea. Someone not named Crell needs to pick this up and run with it. :-) Who wants to be the hero of Drupal and make the installer not suck? (Contact me for access to the sandbox if you want.)
Once the installer is done, the same thing can and should be done to both cron.php and update.php. (Actually cron.php may not be necessary anymore, but definitely update.php should also become its own little micro-app.)
The installer's pseudo-paths should turn into real paths. Otherwise there should be no significant UI changes.
This *should* be possible to do without changing the API for install profiles, but that will be determined by implementation. (Although we may want to adjust the install profile API as well in light of the new installer in a follow-up patch.)
Who wants it???
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
