Seit der Einführung von Gutenberg berichten wir hier in regelmäßigen Abständen darüber, was sich für Nutzer von WordPress ändert. Wie funktioniert der Gutenberg-Editor? Welche Blöcke gibt es? Wie können Vorlagen oder wiederverwendbare Blöcke erstellt und genutzt werden? Wohin geht die WordPress-Entwicklung?
Worüber wir allerdings noch nicht geredet haben, ist der Theme-Aufbau, der sich mit Einführung der Blöcke gerade grundlegend ändert. Für Autoren und Redakteure ist dieses Theme zwar nicht so relevant, aber als Website-Betreiber bzw. Administrator sollte man sich mit dem Thema auseinandersetzen, auch wenn man selbst nicht Theme-Entwickler ist.
Klassische WordPress-Themes
Ursprünglich bestand ein WordPress-Theme aus verschiedenen Template-Dateien. Diese Template-Dateien waren (vereinfacht gesagt) .php-Dateien, die die entsprechenden Template-Tags, in Kombination mit HTML enthielten. Einfache Themes enthielten Templates für die folgenden Seiten:
- 404.php
- archive.php
- comments.php
- footer.php
- front-page.php
- header.php
- index.php
- page.php
- search.php
- sidebar.php
- single.php
Zwingend notwendig waren aber nur die Dateien header.php und footer.php sowie die index.php.
Die index.php des Standard-Themes Twenty Nineteen sieht wie folgt aus:
<?php
/**
* The main template file
*
* This is the most generic template file in a WordPress theme
* and one of the two required files for a theme (the other being style.css).
* It is used to display a page when nothing more specific matches a query.
* E.g., it puts together the home page when no home.php file exists.
*
* @link https://developer.wordpress.org/themes/basics/template-hierarchy/
*
* @package WordPress
* @subpackage Twenty_Nineteen
* @since Twenty Nineteen 1.0
*/
get_header();
?>
<div id="primary" class="content-area">
<main id="main" class="site-main">
<?php
if ( have_posts() ) {
// Load posts loop.
while ( have_posts() ) {
the_post();
get_template_part( 'template-parts/content/content' );
}
// Previous/next page navigation.
twentynineteen_the_posts_navigation();
} else {
// If no content, include the "No posts found" template.
get_template_part( 'template-parts/content/content', 'none' );
}
?>
</main><!-- .site-main -->
</div><!-- .content-area -->
<?php
get_footer();
Man erkennt hier sehr schön die Template-Tags, die gemeinsam mit HTML-Code die Struktur der Seite abbilden. Es gibt Verweise auf weitere Template-Dateien in Unterordnern. Dies vereinfacht den Zugriff auf wiederkehrende Elemente, die in verschiedenen Template-Dateien eingebunden werden können.
Dazu kommen noch die folgenden Dateien:
- functions.php
- README.txt
- rtl.css
- screenshot.png
- style.css
Hier sind insbesondere die style.css zu nennen, die alle CSS-Anweisungen enthält sowie die functions.php.
Neue Block-Themes
Durch die Umstellung auf Block-Themes werden Theme-Dateien in Zukunft völlig anders aufgebaut sein. Die index.php ist leer und nach den anderen PHP-Dateien sucht man vergeblich. Stattdessen gibt es Block-Templates und Block-Template-Parts mit dazugehörigen Ordnern und hier befinden sich html-Dateien.
Zu den Block-Templates gehören die folgenden Dateien (hier am Beispiel des Standard Themes Twenty Twentytwo):
- 404.html
- front-page.html
- index.html
- page.html
- single.html
Zu den Block Templateparts gehören die Dateien
- footer.html
- header-large-dark.html
- header.html
Diese Template-Teile können dann in die Template-Parts integriert werden.
Außerhalb der Ordner findet man noch die theme.json. Hier finden sich alle Design-Möglichkeiten für das Theme, wobei CSS-Anweisungen auch innerhalb der Templates hinterlegt werden können. Genauere Informationen dazu findet ihr bei wordpress.org.
Vergleichbar mit der “alten” index.php ist nun die index.html:
<!-- wp:template-part {"slug":"header","tagName":"header","style":{"spacing":{"padding":{"right":"max(1.25rem, 5vw)","left":"max(1.25rem, 5vw)"}}},"layout":{"inherit":true}} /-->
<!-- wp:group {"style":{"spacing":{"padding":{"right":"max(1.25rem, 5vw)","left":"max(1.25rem, 5vw)"}}}} -->
<div class="wp-block-group" style="padding-right:max(1.25rem, 5vw);padding-left:max(1.25rem, 5vw)"><!-- wp:query {"queryId":1,"query":{"offset":0,"postType":"post","categoryIds":[],"tagIds":[],"order":"desc","orderBy":"date","author":"","search":"","sticky":"","perPage":10},"tagName":"main","displayLayout":{"type":"flex","columns":3},"layout":{"inherit":true}} -->
<main class="wp-block-query"><!-- wp:post-template {"align":"wide"} -->
<!-- wp:post-featured-image {"isLink":true,"width":"100%","height":"318px"} /-->
<!-- wp:post-title {"isLink":true,"fontSize":"large"} /-->
<!-- wp:post-excerpt /-->
<!-- wp:post-date {"format":"F j, Y","isLink":true,"fontSize":"small"} /-->
<!-- /wp:post-template -->
<!-- wp:separator {"align":"wide","className":"is-style-wide"} -->
<hr class="wp-block-separator alignwide is-style-wide"/>
<!-- /wp:separator -->
<!-- wp:query-pagination {"paginationArrow":"arrow","align":"wide","layout":{"type":"flex","justifyContent":"space-between"}} -->
<!-- wp:query-pagination-previous {"fontSize":"small"} /-->
<!-- wp:query-pagination-numbers /-->
<!-- wp:query-pagination-next {"fontSize":"small"} /-->
<!-- /wp:query-pagination --></main>
<!-- /wp:query --></div>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer","layout":{"inherit":true}} /-->Auch hier findet man Verweise auf andere Dateien (Templateparts), aber anstatt Template-Tags findet man nun den HTML-Code für Blöcke.
Erstellt man sich nun eigene Templates oder Templateteile, stehen diese zusätzlich zu den vom Theme vorgesehenen Templates zur Verfügung. Sie bleiben auch bei einem Theme-Wechsel bestehen.
Child-Themes
Besonders spannend ist diese Umstellung auch in Hinblick auf Child-Themes. Werden diese in Zukunft überhaupt noch benötigt und falls ja, wie funktionieren sie? Eine anregende Diskussion zum Theme Child-Themes gab es auf Twitter.
Image(s) licensed by Ingram Image/adpic.
Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienstleistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.
DAS IS VERRÜCKT!!
Die neuen Templates sind…verrückt!
> Vergleichbar mit der “alten” index.php ist nun die index.html:
Jedesmal, wenn ich mir die neuen Templates anschaue, greif ich mir auf den Kopf.
Vorher hatte man standardkonformes HTML und lesbares PHP – eben durchmischt mit Template-Tags.
Tags, die Funktionen waren. Funktionen, die dir jede gute IDE (zb PHPStorm) auflösen konnte.
Auflösen heißt, dass du zur Funktionsbeschreibung springen konntest. Du dir also anschauen konntest, was hinter der Funktion, also dem Template-Tag, steckt.
Jetzt?
Das ist eine künstlich erfundene Sprache.
I don’t get it.
Das soll der Weisheit letzter Schluss sein?
Weit weg von jedem Standard?
Mit einer hohen Eintrittshürde – also dem konträren Programm zu früher?
@souri
Passt aber doch prima zu der üblen Art und Weise, wie die Blöcke in der Datenbank gespeichert werden. Als ich zum ersten Mal gesehen haben, dass alle Blöcke einer Seite in einen Datensatz geschrieben werden und dort nur durch Kommentare getrennt werden, habe ich nur noch mit dem Kopf geschüttelt.
Ich stimme den beiden Kommentaren vor dem meinigen aus absoluter Überzeugung und aus vollem Herzen zu.
Gutenberg wird immer mehr zum Fiasko. Ich hatte mal ein kurzes Video über den Navigator (in GB 11.7) gemacht:
https://app.vidstep.io/watch/WbnMksPDF2Ih1bgwSGy7
Rechts ist eine Seitenleiste, die das, was man sieht, kommentiert/erläutert. Man muss auch dazu bedenken, dass der Navigator seit 2? Jahren in Entwicklung ist.
Und Navigator ist nur ein Element eines FSE-Themes. Kleine Randnotiz: Die Entwicklungszeit von Gutenberg ist nahezu identisch mit der von Elementor …
Jedes Mal, wenn ich GB erneut teste, packt mich das kalte Grauen. So ein schlechtes UI ist mir selten vor die Linsen gekommen. Es ist auch Kunden nicht zu vermitteln. Mich hat schon so manches Mal der Gedanke beschlichen, ob da irgendwie eine geheime Wette läuft, wer die meisten Klickwege produzieren kann.
Zurück zum FSE: Glücklicherweise gibt es (mindestens) 1 Plugin, das es ermöglicht komplett auf Themes zu verzichten.
Leider kann man sich nicht von WordPress komplett abkoppeln, so wie es ClassicPress versuchte. Denn dieser Weg führt dann auch zum Fiasko: Nämlich demselben, den es damals auch bei TYPO3 mit der Version 3 gab. Viele Websites auf TYPO3 sind auf die alte Version – mit all den Problemen hinsichtlich Sicherheit und Support, weil die Admins nicht in der Lage waren, den Core upzudaten.
Von daher sollte man bei dem Blick über den CMS-Tellerrand schon gelernt haben, dass es so nicht geht. Zumindest solange nicht, bis man nicht einen signifikanten Teil der Core-Devs mitnimmt.
(Das ist bei ClassicPress nicht der Fall. Nach dem was ich hörte, sind da nur noch 3 Leute aktiv. Das Forum dort ist auch eher einsam.)
Ich vermute es wird auf eine gemeinsame Welt für alle hinauslaufen:
– Wir bleiben im WordPress
– Aber der Editor bleibt -wie auch bisher- eine Option: Man kann und dies zeigt beispielsweise das Plugin Iceberg, durchaus den Block Editor so einfangen, dass er einen anderen Editor nutzt als den Gutenberg.
Dann wird es eben nur noch einen “Block” geben, und der hat dann zufälligerweise den Namen “Markdown Editor”, “TinyMCE Editor”, “Classic Editor” oder “HTML-Editor”.
– Man wird auch Wege finden, das Full Site Editing abzuschalten. Dies wird insbesondere wichtig sein, wenn man WordPress weiterhin als CMS und nicht als Blogsystem sieht.
– Es sollte auch kein Problem sein, diese neue wirre Form der HTML-Kommentaranweisungen, die in Gutenberg für Blockanweisungen verwendet werden, in Shortcodes umzuwandeln – oder eben Shortcodes in diese Art der Darstellung. Denn beides sind ja syntaktisch interpretierbare Anweisungsblöcke. Also kann man sie sowohl in die eine, wie auch die andere Richtung übersetzen. Würde mich nicht wundern, wenn es dazu kängst ein Plugin gäbe.
Im bin jetzt nicht Teil des Cores oder einer anderen Community. Ich bin nur an der Theme- und Plugin-Entwicklung drin, aber hauptsächlich bin ich so ne Art Provider für eine nicht gerade kleine Multi-Multisite-Instanz. Von daher ist meine obige Vermutung, wie es sich entwickeln wird, natürlich etwas ins Blaue geraten.
Aber meiner Erfahrung nach setzen sich am Ende die Bedürfnisse der Anwender durch. Einfach weil das viel mehr Leute sind und dadurch die Masse der Rückfragen/Hilfegesuche/Problemmeldungen von dieser Seite selbst den härtesten Kern an Admins und Devs irgendwann schleift und dazu bringen wird, entweder das Handtuch zu schmeissen oder die GUI doch wieder Benutzerfreundlich (im Sinne der User und nicht der Admins) zu machen.
Wenn das was einige -etwas überspitzt gesagt- React-Fanboys nun ihr Ding durchziehen, dann ist das erstmal für die toll. Man sieht es ja auch auf den Blogbeiträgen bei der Community, wie begeistert da einige von ihrem Block-Editor sind. Finde ich auch gut, wenn Leute mit Herz und Seele dabei sind.
Aber trotzdem muss es am Ende für die User passen.
Und wenn diese allein schon daran scheitern, ein einfaches Copy&Paste von Inhalten zu machen, weil der Block Editor ungefragt aus Absätzen Einzelblöcke macht, die man dann nicht mehr zusammen selektieren kann, dann wird das Ding nicht angenommen.
Die Leute werden dann mit ihren Füßen abstimmen und eben den Classic Editor fordern.