Full Site Editing: Site Title Block [8]

[gwwar]

Let's create a site title new block in the full site editing plugin that is backed by the “blogname” record in the wp_options table. This means that we can update this value by:

1. In the FSE using this Site Title block
2. “Site Title” set in /wp-admin/options-general.php
3. In the Customizer under Site Identity

Changes made in any of these areas should be correctly reflected.

Please verify if we need to respect any related title hooks on display.

We should not display anything on the published view, if "Display Site Title" is unchecked in the Customizer. Optional if we want to show this as a block option.

The site title can be be fetched/updated via core's /settings endpoint as the title member.

See also: paAmJe-nP-p2

[apeatling]

Be sure to take a look at and reuse @mattwiebe's MVP block work where possible (although it was a combined header block).

[gwwar]

cc @mattwiebe @obenland @mtias if you'd like to add any notes on requirements

[mattwiebe]

The header block lived most of its dev life as separate title and description blocks and extracting them as such from the MVP should be pretty easy.

Note that Gutenberg does not provide any facility for option-backed blocks. The workarounds I did were, um, creative. Since the value is not serialized into the block itself, as Gutenberg expects, we have to use fake object attributes (that unfortunately get serialized) which we continually update in order to trick Gutenberg into believing the block has been updated. I also had to listen to various internal events in order to orchestrate saving.)

This would seem to be a good time to try to shepherd WordPress/gutenberg#3112 to completion. Core will need it sooner or later and sooner is much better for us.

[apeatling]

Is this one in progress @codebykat? I was looking at the team board and moved it, but then wasn't sure.

[gwwar]

@codebykat is writing up some details on the site options work needed. Currently Gutenberg is not aware of this state, and it needs to be added in some form.

[apeatling]

Okay, for the first launch would @mattwiebe's original "creative" solution work? To quote Dennis -- "make it work, make it right, make it fast". ;)

[gwwar]

@apeatling I don't think the creative solution is worth it if the technical costs here are maybe another local editor store/API endpoint. The work here I think should be straightforward but we can maybe move with a "creative" fix + Gutenberg PR if we need explicit Gutenberg updates and can't wait for a proper release.

[codebykat]

Handing this one off for sabbatical!

Internal discussion is at paYKcK-4a-p2 with next steps, but for now we're not going to worry about the EditorProvider stuff that would let us hook a custom source to the block, and instead will try building this as a dynamic block. The text that is serialized is just a placeholder (e.g. <!-- a8c:site-title -->), and the actual work would happen in other handlers (save is a no-op, there's a handler on the PHP side to render it which pulls from the existing options store, and we need some custom edit handling to dispatch the API site option updates. We might also need some custom handling for preview).

The first thing to try here is to get @mattwiebe's implementation of the site title block from the MVP working as a standalone block (within post content / the current Gutenberg editor is fine). The relevant code is:

• https://github.com/Automattic/site-builder/tree/master/src/site-header
• https://github.com/Automattic/site-builder/tree/master/src/settings-helper (used here)

[gwwar]

I would recommend creating a dynamic block here, that doesn't generalize blocks backed by site options. It makes it a bit easier to build and we can replace this later with the core implementation.

In other words, make a named site title block that is a dynamic block.

Within post content, we don't serialize extra properties. It might look similar to something like this in code view <!-- wp:a8c/site-title -->.

The related PHP handler is then responsible for fetching the site title option and rendering that in page.

Most of the work we need to do is within the edit function. Where we allow editing/interaction, save that in-memory (not serialized to post_content), and then make the related API request on publish.

Happy to answer any related questions.

See also:
https://developer.wordpress.org/block-editor/tutorials/block-tutorial/creating-dynamic-blocks/
https://developer.wordpress.org/block-editor/key-concepts/#serialization-and-the-purpose-of-html-comments
https://developer.wordpress.org/block-editor/developers/block-api/block-edit-save/#edit