Vorlagen

shutterstock 1495869476 - Wordpress Template: Umstellung auf responsive Design

Eine responsive Website zu haben, ist unglaublich wichtig. Dieses Tutorial ist besonders wichtig, wenn Sie noch ein statisches Theme verwenden, das Sie responsive machen möchten.
Dies kann oft einfacher sein, als ein bereits responsives Theme zu nehmen und es an Ihr Design anzupassen. Aber auch wenn Sie nur daran interessiert sind, zu lernen, wie man responsive Design praktisch umsetzt, ist dies der richtige Artikel für Sie.

Wie Sie Ihr WordPress-Theme in Responsive Design umwandeln

Zunächst müssen wir die Grundlagen des Responsive Design durchgehen:

  • Fluid Site Grid mit proportionalen statt festen Maßen
  • Flexible Bilder
  • Implementierung von Designänderungen, um die Benutzerfreundlichkeit für Nicht-Desktop-Geräte zu gewährleisten
  • Verwendung von CSS-Media-Queries zur Definition von Haltepunkten für Designänderungen

 

Von hier aus werden wir lernen, wie wir die oben genannten Punkte nutzen können, um ein statisches WordPress-Theme in ein responsives zu verwandeln.
Seien Sie sich jedoch bewusst, dass die Prinzipien zwar die gleichen bleiben, Ihr Theme aber möglicherweise anders aufgebaut ist als die Beispiele unten.
Betrachten Sie dies daher nur als grobe Orientierung. Möglicherweise müssen Sie einige Anpassungen für Ihre eigene Website vornehmen.

Benötigte Werkzeuge

Die Werkzeuge, die wir für die Umsetzung dieses Projekts benötigen, sind leicht verfügbar.
Zunächst einmal brauchen wir eine Möglichkeit, die HTML- und CSS-Struktur unserer Website zu überprüfen. Mein Lieblingstool dafür ist Firebug, aber Sie können auch die Chrome Developer Tools und die Firefox Developer Tools verwenden. In diesen können Sie Ihre Webseite in verschiedenen Größen anzeigen lassen. So lässt sich zum Beispiel die Breite von einem Ultrawide Monitor simulieren.

Darüber hinaus müssen wir einige PHP- und HTML-Dateien bearbeiten. Ein einfacher Texteditor wie Notepad++ wird dafür funktionieren, aber Sie können auch andere Optionen in diesem Artikel finden.

Vielleicht möchten Sie auch in Erwägung ziehen, Ihre Website in einer lokalen Entwicklungsumgebung einzurichten, damit Sie damit experimentieren können, sie responsive zu machen, ohne Ihre Live-Site durcheinander zu bringen.

1. Standard-Zoom definieren

Unser erster Schritt ist das Einfügen der folgenden Codezeile in den Header unserer Seite:

Damit wird den Browsern mitgeteilt, dass sie Ihre Seiten basierend auf der Gerätebreite rendern sollen, d.h. wenn der verwendete Bildschirm nur 320px breit ist, wird die Website in dieser Größe gerendert, anstatt auf eine größere Standardgröße zurückzufallen.
In WordPress wird dies typischerweise durch das Bearbeiten der Datei header.php in Ihrem Theme-Ordner erreicht, wenn Sie Dinge zum Header der Website hinzufügen. Der Code wird zwischen den Tagsundeingefügt.

2. Fluid-Element-Breiten und -Höhen einstellen

Als Nächstes müssen Sie die Container für die Hauptabschnitte Ihrer Website finden.
Hierfür bietet sich das bereits erwähnte Firebug an, da es die HTML-Struktur Ihrer Website im Browser anzeigen kann.
Ein typisches WordPress-Theme hat die folgenden Elemente:

    • Body
    • Wrapper
    • Kopfzeile
    • Menü
    • Hauptinhalt
    • Seitenleiste
    • Fußzeile

 

Unsere Aufgabe ist es nun, dafür zu sorgen, dass diese nicht statisch, sondern fließend breit definiert sind. Wir tun dies, indem wir das CSS innerhalb des Stylesheets ändern.
Beginnen wir als Beispiel mit dem Wrapper und sagen wir, dass dies das ist, was Sie in Ihrem Stylesheet finden:

 

#wrapper {
width: 900px
}

 

Wie Sie sehen können, handelt es sich um eine feste Breite (900 Pixel), die wir nun in etwas Fließendes umwandeln wollen:

 

#wrapper {
max-width: 900px;
width: 100%
}

 

Was bewirkt diese Änderung? Im Grunde wird dem Element mitgeteilt, dass es den gesamten benötigten Platz einnehmen soll, aber seine Breite auf maximal 900 Pixel begrenzt ist.
Auf diese Weise sieht die Seite auf jedem Bildschirm, der größer als 900px ist, genauso aus wie vorher, nimmt aber auf jedem Gerät, das kleiner als 900px ist, die gesamte Breite ein.
Aber das ist im Grunde alles, was es braucht, um ein WordPress-Theme responsive zu machen.

Jetzt müssen Sie nur noch durch Ihre gesamte Seitenstruktur gehen und alle festen Breiten in flüssige Breiten umwandeln, indem Sie Pixel in Prozentwerte ändern. Auf diese Weise passen sich die Seitenelemente automatisch an die Größe des Bildschirms an, auf dem sie dargestellt werden.

