Einblicke aus unserem Entwicklungsteam, ein Interview mit Jakob Trost, unserem CTO.
Inhaltsverzeichnis
- Die Entwicklung mit WordPress Blocks und die Erstellung eines Block-Themes für WordPress war und ist immer noch aufregend.
- Das Interview
- Wenn du nur drei Herausforderungen in der Blockentwicklung nennen könntest, welche würdest du hervorheben?
- Bevor wir tiefer eintauchen, kannst du kurz erklären, was ungefiltertes HTML ist?
- Wie wirkt sich das auf die Blockentwicklung aus?
- Kannst du uns ein Beispiel nennen?
- Die zweite Herausforderung, die du erwähnt hast, ist der Navigation Block
- Wie geht die Greyd.Suite mit den Mängeln des Navigation Blocks um?
- Kommen wir zur dritten Herausforderung: Global Styles. Vor welchen Herausforderungen steht ihr da?
- Was tut ihr, um informiert zu bleiben?
- Worauf bist du am meisten stolz, wenn du auf eure Arbeit zurückblickst?
Die Entwicklung mit WordPress Blocks und die Erstellung eines Block-Themes für WordPress war und ist immer noch aufregend.
Gutenberg has been the best thing that happened in WordPress. But it’s also filled with hurdles and learning experiences. Recently, we published an interview about why we chose to put our cards on a block theme and working with the Site Editor in WordPress. We encountered several challenges that are not only insightful for fellow developers but also illuminate the intricacies of working with what some would call “the new WordPress way”.
Das Interview
Wenn du nur drei Herausforderungen in der Blockentwicklung nennen könntest, welche würdest du hervorheben?
Die ersten Dinge, die mir in den Sinn kommen, sind ungefiltertes HTML, der Navigation Block und die Global Styles.
Bevor wir tiefer eintauchen, kannst du kurz erklären, was ungefiltertes HTML ist?
Über ungefiltertes HTML können Nutzer in WordPress HTML-Code direkt in Beiträge und Seiten einzufügen. Diese mächtige Funktion ist aus gutem Grund hauptsächlich auf Administratoren und Superadministratoren beschränkt. Die größte Herausforderung bei ungefiltertem HTML sind die Sicherheitsrisiken, die damit verbunden sind. Die Plattform filtert diese Möglichkeiten auf der Grundlage des Benutzers und beeinflusst, welche Elemente und Attribute verschiedene Benutzergruppen speichern und bearbeiten können. Und das ist auch gut so.
Wenn Nutzer ohne Rechte versuchen, bestimmte HTML-Elemente oder -Attribute einzubinden, können diese beim Speichern des Inhalts entfernt werden, oft ohne dass der Nutzer eine Warnung erhält. Diese stillschweigende Entfernung kann zu Verwirrung führen, das Seitenlayout stören und die Zugänglichkeit der Website beeinträchtigen, insbesondere bei Elementen wie ARIA-Labels oder Datenattributen, die zwar wichtig, aber für normale Nutzer nicht zugänglich sind.
Wie wirkt sich das auf die Blockentwicklung aus?
Für die Entwickler bedeuten diese Einschränkungen einen erheblichen Mehraufwand. Jeder erstellte Block erfordert eine akribische Freigabe der notwendigen HTML-Attribute und Elemente. Das erhöht nicht nur die Komplexität der Entwicklung, sondern auch das Risiko von Fehlern. Erschwerend kommt hinzu, dass die Dokumentation oft unzureichend ist, was den Entwicklungsprozess noch schwieriger und fehleranfälliger macht. Diese Herausforderungen sind besonders ausgeprägt in Szenarien mit komplexen Benutzerrollen oder fortgeschrittenen Berechtigungsstrukturen.
Nehmen wir den Fall eines Plugins für die Benutzerverwaltung, bei dem die Benutzer die Möglichkeit haben, ihre Rollen selbst zu erstellen und zu verwalten. Hier werden die Herausforderungen von ungefiltertem HTML besonders deutlich. Eine unzureichende Konfiguration kann dazu führen, dass die Nutzer die Seiten nicht effektiv bearbeiten oder speichern können. Sie sehen sich mit der Fehlermeldung konfrontiert: “Dieser Block enthält unerwarteten oder ungültigen Inhalt. Blockwiederherstellung versuchen”.
Dies führt zu einem erheblichen Mehraufwand bei der Fehlersuche und der laufenden Wartung, was sowohl die Nutzer als auch die Entwickler belastet.
Kannst du uns ein Beispiel nennen?
Ein gutes Beispiel dafür ist die Einschränkung bei Eingabefeldern. Wie ich bereits erwähnt habe, schränkt WordPress aus Sicherheitsgründen das Speichern von Eingabefeldern für bestimmte Benutzergruppen ein, z. B. für die Standard-Editor-Gruppe. Das liegt daran, dass Eingabefelder potenziell schädliche Zeichenfolgen enthalten können, die ein Sicherheitsrisiko für die WordPress-Installation darstellen.
Für uns stellte dies ein großes Hindernis dar, vor allem bei der Entwicklung von benutzerdefinierten Blöcken für unseren Formulargenerator, der zwangsläufig Eingabefelder benötigt. Die Sicherheitsmaßnahmen sind zwar unerlässlich, haben sich aber bei der Entwicklung der Blöcke als großes Hindernis erwiesen.
Das Problem wurde beim Testen mit verschiedenen Benutzerrollen deutlich. Das System filterte beim Speichern eines Beitrags Elemente heraus, die die Benutzerrolle nicht speichern durfte. Das führte dazu, dass Formulare nicht mehr funktionierten und Daten verloren gingen, ohne dass der Benutzer eine Fehlermeldung oder Warnung erhielt.
Um dieses Problem zu lösen, waren umfangreiche Recherchen zu den Sicherheitsfiltern von WordPress erforderlich. Unser Team wühlte sich durch stapelweise Dokumentation und Quellcode, um diese Einschränkungen zu verstehen und zu umgehen, ohne die Sicherheit der Website zu gefährden.
Die zweite Herausforderung, die du erwähnt hast, ist der Navigation Block
Oh ja! Ein besonders herausfordernder Aspekt bei der Arbeit mit WordPress Blocks war die Verbesserung der Funktionalität des Navigation Blocks. Das sagen nicht nur wir. Er gilt allgemein als einer der wichtigsten, aber auch schwierigsten Blöcke, mit denen man arbeiten kann. Der Navigation Block ist schon lange ein Diskussionsthema in der Entwicklergemeinschaft. Er ist für seine Komplexität und seine Einschränkungen bekannt und für viele ein Grund zur Frustration. Die jüngsten Entwicklungen und Ergänzungen haben seine Funktionalität und Benutzerfreundlichkeit jedoch erheblich verbessert!
Die WordPress-Entwickler haben vor allem in den letzten sechs Monaten bemerkenswerte Fortschritte bei der Verbesserung der Benutzerfreundlichkeit gemacht.
Eine wichtige Verbesserung ist die Einführung verschiedener Registerkarten wie “Einstellungen” und “Design”. Diese Ergänzungen ermöglichen ein intuitiveres Verständnis und eine einfachere Handhabung der Navigationsstruktur, was die Möglichkeiten zur Strukturierung und Anpassung der Navigationsmenüs erheblich verbessert. Aber… Trotz dieser Verbesserungen bleibt eine große Lücke im Bereich der Styling- und Designoptionen. Entwickler können zwar Schaltflächen in den Navigation Block einfügen, sind aber in Bezug auf detaillierte Anpassungen eingeschränkt. Standard-Designfunktionen wie dicke Ränder unter den Navigationselementen, Hover-Effekte oder die Möglichkeit, das Aussehen von sekundären und tertiären Elementen zu verändern, fehlen. Diese Einschränkung ist eine große Hürde bei der Erstellung vielfältiger und kreativer Designs.
Wie geht die Greyd.Suite mit den Mängeln des Navigation Blocks um?
Um diese Unzulänglichkeiten zu beheben, haben wir umfassende Designoptionen für das gesamte Menü eingeführt. Du kannst jetzt einen Standardstil auf alle Menülinks anwenden. Du kannst z. B. einen dicken schwarzen Drei-Pixel-Rahmen unter jedem Element festlegen, das Padding anpassen und die Hintergrundfarbe bei Hover ändern. Durch diese Anpassungsmöglichkeiten wird die Benutzerinteraktion deutlicher, z. B. der Hover- oder Focus-States.
Außerdem haben wir die Anpassungsmöglichkeiten auf der Ebene der einzelnen Elemente erweitert. Es reicht nicht mehr aus, ein Element in eine Schaltfläche umzuwandeln, sondern Entwickler können jetzt jedem Element einen eigenen Stil zuweisen. Dazu gehören unterschiedliche Umrandungen, Beschriftungen oder andere stilistische Änderungen, die mehr Flexibilität beim Design bieten.
Eine unserer wichtigsten Neuerungen ist die Implementierung von aktiven Stilen. Diese Funktion ermöglicht es Entwicklern, unterschiedliche Hover- und Aktiv-Zustände für jeden Menüpunkt zu erstellen, sowohl für das gesamte Menü als auch für jedes einzelne Element. Diese Verbesserung steigert das Potenzial des Navigation Blocks erheblich und ermöglicht dynamischere und ansprechendere Nutzererfahrungen.
Kommen wir zur dritten Herausforderung: Global Styles. Vor welchen Herausforderungen steht ihr da?
Die Herausforderung besteht darin, dass niemand die Global Styles-Schnittstelle von WordPress direkt beeinflussen kann. Während die klassische PHP-basierte Entwicklung von WordPress umfangreiche Anpassungen ermöglichte, hat die blockbasierte Entwicklung diese Flexibilität deutlich eingeschränkt. Diese Änderung hat zwar die Benutzerfreundlichkeit verbessert, stellt aber eine Herausforderung für Entwickler dar, die umfassendere Designoptionen anbieten möchten, wie z. B. Hover-Styles für Buttons oder Konfigurationen für Eingabefelder.
Unsere Lösung bestand darin, ein benutzerdefiniertes Plugin namens Greyd.Styles zu entwickeln, um die globalen Stile zu ergänzen – ein Ansatz, der zwar effektiv, aber nicht ideal ist, was die Benutzerfreundlichkeit angeht. Aber es gibt den Nutzern der Greyd.Suite die Möglichkeit, diese wichtigen visuellen Unterscheidungen zu treffen.
Was tut ihr, um informiert zu bleiben?
Einige unserer Lieblingsressourcen sind WP Tavern, Artikel im Entwicklerbereich von WordPress.org, vor allem die von Justin Tadlock, und das WordPress.org-Forum, um auf dem Laufenden zu bleiben. Ein Podcast, den wir aufmerksam verfolgen, ist der von Birgit Pauli-Haack moderierte Gutenberg Changelog. Du findest ihn auf der Gutenberg Times Website.
Worauf bist du am meisten stolz, wenn du auf eure Arbeit zurückblickst?
Wir sind stolz darauf, unsere Codestruktur zu modernisieren, damit sie sowohl mit Block-Themes als auch mit klassischen Themes kompatibel ist. Unser Fokus liegt auf Effizienz, Skalierbarkeit, Pagespeed und Nachhaltigkeit. Wir sind bestrebt, nahe am WordPress Core zu bleiben und seine nativen Funktionen zu nutzen, damit unsere Kunden immer von den neuesten Entwicklungen profitieren