Websupporter

Vor allem über WordPress.

Ein neuer Editor für WordPress?

Mal ehrlich, wie gefällt Euch eigentlich der Editor von WordPress? Benutzt Ihr ihn eigentlich und wenn ja wie? Ich selbst muss gestehen, dass ich den größten Teil meiner Blogbeiträge in einem ganz normalen Plaintext Editor verfasse, ein wenig mit HTML-Tags vorbereite und erst am Ende nach WordPress wechsle, um die letzten Stylings zu machen, ein bisschen Preview und meist eine etwas unglückliche Fehlerkorrektur vornehme. Nein, ich bin kein großer Freund des WordPress Editors und das ist eigentlich kein gutes Urteil, wenn man bedenkt, dass im Herzen eines Blogsystems eigentlich der Editor schlagen sollte.

Nun scheine ich damit nicht ganz alleine zu sein, zumindest ist der Editor eines der Fokusprojekte für das Projekt WordPress 4.8. Derzeit läuft deshalb eine Umfrage, wie der Editor denn bisher eigentlich genutzt wird.

Was? Eine Umfrage? Ja, denn bisher gibt es noch kein geeignetes Instrument, tatsächliches Userfeedback einzuholen. Vielleicht eine der spannendsten Debatten in der WordPress Entwickler⋅innenszene ist derzeit, wie man eigentlich eine 80:20-Regel grob einhalten möchte („wenn es 80 Prozent der Leute nützt eignet es sich für den Core“), wenn man nicht über die geringsten Daten verfügt, wie WordPress eigentlich genutzt wird. Man erinnere sich an die Diskussion, den Blocksatz-Button aus dem Editor zu entfernen. Doch, das Thema, wie man Nutzer⋅innen-Daten am besten erhebt und welche Diskussionen dazu laufen, bietet sicher genug Stoff für einen eigenen Beitrag. Eine Umfrage also. Angesichts der letztlich nicht vorhandenen Datenlage ist das sicher der beste Ansatz.

Natürlich erhofft man sich davon interessante Einblicke, welche Features man erhalten sollte, welche stören oder gar weg können. Mich stört beispielsweise ganz enorm, dass ich bei langen Texten Ewigkeiten scrollen muss, bis ich zu den darunterliegenden Metaboxen komme (Man kann das übrigens oben rechts bei Screen Options abstellen). Doch natürlich bleibt es nicht nur dabei, Daten zu erheben, vielmehr wird schon längst an einem neuen Editor gebastelt und erste Prototypen und Mockups liegen vor, die wirklich vielversprechend sind.

Gutenberg. Prototyping since 1440.

Der Prototyp, an welchem gearbeitet wird, heißt „Gutenberg“ und zielt darauf umfangreiche und auch designlastige Beiträge so mühelos wie möglich zu erstellen. Statt sich also einen Text als solide Einheit vorzustellen, ist der Ansatz hier, Texte eher in Blöcken zu denken, welche dann schnell durch den Text manövriert werden können. Ein Block muss dabei nicht nur ein Absatz sein, sondern kann auch aus einem Bild, einem Video oder anderen Elementen bestehen. Ein Ansatz, der durchaus nicht unüblich ist, wenn man mal mit dem einen oder der anderen Webdesigner⋅in gesprochen hat.

Ich habe einen kleinen Screencast vorbereitet, der Euch den neuen Editor zeigt, so wie er heute zu finden ist.

Youtube

Click the button below to load the content from Youtube.

Ich muss gestehen, mir gefallen solche Editoren und auf jeden Fall gefällt mir der Weg, der hier eingeschlagen wird. Ob ich am Ende tatsächlich meine Texte darin schreiben werde, weiß ich noch nicht, aber toll sieht es aus. Die Arbeit an dem Editor ist in vollem Gange. Tammie Lister bittet darum, den Prototypen ausführlich zu testen und Fragen zu beantworten wie beispielsweise

  • Kannst Du auf den ersten Blick erklären, wozu jede Sektion gut ist?
  • Kannst Du einen Absatz schreiben und wie fühlt es sich an?
  • Kannst Du ein Bild hinzufügen? Ist das schwierig?