Der Teufel steckt jedoch im Detail, deshalb hier einige wichtige Hinweise:
Jedes Element, das in einem anderen verschachtelt ist und sich über den gesamten Bildschirm erstrecken kann (oder so viel Platz, wie es zur Verfügung hat), kann einfach auf 100 % Breite gesetzt werden (oder sogar automatisch oder ohne Breite). Wenn das übergeordnete Element (z. B. ein Wrapper) eine festgelegte maximale Breite hat, hält sich das untergeordnete Element automatisch an dessen Abmessungen.

Bei anderen Elementen, die in ihrer Ausdehnung begrenzt werden müssen (z. B. Hauptinhalt und Seitenleiste nebeneinander), müssen Sie ein wenig experimentieren, um den richtigen Prozentsatz zu finden, damit das Layout gleich bleibt.

Beachten Sie, dass Prozentangaben in CSS relativ sind. Das heißt, wenn Sie die Breite eines verschachtelten Elements (ein Element innerhalb eines anderen Elements) auf 70 Prozent setzen, nimmt es 70 Prozent des übergeordneten Elements ein, nicht des gesamten Bildschirms. Capisce?

Firebug ist hier Ihr Freund, da es Ihnen erlaubt, Live-Bearbeitungen vorzunehmen und CSS-Änderungen auszuprobieren, während Sie die Auswirkungen auf dem Bildschirm sehen.
Dennoch kann ich aus Erfahrung sagen, dass es eine Weile dauern kann, bis Sie alle festen Maße gefunden haben.

Daher sollte man zusätzlich zu Firebug auch eine Textsuche in seinem Stylesheet durchführen, um alle Deklarationen von Breiten und, wenn man schon dabei ist, Höhen zu finden.

Letzteres liegt daran, dass sich jeder Text innerhalb von HTML-Elementen vertikal ausdehnt, wenn die Bildschirmgröße komprimiert wird.
Um sicherzustellen, dass er nicht aus dem enthaltenen Element herausbricht oder abgeschnitten wird, müssen Sie sicherstellen, dass Sie auch keine festen Höhen haben. Entweder deklarieren Sie überhaupt keine Höhe oder, falls nötig, stellen Sie diese auch auf Prozentwerte um.

Noch ein kurzer Hinweis zu Margins und Paddings, also den Abständen um und innerhalb von HTML-Elementen. Sie sorgen dafür, dass genügend Abstand zwischen den Seitenelementen und um den Inhalt herum vorhanden ist, damit alles verständlich und lesbar ist.

Während es sinnvoll sein kann, diese in relativen Zahlen anzugeben, deklarieren viele Themes da draußen (zum Beispiel das Genesis-Framework) sie in Pixeln.
Da diese Leute wissen, was sie tun, werde ich mich an ihre Methode halten. Die Wahl bleibt jedoch Ihnen überlassen.

Am Ende sollten Sie eine Webseite haben, die sich beim Verkleinern und Vergrößern an die Größe des Browserfensters anpasst.
An diesem Punkt werden viele Seitenelemente wahrscheinlich zusammengestaucht aussehen, was bei weitem nicht das ist, was Sie wollen, aber keine Sorge, dazu kommen wir weiter unten.

3. Bilder skalieren

Danach ist es an der Zeit, dafür zu sorgen, dass unsere Bilder automatisch entsprechend der Bildschirmgröße skaliert werden.
Das geht ganz einfach, indem Sie folgendes in die style.css einfügen:

img {
height: auto;
max-width: 100%;
}

 

Damit deklarieren Sie, dass Bilder in ihrer Originalgröße angezeigt werden sollen, bis ihr Containerelement (oder der Bildschirm) eine Grenze setzt.
Natürlich müssen Sie sich auch im Stylesheet umsehen, ob andere Deklarationen dies überschreiben. Eine Suche nach img hilft dabei.

Für den Fall, dass Sie Bilder in neuen Größen nachbauen müssen, um sie an Ihr neues responsives Design anzupassen, gibt es im WordPress-Verzeichnis genau das richtige Plugin dafür.

4. Implementieren Sie (die richtigen) Haltepunkte

Nachdem wir die grundlegende Responsivität (oder ist das Verantwortung?) eingeführt haben, gehen wir nun zu den Break Points für Ihre Designänderungen über.
Das sind Abbruchpunkte, an denen die Website einige größere Designanpassungen vornimmt, um weiterhin das beste Layout für Ihre Benutzer zu liefern.
Zwei Dinge dazu:

      1. Haltepunkte sollten immer designspezifisch sein, nicht gerätespezifisch. Es gibt einfach zu viele Geräte, um sie alle zu bedienen. Indem Sie sich darauf konzentrieren, was für Ihr Design am sinnvollsten ist, decken Sie automatisch alle Geräte ab, die in Zukunft auf den Markt kommen.
      2. Beginnen Sie mit dem kleinsten Bildschirm und arbeiten Sie sich dann nach oben vor. Der einfachste Weg, Sollbruchstellen zu identifizieren, ist, zuerst sicherzustellen, dass Ihr Design auf Mobiltelefonen gut aussieht, und dann den Bildschirm von dort aus zu erweitern. Wenn Sie einen Punkt bemerken, an dem Ihr Design anfängt, schrecklich auszusehen, ist das Ihr Haltepunkt.

 

