How/if to improve save workflows to notify users of specific post data changes?

[SantosGuillamot]

Context

Block bindings API has introduced the possibility of editing the value of custom fields directly from the editor. This means that if you have a paragraph connected to post meta, when you edit the paragraph you are actually editing the value of the custom field and not the content of the block.

In order to clarify that for users, this pull request introduced some logic to trigger the "Save panel" noticing when the post meta changes. However, it has been reverted here because it was reusing the multi-entity save workflow, even when the user edits just a single entity (the post). This didn't seem right, and it was causing some issues:

• After saving, it triggered a "Site updated" message: link.
• After saving, two requests with the same purpose were triggered: link.
• When locking the "Save" button, it was still clickable: link.

(You can see the before and after in the pull request reverting the changes)

These are just the reported ones, but I assume there might be more we didn't encounter.

For these reasons, I'm opening this issue to think about these workflows holistically to ensure whatever we build fits all the requirements and doesn't break the existing experience.

There have been multiple conversations in multiple places, but I thought it could be better to have the whole context in the same place to ensure we make informed decisions.

Questions / Discussions

I've tried to gather the different discussions related to this topic

1. Should we trigger the save panel in "single-entity" changes?

At this moment, when you are in a post and you edit anything related to that post, you just have to click the "Save" button, and it will save as expected. This means that if you edit a custom field and you click save, it will just save.

However, editing custom fields through connected block introduces a new paradigm: When users edit a paragraph that is connected to a custom field, how do they know that they are editing a custom field instead of the post content?

For that reason, it was suggested to have a similar workflow as the "multi-entity" save has. The idea was to trigger the panel before saving the post to notify the users that post meta had changed.

If this is desired, we need to explore creating a "single-entity" workflow instead of hooking into the "multi-entity" one.

This is an example of the Save panel that was triggering when you edit a custom field in a post:

As you can see, there are a few things wrong related to using the "multi-entity" workflow. For example, we can see the "Site updated" message and you can uncheck the current post which I am not sure it makes sense.

2. If so, which post data should trigger this panel?

Originally, only post meta changes were triggering this panel for "single-entity". However, we need to revisit if this should be the case for other fields like title, description, excerpt, etc.

3. Should users be able to deselect some of the changes? Which ones?

In the "multi-entity" workflow, when you modify multiple entities, you can deselect the ones that you don't want to save.

So, if we decide to add a similar workflow for post data in "single-entity" changes, should we provide this possibility?

Something like the following, where we modify multiple templates, but including post meta, post title, post description...

Another possibility could be to just show a bullet list like the "Custom Styles" one. It is something that was being explored to list the modified custom fields: link.

If we follow that approach, we have to decide if we want to provide this possibility for custom fields as well.

Back then, @jasmussen shared some mockups to show how it could look like: link.

4. How would this integrate with the "multi-entity" save workflow?

Whatever we decide should work on the "multi-entity" workflow as well, and there are a few things that might need some discussion. For example, right now most of the messages there track "site changes". Which message should we show when we edit a bunch of posts? Is "site updated" still accurate?

Related discussion happened here: link.

5. Should it be integrated into the pre-publish workflow?

Related issue: link.

If we decide to trigger the panel when saving a single entity, it could make sense to trigger it in the pre-publish workflow as well. The use case there is slightly different, so we would need to ensure everything integrates correctly.

---

Something I am missing @artemiomorales @cbravobernal ? More questions?

I'd love to hear any thoughts on everything related to this 🙂

[cbravobernal]

Thanks @SantosGuillamot for opening this issue.

how do they know that they are editing a custom field instead of the post content?

Why they need to know it?

I understand that a double confirmation is needed if you are changing a global setting in the whole site when you change it in a custom post or page, in order to prevent user misunderstandings.

But if the custom field content is per post / type, why adding that additional check?

My point of view is that a user that is changing a post doesn't care if it is a custom field, a block or whatever, they want to change that value inside that post or page. Right now, plugins like ACF just provide an input that is changed and saved like any post content.

Imagine you edit The Godfather movie (as the web responsible): https://wpmovies.dev/movies/the-godfather/

The budget changed, you go to the post, edit the budget, save, gets updated. You don't care if it is a custom field or not.

I think one potential benefit of block bindings could be layout prepopulation, giving the user an example of how a post should be done (I'm thinking about big publishers or heavily CMS based sites), in that case, if you are changing that layout, we should be able to differentiate the layout vs content approach.

And, now that you mention, I think is really important to land the revert before messing with the save workflow for literally millions of users 😅

[SantosGuillamot]

Why they need to know it?

Maybe they don't need to know. I just wanted to bring the question to hear opinions 🙂 I am not sure which is the best approach. I can imagine that if they are using the post content or the post meta in other places, it could also get confusing.

Right now, plugins like ACF just provide an input that is changed and saved like any post content.

Yes, but they have a dedicated place. With bindings, you use the same rich text to edit the post content or the custom field.

I think one potential benefit of block bindings could be layout prepopulation

This is something I'd like to explore in the future.

[cbravobernal]

I can imagine that if they are using the post content or the post meta in other places, it could also get confusing.

But for that you need to develop a custom thing calling that specific post. If you are changing post titles, and you have a list of them somewhere, is expected they will change.

Yes, but they have a dedicated place. With bindings, you use the same rich text to edit the post content or the custom field.

And first idea of block bindings has been always not needing that dedicated place, and just use the editor, which should be the most natural way. Again, changing the budget in the editor (where is shown) should be a better experience than changing it in a field (for example that way you can check that the content is too long for that, something you cannot do in a field)

[artemiomorales]

Maybe they don't need to know. I just wanted to bring the question to hear opinions 🙂 I am not sure which is the best approach. I can imagine that if they are using the post content or the post meta in other places, it could also get confusing.

As I think on it, I'm with Carlos. I don't think we need to surface the fact that the Post Meta has changed, not yet anyway.

There may be cases in which it would beneficial to trigger a notification, but we could err on the side of less UI and less cognitive overload for now and move ahead without one. And based on feedback, if it turns out users would prefer to have the indication, then we could implement one at that point.