Getestet werden kann Gutenberg hier. Die Entwicklung und auch das Bugreporting finden auf Github statt. Derzeit wird daran gearbeitet Gutenberg zu einem Featured Plugin weiterzuentwickeln, so dass jede⋅r sich selbst ein Bild verschaffen kann und den neuen Editor als Plugin testen kann. Die technischen Schwierigkeiten und die Zukunft von post_content werden unter anderem in diesem Beitrag diskutiert. Wie separiert man die Blöcke, um sie handhabbar zu machen, ohne die post_content-Spalte der Datenbank zuzumüllen? Vorschläge reichen von data--Attributen an HTML-Elementen bis hin zu HTML-Kommentaren wie <!-- wp:image -->.

Wirklich viel kann man natürlich noch nicht sagen, da alles noch ziemlich am Anfang steht, aber der neue Editor, das wird auf den ersten Blick sichtbar, hält einige Überraschungen bereit und auch unzählige Fragen wie Browsersupport für IE8 und ähnliches.

Wenn Du an der derzeitigen Umfrage zum aktuellen Editor noch nicht teilgenommen hast, kannst Du das hier schnell nachholen. Was hältst Du vom aktuellen Editor und wie findest Du den Entwurf für den Neuen?

Über den Autoren

Seine erste Webseite hat David Remer 1998 in HTML verfasst. Wenig später war er fasziniert von DHTML und JavaScript. Heute konzentriert sich vor allem auf das Entwickeln von WordPress Themes und Plugins für Inpsyde. Außerdem hat er das Buch "WordPress für Entwickler" verfasst.

