Add a Composer script handler which automatically uninstalls Experience Builder whenever it is updated

    // Delete all xb_page entities and uninstall XB.
    $run_drush(['entity:delete', 'xb_page']);
    $run_drush(['pm:uninstall', 'experience_builder', '--yes']);

Is this guaranteed to uninstall Experience Builder? What happens if there are other dependencies on XB - let's say someone has built a view of XB pages? I feel like this risks data loss if we are just force uninstalling the module with no questions asked.

That's more a question for @effulgentsia to answer, I think, but "complete data loss" is precisely the idea. Since XB's data storage model can't be considered stable until beta1, we want to wipe everything out.

Also this won't work for people like me who run Drupal inside ddev but who also run composer on the host, there is no workaround for that I guess.

I think forcing data loss with no warning is surprising behaviour and should be avoided. At least we should ask "we are going to reinstall Experience Builder, are you sure you want to continue" - maybe just drop the --yes from the uninstall?

1. I agree with #10

   I think MR works well for Drupal CMS but it seems like getting testers for XB to be a pain.

   This seems like a general problem that if you are using a Alpha version of the module each update is going to risk problems, maybe very bad ones, when you update the module. But that seems to risk you would also take with using any alpha module.

   Say we have testers that are using Alpha1 they have made some complex pages, global templates changes, global css, and code component changes.

   They find a small UX bug and we fix it in Alpha2. They want to test Alpha2 and give feedback. By default they would have to rebuild everything that they had already done. what if we they rebuild everything and bug is not there. Is it not there because fixed in Alpha2 or is it not there because when they rebuilt everything they did it just slightly different and they didn't hit the bug and won't have hit in Alpha2 either.

   Upgrading between Alphas doesn't guarantee that we will break the data model and your site won't work. It just means it might. If we did this I can't imagine anyone would try to do anything complex with the alpha versions of XB, especially after we wiped their data the first time(maybe they didn't pay close attention during composer update). I think we do want risk takers to try complex with XB. That we would more confident to move onto alphas

2. what happens if someone updates XB with Automatic Updates? They wouldn't see an option to not uninstall even if we added, right? I could see there being a large intersection of people who don't want to deal with Composer, so they use AU, and those who don't want to deal with twig templates, so they use XB.

I chatted with @phenaproxima about this. It seems like if the script is updated to only uninstall if experience_builder.demo_mode is true, then wiping with each update is ok. ✨ Add a code-only (not changeable via UI) "demo mode" flag that Drupal CMS can set and that future XB MRs can use to constrain XB functionality Active explicitly added this for Drupal CMS so I can't imagine others will use it. It seems like it is up to Drupal CMS to provide the message around.

Just to be careful I think we should update the description of demo_mode in config/schema/experience_builder.schema.yml to explain this behavior. This will avoid people finding this setting and not understanding what the implications of setting is, and this issue is definitely adding more implications for setting this flag.

Need to check demo_mode and update demo mode description

This seems like a general problem that if you are using a Alpha version of the module each update is going to risk problems, maybe very bad ones, when you update the module. But that seems to risk you would also take with using any alpha module.

I agree with this for someone that installs the alpha module themselves.

For Drupal CMS users, the XB demo is going to be promoted as part of the default install, and I think maybe even XB was going to be installed by default without any user intervention at all.

That means that production Drupal CMS sites would have XB enabled, and then if there are breaking changes (like a config entity type ceasing to exist), their sites may not be updateable, at all. e.g. not just loss of XB data, but a hosed site that fatal errors after update with no obvious way to restore.

This is where the uninstall and reinstall idea came from, to avoid that situation and instead restore XB to a blank slate every time it's updated.

But that approach then creates its own various problems that now XB keeps getting uninstalled and reinstalled, needing the composer script because that's the only place to intervene etc.

I would re-iterate again, that I think all of this could be avoided if the energy spent here instead went into an online demo with tugboat or similar, until XB actually can provide an upgrade path for its config (e.g. reaches beta) and doesn't need these extreme measures. Trying to create an ephemeral demo on what are supposed to be production installs is just inviting catastrophic data loss or inability to update, in the various myriad forms those issues could appear.

@catch my general concern from #11 that you were responding to in #15, is not an issue for me if we implement #12. Basically just only do this for demo_mode, which I think practically this means only do this for Drupal CMS.

I agree with this for someone that installs the alpha module themselves.

So if this only affects demo_mode/Drupal CMS then I think others can use the alpha module like any other alpha module

...Trying to create an ephemeral demo on what are supposed to be production installs is just inviting catastrophic data loss or inability to update, in the various myriad forms those issues could appear.

I haven't been involved in the discussion around but I can see your point.

Is there another issue where I can see the discussion?. If demo_mode is done I want to see if there is anything we can do to lesson the risk in XB itself

@tedbow there are a lot of issues about this now, bits of discussion in:

🐛 Cannot download and install new modules using Project Browser (developer experience) Active 🌱 Milestone 0.2.0: the one for Drupal CMS 1.0 Active 📌 Create a specialized recipe to hold the XB demo Active 📌 Make Experience Builder a production dependency Postponed

This might be a wontfix (yay!) in the likely event that 📌 Remove the XB demo Active comes to pass. Postponing until we know the status of that issue.