Wenn Sie Ihr Browser-Fenster zum ersten Mal auf die Größe eines Handy-Bildschirms schrumpfen, wird es wahrscheinlich keine schöne Seite sein.
Eines der klassischen Probleme an diesem Punkt ist, dass Elemente, die nebeneinander platziert sind, zwar immer noch in ihrer jeweiligen Breite angezeigt werden, jedoch auf einem viel kleineren Raum, wodurch alles unmöglich zu lesen ist.

Daher ist das erste Gebot der Stunde, diese Elemente untereinander zu verschieben.
Ein klassisches Beispiel dafür ist, die Sidebar unter den Inhalt zu schieben, indem man die CSS-Eigenschaften mit einer Media Query ändert.

Dies könnte folgendermaßen aussehen:

 

@media only screen and (max-width: 500px) {
.content {
float: none;
display: block;
width: 100%;
}

.sidebar {
float: none;
display: block;
width: 100%;
}
}

 

Fügen Sie die Abfrage am Ende Ihres Stylesheets ein. Der obige Code sorgt auch dafür, dass sich Ihr Inhalt über den gesamten Bildschirm ausdehnt und lesbar ist.
Danach ist es an der Zeit, sich den Rest der Seite anzusehen und alle notwendigen CSS-Änderungen vorzunehmen, damit die Seite in ihrem aktuellen Format anständig aussieht.
Übernehmen Sie alle Änderungen in Ihre neu erstellte Medienabfrage und speichern Sie das Stylesheet. Gut gemacht!

Jetzt können Sie das Browserfenster langsam nach außen erweitern, um festzustellen, wann das Layout anfängt, unattraktiv auszusehen und Sie Anpassungen vornehmen müssen.
An diesem Punkt erstellen Sie eine neue Media Query und passen das Design entsprechend an.

Um herauszufinden, wie groß Ihr Browserfenster tatsächlich ist, kann ich die Chrome Developer Tools oder dieses Firefox-Plugin empfehlen. Kopieren Sie den obigen Code, passen Sie die max-width-Deklaration der Media-Query an und geben Sie anschließend alle CSS-Änderungen ein, die Sie umsetzen müssen.

Achten Sie darauf, dass Sie die neuen Media Queries am Ende des Stylesheets einfügen, aber oberhalb der bestehenden.

Da CSS-Stile weiter unten die Stile darüber überschreiben, ist es wichtig, dass die Media Queries von größeren zu kleineren Bildschirmgrößen übergehen.
Im Idealfall sollten Sie am Ende ca. 3-5 größere Umbruchpunkte haben und eine Seite, die bei jeder Fenstergröße ein lesbares und attraktives Layout zeigt, bei dem alle Seitenelemente durchgehend intakt bleiben.
Es wird ein bisschen Versuch und Irrtum erfordern, aber Sie werden es schaffen, da bin ich mir sicher.

5. Anpassen von Schriftarten

Als Nächstes wenden wir uns dem Inhalt zu, insbesondere dem Text auf Ihrer Website, da die Wahrscheinlichkeit groß ist, dass Sie irgendwann an dessen Größe herumschrauben müssen.
Besonders Kopfzeilentext passt oft nicht richtig auf kleinere Bildschirme. Achten Sie darauf, wenn Sie sich Ihre Website auf verschiedenen Geräten und in verschiedenen Browserfenstern ansehen.
Zum Glück lässt sich die Schriftgröße auch einfach per CSS innerhalb von Media-Queries steuern, etwa so:

 

@media only screen and (max-width: 450px) {
.site-title, h1 {
font-size: 22px;
}
}

 

Darüber hinaus sollten Sie die Gesamtschriftgröße abhängig von der Größe des Bildschirms, auf dem die Seite angezeigt wird, ändern.

6. Andere Änderungen

Wie bereits im ersten Artikel erwähnt, geht es beim Responsive Design nicht nur darum, dass die Dinge auf einen Bildschirm passen, sondern auch darum, dass die Website benutzbar bleibt.
Daher ist es eine gute Idee, als letzten Schritt Ihre Seite auf die Nutzbarkeit auf verschiedenen Geräten zu überprüfen.
Zum Beispiel kann es manchmal sinnvoll sein, Elemente auf kleineren Bildschirmen auszublenden, wenn sie ohne Maus schwer zu bedienen sind oder einen Teil der Seite verdecken.

Das ist einer der Gründe für die Existenz von ausklappbaren Menüs. Auf Handy-Bildschirmen ist einfach nicht so viel Platz vorhanden. Ich habe auch Schieberegler aus der Version der mobilen Website entfernt, weil sie fast unmöglich zu benutzen waren.
Gehen Sie also mit diesen Gedanken im Hinterkopf über Ihre Website. Wenn Sie ein Besucher wären, was würde Ihnen das Leben leichter machen? Mit Media-Queries können Sie im Grunde alles ändern, was Sie wollen.
Und wenn Sie schon dabei sind, sollten Sie Ihre neue responsive Website durch einige Cross-Browser-Test-Tools laufen lassen, um sicherzustellen, dass alles in verschiedenen Szenarien gut aussieht.

