Don't edit or preview blocks in the customizer

[draganescu]

It appears that there is a problem with making the Customiser auto refresh and auto update the changes made to blocks. (#25157, #25153, #25154)

When the embedded Gutenberg editor in the customiser's sidebar has some changes, the changes are not picked up by the auto preview system, because it expects a certain HTML to exist. Also, it seems the object based architecture of the whole Customiser encapsulates things in a way that makes the widget auto preview API not available if each control is not registered before.

The JS API of the customiser leads to a solution where we don't replace the widgets panel with a full blown editor, but instead we maintain it and each widget will show up as it does today, plus the blocks as a Block widget.

The more complex option is to instance a small editor for each block widget and maybe that would be picked up by the auto preview system, as it contains generic inputs, but no guarantees.

The less complex but more straightforward option is to allow the widgets to be editable as they are now, but to not allow block widgets to be editable in the customiser. The blocks will appear as block widgets and they will NOT be editable in the customizer, instead we can add an edit link that takes the user to the widget editor.

It is not the most seamless of user experiences, to say it lightly. On the other hand, it can be a good 1st iteration, with an eventual later improvement. Any other ideas or pointers to missed technical solutions are welcome 👍

cc @mapk @mtias @youknowriad

See #25626 for implementation.

[pagelab]

The blocks will appear as block widgets and they will NOT be editable in the customizer, instead we can add an edit link that takes the user to the widget editor.

It only makes sense to pursue this simpler option if the more complex option is guaranteed to work. So, IMO, the more complex one should be tested and implemented right away.

[draganescu]

What do you mean @pagelab ?

It only makes sense to pursue this simpler option if the more complex option is guaranteed to work.

It's not guaranteed 😆 what is in software development? Maybe it will work, but the key here is that this mini editor in each widget panel will probably gonna seriously cut the chances of the widgets editor in 5.6.

We can come up with a solution later and the good parts of the simple option is that it allows us to improve later in a fully backward compatible way.

[pagelab]

What do you mean @pagelab ?

Sorry for not being very clear, @draganescu. 😄

I mean, what's the point of adding non-editable block widgets there?

This will probably just frustrate users.

[mapk]

This will probably just frustrate users.

I agree here, but if we're allowing users to add blocks to the Widget areas in wp-admin than this should be reflected somehow in the Customizer. Let's say I add a Paragraph block and a 3rd party widget in the wp-admin screen. I'd like to see these both reflected in the Customizer as well. If I add another widget through the Customizer, I still want to, at the very least, see the Paragraph block too, even if I can't edit it.

This would be a frustrating experience though. Does @celloexpressions (Customizer maintainer) have any input on how we can move forward?

[draganescu]

@mapk as #25626 shows everything will be visible in the Customizer, but the blocks won't be editable directly there, with preview. They'd be editable in the widgets editor.

[mapk]

as #25626 shows everything will be visible in the Customizer, but the blocks won't be editable directly there, with preview. They'd be editable in the widgets editor.

Yea, that might have to work for now.

[francescamarano]

Hello folx!
From the conversation, it's my understanding that this feature won't be ready for WordPress 5.6 Beta 1 (October 20th), so I will link to it in the upcoming post with updates from 5.6.
Thanks for all your hard work!

[draganescu]

This is closed by #25626 and I'll open a new issue about finding a solution to the problem itself.

[celloexpressions]

I didn't get a notification for the mention above for some reason. Fortunately I stumbled upon this issue.

The problem seems to be that the block editor implementation didn't correctly implement the customize API, particularly settings. Everything is object-based, with panels (widgets), sections (widget areas), settings (for each widget) and associated controls (for each widget). The block editor needs to map to each of these objects as appropriate. When the settings are correctly mapped to the UI, then everything is previewable and savable. Also of the issues described above point to the settings not working.

There is a fundamental issue with the approach here. Much of the widgets panel in the customizer may need to be refactored to work seamlessly with blocks, similar to the widgets screen in wp-admin. The legacy code to make the legacy widgets API work likely needs to stay, but the rest of the customize JS can be updated to integrate with the Gutenberg JS. Someone familiar with the block editor JS will need to figure out the best way to implement this integration.

This would have been much easier if Gutenberg was written extending the customize API in the first place (similar to the proposed settings API, as I suggested in 2017), but it should still be possible now.