Bisher wurde der Inhalt eines Beitrags oder einer Seite in die Tabelle wp_posts in der Spalte post_content gespeichert. Doch wie wird das nun gelöst, ist jeder Block ein eigener Datenbank Eintrag?

Der Inhalt von Beiträgen und Seiten wird auch weiterhin komplett in der Spalte post_content in der wp_posts Tabelle abgespeichert. Dies verhindert zum einen das Zusätzliche Abfragen von Datenbankeinträgen, was Performance Einbusen bedeuten würde, zum anderen bietet diese Lösung die beste Abwärtskompatibilität mit den schon bestehenden Inhalten.

Laden

Wenn ein, aus mehreren Blöcken bestehender, Inhalt im Editor geladen wird, wird mit Hilfe eines Parsers der Text in die jeweiligen Blöcke aufgeteilt. In der Informatik nennt man diesen Schritt Serialisierung. Strukturierte Daten werden in eine Sequenzielle Darstellungsform abgebildet. Für die Strukturierung der Blöcke im Inhalt werden HTML Kommentare verwendet. Diese werden vom Parser interpretiert und und so eine geordnete Liste von Blöcken erstellt um den sogenannten Post State zu erzeugen.

<!– wp:heading –>
<h2>Eine Überschrift</h2>
<!– /wp:heading –>

<!– wp:paragraph –>
<p>Hier steht Text</p>
<!– /wp:paragraph –>

Block API und Rendern

Mit Hilfe der Block API werden die einzelnen Blöcke nun interpretiert und visuell dargestellt. Blöcke haben jeweils eine edit() Funktion, die beschreibt wie der Inhalt im Editor interpretiert werden soll. 

Wenn sich Block Attribute oder Inhalte ändern, wird die Darstellung neu gerendert und die rechte Schlaufe des Diagrams einmal durchlaufen. Dies geschieht auch, wenn ein neuer Block hinzugefügt oder entfernt wird.

Serialisieren und Speichern

Wenn der Inhalt nun gespeichert wird, wird jeweils die save() Funktion eines jeden Blocks ausgeführt und eine HTML Darstellung erzeugt. Zusätzlich wird der HTML Kommentar um den Block gesetzt, um ihn beim nächsten Laden wieder interpretieren zu können. Im nächsten Schritt werden die Blöcke der Seite oder des Beitrags zusammengesetzt und wieder in die Spalte abgespeichert.