7. Fertigstellen und Feiern

Wenn Sie so weit gekommen sind, herzlichen Glückwunsch! Ihre Website sollte nun vollständig responsive sein und sich an jede Bildschirmgröße anpassen.
Jetzt ist es nicht mehr so schwer, oder? Ich wusste, dass Sie es schaffen können, und ich bin sicher, dass Ihre Besucher und Google sich über das neue Design freuen werden!

Zusammenfassung

Responsive Design ist heutzutage fast schon ein Muss für Websites, und zum Glück bietet WordPress jede Menge Themes, die standardmäßig mobilkompatibel sind.
Sollte Ihr Theme nicht dazugehören, keine Sorge. Mit unserer Fibel zum Responsive Design und den obigen Tipps sollten Sie nun in der Lage sein, diese Situation zu beheben.
Dieser Artikel kann Ihnen zwar nur die Prinzipien beibringen und nicht jeden Fall durchgehen, der auftauchen könnte, aber er reicht aus, um Ihnen den Einstieg zu erleichtern und Ihnen zu ermöglichen, die Details selbst herauszufinden.

Die Verwendung von benutzerdefinierten CSS-Eigenschaften für das WordPress-Admin-Farbschema-System ist für den WordPress-Meilenstein 5.7 aufgeführt. Es fühlt sich unauffällig genug an, dass die meisten es als ein einfaches Upgrade übergehen würden, um mit der Zeit zu gehen. Dieses Feature kann jedoch Wellen erzeugen, die sich ausbreiten und dem Ökosystem in den kommenden Jahren zugute kommen.

Kirsty Burgoine, eine Front-End-Entwicklerin bei Human Made, kündigte die Einführung von benutzerdefinierten CSS-Eigenschaften für den WordPress-Admin an. Die erste Arbeit landete in einem Ticket zur Iteration der Admin-Farbschemata. In der ersten Phase wurde die Farbpalette von 199 Farben auf 99 reduziert, um eine vernünftige Liste zu erstellen, mit der man arbeiten kann.

In der zweiten Phase wird untersucht, wie man ein sinnvolles System für benutzerdefinierte CSS-Eigenschaften implementieren kann. Das bedeutet, die gefürchtete Arbeit der Benennung von Dingen zu erledigen. Das Core-CSS-Team ist derzeit auf der Suche nach Feedback darüber, wie die Eigenschaftsnamen in Zukunft am besten gehandhabt werden sollen und ist offen für alternative Implementierungsvorschläge.

Sobald die benutzerdefinierten Eigenschaften eingeführt sind, könnte das neue System langfristig eine Welt voller Möglichkeiten eröffnen.

Vorausschauend denken

Meine Hoffnungen auf WordPress-Admin-Themes lebten und starben mit jeder Nachricht über benutzerdefinierte Farbschemata, phantasievolle Mockups und den allgemeinen Hype um Projekte, die nie das hielten, was sie versprachen. Vielleicht mache ich mir jetzt wieder Hoffnungen.

Entwickler können seit WordPress 2.5 benutzerdefinierte Admin-Farbschemata registrieren, aber es war nie ein ideales System.

Eines meiner Lieblings-Plugins ist Admin Color Schemes, das von Designern aus dem WordPress-Kernteam gepflegt wird. Es fügt mehrere Schemata hinzu, aus denen die Benutzer wählen können.

Sass, das heute zur Generierung der Admin-Farbschemata im Core verwendet wird, hat den Prozess vereinfacht. Entwickler von Drittanbietern müssen jedoch immer noch dafür sorgen, dass ihre benutzerdefinierten Schemata zwischen den WordPress-Versionen aktualisiert werden. Das System ist nicht dafür ausgelegt, vor zukünftigen Kompatibilitätsproblemen zu schützen.

Benutzerdefinierte CSS-Eigenschaften ändern das Spiel. Mit ihrer weit verbreiteten Verwendung und der Kompatibilität mit modernen Browsern ist das benutzerdefinierte Admin-Thema – zumindest das Farbschema – viel mehr eine Realität.

Ich war nicht mehr so aufgeregt über die Möglichkeit von etwas Neuem, seit Tung Do 2013 sein kurzlebiges DP Dashboard Plugin veröffentlicht hat. Jetzt, ein paar Tage vor acht Jahren seit der ersten Beta-Testphase, habe ich wieder etwas Hoffnung.

In Anbetracht der kleinen Weisheit, die ich im Laufe der Jahre angesammelt habe, sehe ich jetzt, dass komplett angepasste Admin-Themes nie zum richtigen Weg geführt haben. Ich bin froh, dass wir ihn nie eingeschlagen haben. Administrationsoberflächen müssen für die Benutzer konsistent funktionieren und sich im Laufe der Zeit an Änderungen anpassen. Benutzerdefinierte Themes waren jedes Mal, wenn WordPress eine neue Funktion hinzufügte, ein Wartungsalptraum. Ein System, das auf benutzerdefinierten CSS-Eigenschaften aufbaut, bedeutet jedoch, dass Anpassungen nicht kaputt gehen – oder viel seltener kaputt gehen – wenn sich die Benutzeroberfläche der Software weiterentwickelt.

