Nun kann man das also auch mit Fotos machen. Es ist sozusagen optisches Knistern. Ein Klick auf den passenden Filter, und schon sieht das Foto aus dem Leuchtkasten aus, als hätte man es mit einer alten russischen Lomo aufgenommen. Oder als wäre der Film vergilbt, oder wellig, oder grau. Die App lädt das Foto nicht nur ins Instagram-Profil hoch, sondern schickt auch gleich noch einen Tweet los mit der Bildunterschrift. Das nützt WordPress zunächst nichts, aber es gibt diverse Plugins und Widgets, um Instagram-Bilder automatisch ins Blog einzubinden. Hier holt das Instagram-Widget for WordPress die Aufnahmen auf die Seite bzw. direkt in die Menüspalte.

Was das soll? Es macht einfach Spaß, mit einer paar Wischbewegungen Fotos zu klicken, schnell zu bearbeiten und dann gleich auf die Seite zu ballern. Was hier im kleinen und aus Spaß läuft, machen andere beruflich. So gab es im Jahr 2010 eine leidenschaftliche Debatte über eine Fotoreportage der New York Times. Zu sehen waren Bilder von US-Truppen in Afghanistan, aufgenommen mit einem iPhone, darauf auch bearbeitet, mit Filtern belegt und dann veröffentlicht. Die Diskussion damals schwankte wohl in etwa zwischen “Fotografen sollten nicht mit einem Telefon Bilder machen, wo kommen wir denn da hin” bis zu “es zählt nicht die Ausstattung, sondern die Bild-Idee, die ein Fotograf hat”. Hier gehts zu der Afghanistan-iPhone-Foto-Reportage.

Das ist sicher nett gemeint – Jetpack ersetzt das beliebte WordPressCom-Stats-Plugin. Um dessen Daten auch im Frontend anzuzeigen, ist der WordPressCom-Stats-Helper nötig. Das Zusatzplugin stellt Widgets für die Sidebar bereit. Hier auf kohlhof.de ist es unten rechts die Info über die “Leser heute”. Und das wird mit Jetpack zum Problem. Denn es ersetzt das Stats-Plugin und deaktiviert es. Beides nebeneinander laufen zu lassen, ist nicht möglich.

Aber ohne das Statistik-Plugin will auch der kleine Helfer nicht mehr Zahlen ausspucken. Er will aber auch nicht mit Jetpack kooperieren – und unten rechts erscheint nur eine Fehlermeldung. Die Dokumentation auf der Jetpackseite gibt nichts dazu her. Aber hier gibt es Hilfe: Entweder mit einem zusätzlichen Plugin (das in meinem Fall aber nicht geholfen hat, es ließ sich nicht aktivieren), oder mit Hilfe von ein bisschen Handarbeit. In der PHP-Datei des WordPressCom-Stats-Helpers müssen ein paar Codezeilen auskommentiert und eine weitere verändert werden. Und schon funktionierts wieder. Immerhin.

Regelmäßige Sicherheitskopien sind ja, um hier noch einmal den wohl unsympathischsten Abteilungsleiter einer Versicherungsgesellschaft zu imitieren, also Sicherheitskopien sind die Lebensversicherung des kleinen Mannes. Immer mal wieder zwischenspeichern kann einem jede Menge Verzweiflung ersparen. Auch online. Die Blog-Software WordPress legt zum Beispiel von jedem Beitrag jede Menge Sicherheits- und Zwischenkopien an. Falls beim Schreiben irgendwas schief geht, weil zum Beispiel die Internetverbindung abbricht, kann man sich später neu einloggen und ganz einfach die letzte zwischengespeicherte Version des neuesten Traktats weiter entwickeln.

Funktioniert einwandfrei. Was WordPress allerdings nicht macht: Erkennen, welche dieser Revisionen später noch einmal benötigt werden könnten, und welche nicht. Als Faustregel kann wohl gelten, dass alles, was veröffentlicht ist und älter als einen Monat, nur in Ausnahmefällen danach noch mal geändert wird, zum Beispiel nach einem hilfreichen Hinweis der verehrten Leserschaft.

