Es gibt praktischerweise eine Wordpress iOS App mit der nicht nur neue Beiträge bequem vom Smartphone aus erstellt und bearbeitet werden können, sondern man kann vom Smartphone aus auch mit ihr ein Bild, ein Gif oder ein Video in ein Wordpress-Blog hochladen. Das Problem dabei ist nur, dass obwohl man bei einem selbstgehosteten Wordpress-Blog zwar wahlweise mit einem eingeschränktem Benutzeraccount angemeldet ist, hochgeladen (Medien-) Dateien über das Rechtemanagement diese des Administrators erhalten. Der eingeschränkte Benutzer kann die Bildinformationen wie Name oder Beschreibung nicht anpassen. Eine Lösung, wie sich dieses Verhalten der App abändern lässt, habe ich bisher noch nicht gefunden. Der Workaround für den Übergang ist aber, über ein SQL-Statement den Eigentümer der Mediendatei zu ändern. Dies geht aber nur für jede Datei einzeln. Gegeben ist, das in der Tabelle für die Posts „wp_posts“ die Datei die Record-ID 4155 besitzt. Der User des Posts wird von dem Wert 1 (Administrator) auf den Wert 2 (eingeschränkter Benutzer) geändert.

UPDATE wordpress_b.wp_posts SET post_author=2 WHERE id=4155;

Wenn man im WYSIWYG-Editor einen Beitrag bearbeitet, so erzeugt WordPress standardmäßig alle 60 Sekunden eine neue Revision. Auf Dauer kann dies zu überflüssigen Einträgen führen, welche die Datenbank sehr stark anwachsen lässt und in ihrer Performance beeinträchtigt. Im WordPress selber gibt es aber leider keine Möglichkeit, dies einzustellen und zu begrenzen.

Eine Möglichkeit als Lösung ist es, die Revisionen aus der Datenbank nachträglich heraus zu löschen.:

DELETE FROM wp_posts WHERE post_type="revision";

Wordpress bietet wie bei den Beiträgen die Möglichkeit, dass die Medien-Dateien wie Bilder oder Audio-Dateien mit Kommentaren und Pingbacks versehen werden können. Aber anders als bei den Blog-Beiträgen selber, kann die Kommentar- und Pingback-Funktion für jede einzelne Medien-Datei nicht über Wordpress deaktiviert werden. Dennoch laufen bei aktivierter Kommentarfunktion mit der Zeit viele Spam-Einträge auf, die es auf Dauer zu unterbinden gilt.

Für eine einzelne Datei mit der Record-ID 9 in der Tabelle der Beiträge der SQL-Datenbank lautet die SQL-Abfrage wie folgt:

UPDATE wordpress_b.wp_posts SET comment_status='closed' WHERE ID=9;
UPDATE wordpress_b.wp_posts SET ping_status='closed' WHERE ID=9;

Für alle Medien-Dateien, bei denen die Kommentar- und Pingback-Funktion es noch zu schließen gilt, kann folgendes SQL-Statement als Sammelabfrage angewendet werden. In der Tabelle, in der die Mediendateien gemeinsam mit den Blog-Beiträgen verzeichnet sind, werden diese mit dem 'Post-Status' „Inherit“ markiert.

UPDATE wordpress_b.wp_posts SET comment_status='closed' WHERE post_status='inherit';
UPDATE wordpress_b.wp_posts SET ping_status='closed' WHERE post_status='inherit';

Nach längerer Zeit sammeln sich bei aktivierten Kommentaren sehr viele Spam-Kommentare an. Dies lassen sich im Wordpress händisch als Spam markieren oder in den Papierkorb löschen. Ab einem bestimmten Grad von mehreren hundert oder tausend Einträgen wird dies aber sehr langwierig und umständlich. Einfacher ist es daher, die unmoderierten Spam-Kommentaren mit einem einzelnen SQL-Statement zu zuordnen. Der Name der Datenbank ist in dem Beispiel 'Wordpress_b.:

UPDATE wordpress_b.wp_comments SET comment_approved='spam' WHERE comment_approved=0;

Man könnte statt 'spam' auch 'trash' für den Papierkorb wählen, oder die unmoderierten Einträge mit dem Statement 'DELETE' direkt löschen, aber …

SQL-Statements lassen sich natürlich auch wunderbar in Shell-Skripte integrieren. In dem Beispiel-Skript werden also alle als Spam oder im Papierkorb abgelegte Kommentare gelöscht.

#!/bin/sh
mysql <<EOF
use wordpress_b;
DELETE FROM wp_comments WHERE comment_approved="trash";
DELETE FROM wp_comments WHERE comment_approved="spam";
EOF

Dies lässt sich natürlich weiter automatisiert steigern indem das Skript mit einem Cronjob periodisch zu einem bestimmten Zeitpunkt ausgeführt wird.