Add ability to skip starter recipe if it was preinstalled

Forgive me if I'm missing something here, but why would we want to run the installer on an already-installed database? I'm not clear on the benefit of doing this.

To put it another way:

demos that include a pre-warmed database

I don't understand this use case. What is the ideal/desired user flow? Is the idea that we would want to preinstall Drupal CMS, then send people back into the installer -- or something that looks like it -- to choose more recipes and answer various setup questions?

That is exactly the use case. Even the standard profile includes a configuration form in its installer, so there is always a possibility that the database could be installed before installation is complete.

Okay, so if I understand your response correctly, the goal is to preinstall Drupal CMS (i.e., base system + starter recipe), then present some sort of onboarding experience.

If I'm grokking it correctly, then I gotta tell you that the installer is probably not the place to do that. There is a lot of work taking place in other tracks to improve the onboarding experience post-installation by improving Dashboard and Project Browser, and improving our integrations with those modules in order to have a well thought-out onboarding flow (which includes the choice of additional recipes). I would encourage you to reach out to @pameeela and @ckrina for more information and context about that. But I would be quite resistant to changing the installer for that purpose, unless there was truly no other way.

I have discussed this with Pamela and she was very clear that the installer had to be part of the on-boarding experience.

Gotcha. What I'd like to see is a proposed design.

The designs I've seen thus far include the installer as we have it, then a redirect to an onboarding dashboard. That's pretty much what we're aiming for, and it's what we're in the middle of building. I don't understand why those designs necessitate a redirect back into the installer itself.

Installer batch performance is considerably improved in Drupal 11.2 so the '172 batch screens' problem will be gone, it'll be more like 9, can probably make it less than that.

At that point pre-installing a demo should be much less necessary.

Redirecting back into the installer should lead to a 'Drupal already installed' message and is generally a can of worms.

A possible option here is to move the recipe selection out of the installer entirely and instead make it the first page after install (with project browser).

Another option is to move project browser into the installer itself so the recipe installation experience is consistent although that will probably be hard.

I did raise this a while back that the onboarding experience is important, but I also think now (a few months later) that the current experience is likely to change in potentially significant ways. We are using the installer to show the recipes because it was the fastest way to do it for now, but it is probably not the best way to do it.

I can’t really say specifically what should happen here as I’m commenting on my phone without looking too closely. But previous discussions were in a different context and some aspects of the roadmap have changed.

I support this issue, Pameeela's comment in #9, and Catch's suggestion in #8. Even though work is being done to make installing Drupal faster, I feel we should not block ourselves from giving users a near-instant demo experience, without losing the ability to add recipes. Why should the Drupal demo be slower than Wordpress Playground's 11 seconds to a usable site?

( Here was the install speed comparison test ✨ Make demo spin-up fast Active I ran in Oct 2024. Perhaps I should do an updated comparison.)

I fully support the goal of this issue. A fast, near-instantaneous demo spin up>? Hell yeah. But I cannot support the proposed implementation.

Running the installer on a "pre-warmed" -- i.e., pre-installed -- database is a contradiction in terms. Once you have a database, you have no further need for the installer. Re-entering the installer once the install has completed (even if certain tasks in the install were skipped) goes flatly against the way the Drupal install system works and I don't feel that it is appropriate for our install profile to hack around that reasonable design decision.

If the goal here is to provide a pre-installed database and guide the user directly into certain setup tasks (like choosing additional recipes, setting their credentials, and so forth) -- which, again -- is a flow that I completely agree with -- then we should go about it another way. We could, for example, set up a one-time login link that kicks you into Project Browser to choose more recipes, or to a wizard that guides you through the onboarding tasks. That would be greatly preferable to bending the logic and assumptions of the install system.

@adrian83, FYI, the installer is now significantly faster (in 1.x-dev) than it previously was, even as recently as October. And as @catch points out, it'll get even better when Drupal 11.2 is out.

set up a one-time login link that kicks you into Project Browser to choose more recipes, or to a wizard that guides you through the onboarding tasks.