Die ganzen Zwischenkopien sind spätestens dann überflüssig. Und es kommt einiges an Datensätzen zusammen, die dann natürlich in der Datenbank landen und dort auf Ewigkeiten ungenutzt rum hängen, Platz verschwenden und sich selbst wahrscheinlich furchtbar überflüssig vorkommen. Es ist an der Zeit, diese unnützen Sicherheitskopien ins digitale Nirwana zu befördern.

Und wie man Revisionen in einer WordPress-Datenbank löscht, das habe ich zufällig erfahren, durch einen ebenso zufälligen Besuch in „Sylvis Blog“ – dort stellt die Autorin gleich fünf, sechs Schritte vor, wie man die Menge der Text-Backups in der WordPress-Datenbank in den Griff bekommen kann. Ich habe mich für das Plugin „Delete-Revision“ entschieden. Es macht genau das, was es soll. Seit etwas mehr als zwei Jahren (so lange ist es schon her, dass WordPress dieses Backup-Feature eingebaut wurde) sind bei mir 1296 Zwischen-Backups angefallen. Fast 1300 Einträge, als das…öööööh…. Einen Klick später waren sie jedenfalls alle gelöscht, die endgültigen Texte sind natürlich noch da.

Das hat die Datenbank also mächtig entschlackt – und hat vielleicht auch für ein bisschen schnelleres Arbeiten im Hintergrund gesorgt.

Als nächstes hätte ich jetzt gern ein Plugin, das automatisch in meinem Arbeitszimmer den ganzen überflüssigen Kram nach unten zum Altpapiercontainer bringt….

So funktionierts, zum Beispiel mit Links:

• Klicken Sie bitte auf die Schaltfläche “Link”
• Ein neues Fenster erscheint, kopieren Sie hier bitte den kompletten Link rein.
• Klicken Sie in dem Fenster auf OK.
• Der passsende HTML-Code wird ins Kommentarfeld eingefügt. Da steht dann zum Beispiel <a href=”http://www.kohlhof.de/kohlhof”>
• Klicken Sie jetzt auf  “Close-Tags”. Dann ist der Link komplett. <a href=”http://www.kohlhof.de/kohlhof”></a>
• Zwischen den beiden HTML-Befehlen sollten Sie jetzt noch den Text eingeben, auf den andere Leser später klicken können. Also zwischen den beiden spitzen Klammern. Zum Beispiel so: <a href=”http://www.kohlhof.de/kohlhof”>Blog von Christian Kohlhof</a>

• Ein zweites Fenster erscheint, hier können Sie einen Text reinschreiben, der statt der Internetadresse angezeigt wird, und auf den man dann klicken kann.
• Klicken Sie wieder mal auf OK.

Dieses Kommentarfeld hier unten ist dann zum Testen freigegeben. (Bedenken Sie bitte, dass der Spamschutz-Mechanismus mehr als zwei Links in einem Kommentar als Werbemüll einstuft und dieser dann erst vom Blog-Chef freigeschaltet werden muss.)

Viel Spaß weiterhin auf kohlhof.de!

Andere haben da größere Sorgen, wie ich gerade lese (nachdem ich dort darauf aufmerksam wurde): So kann das automatische Update auf WordPress 2.8 im schlimmsten Fall die ganze Installation zerschießen und die Software ins Nirvana schicken. Die Datenbank und damit alle Artikel sind davon zwar nicht betroffen – aber von Hand alles wieder hochladen und einrichten ist auch nicht gerade vergnügungssteuerpflichtig (um hier ausnahmwsweise mal Herrn Stoiber zu zitieren). Hintergrund für den Crash ist wohl ein Problem, wenn das automatisierte Update wegen fehlender Schreibrechte Dateien nicht ersetzen kann. Dann versucht die Update-Funktion, alles wieder rückgängig zu machen und löscht dann sozusagen aus Versehen ein paar Dateien zu viel.

Hier ist das zum Glück nichts passiert – aber aus oben beschriebenem Grund veröffentlichen die WordPress-Programmierer wohl schon bald Version 2.8.1. Mal sehen, ob ich dann die Auto-Update-Funktion nutze… ich bin da irgendwie skeptisch ;-)

Was lehrt uns diese erschütternde Episode? Ganz klar: Machen Sie ein Backup – und zwar regelmäßig von Dateien und Datenbank.