Month: March 2017

Ein neuer Editor für WordPress?

Typewriter

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.

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?

3 Wege WordPress zu deaktivieren

Gestern habe ich mir mal ein bisschen angeschaut, welche meiner Beiträge eigentlich am beliebtesten sind und festgestellt, das unter den Topbeiträgen meine “Deaktiviere dies”-, “Deaktiviere das”-Beiträge sind.

Daraus entstanden diese Tweetserie


https://twitter.com/websupporter/status/838113060791402498

Ich ging erst mal Schlafen und als ich heute morgen aufwachte, dachte ich mir, vielleicht adressiere ich ja die falsche Crowd und gehe einfach zu destruktiv mit WordPress um. Ich sollte vielleicht einfach mehr über “Wie Du X aktivierst” oder “Wie Du Y anwendest” schreiben und hatte mir sogar schon ein Thema zurecht gelegt, bis ich dann in meine Timeline guckte und sah, dass Robert, Thorsten und Heiko schon Vorschläge hatten, wie WordPress am besten deaktiviert wird. Nie um einen kleinen Clickbait verlegen lege ich also meine guten Vorsätze beiseite und geb der Crowd, was die Crowd verlangt.

“How to deactivate WordPress” – Ein nicht ganz ernst gemeinter Beitrag zur Debatte.


Vorbemerk: Etliche Vorschläge in diesem Beitrag führen dazu, dass Dein WordPress nicht mehr zu erreichen ist. Das ist sozusagen das Ziel. Wenn Du weißt, was Du tust, probiere es gerne aus, aber beschwere Dich später nicht “David hat mein WordPress kaputt gemacht”; das warst Du. Wenn Du willst, dass ich es fixe: Ich berechne 80 Euro + Umsatzsteuer für jede angebrochene Stunde.


Heiko schlägt im Wesentlichen vor, einfach den Linux Server herunterzufahren.

Meiner Meinung nach ist das ganz schön brutal und passt nicht ganz in mein Clickbait-Schema. Aber vielleicht ja mal ein Artikel “Wie ich meinen Linuxserver gegen die Wand fuhr”? Außerdem Heiko: Was passiert denn, wenn auf dem Server noch ne Drupal-Installation läuft. Derartige Kollateralschäden würde ich gerne vermeiden. Die Leut drüben bei Drupal sollten wir da nicht mit rein ziehen.

Bleiben die zwei Vorschläge von Thorsten und Robert. Robert schlägt vor, einfach die globale $wpdb in der init-Aktion auf null zu setzen. Traut sich aber nicht mal im Tweet, das zu aktivieren (Hashtag: Hashtag).

Thorsten geht das nicht weit genug; er radiert einfach gleich sämtliche globalen Variablen aus. Die mag der einfach nicht.

Ich hab mir beide Vorschläge mal angeschaut und bin damit nicht so glücklich. Erstens ist WordPress nicht deaktiviert, sondern läuft ja einfach weiter und Zweitens krieg ich auch noch jede Menge PHP Notices und Errors. Das ist doch keine saubere Enterprise-Lösung für unser kleines, dreckiges Problem.

Das ist doch keine Lösung?!
Das ist doch keine Lösung?!

Evaluieren wir also noch einmal, welche Möglichkeiten uns zur Verfügung stehen:

Ein erster Weg WordPress zu deaktivieren. Der Maintenance mode

WordPress verfügt über einen eingebauten “Maintenance mode”, den wir für unsere Zwecke missbrauchen könnten. Relativ am Anfang der wp-settings.php wird die Funktion wp_maintenance() aufgerufen, welche prüft, ob im Root-Verzeichnis von WordPress eine .maintenance-Datei rumliegt. Setzt diese auch noch die Variable $upgraded auf einen Timestamp der nicht älter als zehn Minuten ist, verabschiedet sich WordPress. Was mir an diesem Ansatz gefällt ist, dass er sehr früh im System ausgeführt wird und also WordPress relativ früh deaktiviert. Was mir weniger gefällt ist, dass wir uns dazu via FTP auf dem Server einloggen müssen, um die Datei hochzuladen. Das ist einfach keine gute UX 😞. Aber trotzdem, eine solche Datei würde ihren Dienst tun:

WordPress deaktivieren mit der .htaccess

Wir könnten argumentieren, dass WordPress gar nicht richtig deaktiviert ist, weil das System ja immer bis zu einem bestimmten Punkt durchläuft, während hingegen ein deaktiviertes Plugin überhaupt nicht mehr ausgeführt wird. Auf der anderen Seite gibt es ja einen Unterschied zwischen Deaktivieren und Löschen. “Logge dich mit FTP ein, lösche alle WP-Dateien aber achte darauf, nicht den wp-content/-Ordner, oder zumindest den uploads/-Ordner zu löschen” ist somit ein anderes Thema. Aber: Wir könnten über die .htaccess gehen. Hier gibt es verschiedene Strategien. Ich habe mich dazu entschieden, statt auf die index.php auf eine index.html umzuleiten. (Ich setze hier einmal voraus, dass in diesem Ordner und den Unterordnern nur WordPress läuft und nicht noch irgendwo Drupal 😂) Das ganze sähe dann in etwa so aus:

WordPress mit Hilfe eines Plugins deaktivieren

Aber auch für diese Lösung müssen wir auf FTP zurückgreifen und irgendwie ist das nicht so richtig WordPressy. Nein, Thorsten und Robert haben Recht, es sollte doch ein Plugin sein, aber dann doch bitte eines, welches so früh wie möglich einsteigt. Das ist das schöne an Thorstens all-Filter. Ich hatte an die plugins_loaded gedacht, doch allem Anschein nach hat sich das Thorsten auch gedacht und dann kurz nachgeschaut und festgestellt, dass all vor dem spezifischen plugins_loaded ausgeführt wird. Für ein Plugin ist all der Hook der Wahl. Man könnte natürlich auch einfach ohne Hooks arbeiten, aber bitte mal: Das ist dreckig.

Was mir nicht in den Kopf geht: Warum schlagen Beide danach vor, globale Variablen zu löschen? Gut, ich verstehe die Antipathie ihnen gegenüber, aber sich dafür solche Notices einzufangen. Nein, lieber nicht. Ich gehe lieber mit wp_die(). Man könnte auch die() oder exit; nehmen, um noch weniger WP-Code auszuführen, aber hey:

Fazit

Mit gefällt die Plugin-Lösung am Besten. Das Plugin könnte noch ein wenig Liebe vertragen, so dass man WordPress auch wieder aktivieren könnte, ohne das Plugin vom Server zu löschen. Aber für einen ersten groben Entwurf denke ich, langt es. Wie würdest Du WordPress am “geschicktesten” deaktivieren? Musstest Du WordPress schon einmal deaktivieren und wenn ja, warum?