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

AFAICT a settings.php setting is impossible, because that'd then mean that everybody working on XB would have to set that 😅

Based on the requirements in the issue summary, I think the following implementation would make sense:

• container parameter
• set by a hidden module
• which is installed by a recipe

Tried it and … nope, any already-installed module appears at /admin/modules/uninstall, even if it gains a hidden: true flag. That also means that the hidden submodule choice is equally simple to undo.

So then … I think still doing what I propose above, but labeling the module or something like that would be reasonable? (Perhaps even without the scary/silly suffix.)

I wonder if it would be sensible for a recipe to be able to set a container parameter?

#3: How could it? Recipes can only install config or perform config actions. A container parameter is outside the realm of config.

Or … is my head so far in baby/diaper/poop land that the poop has affected my thinking? 🤣💩

For #3, I was thinking what if the Recipe system could read something from a recipe's yml file and use that to set something in the database that would affect the container parameter. But, I think that's incorrect as you point out. However, instead of setting a container parameter, it could perhaps set state?

Alternatively, what if "demo mode" is actually the default, and instead there's "canary mode"? In this case, Drupal CMS wouldn't need to set anything, and XB could ship with a hidden xb_canary module that can be enabled via Drush, if you want to unlock XB's full functionality?

> Recipes can only install config or perform config actions.

So let's just use config? We don't have to provide UI, and in a future version of XB when we want to remove the flag, we can force-remove the config via an update hook.

I followed the discussions on this issue and thought of trying to implement it the config ways.Attaching the patch(which is just a POC) for what i tried to disable the preview button for now.

Any one has any thoughts on this approach?

Thanks, @utkarsh_33! I agree with #6. Let's just go with what's simplest which is config. Although it means someone could use the config import UI to change it, they could also use that UI to install a hidden module, so I don't think it's worth us jumping through hoops to do something different than config for this.

#7 looks pretty good. Only thing is as far as I know, default isn't supported as a config schema instruction. The way to provide default config is to include a config/install/experience_builder.settings.yml file.

MR reviewed — looks very close!

#6++ — as long as there's no UI, it's probably sufficiently difficult to undo. We could rename it to be more obscure/scary, something like demo_mode_drupal_cms_only_do_not_change? 😅

Are there other obvious things that should be behind this flag? We don't need to get them all in this issue/MR, but if there's any obvious ones, we can get 'em done here.

Addressed the latest feedbacks.Marking it NR again.

LGTM — letting @effulgentsia decide if this is ready to merge, or whether he'd like to make the setting name less obvious/more scary 👻 as described in #10.

Tiny naming nit on the MR, otherwise this also looks good to me. Personally I prefer the simple naming and don't think we need any "scary" key name in config here.

@longwave WFM. @effulgentsia can still change it in a trivial follow-up if he feels strongly.

Still needs sign-off from either @jessebaker, @hooroomoo, @balintbrews or @bnjmnm.

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