Allow CMS Author to set site's homepage from navigation

Okay, I think this jumps the shark a bit as we have no way to stage configuration changes.

Approach 1: base field on xb_page

- There is a new "hidden"/internal boolean flag on pages called homepage
- Mark as homepage actually toggles a base field, which goes to auto save
- On preSave we see if homepage === TRUE, change system.site and remove the value of homepage

problem: how to prevent marking multiple as homepage in autosave data?

Approach 2: make ApiPublishAllController aware of frontpage concept

- the concept of what would be the new homepage cannot live in the entity data
- needs to be part of staged config changes

create a one-off snowflake concept in AutoSaveManager to track changes for the homepage (system.site.path.front) only

I think approach 1 is fine until we add Workspaces integration.

problem: how to prevent marking multiple as homepage in autosave data?

Do we need to? Why not just let the last save win?

Why not just let the last save win?

Perfectly acceptable to me!

CI is failing, but I'd rather get reviews on the approach before fixing.

🏓 https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...

I need to update the issue summary with changes on the approach from the MR

I pushed to the MR with changes to use AutoSaveManager for handling simple config changes. It's not 100% done but enough to review and validate as an approach.

See review on MR; AFAICT this is blocked on ✨ Auto-save code components Active . Notified @tedbow over at #3500042-37: Auto-save code components → an hour ago.

✨ Auto-save code components Active is in, and responded on the MR 👍

But also now that I am thinking about. What happens if you delete the page you set as the home page?

We should not allow deleting the home page. User would have to assign another page as a home page before they could delete it. I'll let you decide if we should implement that here or in another issue.

wim leers → credited tedbow → .

#16 seems reasonable to consider part of this issue from a UX POV, but I don't think it makes practical sense.

Because it would need to work generically, not just for the Page content entity type. Plus, it'd require no longer hardcoding the link in the UI. Wrote up a detailed plan at 📌 Disallow deleting an XB-enabled content entity if it's currently the homepage Active .

The UI doesn't currently convey:

• that the currently viewed page is the current homepage
• that the currently viewed page is about to become the current homepage (thanks to auto-saving)
• which page in the list is the current homepage

I also think that the UI strings are quite confusing, which @tedbow also pointed out in the MR.

This is what it all currently looks like:

@mglaman has indicated these aspects are missing from the design.

To clarify: I defer to @lauriii where to draw the line, but if not everything in #19 is addressed here, there will definitely need to be one or more follow-ups.

Also, can we link the designs in the issue summary? 🙏

We don't have full designs for this flow but attaching a design that shows how the homepage would look like in the navigator / top bar which addresses most of the concerns. The home icon should appear in the review changes panel too. We could open a follow-up to explore if we need to clarify this action in the review changes panel.

Let's focus on the deletion aspect in 📌 Disallow deleting an XB-enabled content entity if it's currently the homepage Active .

#22: that doesn't address .

I don't really understand the confirmation panel. What are we trying to warn the user about? I don't remember seeing designs with a confirmation panel. I understand that we have a confirmation panel for deleting a page since it takes place immediately. But since changing home page goes through the review changes I don't see why we need the warning.

Setting a draft page as home page would be fine since it would be published once we have 📌 Create an endpoint to publish all auto-saved entities Active . We need to think about archived content in relation to setting a home page once we implement support for that.

This ended up in my sprint and need to upload. But I think one of the remaining blockers was the missing 🏠 icon if a page/entity/whatever in the navigation has a path which matches system.site.path.front?

mglaman → changed the visibility of the branch 0.x to hidden.

I've recreated the MR https://git.drupalcode.org/project/experience_builder/-/merge_requests/882

mglaman → changed the visibility of the branch 3503412-allow-cms-author to hidden.

mglaman → closed merge request !614

I consider the MR is 90%. It needs review on the approach.

This is not passing tests, unfortunately, so not ready for review.

FYI: this issue's MR contains a superset of what 🐛 Define what should happen if you delete a page while you are editing it Active 's initial MR (!804) was also trying to achieve. 😅🙈 Unfortunate to see so much waste.

Since this was last worked on, 🐛 Page status changes from "Published" to "Changed" even when no actual changes are made Active landed, so now the autosave manager may only save entities (EntityInterface objects). We could expand that to allow simple config, but I'm curious what you all think of the following idea instead...

What if we created a new entity type (neither a content entity nor a config entity, just an EntityInterface object) that can contain one or more config actions? It would have no storage but could be saved to autosave, and its save() method would instead apply the config actions.

Would that be a nice way to achieve the goal of this issue? It would have the added benefit of not having to deal with conflicts if keys in system.site other than page.front got changed outside of XB.

Yeah that works for me, the alternative is to add a new method to the auto save manager ::saveSimpleConfig::/getSimpleConfig which is also fine if the new entity-path is too long

Okay, stepping up for Round 3 on this thing. I like #36 vs a config entity wrapping/representing the simple config. Also possibly easier to display change in pending changes.

mglaman → changed the visibility of the branch 3503412-set-page-as-homepage-simplify to hidden.