WordPress bekommt einen Redakteur, der nie krank wird

Fast jeder Betrieb hat irgendwo ein WordPress laufen. Die alte Firmenseite, ein Blog, den mal jemand angefangen hat, die Vereinsseite. Sie läuft, sie ist erreichbar, und der letzte Beitrag ist von 2023.

Das liegt selten am Willen. Schreiben kostet Zeit, die im Tagesgeschäft nicht übrig ist. Die klassischen Auswege sind alle unbefriedigend: Ein Texter kostet Geld, selbst schreiben kostet Abende, und Text aus einem KI-Fenster in den Editor kopieren ist Fummelei, bei der jedes Bild von Hand hochgeladen werden will.

Der Ausweg, der wirklich etwas ändert, ist ein anderer: Die KI bekommt einen eigenen Zugang zur Seite. Dann schreibt sie nicht nur, sie stellt auch ein.

Was das praktisch heißt

Man legt in WordPress einen Benutzer an, so wie man einen Aushilfsredakteur anlegen würde. Rolle „Redakteur", nicht Administrator. Der darf Beiträge schreiben, Bilder in die Mediathek laden und Entwürfe anlegen, aber keine Einstellungen ändern und keine Plugins installieren. Das dauert zwei Minuten und ist die wichtigste Entscheidung im ganzen Ablauf.

Danach genügt ein Auftrag in normalen Worten: Schreib einen Beitrag über dieses Thema, mach ein passendes Titelbild dazu, leg ihn als Entwurf an, ich schalte ihn frei. Was dann läuft, läuft ohne mich: Text, Bild, Bild auf WebP eingedampft und unter 200 Kilobyte gebracht, hochgeladen, als Beitragsbild gesetzt, Kategorien und Schlagwörter vergeben, Entwurf gespeichert.

Mein Anteil schrumpft auf zwei Handgriffe: Thema nennen, hinterher gegenlesen und freischalten. Das Gegenlesen ist dabei nicht die Formalie, sondern die eigentliche Arbeit. Dazu unten mehr.

Der Fehler, den ich gemacht habe

Und jetzt der Teil, den ich beim ersten Anlauf falsch aufgeschrieben hatte.

In meiner ursprünglichen Fassung dieses Beitrags stand: Nimm die alte XML-RPC-Schnittstelle, die funktioniert direkt mit Benutzername und Passwort, kein Plugin nötig. Das stimmt technisch. Es ist trotzdem der falsche Rat.

Denn was passiert mit so einem Zugang? Er wandert in eine Notizdatei, damit man ihn wiederfindet. Die Notizdatei wandert ins Projektverzeichnis. Das Projektverzeichnis wandert nach Git. Und irgendwann steht das Kontopasswort im Klartext in einem Repository und in dessen kompletter Historie.

Genau das ist mir passiert, aufgefallen am 12. August.

Der Ehrlichkeit halber gehört dazu, wie weit es tatsächlich gereicht hat: Mein Git liegt nicht auf GitHub, sondern auf einem eigenen Server im Haus, und der ist aus dem Internet nicht erreichbar. Das Repository war innerhalb dieses Servers auf „öffentlich" gestellt — öffentlich heißt dort aber: für jeden im eigenen Netz. Um an das Passwort zu kommen, hätte jemand erst in dieses Netz gelangen und danach gezielt in die Versionsgeschichte einer Datei schauen müssen. Nach allem, was ich sehe, ist nichts abgeflossen.

Trotzdem habe ich es ersetzt, und zwar aus einem einfachen Grund: „Wahrscheinlich hat es keiner gesehen" ist keine Sicherheitsmaßnahme, sondern eine Hoffnung. Ein Zugang, der einmal im Klartext irgendwo lag, gilt als bekannt. Was ihn hier gerettet hat, waren zwei Schichten, die zufällig beide gehalten haben — eigener Server statt fremder Cloud, und kein Weg von außen hinein. Verlassen möchte ich mich darauf nicht, denn die eine Schicht, die versagt hat, war die einzige, die ich selbst in der Hand hatte.

Deshalb steht das hier so ausführlich: Der Fehler ist nicht spektakulär, er ist alltäglich. Genau deswegen passiert er.

Richtig ist es so:

Ein Anwendungspasswort statt des Kontopassworts. WordPress bringt das seit Version 5.6 mit, unter Benutzer → Profil ganz unten. Man erzeugt pro Anwendung eines, es gilt nur für die Schnittstelle, und man kann es einzeln widerrufen, ohne dass sich jemand neu anmelden muss. Wird es bekannt, klickt man es weg und erzeugt ein neues. Beim Kontopasswort geht das nicht so schmerzfrei, weil daran alles hängt.

Der Zugang gehört in einen Passwortspeicher, nicht in eine Datei. Egal wie praktisch der Kommentar in der Konfigurationsdatei ist. In Dokumentation steht der Verweis auf den Eintrag, nie der Wert.

Und wenn ein Zugang doch einmal offen lag, wird er ersetzt. Nicht die Datei aufräumen und hoffen. Die Historie eines Repositories vergisst nichts, und Aufräumen ohne Wechseln ist Selbstbetrug.

Das kostet fünf Minuten mehr als der schnelle Weg. Ich habe die fünf Minuten gespart und dafür einen kaputten Kanal.