If the UX can be made to work, then moving some of what are currently install tasks to a wizard would be great - you could probably get to the point where the only thing in the installer is the language selection (which Drupal CMS doesn't have enabled yet anyway) + database credentials (which will be pre-filled for demos and ddev), then the minimum modules + theme to allow the wizard to work could probably be installed in one or two batches.

Would also be compatible with 🌱 Installerless Drupal Postponed - still a long way off but might motivate more people to work on it.

Running the installer on a "pre-warmed" -- i.e., pre-installed -- database is a contradiction in terms. Once you have a database, you have no further need for the installer. Re-entering the installer once the install has completed (even if certain tasks in it were skipped) goes flatly against the way the Drupal install system works and I don't feel that it is appropriate for our install profile to hack around that design decision.

I must point out that re-entering the installer after database tables have been created is exactly how the install system works. The install system saves its state to the Drupal database for just this purpose. If installation is interrupted, the install system is designed to simply continue performing unfinished tasks when it restarts.

I am happy for the people who have time to work on ambitious ideas such as installer-less Drupal. I will support them in every way I can. I understand that for these people, it may be frustrating to work on making what we have now the best it can be. That’s why I do that.

I must point out that re-entering the installer after database tables have been created is exactly how the install system works.

No this isn't quite right, because at the very end of the installer, it also records that it's finished, so that an installed site can't be sabotaged by re-running the installer. See AlreadyInstalledException.

I understand that for these people, it may be frustrating to work on making what we have now the best it can be.

We're also trying to improve what we've got in issues like 📌 Add the ability to install multiple modules and only do a single container rebuild to ModuleInstaller Active - but that's a (large IMO) incremental step forwards, as opposed to sideways.

at the very end of the installer, it also records that it's finished, so that an installed site can't be sabotaged by re-running the installer. See AlreadyInstalledException.

That’s what I am referring to. The AlreadyInstalledException is only triggered if the installer has recorded that it's finished. Otherwise the installer just resumes where it left off until it is finished. I think it would be helpful if this discussion were happening in the merge request so we can all see exactly what it is we are discussing.

Here's something I'd be willing to do as a concession: giving the installer the ability to skip the starter recipe, by making it a visually hidden checkbox (unconditionally checked by default -- you'd have to find some way to uncheck it, but patching the installer would be one way to do that).

That way, you would have an opening to provide an essentially pre-installed database with the starter applied and the "install completed" flag removed, and the installer would theoretically be re-entrant at the point you want it.

I think that would be a little hacky, but it would also be a reasonable change in the installer that doesn't try to circumvent Drupal by catching AlreadyInstalledException, and it sounds like it would allow you to get what you want in the context of your own set-up and infrastructure.

Opened https://git.drupalcode.org/project/drupal_cms/-/merge_requests/353 to implement the idea in #18. It would allow you to enter the installer with with_starter=0 in the URL, which should cause the starter to not be applied.

Does that suffice for your use case, @darren oh? I'd be willing to merge that if so.

That wouldn't help because the user has to be provided with a special link to get the benefits. I know the solution I provided does not help users who start with an empty database and accidentally interrupt the installer before it finishes, so I am working on a solution that uses a value in the install state to determine which recipes are already applied.

I don't feel like this addresses my concerns from #12, for two reasons.

1. Checking internal state left by Project Browser is a violation of Project Browser's API boundaries. That state is not intended to be used by external code.
2. This violates the the principle I closed with in my comment:
   

   If you see the installer, you have no database yet.
   If you have a database, you never see the installer.

If the installer is checking for any kind of pre-existing state, it's overstepping that line, and I'm not going to be comfortable with that.

It's one thing to add a hidden flag or switch that allows parts of the installer to be skipped -- I'm okay with that. But that flag/switch cannot come from the database, because the installer (especially the early installer, where RecipesForm runs) must assume that it doesn't have a database. The flag must come from the outside. If a URL parameter won't work, how about an environment variable? Or, if push comes to shove, why not just patch or fork the installer in DrupalForge?

Also, my question from #12 has not yet been answered:

if you already have a database, why do you want people to see the installer?

For reasons that I have clearly explained, pretending that the installer has no tasks to perform once there is enough of a database to bootstrap Drupal is not feasible for non-technical users.

I spoke to @darren oh about this over Zoom and we arrived at an understanding here.

What hadn't been clear to me up to now is that the main goal here is fault-tolerance. If the installer times out in the middle of applying recipes, for example, then you would get kicked back into the installer with no idea of how far you got. If you had any recipes that weren't idempotent (not a problem for Drupal CMS, but it's always a potential concern with recipes), you wouldn't be able to apply them again if you tried. And if you got punted back to the beginning of the installer, you'd just be priming yourself for further timeouts and trickiness. All of which would understandably leave a very bad impression.

So there you go -- skipping the starter for ...reasons? Dubious. Making the installer fault-tolerant and recoverable? I'm on board with that!

I'm totally fine with this implementation - an internal event subscriber works well, as long as its stored state is cleared when the install is finished. I would also like to make sure the intent behind the event subscriber is well-documented so future me (or someone else) doesn't come along and accidentally rip it out.

I've asked Darren to make a couple of final changes in the event subscriber, and then I'll go in there to document the intention. If it passes tests, I'm comfortable merging this.

phenaproxima → closed merge request !353

It was tough to get this right, but I'm okay with where we landed. I'm always in favor of increasing fault tolerance and I can see the value for people who want to try Drupal CMS on cheap shared hosting. The initial miscommunication in this issue was a challenge but I'm glad we were able to get it sorted out and find a path we're all satisfied with.

Whew. Merged into 1.x. Thanks, everyone.

Automatically closed - issue fixed for 2 weeks with no activity.