Should maintenance mode be suggested or enforced?

I vote suggested, not enforced. I think it should be discouraged Project Browser on production sites anyway, so ideally the most common use is on local/dev sites where the maintenance mode switch isn't really necessary and it would just be creating extra hoops to go through. If there was a way to identify a production instance I might suggest something different.

@bnjmnm I agree that for development use this isn't needed.

There probably needs be some implicit documentation around or warnings in the UI about using it in production.

Another possibility would be looking at making the UX for going in and out of maintenance better. If Project Browser is really intended as a development tool that we don't want people using on production what's the harm in the user being prompted on when they first try to install a module via Project Browser that site will also be put into maintenance mode.

I think part of the original intent is to actually get more "no-code" people into Drupal, and admittedly, these people may be running their local hiking group's site in production on shared hosting or something. In that way, I believe we ought to enforce maintenance mode. However, as a developer, I would hate to have it happen especially if I know I'm only using it (PB) in "single user mode" on my local machine.

My suggestion would be, then, to have the constraint in place in Package Manager, but skip it if $config['package_manager']['enforce_maintenance_mode'] = FALSE; then, developers can put this in their local config or settings.local.php. The only "harm" of enforcing maintenance mode is that it's maybe a little slower. For people who care about that, they could opt out?

My suggestion would be, then, to have the constraint in place in Package Manager, but skip it if $config['package_manager']['enforce_maintenance_mode'] = FALSE; then, developers can put this in their local config or settings.local.php.

Maybe it would just be easier for the something in settings.local.php that just keeps the site in maintenance mode? This would need to be a core change but is there is any reason not to be in maintenance while you are developing locally? I guess if you are signing in as different roles for testing but you could always update settings.local.php

I worry that $config['package_manager']['enforce_maintenance_mode'] = FALSE; would just be used as a way to override the validation and let people install modules and do other operations on production, especially since this module and Package Manager itself has gotten this far without fully thinking about the implications of running operations on the site out of maintenance mode. Are other site builders really going to be able understand the implications of running these operations out of maintenance mode.

@bnjmnm in #2: but what do you think about:

Another option is that Package Manager itself should inspect the stage determine if any running code will be updated. Running code probably would mean any installed modules or themes and any third party packages at all. The Package Manager could either force maintenance mode or just stop operations if the site is not in maintenance mode

in the issue summary?

If that were implemented, then Project Browser would not have to enable maintenance mode either 99% of the time, except that 1% of the time when it is truly risky not to.

@chrisfromredfin in #4: and what you suggest is perfect for that 1% case! But … perhaps it's overkill? 99% of the time you won't be affected anyway?

Would love to find Wim and Ted at DrupalCon Portland and put a (ted)bow on this!

Of the two choices in the proposed resolution, I like what Wim says in #6 - which is that if Package Manager enforces or enables maintenance mode itself, then (a) we don't need to worry about it, and it provides a consistent experience when more modules come along and start relying on Package Manager, and (b) it solves the 99% use case, which nullifies the 1% need for the settings.local.php override (maybe those numbers are more like 90% and 10%, but I think the point is still valid).

We would want to notify users that their site will be put in maintenance mode during "the operation" - and I would personally just encourage doing it at the latest possible time (for example prior to applying to real codebase, and not, say, during the beginning of the copy-to-stage phase), but I think that goes without saying. :)

It sucks that we don't have an authoritive way in Drupal Core to ask (or verify with) a Site Builder if the current site is pre-production or not. For example, on platform.sh there is a defined user journey which is "Go-live steps" and a production mode, so it's pretty clear where a site is at when they design interface solutions.

This is more of a problem for projectsl ike Project Browser because it is trying to be inclusive of the naive site builder person, by being flexible about things that might trip them up, while also safe to use in other contexts.

Wouldn't it be lovely...

public needsMaintenanceMode() {
  if ($this->coreSiteEnvironmentState->isProduction()) {
    return TRUE;
  }
  return FALSE;
}