Kommentare

  1. Hi David,

    schöner Beitrag!

    Also ich nutze den WordPress-Editor für meine deutschen Beiträge und schreibe lediglich die englischen wegen Grammatik et cetera in einem externen vor 🙂

    Finde den Prototyp ebenfalls ziemlich cool und bin gespannt, wie viel Flexibilität der Nutzer am Ende dann wirklich beim Erstellen von Beiträgen haben wird und wie einfach es beispielsweise Theme-Devs haben werden, eigene Blocktypen zu definieren (zum Beispiel für Small Caps 🙂 ).

    LG
    Florian

    1. Hi Florian,

      bin gespannt, wie viel Flexibilität der Nutzer am Ende dann wirklich beim Erstellen von Beiträgen haben wird

      Ja, das wird interessant. Ich hoffe, man wird nach wie vor irgendwo einfach den HTML-Beitrag eingeben können. Aber irgendwie gehe ich stark davon aus.

      wie einfach es beispielsweise Theme-Devs haben werden, eigene Blocktypen zu definieren

      Für mich kommt da gerade die Frage auf, ob Blocktypen eher Pluginterritory sind und was nach einem Themewechsel mit Blocktypen passieren würde, die in einem Theme definiert wurden. Ergäbe sich daraus ein ähnliches Dilemma wie bei Themeeigenen Shortcodes?

      1. »Für mich kommt da gerade die Frage auf, ob Blocktypen eher Pluginterritory sind und was nach einem Themewechsel mit Blocktypen passieren würde, die in einem Theme definiert wurden. Ergäbe sich daraus ein ähnliches Dilemma wie bei Themeeigenen Shortcodes?«

        Ja, da gebe ich dir vollkommen Recht. Das Beispiel sollte eigentlich auch Dop-Caps (Initialen) sein. Die müssten ja konkret vom Theme unterstützt werden, weshalb es für sowas eventuell sinnvoll sein könnte, dass auch ein Theme irgendwie eine zusätzliche Einstellung für Textfelder hinzufügen kann (da geht nach einem Theme-Wechsel dann ja kein Inhalt verloren, sondern »nur« der Drop-Cap-Style 🙂

  2. Ich schreibe auch viel extern, z.B. in Ommwriter, nutze den Editor aber sehr gerne, besonders seit es die Markdown-Shortcuts gibt.

    Die Umfrage ist sicher wichtig, auch wenn sie letztlich kaum Leute außerhalb der engeren Community erreichen wird. Darum finde ich es besonders spannend, ob und wie der neue Editor irgendwann mit den populären Page-Buildern konkurrieren wird — und wie die Firmen hinter jenen darauf reagieren werden.

    1. Hi Caspar,
      ja, der Prototyp sieht für mich auch so aus als könnte der den Pagebuilder-Markt ordentlich aufmischen.

      Bisher kommen mir dazu drei Gedanken:
      1. Natürlich, wie flexibel können sich Plugins in den Editor reinhängen?
      2. Werden, und wenn ja wie, Spalten gehandelt oder nur Reihen? Das wäre sonst etwas für 3rd parties.
      3. Wie auch Florian schon angesprochen hat: Wie einfach könnten 3rd parties weitere Blockelemente definieren?

      Ich denke an diesen drei Punkten hängt relativ viel für das Pagebuilder Segment.

      Die Umfrage ist sicher wichtig, auch wenn sie letztlich kaum Leute außerhalb der engeren Community erreichen wird.

      Das war auch mein Gedanke, weshalb ich dachte, ein Blogbeitrag verbreitet über den WordPress Planet kann nicht schaden 🙂

  3. Ein sehr guter Editor müsste in Richtung Adobe Dreamweaver gehen. Wenn ich viele verwende und verschachtle, habe ich wegen fehlender Einrückung den Ueberblick nicht mehr.
    Mindestens sollte also die Tabulator-Funktion gehen und bitte den Quellcode so sein lassen, wie ich ihn eingegeben habe und nicht umformatieren („zusammenstauchen“).

    1. Hi Markus,
      das ist interessant. Wie Caspar hatte auch ich erst einmal nur die Pagebuilder als Analogie im Kopf. Aber natürlich gehören auch WYSIWYG-Editoren in das Umfeld, die ganze Webseiten entwerfen. Damit verbunden wäre für mich dann die Frage, wie mächtig der Editor eigentlich sein sollte, denn mit Dreamweaver ist ein Tool im Spiel, welches die Frage aufwirft, wo das Theme aufhört und das „Content“-Design anfängt.

      Ich selbst hatte den Dreamweaver schon seit Jahren nicht mehr in der Hand, habe mir aber mal kurz ein paar Youtube-Tutorials wieder angeschaut. Zu überlegen ist, wie viel Vorwissen eigentlich notwendig sein muss, um möglichst den gesamten Funktionsumfang eines Editors nutzen zu können.

  4. Hi David,

    danke für den Link für die Umfrage.

    Ich persönlich nutze seit den Anfängen den Text-Editor und erweitere lediglich mit Hilfe von AddQuicktag die Button-Leiste. Das einzige was mir fehlt, wäre eine Art Syntaxhervorhebung um den Text gegenüber den HTML-Tags zu hervorheben. Manchmal nehme ich auch vorab einen Text- bzw. HTML-Editor (Desktop) wegen der Syntaxhervorhebung, aber das ist mir zu umständlich, da es halt ein zusätzlicher Schritt ist.

    Ich konnte mich nie mit dem WYSIWYG-Editor anfreunden. Was u.a. daran liegen mag, dass ich gerne mit Text- bzw. einfachen HTML-Editoren arbeite.

    Gutenberg ist zwar ein interessanter Ansatz, aber ich hoffe dennoch das der gute alte Text-Editor in WP erhalten bleibt. 🙂

    1. Hi Vladimir,
      danke für Deinen Kommentar. Wenn ich die derzeitigen Diskussionen richtig verstehe, die sich rund um Browsersupport und Fallback drehen, ist derzeit zumindest der Texteditor nicht wirklich in Gefahr 🙂

      Ich glaube, ich würde ihn auch vermissen.

  5. Leider ist das Front-end editing komplett aus dem Fokus geraten. Mir scheint es getraut sich da keiner wirklich ran – und man arbeitet dann an Gimmicks am Backend. Diese mögen schick sein, aber ob sie nun vorhanden sind oder nicht halte ich nicht für sooo entscheidend.
    Ich denke insbesondere an meine Anwender. Das sind Sachbearbeiter die Texte (z.B. Organisationspläne) fast ausschließlich ändern oder erweitern, selten neu erstellen. Denen kann ich das Backend so und so nicht anbieten. Die Erwartung ist sehr einfach: ich melde mich an und habe dann die Möglichkeit direkt am Frontend durch einen Edit-Button direkt ändern.
    Ich weiß, die Diskussionen darüber gehen schon mehrere Jahre. Und es gibt viele Meinungen darüber. Umso bedauerlicher, dass man das Thema noch nicht mal von der Voraussetzungen her angeht.

    1. Hi Andreas,
      danke für Deinen Beitrag 🙂

      Man stelle sich vor: Frontend Editing als Standard in WordPress. Quer durch alle Themes und alles. Das stelle ich mir tatsächlich schwierig vor. Nur, kurz, obwohl es Dir sicherlich bewusst ist, es gibt Plugins, die dieses Topic schon ganz gut abdecken. Eines habe ich mal in einem Beitrag über die REST-API vorgestellt.

      Würde denn ein solches Frontend Editing für Dich dann den Editor im Backend vollständig ersetzen, so dass dieser einfach entfernt werden könnte?

      1. Wirklich interessant. Deinen Beitrag über die REST-API kannte ich nicht. Der Darin enthaltene Ansatz zum Front-end editing ist schon ziemlich weitgehend und ganz schön cool.
        Meine Gedanken dazu: Ja, in der Tat schwierig, aber sicher (!) nicht unmöglich. Man muss es eben „nur“ anpacken. Mir schon klar: leichter daher gesagt als getan. (Und ich kann es im Übrigen schon mal gar nicht).
        Zu deiner Frage nochmal: Front-end editing verstehe ich in der Tat zunächst mal nur für Anwender. Da ist gemeint, Personen, die das Backend nicht betreten, die in der Regel noch nicht mal den Unterschied zwischen Back und Front kennen, die auch nicht wissen, was WordPress ist. Dort gibt es auch keine Html-Ansicht. (Im Microsoft-Word switcht du ja zwischendurch auch nicht mal in die Binär-Ansicht)
        Der Backend-User ist fortgeschrittener. Er weiß z.B. schon einmal, dass er es mit WordPress zu tun (und nicht Typ, Joomla etc).
        Mein Credo läuft so etwa in die Richtung zusammen, dass man das Technik-Gefrickel im Backend eher etwas zurückstellt (denn die Leute die im Backend arbeiten kommen mit dem Ist-Zustand gut klar). Stattdessen ist es wünschenswert mal den Endanwender (ganz am Ende der Nahrungskette) auch mal etwas Komfort zukommen zu lassen.

  6. Sieht doch auf den ersten Blick ganz nett aus. Die stärkere Strukturierung des Contents gefällt mir sehr gut. Natürlich gibt man damit auch immer ein bisschen Flexibilität auf. Ich frage mich gerade, ob es dann einen Extra Blocktyp für Shortcodes geben wird oder einfach einen „raw“ Typ vielleicht.
    Eine leichte Erweiterbarkeit und Anpassungsmöglichkeiten sind auch sehr wichtig. Damit man dem DAU ein System zusammenbauen kann, mit dem er möglichst wenig „kaputt“ machen kann.
    Bin sehr gespannt auf das Endergebnis!

  7. Hi David,

    schaut nach einem tollen Feature aus, welches das WordPress Team da einbaut. Bin schon gespannt darauf und freue mich diesen endlich nutzen zu können. Dann erspare ich mir die Verwendung eines externen Plugins, welches doch des öfteren auch Probleme bereitet.

  8. Ich finde den WordPress Editor an sich nicht schlecht, nur das mit dem Bilder einfügen nervt immer etwas und empfinde ich teilweise als ziemlich umständlich. Muss aber auch gestehen, dass ich meine Texte immer vorschreibe und erst dann in den Editor reinkopiere 😉

  9. Die Konzeption von Gutenberg i.v.m. der aktuellen REST API ist leider nach wie vor soooowas von broken, das kann man auch beim besten Willen nicht fixen ohne alles umzuwerfen, paar Tage vor Release von 5.0 :-/

    Sie basteln da schon seit Anfang des Jahres dran rum, da gab es schon die ersten Tickets dazu, z.B. #4623 u.ä.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.