Ich habe mich gerade erst über Gutenberg informiert, den Namen für eine Überarbeitung des WordPress-Editors. Du kannst ihn jetzt schon nutzen, da er zunächst als Plugin entwickelt wird, mit der Idee, dass er schließlich in den Core integriert wird. Das Repo bietet bessere Informationen.
Meiner Meinung nach ist dies die größte Änderung am WordPress-Editor in der Geschichte von WordPress. Das scheint hier besonders relevant zu sein, da wir gerade über Content-Blöcke gesprochen haben und wie verschiedene CMS damit umgehen. Genau das ist Gutenberg: ein Content-Block-Editor.
Anstatt dass der Inhaltsbereich eine aufgehübschte Textarea ist (vielleicht eine der berechtigtsten Kritiken an WordPress), wird der Inhaltsbereich zu einem Container für alle verschiedenen „Blöcke“, die du dort einfügen möchtest. Blöcke sind Dinge wie Überschriften, Text, Listen und Bilder. Sie sind auch aufwendiger wie Galerien und Embeds. Entscheidend ist, dass Blöcke erweiterbar sind und wirklich alles sein können. Ähnlich wie ein [Shortcode], stelle ich mir vor.
Einige Bilder aus Brian Jacksons Diving Into the New Gutenberg WordPress Editor helfen, das zu verdeutlichen.
Wie bei jeder großen Softwareänderung ist sie umstritten (sogar polarisiert). Ich erhielt eine E-Mail von jemandem, der mich davor warnte.
Der Konsens ist, dass dieses UI-Upgrade WP entweder in die Zukunft katapultieren oder Millionen von WP-Websitebesitzern verärgern und WordPress töten könnte.
Ich neige dazu zu denken, dass WordPress 2-BIG-2-DIE ist, also wahrscheinlich Ersteres.
Ich denke auch, dass das Zusammenfügen von Blocktypen eine generische und intelligente Abstraktion für ein CMS ist. Gutenberg scheint es auf gesunde Weise zu handhaben. Die Blöcke werden einfach in speziell formatiertem <!– wp:core/text –> <!– /wp:core/text –> eingeschlossen, um einen Block zu kennzeichnen, sodass der Inhalt hochgradig kompatibel ist. Eine WordPress-Website ohne Gutenberg wird keine Probleme damit haben, noch sie woandershin zu portieren.
Außerdem wird der Inhalt in Templates weiterhin als ein großer Brocken behandelt.
Um sicherzustellen, dass eine Schlüsselkomponente der Stärke von WordPress erhalten bleibt, sollte die Quelle der Wahrheit für den Inhalt in
post_contentverbleiben, wo der Großteil der Postdaten auf eine zugängliche und portable Weise vorhanden sein muss.
Unabhängig davon, wie du es im Editor strukturierst, wird es als ein Brocken in der Datenbank gespeichert und mit einem Befehl in Templates ausgegeben. Das macht es vielleicht *weniger* flexibel, als du es dir aus Templating-Sicht wünschen würdest, schränkt aber diese Änderung auf ein erträgliches Maß ein und bleibt sehr WordPress-artig.
Es scheint, dass ein Großteil der Kontroverse entweder aus „Wer hat meinen Käse verschoben“-Sentiments oder aus dem resultiert, was es im Moment unterstützt und was nicht. Ich halte beides nicht viel, da die Leute den Käse ziemlich schnell finden und dies noch unter einer anscheinend intensiven aktiven Entwicklung steht.
Eine große Sorge ist die Unterstützung von benutzerdefinierten Meta-Boxen. Joost de Valk
Fakt ist, dass, wenn du Gutenberg jetzt testest, du sehen wirst, dass Yoast SEO nirgends auf der Seite ist. Ebenso wenig wie all die anderen Plugins, die du vielleicht nutzt, wie Advanced Custom Fields oder CMB2. All diese Plugins verwenden sogenannte Meta-Boxen, die Boxen unter und neben dem aktuellen Editor.
Die Tatsache, dass das Gutenberg-Team Meta-Boxen in Erwägung zieht, ist unserer Meinung nach ein großer Fehler. Das würde bedeuten, dass viele, viele Plugins ab dem Zeitpunkt, an dem Gutenberg herauskommt, nicht mehr funktionieren würden. Unzählige benutzerdefinierte Integrationen würden aufhören zu funktionieren. Hunderte von Tausenden von Entwicklungsstunden müssten zumindest teilweise neu gemacht werden. Und das alles, während der aktuelle Editor für die meisten Websites perfekt funktioniert.
Das klingt tatsächlich nach einer großen Sache. Ich frage mich, wie einfach es sein wird, sich schrittweise in Gutenberg einzuarbeiten. Zum Beispiel, es für Standardbeiträge und Seiten zu aktivieren und es für benutzerdefinierte Beitragstypen auszuschalten, bei denen du eher benutzerdefinierte Meta-Boxen benötigst (oder eine Kombination davon).
Auf dieser Seite nutze ich benutzerdefinierte Meta-Boxen (sogar einfache klassische benutzerdefinierte Felder) sowie mein eigenes HTML im Editor, sodass Gutenberg nichts ist, auf das ich schnell umsteigen kann. Das lässt mich fragen, ob es immer einen „klassischen“ Editor geben wird oder ob der neue Editor zu einem bestimmten Zeitpunkt obligatorisch sein wird.
Noch mehr Kontroversen gab es wegen der React-Lizenzierung. Das lief im Wesentlichen so:
- Matt Mullenweg: Wir werden von React weggehen (das Gutenberg verwendet), wegen der Lizenzierung.
- React: Ihr habt alle Unrecht, aber wir geben auf. Es ist jetzt MIT.
- Matt Mullenweg: Das ist gut, aber jetzt geht es darum, den Leuten zu erlauben, jede neue JavaScript-Bibliothek zu verwenden, die sie wollen.
Ich habe noch nie von „framework-agnostischem“ Block-Rendering gehört, aber anscheinend ist das eine Sache. Oder vielleicht auch nicht? Omar Reiss
Mit dem neuen Gutenberg-Editor ändern wir die Art und Weise, wie das WordPress-Admin-Interface aufgebaut wird. Wo wir bisher die Benutzeroberfläche mit PHP rendern, werden wir mehr und mehr serverseitig mit JavaScript rendern. Nach dem Editor wird dies wahrscheinlich für den Großteil des Admin-Bereichs gelten. Das bedeutet, dass du, wenn du dich in die Admin-Oberfläche integrieren möchtest, dich mit dem JavaScript integrieren musst, das die Oberfläche rendert. Wenn WordPress Vue wählt, musst du WordPress Vue-Komponenten zum Rendern liefern. Wenn WordPress React wählt, musst du WordPress React-Komponenten zum Rendern liefern. Diese Dinge passen nicht zusammen. React rendert keine Vue-Komponenten und umgekehrt. Es gibt keine Bibliothek, die beides kann. Wenn WordPress ein bestimmtes Framework verwendet, muss jeder dieses Framework verwenden, um integrieren zu können.
Das ist eine knifflige Situation. Vor der Änderung der React-Lizenz habe ich um einen Nickel gewettet, dass sie Vue nehmen würden. Danach vermute ich, dass sie bei React bleiben werden. Ihr eigenes Calypso ist komplett in React geschrieben, zusätzlich zu dem, was es bereits für Gutenberg gibt, also scheint es ein Kontinuitätsbonus zu sein.
Das wird eine spannende Tech-Geschichte zum Verfolgen! Seiten wie Post Status werden sie wahrscheinlich genauer verfolgen, als ich es kann.
Ich habe über einen guten Ersatz für ein CMS nachgedacht, das tatsächlich schnell und sicher ist.
Was hält jeder von .NET Core 2.0? C# und Java bieten beide große Sicherheit (weit über PHP) und Geschwindigkeit.
.NET Core 2 läuft auch unter Linux und kann in Docker containerisiert werden.
Siehe hier
http://redhatloves.net
Es gibt nichts inhärent Sicheres oder Unsicheres an einer Programmiersprache. Es kommt alles darauf an, wie man sie benutzt.
Ich kann nicht glauben, dass du PHP im Jahr 2017 durch .NET ersetzt.
Ich weiß nicht, was deine Sicherheitsanforderungen sind, aber sieh dir https://craftcms.com als WordPress-Alternative an, oder nutze https://www.contentful.com, um Inhalte zu speichern und dein eigenes Frontend zu schreiben.
Das sind meine aktuellen CMS-Wahlen. Ich würde erwägen, zu WordPress zurückzukehren, aber niemals zu Java oder C#. Das sind sehr wortreiche Sprachen, die nicht für Websites konzipiert sind.
Joe, worüber redest du eigentlich. WordPress ist schnell und sicher genug?
Der einzige Grund, warum WordPress (und viele Leute) PHP verwenden, ist die Portabilität. Wähle irgendein Hosting und es hat PHP.
Aber es ist eine schreckliche Programmiersprache und man muss den Kurs über formale Sprachen an der Universität nicht genau verfolgt haben, um das zu erkennen. Selbst sein Autor sagte in mehreren Interviews, dass die Dinge außer Kontrolle gerieten und er nie beabsichtigt hatte, eine Programmiersprache zu schaffen.
Wenn wir die Sprache frei ersetzen würden, wäre die offensichtliche Wahl Python (und wahrscheinlich Flask, obwohl das nur meine Präferenz ist).
Heutzutage sage ich meinen Kunden für kundenspezifische Arbeiten, dass sie einen VPS mieten sollen, und ich entwickle die serverseitige Software mit Flask. Es scheint heutzutage auch CMS zu geben, die in Python entwickelt werden, entweder mit Flask oder Django.
Wenn jemand ein CMS so gut wie Craft in ASP.NET Core machen würde, würde ich lange gehegte Freudentränen weinen.
Das Problem ist, dass .NET trotz vieler wirklich guter Dinge nie ein großartiges CMS hatte. Die früheren Plattformbeschränkungen, die Vorliebe für MSSQL und der Mangel an Frontend-fokussierten Entwicklern in diesem Bereich haben es nahezu unmöglich gemacht. (Ja, Orchard, das ist eine Sache – ein übermäßig architektonisches, kaum genutztes Ding)
Jetzt, da Code on-the-fly auf mehreren Plattformen kompiliert wird, die Geister von WebForms ausgemerzt sind, JavaScript-Frontends Standard sind und die teuflisch schnelle Leistung noch teuflischer schnell ist – vielleicht wird es passieren.
GM war zu groß, um zu scheitern.
” Ich frage mich, wie einfach es sein wird, sich schrittweise in Gutenberg einzuarbeiten.”
Das ist das Kernproblem, das viele von uns beschäftigt – der aktuelle Plan ist, dass es nicht optional sein wird. Es wird in 5.0 ausgeliefert und wird der Standardeditor sein, Punkt. Nun, Matt hat erklärt, dass 5.0 von der Bereitschaft Gutenbergs abhängt und nicht von einem datumsgesteuerten Release, aber nur wenige von uns haben Vertrauen, dass 5.0 bis z.B. Herbst 2018 aufrechterhalten wird. Daher ist die Frage, was es unterstützt und wie gut es mit einer Vielzahl von Websites getestet wurde, entscheidend.
Es gibt VIELE Websites, die Dinge wie Advanced Custom Fields, verschiedene Shortcodes usw. verwenden. Die Art und Weise, wie all dies verwaltet und generiert wird, zu ändern, ist ein RIESIGES Unterfangen und äußerst riskant. Für mich wird das Risiko durch mangelnde Klarheit und Details noch verschärft. Wir haben keine detaillierte Roadmap. Wir haben keine angegebenen Anforderungen, die vor der Veröffentlichung erfüllt sein müssen. Wir haben keinen angegebenen Plan für die Durchführung von Kompatibilitätstests. Soweit ich weiß, haben Plugin-Entwickler noch keine stabile API mit Dokumentation oder klare Dokumentation, wie sie ihre Plugins an Gutenberg anpassen können.
Was ich sehen möchte, ist der Ansatz, den Core mit der REST-API verfolgt hat. Das hat lange gedauert, um sich zu entwickeln, war lange Zeit als Plugin verfügbar und wurde erst integriert, als es wirklich fertig war. Releases wurden nicht dafür zurückgehalten. Und es wurde praktisch ohne Zwischenfälle gestartet.
Gutenberg ändert den Kernbestandteil von WordPress – wie Inhalte erstellt und verwaltet werden. Es sollte mit Vorsicht und viel Nachdenken und Feedback geändert werden.
Ich habe an diesem Zirkus die letzten 2-3 Jahre teilgenommen, mit Idiotien wie dem halbfertigen, schlecht dokumentierten Customizer (der anscheinend ursprünglich durch die Change Issues ergänzt wurde... aber die kommen 2 Jahre zu spät!), den Media Widgets (anstatt die Media DB ordentlich zu erledigen) usw. pp.
Viel Feature Creep, der die Entwicklung meistens anstrengender macht.
Jetzt der „Gutenberg“-„Spaß“ unterwegs... Ich habe ernsthaft darüber nachgedacht, WP für immer zu forken. Nicht, um es auf extreme Weise neu zu gestalten, wie viele Leute darüber nachdenken, es in mehrere Iterationen aufzuteilen, sondern nur, um den Feature Creep zu entfernen, alles etwas zu beruhigen und vielleicht Optionen hinzuzufügen, um Usability-Alpträume wie den Theme Customizer, XML-RPC und so weiter zu deaktivieren.
cu, w0lf.
Du sagtest: „Das ist das Kernproblem, das viele von uns beschäftigt – der aktuelle Plan ist, dass es nicht optional sein wird… Matt hat erklärt…“
Ich schätze, Open Source bedeutet nicht Offenheit für Diskussionen? ;)
Es muss schön sein, die Welt zu regieren, oder zumindest die 28% aller Websites davon.
Rick:
Du solltest dir unbedingt die Arbeit ansehen, die ermöglicht, bestehende Metaboxen mit Gutenberg zu verwenden. Sie wird gegen ACF und viele andere Plugins getestet, die Metaboxen intensiv nutzen. Sobald sie in einer Gutenberg-Version landet, solltest du sie unbedingt gegen deinen Workflow testen.
Mit welchen Plugins oder Shortcodes hattest du Probleme? Shortcodes sollten weiterhin funktionieren.
Gibt es etwas Bestimmtes, auf das sich dieses „usw.“ bezieht? Gutenberg befindet sich noch in der aktiven Entwicklung, aber das Ziel ist es, die überwiegende Mehrheit der bestehenden Anwendungsfälle abzudecken. Wenn wir etwas übersehen haben, würde ich es gerne wissen.
Ich stimme zu, dass wir die Dokumentation verbessern müssen, das ist eine fortlaufende Anstrengung. Hast du bestimmte Plugins im Sinn, wenn du an die Konvertierung denkst, damit sie für Gutenberg funktionieren? Das Betrachten realer Anwendungsfälle wird definitiv bei der Erstellung der Dokumentation helfen.
WPezDeveloper:
Das ist nicht ganz fair, es gibt viele Möglichkeiten, an der Diskussion teilzunehmen. WordPress Slack, die Make WordPress Blogs, der Gutenberg Issue Tracker, und wir lesen auch die Kommentare zu solchen Beiträgen. So ziemlich alles, was über Gutenberg geschrieben wird, wird von jemandem im Kern-Gutenberg-Team gelesen. Natürlich müssen Entscheidungen getroffen werden, und du stimmst diesen Entscheidungen vielleicht nicht immer zu. Aber jeder ist immer willkommen, an der Diskussion teilzunehmen!
Es klingt ziemlich offensichtlich, dass sie die normalen Metaboxen unter dem Gutenberg-Editor belassen sollten, zumindest während der (langen) Übergangsphase.
Bestehende Plugins würden weiterhin funktionieren und neue würden in React erstellt.
Schon bald werden die Benutzer „moderne“ Plugins bevorzugen, die Gutenberg nutzen, und die Community wird sich auf natürliche Weise weiterentwickeln. Erst dann sollte WordPress die Unterstützung für alte Plugins entfernen.
Federico:
Genau daran wird gerade gearbeitet! Bestehende Metaboxen werden mit Gutenberg funktionieren, obwohl Plugins definitiv überlegen sollten, wie sie ihre Metabox-Nutzung auf Gutenblocks umstellen.
Ich mag diese Art von Experimenten nicht. Warum etwas ändern, das funktioniert? Ich denke ernsthaft über Alternativen nach, Publii (statisches CMS https://getpublii.com) sieht wirklich gut aus.
Andere Optionen, die ich in Erwägung ziehe:
Bolt
ProcessWire (als eigenständige Option; es ist besser, sich auf mehr als nur ein CMS zu konzentrieren)
Oktober CMS
Sitecake
ImpressPages
Die wichtigsten Spezifikationen sind: Richtige Dokumentation (oder zumindest ordnungsgemäße Kommentare im Quellcode / PHPDoc), Funktionen vergleichbar mit dem aktuellen WP, erweiterbar mit Plugins oder Erweiterungen, keine verrückten Systemanforderungen.
cu, w0lf.
Ich habe bereits einige Websites mit Grav erstellt, das in die Kategorie der statischen CMS fällt.
Funktioniert gut, wenn auch mit einer gewissen Lernkurve. Besonders gut geeignet für kleine und mittelgroße Websites.
Für die größeren Projekte vielleicht ein Wechsel zu Drupal?
Nun, wo du es erwähnst... du kannst jetzt mühelos Vue nach React kompilieren mit dem React-Vue-Loader.
Sie könnten sich für Stenciljs entscheiden, das verspricht, Framework-agnostisch zu sein.
Gute Rezension, Chris!
Ich weiß, dass das Blockformat ein kleiner Streitpunkt war, aber ich bin froh zu sehen, dass die Vorteile davon klarer werden. Bei jeder Entscheidung gibt es natürlich Nachteile, wie du bemerkt hast.
Portabilität und Lesbarkeit sind jedoch zwei der Hauptmerkmale, daher hoffen wir, dass es für die Leute einfach zu benutzen und zu lesen ist.
Das ist sicherlich eine der in Betracht gezogenen Optionen, aber Metaboxen sollten idealerweise einfach funktionieren. Es gibt einen wirklich coolen PR in Arbeit, der es bestehenden Metaboxen ermöglicht, mit Gutenberg zu funktionieren. Er nimmt Gestalt an, also wird er in einer zukünftigen Gutenberg-Version landen. Testen und Feedback sind sehr erwünscht!
Lustigerweise arbeiten wir auch daran! Das ist noch experimentell, aber der in diesem PR gezeigte Ansatz ermöglicht es einem Gutenblock, der in Vue geschrieben ist, Gutenberg-Komponenten zu nutzen, die für React geschrieben wurden (in diesem Fall kann der Vue-Gutenblock als „editierbarer“ Block fungieren, der auf einer Reihe interner Komponenten beruht). Das aktuelle Experiment verwendet benutzerdefinierte Elemente in der Interoperabilitätsschicht, die von einigen Frameworks nativ unterstützt werden (insbesondere Polymer und Stencil) und für andere Frameworks Wrapper verfügbar haben.
Wie Chris erwähnte, könnte dies mit Vuera oder React-Vue-Loader geschehen.
Diese Inhaltsblöcke erinnern mich an Django. Danke.
/legt sich hin.
Eine der Funktionen, die offensichtlich scheint (hier noch nicht wirklich angesprochen, aber wahrscheinlich bald folgen wird), ist die Live-Ansicht bzw. das Frontend-Editing. Ich würde mir das gerne auf der Roadmap wünschen, auch wenn es ein ambitioniertes Ziel ist.
Es gibt Entwickler, die mit ACF und der „Blocks“-Methode eine hervorragende Frontend-Erfahrung geschaffen haben. Die Entwicklung benutzerdefinierter Editoransichten wie Panels von Modern Tribe ist ein Schritt in die richtige Richtung https://vimeo.com/194057171.
Hallo Jake,
Frontend-Editing steht nicht auf der Roadmap für WordPress 5.0, aber du solltest danach mit deutlich mehr Frontend-Arbeit rechnen. Der Fokus von Gutenberg wird sich auf die Customization-Erfahrung verlagern, was natürlich eine enge Verknüpfung mit dem Frontend beinhaltet. Ich zweifle nicht daran, dass es dabei einige interessante Experimente im Frontend-Editing geben wird.
In der Zwischenzeit ist der Plan, die Art und Weise, wie Themes sich in Gutenberg im Dashboard einhängen können, zu verfeinern, damit du eine frontend-ähnliche Darstellung für die von dir bearbeiteten Inhalte siehst.
Überrascht, dass so viele Leute hier so an den WP-Content-Editor gebunden sind. Ich baue seit Jahren benutzerdefinierte Feldersets & Optionen, um einen Mangel an modularen, flexiblen Inhalten in WP zu kompensieren.
Ich freue mich darauf, mich mit Gutenberg zu beschäftigen.
Gutenberg scheint wirklich interessant zu sein und es ist bereits auf WP.com live.
Aber meiner Meinung nach ist einer seiner größten Nachteile, dass es fast überall `&nbps;` einfügt. Das ist wirklich störend und erzeugt Rendering-Probleme, wie z.B. das Brechen von Sätzen an seltsamen Stellen.
Was ich also zwischen den Zeilen lese, ist, dass WordPress langsam von PHP zu einem Javascript-Framework migriert.