Während der Fokus im Moment auf Farbschemata liegt, hält nichts WordPress davon ab, in der Zukunft weitere Funktionen zu entwickeln. Es ist möglich, ein globales Stylesystem einzurichten, mit dem Designer den Admin auf alle möglichen interessanten Arten gestalten können, ohne etwas kaputt zu machen. Kleinere Optionen wie der Rahmenradius von Schaltflächen, die Wahl der Schriftart oder die Schriftgröße von Überschriften könnten mit der Zeit leicht eingeführt werden.

Da das Blocksystem weiterhin Teile der WordPress-Administration ersetzt, werden benutzerdefinierte Admin-Skins viel einfacher zu pflegen sein. Da alles im Blocksystem als Komponente aufgebaut ist, ist es zukunftssicherer gegen Rückwärtskompatibilitätsprobleme.

Es ist ein langer und kurvenreicher Weg zu einem funktionsreichen Admin-Skin-System. Es liegt jedoch nicht außerhalb des Bereiches des Möglichen.

Ich freue mich auf den Tag, an dem Theme-Autoren einfach Admin-Designs ausrollen können, die zum Frontend passen. Vielleicht ist eine Integration mit der theme.json des Blocksystems eine Möglichkeit. Ich hätte auch nichts dagegen, in Zukunft ein separates Admin-Theme-Verzeichnis zu sehen. Der Anwendungsfall ist vielleicht noch zu nischig, aber es schadet nie, die Idee im Hinterkopf zu behalten.

Zumindest erlaubt der Wechsel zu benutzerdefinierten Eigenschaften dem Team, das Admin-CSS aufzuräumen und macht es einfacher, benutzerdefinierte Farbschemata hinzuzufügen. Das ist ein Gewinn für das WordPress-Projekt.

WordPress 5.7 Beta 1 wurde diese Woche pünktlich veröffentlicht und ist bereit für breitere Tests. Diese Version wird 68 neue Funktionen und Verbesserungen, Dutzende von Fehlerkorrekturen und die Versionen 9.3 – 9.9 des Gutenberg-Plugins enthalten.

Einige der Highlights, die in 5.7 erwartet werden, sind die folgenden

Lazy-load iframes: Als WordPress 5.4 Lazy-Loading für Bilder einführte, diskutierten die Mitwirkenden darüber, dies auch auf Iframes auszuweiten. Nun, da das Lade-Attribut für iframe-Tags zum HTML-Standard hinzugefügt wurde, wird es in 5.7 im Kern unterstützt werden.

Vereinfachte Migration von HTTP zu HTTPS: WordPress kann nun erkennen, ob die Hosting-Umgebung eines Benutzers HTTPS unterstützt und ermöglicht einen Ein-Klick-Aktualisierungsprozess, der gemischte Content-Rewrites behandelt, wo dies möglich ist.

Standardisierung der in WP-Admin-CSS verwendeten Farben auf eine einzige Palette: WordPress implementiert ein System für benutzerdefinierte CSS-Eigenschaften, das das Hinzufügen von benutzerdefinierten Farbschemata vereinfachen wird.

Laufende Aufräumarbeiten nach dem Update auf jQuery 3.5.1

Neue Robots-API: Diese neue API ermöglicht es Entwicklern, den Inhalt des in die Seite eingefügten Robots-Meta-Tags zentral zu verwalten, und enthält eine Einstellung, mit der umgeschaltet werden kann, ob Suchmaschinen große Medien von der Website anzeigen dürfen. Standardmäßig wird eine max-image-preview:large robots-Direktive in das robots-Meta-Tag injiziert, die auf der neuen Einstellung basiert.
Diese Funktionen müssen getestet werden, zusammen mit der Vielzahl von Updates, die vom Gutenberg-Plugin übernommen wurden. Der Editor erhält die sichtbarsten Verbesserungen in 5.7, mit Funktionen wie dem Ziehen von Blöcken und Blockmustern aus dem Inserter in den Canvas, großen Verbesserungen am Button-Block, neuen Social Icons und vielem mehr.

Das offizielle Release wird in knapp fünf Wochen am 9. März 2021 erwartet. Testen ist ein wichtiger Teil des Prozesses, um WordPress mit jedem Update besser zu machen. Der einfachste Weg, um dabei zu sein, ist die Installation des WordPress Beta Tester Plugins (eingestellt auf den Bleeding Edge Channel und den Beta/RC Only Stream), oder das Herunterladen und Installieren der Zip der Beta-Version.

FSE und WordPress-Themes: Wie sieht das MVP aus?

Josepha Haden Chomphosy, die Geschäftsführerin von WordPress, postete eine Fortsetzung ihres Ausblicks auf das kommende Jahr. Es kamen Fragen auf, wie ein Minimum Viable Product (MVP) für Full Site Editing (FSE) aussieht, das im Gutenberg-Plugin voraussichtlich im April fertig sein wird. Das Kernteam strebt außerdem eine Einführung von FSE in WordPress im Juni an, wenn WordPress 5.8 ausgeliefert wird.

