Installerless Drupal

I think now that

• the Recipes initiative is approaching the point where it's possible to replicate the Standard install profile (see #3417835: [PP-1] Convert the Standard install profile into a set of recipes → ) using just a recipe
• 🐛 Install profile is disabled for lots of different reasons and core doesn't allow for that Fixed is pretty much ready
• … combined with from the issue summary

… means that this issue is becoming relevant (and desirable) again. Imagine being able to try various complete recipes without having to set up DB/filesystem etc.

For background reading on implementation, there are these two very old issues, however since the installer hasn't changed much in the meantime, a lot of the considerations are still relevant:

#1226380: Generate minimal mocked or SQLite environment and use to install Drupal in full environment →
📌 [meta] Use a proper kernel for the installer Active

I think the main focus of this issue should be - would it be desirable if the installer was a single form, ideally with as many defaults filled in as possible, which then takes you to a core recipe selection and/or project browser. If it is, then we can continue towards making it possible in the various issues that are trying to reduce the up-front installer work, but with getting to that point in mind a bit more.

would it be desirable if the installer was a single form, ideally with as many defaults filled in as possible, which then takes you to a core recipe selection and/or project browser

This sounds not just desirable, but AMAZING! 😄

I'm not familiar with the two issues you linked. Is 📌 [meta] Use a proper kernel for the installer Active a blocker for this?

I'm not familiar with the two issues you linked. Is #1530756: [meta] Use a proper kernel for the installer a blocker for this?

Trying not to get into the depths of implementation too much here, but I guess we're only at #17 comments after seven years so maybe it won't hurt :P

The biggest issue we still have, which I also brought up back in 2011 in #679112-13: Time for system.module and most of includes to commit seppuku → is that the installer depends on system module.

It does so less than it did in 2011, but we still rely on the batch API, which relies on the sessions table, which is defined in system_schema(), which is installed by install_begin_request().

We would need a combination of 🌱 [meta] Replace hook_schema() implementations with ::ensureTableExists() Active and/or an apcu or file-based sessions storage implementation so that we can either have a session without a database, or have a session as soon as an initial form is submitted (which could be sqlite in the public file system by default).

This might not be exclusive - if we still want to create user 1 and log the user in, we also need to do the {users_data} table which is user_install(), although that least is only currently a dependency of the end of the installer instead of the beginning of it currently. Either way the general principle is the same - we need the installer to function as an app, which doesn't have circular dependencies on arbitrary modules, so that it can install project browser before user and system module if possible.

The other major part of this for me would be non-blocking batch UI, so that when you install a module from project browser or do other things in the installer, we can show an AJAX progress bar instead of an interstitial page that stops you looking at anything else.

There was issue to ship minimal sqlite db for installer but I can't find the issue

@andypost I think that was #1226380: Generate minimal mocked or SQLite environment and use to install Drupal in full environment → .

To add onto #15/#17 there is maybe a more high level view of this:

1. Make the installer more minimal and self-contained - just requirements check and minimum configuration with defaults, selecting a language etc, but not site name, e-mails, user/1 etc. to enable Drupal to run in sandbox mode.

2. We can then go to the actual sandboxed Drupal install, but with project browser as the first thing you see, allowing you to browse through recipes and modules (local and/or remote) and try them out.

3. At some point we have to take the site from sandbox to a permanent site on a real database, but make that an optional process that you can do after experimenting.

4. Keep drush and maybe UI support for skipping sandbox mode, this might be 'install from existing config'.

Btw core already provides site-install (even from config) command and even #3089277: Provide core CLI commands for the most common features of drush →

but I guess we're only at #17 comments after seven years so maybe it won't hurt :P

hahhaha indeed 😆

The high-level view in #19 paints a more complete picture of the UX that this issue is aiming for. And #17 dives into some (very much appreciated!) detail of what it'd take at a technical level to get there.

It seems it all boils down to the Batch system and the infrastructure that needs. This makes me wonder … and I can't believe I'm about to write this but … do we truly need server-side sessions? Those are AFAICT necessary for A) determining how far a long-running operation got, B) security reasons, C) client closed connection and we want to continue the long running process.
However, in this ephemeral demo-only context with no sensitive data and no traffic being served other than this one user, can't we get away with not using (server-side) session? And instead track the necessary metadata in https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage? That requires the server to trust the client, but in this context … that doesn't matter anyway? 🤔

I probably am overlooking a crucial fact or five. Trying to think out of the box 🤓

I've opened 🌱 [meta] Streamline the UI installer Active which is more about re-organising the order of the installer with project browser et al - installerless Drupal doesn't mean anything if you still have to choose an install profile in step 2. So I'm postponing this issue on that (and moving it to core since I can never find it when I'm looking for it).