Vorher: das Backup, und zwar eins, das schon einmal zurückgespielt wurde

Bevor irgendeine Maschine Schreibrechte auf der eigenen Seite bekommt, wird gesichert. Nicht weil eine KI mutwillig etwas zerstört, sondern weil sie gehorcht: Wer ihr aus Versehen die Beitragsnummer eines bestehenden Artikels nennt, bekommt einen überschriebenen Artikel. Und das ist nur der neue Grund. Der alte gilt weiter — Updates, Plugins, Hoster.

Der Ablauf ist unspektakulär. Einmal ein vollständiges Backup, bevor der Zugang eingerichtet wird. Danach ein automatischer Lauf, wöchentlich reicht bei einem Blog. Und vor jeder größeren Aktion noch einmal von Hand.

Zur Werkzeugfrage, weil danach oft gefragt wird und die Antwort davon abhängt, ob man an den Server kommt.

Wenn Sie SSH-Zugang haben, brauchen Sie kein Plugin. Ein Datenbank-Dump und ein Archiv des Verzeichnisses wp-content, beides per Cron, danach eine Kopie auf einen Rechner bei Ihnen. Das ist der einzige Weg, bei dem wirklich nichts das Haus verlässt, und er ist obendrein der schnellste beim Zurückspielen. So mache ich es bei meinen eigenen Servern.

Ohne Server-Zugang kommen zwei kostenlose Plugins in Frage, die beide auf eigenen Speicher schreiben können statt in eine fremde Cloud:

• BackWPup — 400.000 aktive Installationen, aktuell Version 5.7.5, seit einiger Zeit von WP Media. Die kostenlose Fassung sichert wahlweise in einen Ordner auf dem eigenen Server oder per FTP dorthin, wohin Sie wollen.
• UpdraftPlus — über 3 Millionen Installationen, Version 1.26.6. FTP ist in der kostenlosen Fassung enthalten. Verschlüsseltes SFTP allerdings nicht, das gehört zur Bezahlversion.

Bei beiden gilt derselbe Vorbehalt, und den sollte man kennen: Es sind kommerzielle Produkte mit kostenloser Einstiegsstufe. BackWPup meldet Nutzungsdaten an einen Analysedienst, im Änderungsprotokoll steht das unter Mixpanel. Das lässt sich in den Einstellungen abschalten, aber man muss es tun. „Kostenlos" heißt nicht automatisch „nichts fließt ab", und wer den Punkt ernst nimmt, schaut nach dem Einrichten einmal in die Plugin-Einstellungen.

Der wichtigste Satz zum Schluss, und er gilt unabhängig vom Werkzeug: Ein Backup, das noch nie zurückgespielt wurde, ist kein Backup, sondern eine Hoffnung. Einmal auf einer Testinstallation ausprobieren, ob aus der Datei wirklich wieder eine Seite wird. Das dauert eine halbe Stunde und ist die beste halbe Stunde in der ganzen Einrichtung.

Der Kalender füllt sich von allein

Ein zweiter Punkt, der in der Praxis mehr bringt, als er klingt: Wer an einem Nachmittag fünf Beiträge schreiben lässt, will sie nicht an einem Nachmittag veröffentlichen. WordPress kann Beiträge terminieren, und die KI kann den Termin gleich mitsetzen.

Damit wird aus einem Schwall ein Rhythmus. Fünf Artikel, im Wochenabstand eingeplant, und die Seite lebt fünf Wochen lang, ohne dass jemand etwas tun muss. Meine eigene Blogseite läuft genau so: jeden Samstag um acht.

Ehrlicherweise gehört dazu, dass ich diesen Takt selbst gerissen habe. Zwischen dem 25. Juli und Mitte August lag hier drei Wochen lang nichts. Das Werkzeug verhindert Lücken nicht, es verbilligt nur das Füllen.

Wo die Arbeit wirklich liegt

Nicht im Schreiben. Im Prüfen.

Ein Beitrag, der über die eigene Firma erzählt, enthält Zahlen, Daten und Behauptungen. Eine KI schreibt eine falsche Jahreszahl genauso flüssig hin wie eine richtige, und sie klingt dabei kein bisschen unsicher. Wer ungelesen freischaltet, veröffentlicht früher oder später Unsinn unter seinem eigenen Namen.

Deshalb ist die Rolle „Redakteur" und der Umweg über den Entwurf keine Vorsichtsmaßnahme für Ängstliche, sondern der Kern des Ganzen. Die Maschine schreibt, der Mensch verantwortet. Bei mir landet jeder Beitrag als Entwurf, und ich lese ihn, bevor er rausgeht. Bei diesem hier habe ich dabei den Absatz über die Zugangsdaten umgeschrieben.

Wann sich das lohnt: Wenn eine WordPress-Seite existiert, die mehr Inhalt vertragen könnte, und wenn die Themen im Kopf sind, aber die Abende fehlen.

Wann eher nicht: Wenn es um Fachinhalte geht, die außer Ihnen niemand prüfen kann. Dann hilft die KI beim Formulieren, aber das Gegenlesen wird nicht kürzer, sondern länger.

WordPress war nie das Problem. Es fehlte nur jemand, der schreibt. Nur muss man diesem Jemand einen Schlüssel geben, den man auch wieder abziehen kann.