Add confirmation page when installing module

I think our target audience probably doesn't care so much that this needs to be core-mvp, but I did tag it core-post-mvp because I think it would be good to inform users (either before OR even after) about what was installed and what to do next. This could dovetail on that issue.

This might be a duplicate; feel free to check against the related issues and see if it's covered there, and if so, close as dupe.

I definitely agree this is post MVP, but a "what next" stage after installing a new module would be a great feature to help new users. For example, displaying a link to the modules configuration page would be extremely useful. I would think this would need to be something that the module provides, since not all modules have a configuration page, and I don't believe it's possible to predict where the configuration page for a module would be. Perhaps a hook or plugin service could be added to allow the module to provide "after successful install" text.

For example, displaying a link to the modules configuration page would be extremely useful.

Some (all?) of the backend infrastructure for this now exists. The new ActivatorInterface has an activate() method (which is what actually installs the module), and it can optionally return a Response object, which could be instructions for what to do next, or maybe a redirect to a configuration page, or...what-have-you.

We'd still need some changes in the frontend JS to make sure those responses are actually respected, but that could be the scope of this issue.

In Linux, when you install a new package, it shows you the dependencies that will be added to the install, and optional modules that would enhance your experience. Those would require additional install commands later.

I have aborted installs just because I didn't realize how many additional packages would be installed. Having a preview page would definitely give new to Drupal the confidence that they are more in control. More information makes it understandable, rather than wondering what it is going to do. Think about someone that sees a module for credit card processing and doesn't realize this will install commerce.

On the preview page, it could also indicate if it was going to download the module, upgrade an existing module, that maybe wasn't enabled, or just enable a module. After all, a module could have been uninstalled previously and not removed, but they didn't know or remember. Or one of the dependencies might be to enable a core module.

This adds to the idea that the button can just be a "Install" button, instead of a "Download & Install", or "Add and Install", because the exact procedure is detailed in the status and you don't have to know up front.

I also like @lostcarpark 's idea of a post install display. Not only can it include setup/config links, but if an upgrade had change notes, or requirements to manually make changes because of an update, that would be a great time to inform them, rather than leaving them to wonder why it isn't working. And a great confirmation page for a screen print to document their setup, and steps they used to get there.

While project browser is a feature all may use, the intent is to make it easier and more comfortable for those with little knowledge of Drupal. Maybe an opt-out config would help those more knowledgeable to disable features they don't want.

What #10 suggests could be done, but would take some significant refactoring. We'd probably need to introduce a new method to InstallerController which evaluates the state of the sandbox (staging area) and reports back, before allowing the user to confirm what's going to be done.

That also means we'd be implicitly moving to a "shopping cart" type of user experience, where you add a bunch of packages to your sandbox, then review what you did before you apply the changes to the live site. That's a pretty big change.

Aren't you adding a bunch of packages when you add the dependencies?

At some point, it must have what is going to be done. Jumping to a display, and then returning to the point where it evaluates, if there are any changes, sounds like minimal intrusion. But I don't know the process is.

Sure, it knows what will happened (well, actually what's already happened over in the staging area where Composer operations are done), but Project Browser's UI and backend controllers are not currently built for displaying a confirmation before the sandbox is copied to the live site. It's a Project Browser problem, not a Package Manager problem.

That's why I said it would need substantial refactoring. :)

I'm not sure that we want to go the whole "shopping cart" route. I think "App store" is more appropriate.

I like the Linux analogy. You ask it to install a package, and it finds all the dependencies it requires, and asks you to confirm.

The actual mechanism would behave slightly differently. Linux figures out what it's going to do, then asks you before it attempts it. Package manager applies the change to the staging area, then lets you confirm before applying to the site.

Automatic Updates already has this, so hopefully we can do something similar. I don't doubt @phenaproxima that it will be a big refactor, but at least we have a model to follow.

I have ideas for post-install, but I would suggest we focus on confirmation during install for this issue.