|
|
|
|
|
|
by jephson
1543 days ago
|
|
|
> from blobs-of-HTML-in-a-database Gutenberg has doubled down on blobs of HTML in the database: everything within `<body>` is stored as one big blob if using "full site editing", including additional markup defined using HTML comments. There is far less separation between data and how it's presented than there ever was with the "classic" editor. |
|
|
This is not correct, surely?
Yes, if you're using FSE you're getting a template from that which is more or less a page. FSE replaces the header/footer/sidebar/widget area thing with an editable scheme.
That is, on one level, a big chunk of HTML -- but it is stored as a block graph (see below). And as far as I am aware the work has been done to allow it to produce HTML5 semantic tags?
There is an insertion point in the FSE template for content from hooks or the loop, which may or may not be returning block graphs. Post content can also now contain loops as created by query blocks, etc.
And yeah, Gutenberg stores as HTML internally.
But the distinction I am drawing here still holds.
The classic model was a blob of post content that was minimally post-processed to expand shortcodes. It didn't attempt to understand the HTML except in a minimal way to figure out if a shortcode should end up in a wrapper tag.
The rest of it was sent straight out into the page (after autop). TinyMCE then tried to deal with it, and had to recognise shortcode patterns. That is what I mean by a "blob": most HTML was handled in an unthinking, unprocessed manner. As text.
In the Gutenberg era they still do store HTML in post_content (for good reason) but it is in a form that can be serialised and deserialised into blocks -- it is not simply markup; it's a complete serialisation format.
https://make.wordpress.org/core/2017/01/17/editor-technical-...
https://developer.wordpress.org/block-editor/explanations/ar...
And unlike in the Classic Editor era where the HTML is handed to TinyMCE for it to sort out, and then sent back and stored as whatever it submitted (minimally filtered), WP can now serialise and deserialise that information as a block graph in both PHP and JS, and there are hooks at both sides.
Yes -- the stored content can be rendered in its frozen form (and will be, by any theme that doesn't know about blocks).
But it can be processed as a block graph instead.
So in fact the data is being stored in a much more semantically accessible way; not only dumb HTML processed with what amounts to regexps.
The fact that it's _also_ effectively HTML in post_content rather than, say, JSON in a new column is a design decision to maximise compatibility.