Dies scheinen hochgesteckte Ziele zu sein, aber Mitglieder der WordPress-Entwicklungs- und Business-Community fragten sich: „Was ist ein MVP für FSE?“ Dies ist keine neue Frage. Ob es nun das rasante Entwicklungstempo ist, eine Panne in der Kommunikation oder dass so viel von dem Projekt hinter vielen Schichten von GitHub-Problemen versteckt ist, es kann schwer sein, zu folgen. Es gibt keine große Webseite, die jeden Schritt bis ins kleinste Detail beschreibt, wohin das Projekt geht. Informationen können sich manchmal verstreut anfühlen. Das kann Drittentwicklern und Geschäftsinhabern, die wissen müssen, was sie erwarten können, um ihre Produkte zu aktualisieren, eine Pause verschaffen.

Joost de Valk, der CPO von Yoast, äußerte in den Kommentaren seine Frustration über diesen Prozess. Wir haben das später noch einmal genauer besprochen.

„Ich denke, FSE wird verändern, was ein Theme ist, und, wenn es richtig ausgeführt wird, wird es viel einfacher, ein Theme zu bauen, da Themes viel kleiner sein werden“, sagte er. „Das bringt die Last auf die Community, sich zuverlässige Methoden für das Styling auszudenken, und Konventionen für Klassennamen oder ähnliches, damit das Styling überall funktioniert. Ich verstehe derzeit nicht, was überhaupt als MVP für Full Site Editing in Betracht gezogen wird, und ich sehe auch keine Diskussionen darüber, wie es mit Themes funktionieren wird, die nicht speziell dafür gebaut wurden, und das macht mir Sorgen.“

Er teilt einige der gleichen Bedenken wie andere in der Community, die das Gefühl haben, dass es keinen Prozess für einen MVP gibt.

„So etwas gibt es nicht“, sagte er. „Eine Vision ohne Ausführung ist nur eine Halluzination.“

Chomphosy sagte, sie sei sich der Zusammenhänge bewusst. „Ich sehe auch, dass die Informationen, die wir veröffentlicht haben, nicht in einem aufgeräumten und nachvollziehbaren Beitrag sind, der den Leuten helfen würde, gute Entscheidungen für 39% des Webs zu treffen“, sagte sie.

Sie zeigte auf ein Ticket, das sechs (jetzt sieben) Meilensteine auflistet. Jeder dieser Meilensteine stellt zusammengenommen dar, wo FSE für ein MVP sein muss.

„Zusammen skizzieren sie eine Architektur, die es erlaubt, ein komplettes Thema mit Hilfe von Blöcken und einem Editor, der dieses Thema anpassen kann, auszudrücken“, schrieb sie. „Das MVP sollte es ermöglichen, eine Version des Twenty Twenty-One-Themes zu erstellen, die nur Blöcke verwendet, ohne jegliche Programmierkenntnisse.“

Es folgt eine Aufschlüsselung der Meilensteine, die erreicht werden müssen, bevor wir die erste Version von FSE in WordPress landen sehen:

Meilenstein 1: Infrastruktur und UI

Der vielleicht wichtigste Teil von FSE ist ein funktionierender Site-Editor. Die Verschmelzung des WordPress-Templating-Systems mit einer kohärenten Benutzeroberfläche ist die Grundlage des Projekts. Die zugrunde liegende Infrastruktur regelt, wie Templates und Template-Teile funktionieren. An diesem Punkt ist dieses Fundament an einer zuverlässigen Stelle. Es sind alle Funktionen, die darauf aufbauen, die mehr Arbeit benötigen. Dieser Meilenstein beinhaltet auch die Einrichtung der Schnittstelle für die Site-Bearbeitung und die Handhabung des Speicherns mehrerer Einheiten.

Die letzte Etappe des Meilensteins ermöglicht es den Benutzern, Vorlagen aus dem Post-Editor heraus zu bearbeiten und so effektiv zwischen der Bearbeitung von Inhalt und Design zu wechseln. Das FSE Outreach Program hat dieses Feature kürzlich getestet, um Feedback nach Gutenberg 9.6 zu sammeln.

Meilenstein 2: Browsing

Dieser Meilenstein umfasst die gesamte Arbeit für die Navigation auf der UI des Site-Editors. Es gibt viele bewegliche Teile, wie das Wechseln zwischen Seiten, Vorlagen, Vorlagenteilen, globalen Stilen und mehr. Die Benutzer müssen wissen, an welchem Element sie gerade arbeiten.

Dies ist der einzige Meilenstein, der als abgeschlossen markiert ist. Es gibt jedoch ein offenes Ticket für die Erforschung der Idee eines „Browsing“-Modus neben dem Bearbeitungs- und Auswahlmodus.

Meilenstein 3: Styling

Dieser Meilenstein konzentriert sich größtenteils auf das kommende Global Styles System. Das System erstellt eine Hierarchie, wie Stile auf Blöcke angewandt werden, von den Standardeinstellungen des Themas über globale Änderungen durch den Benutzer bis hin zu den Stiloptionen pro Block.

