Problem/Motivation

In #2944113: [policy, no patch] Should Umami/OOTB support backwards compatibility and an offical upgrade path from one version to another? we discussed that it could be useful to have a reinstall button to make it easier to start over with the demo. This button would also signal that the demo is ephemeral and it should not be built on.

Proposed resolution

Explore adding a reinstall button. Design, technology, etc. Define whether this is a requirement for Umami for some milestone.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

CommentFileSizeAuthor
#6 Screen Shot 2018-05-24 at 12.31.55.png50.39 KBcatch

Comments

Gábor Hojtsy created an issue. See original summary.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

A security concern was raised that if this is accessible outside of umami this could wipe your site inadvertently. We would need to make sure it is only accessible from the umami profile. Still in that case if someone happens to build their site on Umami (WHICH WE DON'T SUPPORT), they would have this feature lingering there and it may wipe their site later when they want to clear the cache or something. It would certainly make building on the demo more dangerous by itself.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I'm not crazy about this idea, for the following reasons:

  • Safe, secure, in-app deletion of an app is a really hard problem to solve.
  • Asking, or worse, requiring a team made up mostly of new core contributors and front-end developers to do this work in order to get a demo (which is mostly YAML + HTML/CSS) in front of people seems like asking an awful lot, and risks stalling the entire Out-of-the-Box effort, which is strategically critical to Drupal's adoption and ongoing health.
  • If we were to grow said team to also include backend developers, then it seems like #2944113: [policy, no patch] Should Umami/OOTB support backwards compatibility and an offical upgrade path from one version to another? would be a much more impactful use of their time + skills, since...
  • It's just as easy to miss that there's a button to delete your site and start over as it is to miss a message that they should delete their site and start over, so like it or not, people are still going to end up building sites on Umami regardless of how much we try to advise them not to. It seems like mitigating against that fact is where our efforts are best focused, not on sleeker shortcuts for people who properly read the docs.

Unless I'm missing something, and there's a drop-dead simple solution to this problem, that's not going to get held up on security team blessing, that's drop-dead easy to design for, then great. Let's do it! But otherwise, this feels like diverting valuable time and people from efforts that could be otherwise spent making the demo really solid and impressive.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

The problem with supporting BC is that is not a one time development investment. Whatever changes are made would need to come with tests (database dump, update function test) and some kind of updates are just impossible to support (you added a field_media, the profile wants to add it, no way to resolve that).

The Umami team on today's call said that they see a possibility to postpone this feature until there need to be a breaking change which requires a reinstall. Although in that case the workflow would be:

1. Wipe
2. Update codebase
3. Install again

And this magic button would only be able to do 1 and 3, not 2. So this button is not a magic bullet either :)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

That's fair about the ongoing investment and some of the trickiness therein for upgrade paths. But if we're targeting people who actually read things + can henceforth locate a magic button, a link to a handbook post that explains how to start over with another profile takes 1 line of code and no particular skill vs. a magic button takes N00 lines of code + very specific expertise + ongoing maintenance.

Again, happy to be told that I'm wrong and this feature is super easy to implement. But in absence of that, this feels like a major distraction that puts the MVP at risk for yet another release.

catch’s picture

catch
he/him
Primary language English
commented
StatusFileSize
new Screen Shot 2018-05-24 at 12.31.55.png50.39 KB

I don't think this has to block things being visible, it's just an idea - specifically an idea which seems like it should be less work than trying to maintain an upgrade path and backwards compatibility.

We don't know how widespread the problem of 'building sites on Umami' will be, so we should think about mitigations. I also think it's better to talk about potential approaches before we run into problems.

@webchick:

a link to a handbook post that explains how to start over with another profile takes 1 line of code and no particular skill

So the only issue is this is we don't know how people have installed Drupal in the first place. If it's any kind of one-click install, then manual instructions on how to empty a database are tricky to document. Also reinstalling core with a different install profile is not straightforward even for experienced Drupal developers.

We have spent a lot of effort trying to optimise the process of installing for new users - like creating settings.php, making it secure etc. The unfortunate side-effect of this, is that it makes reinstall harder.

Even though I've been using Drupal for over 10 years, I regularly mess up reinstalls and hit errors.

I often start site building on minimal or standard, export the configuration, then continue building the site using config_installer. The first time you reinstall after that change with drush, drush will complain that the install profile in settings.php does not match the one you've picked.

With the UI installer, the same problem happens:

Since the installer makes settings.php read-only, it may be necessary to either delete that file, or to manually edit it and change the install_profile setting. So we don't require people to do anything with settings.php when they install, but we do when they reinstall.

You can see various bug reports about this with config_installer. While the use-case is different, the process of installing again with a different profile is not, and it's tripped up long-term Drupal developers in multiple different hosting environments.

#2819385: Trying to modifying settings.php when it is read-only
#2802903: Install profile setting in settings.php causes import issues

#2156401: Write install_profile value to configuration and only to settings.php if it is writeable dealt with one aspect of this, but that's for locked down environments with a pre-prepared settings.php.

Core doesn't actual require the install profile in settings.php, we write to it for backwards compatibility, so maybe we can remove that bc layer in a minor release (I don't think anyone will miss it): https://www.drupal.org/node/2538996

A related issue I opened a very long time ago is #1242956: Allow install profiles to be switched. If someone was to uninstall the Umami theme (and profile), and we allowed switching the install profile to standard, that's really no different to building up the same configuration from scratch. And it's less destructive than a nuke button.

catch’s picture

catch
he/him
Primary language English
commented
Related issues: +#2975328: Install profile in settings.php and mismatch check makes re-installs of Drupal hard

Opened #2975328: Install profile in settings.php and mismatch check makes re-installs of Drupal hard.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

This may be blocked on that then unless we want to (and can in the environment) delete settings.php which would mean users need to know db creds which they may have never known (ie. in an ideal simplytest.me environment or another managed environment).

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Title: Add a button to reinstall Umami demo » [PP-1] Add a button to reinstall Umami demo
Status: Active » Postponed

Based on #8.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Title: [PP-1] Add a button to reinstall Umami demo » Add a button to reinstall Umami demo
Status: Postponed » Active

#2975328: Install profile in settings.php and mismatch check makes re-installs of Drupal hard landed, so this is unpostponed. Also closed #2802903: Install profile setting in settings.php causes import issues.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

quietone’s picture

quietone commented
Status: Active » Closed (won't fix)

Things have changed since this issue was opened and we now have, #3523324: Deprecate and remove the Umami demonstration profile from core, make it a contributed site template.

Therefor I am closing this issue.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.