The status badge should indicate if there are changes to the page

I think the clients existing call to /xb/api/autosave which uses ApiPendingChangesController could be used to if there are auto-saved changes. I am unclear if the client already has info about " current page has been published previously". but if it does there should not be need to be any back end changes.

This would need to be solved though 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active

I suspect both FE and BE are needed. But before that can happen I do think we need to adjust or agree upon terminology here.

Currently in 0.x the status badge can exist in one of two states. Published or Draft. This is currently based on the status of the node. When creating a new node through XB it is set to Draft but, because it’s based on the status of the autosaved version of the node, as soon as an autosave is created (and the page is refreshed) it will be Published. I suspect this is not your intended behaviour.

Step one: We need a way to differentiate between Drupal’s Publish status and our “Publish all changes”. They are both currently called Publish and it’s confusing. I guess also the badge is referred to as the Status Badge but I don't think the intent is to show the node's status value but actually the state based on XB's autosave state.

Step two: Outline exactly what that badge is supposed to show. And when it should show in each of those scenarios.

Ideally we would have a workflow in Figma that shows the status in each of these steps (there may be more, this is off the top of my head)

1. User creates new page and opens it in XB->User makes a change->user reviews and “publishes all changes”
2. User opens an existing page in XB->User makes a change->user reviews and “publishes all changes”
3. User opens an existing page in XB that has an autosave->User makes a change->user reviews and “publishes all changes”

Additionally, there are weird things like
User opens an existing page->User changes the status to “Unpublished” in the page data form->user reviews and “publishes all changes”

Here's a flowchart that I believe should answer the questions from #3:

1. New content is created which has never been published: Draft
2. Content has been published and no changes has been made: Published
3. Changes have been made to content that was previously published: Changed
4. Content that has been published previously but has been since then unpublished: Archived

After some too-ing and fro-ing and meetings I have drawn this which I think captures the states of the Status Button and when each state should be shown.

1. We need some way to determine this and then that info needs to be made available to the React code.
2. As @tedbow said in #2, the response from /xb/api/autosave contains a list of autosave items. Each has an entity type and id that we can compare to the current entity type and id. If there is a match, we know there are changes.
3. Same as 1.

Once we are able to expose the required info for 1 and 3, I don't think the logic on the FE is complex to implement.

wim leers → made their first commit to this issue’s fork.

🤣 Ran into the infamous d.o bug where concurrent edits cause an issue to become unpublished! Oh irony 😆

Forgot to signal this is soft-postponed for #9.2: there is a pure BE MR that can already land and should be reviewed.

But for the FE pieces to happen, both this issue's MR and the one at 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active must have landed.

I believe 📌 Hide "Published" field from Pages Active could use the heuristic defined here for identifying new entities because the pages are created initially as unpublished, but need to be published as part of the "Publish all changes" action.

#12++

Merging in 0.x

meant to assign to myself in #15

MR670 is branched from MR648 and has the additional FE parts to show and update the status badge in UI.

Added test coverage of the new flags. I'm not sure how isNew == FALSE && status == TRUE is supposed to make sense so I didn't test that specific case.

IMHO the back-end MR (648) is ready. I wrote the original, but @longwave refined it.

Short-term vs long-term: we don't know enough yet for long-term solution

I totally hear @larowlan that this is short-term-focused, but that's what we have to do to make this happen in time for Feb 27 (see 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active ) 🙈

Note also that a generalized solution will need to support all of the eligible content entity types: 📌 Allow XB to be used on all node types Active — which we're not at all planning to work on this week.

Front-end cannot achieve final UX without the blocker

Finally, note that

But for the FE pieces to happen, both this issue's MR and the one at 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active must have landed.

in #11 led me to add the [PP-1] prefix. That's still accurate. Reason: without #3502902 fixed, the simple act of previewing an existing entity in XB will cause an auto-save entry to be generated, which in turn will cause the status badge to immediately show Changed. Even though nothing was changed yet!

There was 1 failure:
1) Drupal\Tests\experience_builder\Kernel\ApiLayoutControllerGetTest::testStatusFlags
Failed asserting that false is identical to true.

Glad I added the tests now. Extracted the title generation to its own static method and called it from both places instead of having to keep two strings in sync.

Preparing for the back-end MR to land.

That's in! Now preparing for the sibling front-end MR 😄

Made an MR for the error I mentioned here 🐛 Undefined array key "status[value]" in Drupal\experience_builder\Controller\ApiLayoutController->get() Active

#28: Thanks! I missed that 🙈 It's been a while since we've had 2 independent MRs passing tests but together causing failures. Thanks for restoring sanity so quickly!

Tested this manually. I can't get this to show the "Published" status which I assume is because of 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active . Otherwise this seems to work great! 👏

@lauriii yup - that issue will (should) fix that!

Approved the tiny BE change, and asked a few Qs. Can we get a GIF too? 🙏

AFAICT this is still ready for FE review.

I think this could benefit from having a storybook story for the different kinds of but we can always add that later if we want. Think it's valuable to get this in right now so it's easier to test backend changes i.e. 🐛 Once previewed in XB an entity with no changes will still show up in "Review x changes" Active

Assigning back to Jesse for screenshot/cast

Retitling now that both the BE + FE MRs are in! 😊

To make this issue's work much more impactful: 📌 Status badge and "Review changes" only update after ~10 seconds Active .

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