Während ein Großteil der Arbeit für ein MVP abgeschlossen ist, gibt es Dutzende von Feature-Tickets im Backlog. Dies ist auch ein Bereich, in dem das Blocksystem Jahre hinter den Page Buildern von Drittanbietern liegt. Erwarten Sie langfristige Funktionserweiterungen basierend auf dem Feedback nach dem Launch.

Meilenstein 4: Theme-Blöcke

Theme-Autoren sollten dieses Ticket genau im Auge behalten. Die einzige Möglichkeit, dass blockbasierte Themes für die meisten Theme-Entwickler Realität werden, ist, wenn alle Template-Tags einen entsprechenden Block im Site-Editor haben. Oder zumindest, wenn die meistgenutzten Template-Tags dies tun. Einige dieser Funktionen sind im Block-Editor nicht mehr anwendbar. Theme-Entwickler sollten sicherstellen, dass sie die Blöcke haben, die sie benötigen, um alles, was sie heute bauen, neu zu erstellen.

Zugegebenermaßen bin ich traurig darüber, dass die Blöcke für Bookmarks/Links wahrscheinlich nicht weiterentwickelt werden. Obwohl die Funktion veraltet ist, bin ich immer noch nostalgisch über die guten alten Blogroll-Tage. Vielleicht wäre es besser, dies als Plugin zu belassen. Eine Wiederbelebung des Link-Manager-Plugins könnte in Ordnung sein.

Meilenstein 5: Query-Block

Der Abfrage-Block und der zugehörige Schleifen-Block sind in gewisser Weise die wichtigsten Teile des Full Site Editing. Sie regeln, welche Beiträge geladen werden und wie sie angezeigt werden. Das Feature ist eines der komplexeren Puzzles, die zu lösen sind. Das Gutenberg-Entwicklungsteam hat monatelang daran gearbeitet, und es ist jetzt auf einer guten Basislinie. Es ist jedoch noch ein weiter Weg, bis es ernsthaft alle Dinge handhaben kann, die Theme-Autoren damit machen müssen.

Im Moment bietet der Query-Block nur eine Handvoll Optionen zum Anpassen der Abfrage. Das Team muss festlegen, welche Steuerelemente in der Seitenleiste für Endbenutzer verfügbar sein sollen und die Blöcke mit Mustern für verschiedene Arten von Post-List-Anzeigen integrieren.

Meilenstein 6: Navigationsblock

Abgesehen vom Abfrage-Block ist die Navigation der einzige andere Block, der einen eigenen Meilenstein benötigt. Probleme mit Navigationsmenüs plagen das WordPress-Projekt schon seit weit über einem Jahrzehnt. Es ist eines der schwierigsten Dinge, die man richtig hinbekommt. Während Navigationsmenüs in WordPress heute im Allgemeinen einfach zu handhaben sind, ist ihr Design vom Endbenutzer nicht anpassbar. Die Ausgabe liegt ganz im Ermessen des Theme-Autors. Die Vielfalt der möglichen Menüdesigns, die Theme-Autoren wünschen, zu berücksichtigen und sie für den Endbenutzer anpassbar zu machen, ist wahrscheinlich eines der schwierigsten Probleme für das Gutenberg-Projekt.

Es gibt mindestens ein paar Dutzend Untermenüs, die von den Autoren mitgestaltet werden müssen. Selbst dann könnte es noch mehrere Versionen dauern, bis der Navigationsblock für die komplexeren Muster, die heute in einigen Themes verwendet werden, bereit ist.

Meilenstein 7: Schrittweise Einführung

Nachdem die ersten sechs Meilensteine, die den MVP repräsentieren, abgeschlossen sind, braucht WordPress einen Weg, der es Endbenutzern und Theme-Autoren ermöglicht, FSE schrittweise zu übernehmen. In erster Linie wäre dies eine Mischung aus blockbasierten Templates und traditionellen PHP-basierten Templates. Entwicklern sollte es erlaubt sein, ihre Themes zu aktualisieren, ohne sie komplett zu ändern und damit möglicherweise Teile ihrer Benutzerbasis zurückzulassen.

Blockbasierte Widgets und Navigationsbildschirme fallen ebenfalls unter diesen Meilenstein. Beide Features wurden auf zukünftige Versionen verschoben, nachdem sie nicht in 2020 landen konnten. Sie werden jedoch Sprungbretter für Benutzer sein, die noch nicht ganz bereit sind, auf FSE umzusteigen oder dies aufgrund ihres Themes nicht können.

 

Automatisierung. Es ist einer dieser Träume in den Köpfen vieler Reviewer aus dem Themes-Team. Wenn es ein Tool gäbe, das sich um 90 % der Probleme kümmern würde, könnte sich das Team auf die 10 % konzentrieren, die von automatisierten Skripten nicht so leicht gefunden werden.

So entstand das Projekt Theme Review Action. Steve Dufresne, ein Mitarbeiter des WordPress-Meta-Teams, hat am Montag einen Aufruf zum Testen und Feedback für das neue Projekt veröffentlicht.

„Wenn wir einige der bestehenden Code-Analyse-Tools kombinieren, einen Teil der manuellen Tests automatisieren und sie für weitere Entwicklungs-Workflows öffnen könnten, könnten wir die Qualität von Themes verbessern, den Druck auf manuelle Tests verringern und den Theme-Review-Prozess beschleunigen?“, fragte Dufresne.

Das Projekt betreibt derzeit mehrere Testsuiten, darunter auch das aktuelle Theme Check Plugin. Theme-Autoren können die Texte ausführen, indem sie den NPX-Befehl in ihrem Theme-Ordner ausführen, ihn als Aktion auf GitHub hinzufügen oder ihn klonen und lokal ausführen. Das Ausführen über NPX wird derzeit unter Windows nicht unterstützt.

Im Moment werden Theme-Autoren benötigt. Unabhängig davon, ob Sie Themes für das Verzeichnis, Kunden, Drittanbieter-Marktplätze oder einen Theme-Shop erstellen, ist dies eine Gelegenheit, WordPress etwas zurückzugeben. Es ist auch eine Gelegenheit, die Werkzeuge zu verbessern, von denen Sie als Theme-Entwickler langfristig profitieren können. Automatisierte Theme-Tests helfen dem gesamten Theme-Ökosystem.

„Theme-Autoren müssen dafür offen sein und verstehen, dass es nicht nur um Anforderungen geht“, sagt Carolina Nymark, eine Vertreterin des Themes-Teams. „Es geht darum, die Qualität von Themes zu verbessern.“

Das Projekt wurde zum Teil durch einen Vorschlag des Themes-Teams von Anfang 2020 beeinflusst. Denis Žoljom identifizierte drei Probleme, gegen die das Team ankämpfte:

Die Leute lesen nicht gerne Anforderungen oder Handbücher.

Einige der Probleme, die auftauchen, sind sich wiederholend und könnten automatisch abgefangen werden.

Das Überprüfen von Themen in Trac ist sehr umständlich.

Der Fokus des Vorschlags lag auf der Verlagerung von Reviews nach GitHub, und konzentrierte sich auf den dritten Punkt. Das Theme Review Action Projekt könnte jedoch der Anfang sein, um einen oder mehrere Punkte zu behandeln.

Die offensichtliche Lösung ist, dass das Projekt automatisiert werden kann. Da das Theme Review Action-Projekt jedoch als GitHub-Aktion eingestellt werden kann, lässt es Raum für den GitHub-Review-Vorschlag des Teams.

„Zwei Dinge, die ich Steve gegenüber erwähnt habe – und das sind meine Meinungen -, sind, dass wir Überprüfungen brauchen, die beim Hochladen von Themes und bei Live-Themes laufen, und wir brauchen eine langfristige Lösung“, sagte Nymark. „Es gab schon früher Versuche, das Testen zu automatisieren, die nicht weiterverfolgt wurden, und ohne einen Plan, wie das Tool eingesetzt werden soll, mache ich mir Sorgen, Zeit darauf zu verwenden.“

Das Team hatte gehofft, dass das Theme Sniffer Projekt irgendwann zu mehr Automatisierung führen würde. Es ist schwer, sich Hoffnungen zu machen, nachdem frühere Ziele nicht verwirklicht wurden.

„Auch ich habe eine ähnliche Sorge, dass das Projekt nicht genug Akzeptanz bekommt, um es in die .ORG-Prüfung zu schaffen, und das ist einer der Gründe (neben der Tatsache, dass ich einfach super beschäftigt bin), dass ich nicht in der Lage war, die Prüfung [der Theme Review Action] zu priorisieren“, sagte William Patton vom Themes-Team.

Während das Team und einige Theme-Autoren immer noch den Theme Sniffer benutzen, lässt die Benutzeroberfläche noch viel zu wünschen übrig. Nymark wies darauf hin, dass es für Theme-Autoren schwer sei, zwischen den Basisanforderungen und den Empfehlungen zu unterscheiden.

„Meldungen von automatisierten Werkzeugen anzuzeigen, die nicht unbedingt Anforderungen sind, ist sehr schwer richtig zu machen“, sagte sie. „Wenn zum Beispiel ein Tool anfangen würde, CSS-Linting-Fehler für die WordPress-CSS-Codierungsstandards zu melden, würden viele Leute das zu rechthaberisch und einschränkend finden.“

Theme-Autoren, die Gruppe, die am meisten von den finanziellen Vorteilen und dem guten Ruf des Theme-Verzeichnisses profitiert, haben oft gezögert, sich zu beteiligen. Nur wenige Unternehmen erübrigen einen Mitarbeiter, um Reviews durchzuführen oder an Tools zu arbeiten, die Entwickler und das Team benötigen. Aufrufe zu Tests, Feedback und Diskussionen bleiben oft unbeantwortet, so dass einige wenige den Löwenanteil der Arbeit erledigen. Damit dieses Projekt erfolgreich wird und sich nicht wie etwas anfühlt, das ihnen aufgedrängt wurde, müssen die Theme-Entwickler mit einbezogen werden.

In der ersten Folge des WP Briefing-Podcasts sprach WordPress Executive Director Josepha Haden Chomphosy über die Fokussierung auf Automatisierung als eines der Ziele dieses Jahres. Wenn es ein Team gibt, das solche Tools gebrauchen könnte, dann wäre es das Themes-Team.