Wir haben im Prinzip drei Möglichkeiten um die Editor-Einstellungen zu beeinflussen. Zum einen dann wenn sie definiert werden.

$editor_args = array(
	'textarea_name' => 'content',
	'textarea_rows' => 5,
	'media_buttons' => false,
	'tinymce' => false,
	'quicktags' => $quicktags_settings,
);

$editor_args = apply_filter( 'some_filter', $editor_args );

Leider ist dies nicht immer möglich, vor allen Dingen im gegebenen Fall nicht. Leider bietet auch die verwendetet Funktion wp_editor() noch die die Klasse _WP_Editors einen entsprechenden Filter an. Warum das so ist, sei mal dahingestellt. Ebenso das es bereits diverse Tickets im Trac zu den Thema gibt. Wenn man sein Ziel nicht auf direkten Weg erreichen kann, dann muss man manchmal einen kleinen Umweg gehen.

Eine Lösung wäre, wenn die Funktion wp_editor() plugable wäre, man sie also gegen eine eigene Funktion austauschen kann. Ist sie aber nicht, muss man den Hebel also woanders ansetzen.

Im betreffenden Fall wurde angeregt in der Klasse einen zusätzlichen Filter einzubauen. Bis dies umgesetzt ist, muss man sich also mit einen kleinen Workaround behelfen.
Wirft man einen Blick in den Code, so sieht man das abgefragt wird ob die Klasse _WP_Editors bereits geladen wurde. Nur wenn sie nicht geladen wurde, wird die Klasse aus dem WordPress-Core geladen. Für uns bedeutet dies also, wir können die Original-Klasse durch eine gleichnamige eigene Klasse ersetzen. Wir müssen nur dafür sorgen das unsere Klasse möglichst früh geladen wird. Am einfachsten erreicht man dies indem man einen der sehr früh ausgelösten Hooks benutzt um die eigene Klasse mittels require_once()/include_once() einzubinden.

Wie man sieht, gibt es in WordPress nicht nur eine Möglichkeit um etwas zu beeinflussen. Der einfachste Weg sind Filter und Actions um Variablen direkt zu beeinflussen. Sind diese nicht gegeben, schaut man sich an ob die betreffende Funktion etwas hergibt, also ob diese ggf. einen Filter/Action besitzt oder ob man sie ersetzen kann. Ist dies auch nicht gegeben, so kann man, wie hier im Beispiel, noch eine letzte Chance nutzen und eine Klasse komplett austauschen.

Der erste Schritt zum Plugin besteht also darin die Klasse _WP_Editors komplett in sein Plugin-Ordner zu kopieren. Der nächste Schritt ist das Einbinden der kopierten Klasse:

/**
 * Including the modified WP class _WP_Editors
 */
add_action(
	'plugins_loaded',
	function() {
		require_once dirname( __FILE__ ) . '/class-wp-editor.php';
	},
	0,
	0
);

Um zu überprüfen ob nun die kopierte oder die Original-Klasse geladen wird, kann man am Anfang der Kopie einfach mal ein die( 'Kopierte Klasse' ); setzen. Bricht WordPress nach einem Neuladen mit einen weißen Bildschirm ab auf dem nur “Kopierte Klasse” steht, so können wir sicher sein das nur unsere kopierte Klasse geladen wird. Nun geht es daran die kopierte Klasse zu modifizieren. Wie im Ticket vorgeschlagen ergänzen wir die Klasse um einen zusätzlichen Filter.

Da wir nun in der kopierten Klasse einen Filter haben den wir nutzen können, reicht es aus diesen zu setzen und in einer passenden Funktion die Werte entsprechend zu ändern.

/**
 * Add the filter to modify the editor settings
 */

add_filter( 'wp_editor_settings', 'modify_editor_settings', 0, 2 );

/**
 * Modify the editor settings. Currently only set the value for using the TinyMCE to true.
 *
 * @param array $settings Array with editor settings
 * @param array $editor_id The ID of the editor
 * @return array
 */
function modify_editor_settings( $settings, $editor_id ) {

	if ( 'attachment_content' == $editor_id )
		$settings['tinymce'] = true;

	return $settings;

}

Ich habe hier bewusst auf umständliche Prüfungen verzichtet um das Beispiel einfach zu halten. Man könnte zusätzlich darauf prüfen ob man sich auch tatsächlich in der Medienübersicht bzw. Medienbearbeitung befindet. Es wird lediglich geprüft ob die Editor-ID attachment_content ist und dann das Flag für den TinyMCE auf true gesetzt.
Durch Anpassung der Funktion modify_editor_settings() lässt sich so der TinyMCE für nahezu alle Eingabefelder aktivieren sofern die Editor-ID bekannt ist und das Eingabefeld über die Funktion wp_editor() erzeugt wird.

Das Plugin ist recht wartungsfreundlich. Sollte eines Tages ein Filter zum Modifizieren der Editor-Einstellungen vorhanden sein, so muss man nicht das komplette Plugin neu konstruieren. Es reicht aus die Einbindung der eigenen Klasse zu entfernen und ggf. den Filter-Namen anzupassen.

Das Plugin ist sehr einfach gestrickt. Es prüft wie alt das aktuelle Passwort ist und gibt, sofern es veraltet ist, einen Warnhinweis im Adminbereich aus. Dieser Warnhinweis (engl. nag screen; deut. Nörgelbildschirm) erscheint auf allen Seiten im Adminbereich.
Neben den Hinweis im Adminbereich kann das Plugin auch einen unübersehbaren Hinweis auf der Startseite ausgeben. Dies ist nützlich für Benutzer die sich um den Adminbereich drücken.

Natürlich gibt es auch ein paar Einstellungen. Die wichtigste ist wohl die Einstellung wie lange es dauern soll bevor ein Passwort veraltet ist. Es lässt sich aber zusätzlich noch einstellen ob der Hinweis auch auf der Startseite erscheinen soll. Ebenso lässt sich einstellen ob Benutzer den Hinweis eine Zeit lang ignorieren (ausblenden) können und nach welcher Zeitspanne der Hinweis wieder eingeblendet werden soll. Als letzte Einstellung lässt sich noch ein Text festlegen der zusätzlich im Hinweis erscheinen kann. So kann man die Benutzer z.B. auf die Risiken eines veralteten Passwortes aufmerksam machen oder auf verbindliche Nutzerregelungen hinweisen.

Da das Plugin, wie gesagt, sehr einfach gehalten ist, gibt es dazu nun auch nicht mehr viel zu sagen. Experten die das Plugin einsetzen und den Hinweis auf der Startseite optisch ändern möchten, steht ein Stylesheet zur Verfügung das angepasst werden kann.

Für Lob, Kritik, Anregungen und vor allem Fehlerberichte steht der Support auf WordPress und das Repo auf GitHub zur Verfügung.

Zum Glück ist das Programmieren nicht meine Lebensgrundlage, ansonsten wäre ich einige Monate lang berufsunfähig gewesen. So konnte ich mir den Luxus einer langen Auszeit gönnen und habe mich rein gar nicht mehr mit WordPress, PHP oder verwandten Themen befasst.
Andere Dinge rückten in den Mittelpunkt und das war gut so. Ich habe den nötigen Abstand gewonnen um wieder klar denken zu können. Den nötigen Abstand um Projekte, die ich begonnen hatte, wieder mit der nötigen Distanz und Kritikfähigkeit betrachten zu können. Abstand der es mir ermöglichte Wichtiges von Unwichtigen zu trennen.

Bei vielen reicht dafür ein Urlaub. Urlaub bedeutet bei mir jedoch oftmals Zeit zum Coden. Und das war dann wohl auch der Fehler den ich gemacht hatte, weswegen meine Auszeit etwas länger ausfiel.
Dadurch das ich mir Zeit für mich selber und andere Dinge genommen hatte – eher nehmen musste – konnte ich den Akku wieder aufladen. Jetzt macht mir das Coden wieder Spaß, die Zeilen flutschen nur so auf den Bildschirm und ich verbeisse mich nicht mehr an unwichtigen Details.
Viele Projekte habe ich auf Eis gelegt oder gleich ganz aufgegeben, ansonsten hätte ich das Coden wahrscheinlich aus lauter Frust komplett an den Nagel gehängt.
Zu den jetzigen Neuanfang gehört auch ein kleines Plugin, welches ich ohne durch Altlasten aufgehalten zu werden, in den letzten vier Tagen umgesetzt habe.

Entstanden ist das Plugin durch die Beschäftigung mit Menschen die es schon als große Leistung ansehen Facebook zu starten. Denn es kann durchaus hinderlich sein wenn man ständig von Menschen umgeben ist die sich auskennen. Man verliert sehr schnell den Blick dafür was diejenigen benötigen (könnten), die sich weniger bis gar nicht auskennen. Raus aus den Elefenbeinturm ist hier die Devise gewesen.
Und so ist in den letzten Tagen Password Change Reminder (PwCR) entstanden. Bei einer schnellen Recherche konnte ich kein Plugin finden welches den Benutzer daran erinnert regelmäßig sein Passwort zu ändern. PwCR macht genau das. Nicht mehr und nicht weniger.
Das Plugin ist, wie so häufig bei mir, in einem sehr früher Stadium. Da können noch ein paar Fehler dabei sein, die (englischen) Texte sind alle noch etwas schief, Übersetzungsarbeit ist zu leisten und natürlich Dokumentation. Genaueres zu dem Plugin werde ich in eine  seperaten Artikel schreiben. Bis dahin kann jeder der möchte es schon mal ausprobieren.

Derzeit schreibe ich an ein paar Artikeln und ärgere mich immer das ich, wenn ich einen Link erstelle, den Titel für den Link manuell ausfüllen muss. Wahrscheinlich bin ich der einzige auf diesen Planeten mit diesen Problem, deswegen habe ich mir schnell mal ein kleines Plugin geschrieben.

Gibt man im URL-Feld eine gültige URL ein und verlässt dieses Feld, dann wird ein Ajax-Request abgesetzt der versucht aus der verlinkten Webseite den title-Tag zu extrahieren. Gelingt dies, wird der Webseitentitel in das Feld für den Linktitel eingefügt. Wenn nicht, passiert nix. Den Titel kann man bei Bedarf dann noch anpassen oder wieder löschen.

Vielleicht nimmt sich ja mal jemand etwas Zeit und gibt ein wenig Feedback, wäre schön und hilfreich.

Nachtrag

Ich hatte nicht damit gerechnet das dass Plugin ein so hohes Interesse wecken würde. Github, dort wo der Plugin-Code derzeit liegt, ist nicht jedem bekannt und auch nicht jeder weiß wie man aus dem Repository ein Zip bekommt. Deswegen hier eine kleine Anleitung dazu.

Als erstes also mal das Github-Repository öffnen. Sollte euer Bildschirm anders aussehen als im Screenshot links, dann klickt auf Code (zwischen der Pulskurve und Network (die rote Markierung habe allerdings ich eingefügt)). Rechts neben Clone in Windows ist ein Button mit einer kleinen Wolke und dem Wort ZIP (siehe Screenshot). Klickt ihr da drauf, dann sollte eine Aufforderung erscheinen eine Zip-Datei zu speichern.
Diese Zip-Datei speichert ihr auf eurem Computer und kann dann bereits aus dem Backend von WordPress heraus installiert werden.
Dazu im Backend auf die Plugins-Seite gehen, dort oben neben Plugins auf Installieren klicken, im nächsten Bildschirm auf Hochladen (oder in der englischen Version Upload), die zuvor gespeicherte Zip-Datei auswählen und fertig. Nun noch das Plugin aktivieren und das war es.

Als kleines Weihnachtsgeschenk für diejenigen die es brauchen können habe ich FrankenKey veröffentlicht. Das Plugin ist eher als “raft draft” anzusehen, also ein Entwurf für ein Plugin das noch im Fluss der Entwickelung ist. Wer es dennoch schon mal testen will oder sein eigenes Plugin darauf aufbauen möchte, ist gerne eingeladen daraus seine eigene Lösung zu erstellen.

Technisch gesehen ist das Plugin sehr simple aufgebaut. Die Tastatur wird mit mousetrap überwacht. Es gibt zwar noch ein jQuery Plugin namens jQuery Hotkeys welches auch von WordPress bereitgestellt wird, dieses ist aber nicht ganz so leistungsfähig wie mousetrap und ich habe es auch nicht richtig zum Laufen bekommen.
selection.js übernimmt die Arbeit der Modifikationen im Text. Es ist ein jQuery-Plugin welches auf Code von Stackoverflow basiert. selection.js liefert den ausgewählten Text und kann diesen zum Teil auch modifizieren (z.B. in Tags einschließen).
Die Kernkomponente frankenkey.js arbeitet wie eine Weiche. Hier werden die Bindungen zwischen Textfeld und mousetrap angelegt und letzten Endes auch die Tastatureingaben verarbeitet. Wird eine Tastaturkombination erkannt, wird zuerst entschieden ob es sich um eine Kombination zum Einfügen von Tags oder eines simulierten Klicks auf einen der Buttons handelt. Grundsätzlich hätte man das Script so gestalten können, dass es lediglich Klicks auf die Buttons in der Werkzeugleiste simuliert. Dadurch das eigene Aktionen definiert werden, können auch andere HTML-Tags als die vordefinierten verwendet werden.

Mich würde mal interessieren ob es so was überhaupt braucht oder ob es völlig überflüssig ist. Was denkt ihr darüber?

Ein paar Grundlagen

Viele kennen es, wenn WordPress versucht Dateiaktionen auf den Server durchzuführen, z.B. ein Plugin oder Theme zu installieren, wird man nach seinen FTP-Zugangsdaten gefragt. Dabei ist es egal ob man eine Archivdatei direkt hochlädt oder von einen entfernten Server ein Update einspielt. Der Grund dafür liegt nicht bei WordPress, sondern bei Unix bzw. einem Unix-ähnlichen Betriebssystem wie Linux. Die Unix-ähnlichen Betriebssysteme kennen nämlich verschiedene Dateiberechtigungen und vor allem Dateibesitzer. Wenn unter einem Unix-System der (FTP-) Benutzer A eine Datei anlegt, so kann auch nur der Benutzer A diese Datei beschreiben bzw. löschen. Benutzer A ist der Dateibesitzer und hat die volle Kontrolle über die von ihm angelegte Datei. Möchte der Benutzer A das die Datei auch von anderen FTP-Benutzern gelesen bzw. beschrieben werden kann, so müssen entsprechende Berechtigungen vergeben werden. Es gibt drei Gruppen denen man den Zugriff auf die Datei erlauben kann: Nur der Eigentümer (also derjenige der die Datei angelegt hat), eine Gruppe von FTP-Benutzern und Alle anderen (others oder public). Zudem kann auch noch die Art des Zugriffs geregelt werden. Möglich sind: Lesen, Schreiben und Ausführen.
Benutzer A könnte z.B. festlegen das die von ihm angelegte Datei nur von ihm beschrieben werden kann, jedoch z.B. alle FTP-Benutzer aus der Gruppe Tastatursklaven die Datei zumindest lesen können. Alle anderen FTP-Benutzer, so z.B. anonyme Gäste, können die Datei weder lesen noch sie beschreiben.

Dies ist ein grundlegender Schutz vor unberechtigten Zugriffen. Es wäre ja schon ein wenig fatal wenn jeder der will z.B. die Datei wp-config.php lesen, geschweige denn sie nach Lust&Laune verändern könnte. Dieser “Schutz” wirkt sich nun nicht nur auf Dateien aus, sondern auch auf Verzeichnisse. Dateien die in einem Verzeichnis liegen das nur vom Eigentümer gelesen werden kann, können nicht von anderen FTP-Benutzern gelesen werden, egal welche Dateiberechtigung die einzelnen Dateien haben.
Jetzt stellt sich natürlich die Frage was das alles mit WordPress zu tun hat. Schauen wir uns dazu erst einmal die “Ausnahme” an. Das wäre der Fall, wenn WordPress auf einem Server installiert ist auf dem PHP als so genanntes php-cgi läuft. Php-cgi ist eine ausführbare Datei und wird immer unter dem Konto des FTP-Benutzers ausgeführt. Wenn php-cgi also eine Datei auf den Server schreibt, hat die Datei als Eigentümer automatisch den FTP-Benutzer als Dateieigentümer.
Der andere Fall, der weitaus verbreiteter ist, ist der, dass PHP als Apache-Modul (php_mod) ausgeführt wird. In diesen Fall ist nicht der FTP-Benutzer der Dateieigentümer, sondern der Apache-Server, der so gesehen auch ein FTP-Benutzer ist, jedoch mit einen anderen Benutzernamen. Je nachdem wie der Server konfiguriert ist, variiert der FTP-Benutzername des Servers. Häufig ist dies “nobody”, aber auch “wwwrun”, “PHP-User” oder schlicht “PHP”. Welcher Benutzername der Apache-Server genau hat, muss also im Einzelfall jeder selber heraus finden, ist aber für das Verständnis gar nicht so wichtig.

Halten wir kurz fest:

• Unter Unix und Unix-ähnlichen Betriebssystemen haben Dateien und Verzeichnisse einen Besitzer
• Nicht jeder FTP-Benutzer kann auf alle Dateien und Verzeichnisse zugreifen
• Die Zugriffe auf Dateien und Verzeichnisse werden durch Zugriffsrechte geregelt
• Läuft PHP als Apache-Modul, so hat der Server einen eigenen “Benutzernamen” und hat dementsprechend auch Besitzrechte an den von ihm angelegten Dateien und Verzeichnisse.

Was passiert beim Upload?

Wenn wir nun versuchen Dateien oder Verzeichnisse in unser Blog hochzuladen, dann muss WordPress erst einmal feststellen wie es dies bewerkstelligen kann. Die einfachste Methode wäre natürlich WordPress würde die Daten einfach mal so auf dem Server ablegen. Genau genommen versucht WordPress dies auch, lässt es aber meistens aus Sicherheitsgründen sein. Um festzustellen ob WordPress die Daten direkt auf den Server speichern kann, schreibt es eine kleine Testdatei. Danach prüft WordPress ob der FTP-Benutzer mit dem Dateibesitzer der Testdatei übereinstimmt.
Im Fall von php-cgi stimmen die Besitzrechte überein und WordPress kann ohne weitere Nachfrage weiter machen.
Im Fall von PHP als Modul hat die Testdatei jedoch den Server als Besitzer und nicht den FTP-Benutzer. WordPress entscheidet sich in diesen Fall dagegen die Daten direkt auf den Server zu schreiben und sucht nach einer anderen Methode.

Natürlich stellt sich jetzt die Frage warum WordPress nicht doch einfach die Daten auf den Server ablegt. Der Grund liegt in den Zugriffsrechten und und einer Sicherheitslücke die sich (theoretisch) daraus ergibt.
Stellen wir uns mal vor Benutzer A und Benutzer B haben auf dem Webserver C jeweils einen Webspace gemietet. Alle Dateien und Verzeichnisse die von Benutzer A angelegt werden, können auch nur von Benutzer A gelesen und beschrieben werden. Genauso verhält es sich mit den Dateien und Verzeichnissen von Benutzer B. Was ist aber mit den Dateien und Verzeichnissen von “Benutzer C“? Benutzer C wäre in diesem Fall der Webserver. Und wenn der Webserver im Webspace von Benutzer A eine Datei anlegt, dann ist der Webserver der Besitzer dieser Datei. Da sich Benutzer A und B einen Webserver teilen, hat Benutzer B theoretisch über den Webserver Zugriff auf die Dateien im Webspace von Benutzer A, die vom Webserver angelegt wurden. Theoretisch könnte Benutzer B also den Webserver anweisen Dateien die er im Webspace von Benutzer A angelegt hat, auszulesen und im Webspace von Benutzer B zu kopieren. Möglich wäre dies, da der Webserver als Dateibesitzer ja die nötigen Rechte dazu hat.
Dies ist eine eher theoretische Sicherheitslücke. Theoretisch deshalb, da auf einen vernünftig konfigurierten Server so etwas nicht möglich sein sollte. Der Server sollte so konfiguriert sein, dass kein Benutzer auf Dateien oder Verzeichnisse außerhalb seines Webspaces zugreifen kann. Andernfalls könnte jeder Benutzer auch problemlos die Konfigurationsdateien des Webservers manipulieren.
Doch grau ist alle Theorie, die Praxis hat schon andere Fälle hervor gebracht. Und genau deswegen geht WordPress auf Nummer sicher und zieht es vor die Daten nicht direkt auf den Server abzulegen sofern es unter PHP als Apache-Modul läuft.

Kurz zusammen gefasst: Stellt WordPress fest das es nicht mit den gleichen Benutzernamen wie der FTP-Benutzer läuft, weigert es sich schlichtweg die Daten direkt auf den Server zu schreiben um nicht eine Sicherheitslücke bei den Zugriffsberechtigungen zu öffnen.

Und es nervt doch

Da PHP als Apache-Modul sehr verbreitet ist, werden auch viele WordPress-Nutzer regelmäßig nach ihren FTP-Zugangsdaten gefragt. FTP ist die zweite Variante mit der WordPress die Daten auf den Server bekommt. Dazu tut WordPress einfach so, als sei es der FTP-Benutzer unter dem der Blog angelegt wurde und der rechtmäßig Zugriff auf alle Dateien hat. Somit werden die Daten nicht mit dem FTP-Benutzer “nobody” (oder PHP-Run, oder PHP, oder oder oder) geschrieben, sondern mit dem von uns angegebenen Benutzernamen und Passwort.

Wer nur selten Daten auf seinen Server kopiert, den wird es nicht stören ab und an mal seine FTP-Daten anzugeben. Es gibt aber so einige Fälle wo es doch sehr nervig werden kann. Als Entwickler schiebt man ständig zu Testzwecken Daten auf den Server und löscht sie dort wieder. Das man auch beim Löschen von Daten die FTP-Zugangsdaten angeben muss, dürfte mittlerweile klar sein. Denn WordPress kann aufgrund der fehlenden Zugriffsberechtigungen nicht als Benutzer “PHP-Run” auf die Daten von FTP-Benutzer “Horst4711″ zugreifen.
Manchmal ist es aber auch einfach zu unbequem die FTP-Zugangsdaten, die sich natürlich kaum einer merkt weil das Passwort kryptisch³ ist, raus zu suchen. Und manchmal hat ausgerechnet der Mitarbeiter die FTP-Zugangsdaten, der gerade in Kambodscha Urlaub macht und nicht erreichbar ist.

Für solche Fälle gibt es einige Möglichkeiten die FTP-Zugangsdaten direkt in WordPress zu hinterlegen. Alle Möglichkeiten haben ihre Vor- und Nachteile. Einige sind sogar, m.E. nach, ein wenig gefährlich.

Speichern ist einfacher als raus suchen

Ab Werk kann man WordPress seine FTP-Daten also nur per Formular übergeben. Wer häufig unterwegs ist und sich dementsprechend genauso häufig in ungesicherte WLAN-Netzwerke einloggt (oder einloggen muss), wird immer ein mulmiges Gefühl haben wenn er die FTP-Zugangsdaten ungesichert quer durch die Bahnhofshalle zum Router schicken muss. Gerade wenn es um Kunden-Server geht ist hier etwas Vorsicht geboten. Falls jetzt jemand die Idee hat SSL wäre ja eine Lösung, der hat im Prinzip Recht. Jedoch denken die meisten Kunden da ganz anders. Wenn SSL extra kostet, dann braucht man das nicht. So denken zumindest die meisten Kunden.
Diese Lösung hat allerdings auch einen Vorteil. Legt man auf dem Server für jeden Admin einen FTP-Konto an, so kann Admin B nicht aus versehen (oder mit voller Absicht) die Dateien und Verzeichnisse von Admin A löschen oder überschreiben.

wp-config

Die erste Alternative zur Übertragung via Formular wäre die FTP-Zugangsdaten in der wp-config.php abzulegen. Dazu stellt WordPress drei Konstanten bereit: FTP_HOST, FTP_USER und FTP_PASS. Die Namen sprechen für sich und es dürfte klar sein für was die einzelnen Konstanten stehen. Wer mehr über die Konstanten von WordPress erfahren will, sollte mal einen Blick bei Dominik Schilling (G+ Profil)  rein werfen. Er hat eine umfangreiche Auflistung alle Konstanten.
Beispiel:

// defining the ftp-account data
if( ! defined( 'FTP_HOST' ) )
  define( 'FTP_HOST', 'meine-dmoain.de' );

if( ! defined( 'FTP_USER' ) )
  define ( 'FTP_USER', 'Horst4711' );

if( ! defined( 'FTP_PASS' ) )
  define( FTP_PASS', '&SchmierMaxe$0815!' );

Man sieht schon wo hier das Problem liegen könnte. Das Passwort liegt unverschlüsselt in einer PHP-Datei von der so ziemlich jeder Hacker weiß das dort was zu holen ist. Auf der anderen Seite steht in der selben Datei aber auch das Passwort für die Datenbank, ebenfalls unverschlüsselt. Man kann jetzt so oder so argumentieren. Die einen sind der Meinung das eh Hopfen&Malz verloren ist wenn die wp-config.php geknackt ist. Die anderen sagen das man einen Hacker nicht noch freien FTP-Zugang zum Server geben muss wenn er sich schon die Datenbank unter den Nagel gerissen hat.
Diese Methode spart auf alle Fälle die lästige Tipparbeit und man muss, sofern man mit mehren Mitarbeitern an einen Blog arbeitet, die FTP-Zugangsdaten nicht jedem aufs Auge drücken. Irgendwo gibt es immer einen der Zugangsdaten auf einen PostIt schreibt und diesen dann irgendwo vergisst oder verliert.
Hier wird deutlich das WordPress eigentlich ein Single-User-System ist dem man notdürftig eine Benutzerverwaltung aufgepflanzt hat. Denn so kann jeder Benutzer mit Admin-Rechten auf alle Dateien und Verzeichnisse zugreifen. Ob nun gewollt oder ungewollt. Es ist durchaus denkbar das Admin B ein Verzeichnis löscht oder überschreibt das von Admin A angelegt wurde und das auf gar keinen Fall gelöscht oder überschrieben werden durfte.

FS_METHOD

Eine andere Alternative zum Formular besteht darin, WordPress dazu zu zwingen die Daten direkt auf den Server zu schreiben. Indem man die Konstante FS_METHOD auf direct setzt, lässt man WordPress erst gar nicht dazu kommen auszuwählen ob es die Daten direkt oder per FTP auf den Server schreibt.
In meinen Augen ein Fauxpas sofern man dies auf einen Shared-Host anwendet. Für die möglichen Gefahren, siehe oben.
Nun ist aber nicht jedes Blog auf einen Shared-Host angelegt. Wer stolzer Besitzer eines eigenen Servers ist, kann diese Methode durchaus dazu nutzen den FTP-Upload zu umgehen. Wenn es auf dem ganzen Server nur einen FTP-Benutzer gibt, gibt es auch keinen zweiten der unberechtigt auf die Dateien zugreifen kann. Wobei man diese Aussage ein wenig relativieren muss. Denn als Apache-Modul ausgeführt, ist der Webserver natürlich auch ein FTP-Benutzer. Durch setzen der Konstante FS_METHOD auf direct, werden alle Dateien und Verzeichnisse mit dem Besitzer “Webserver” (oder so ähnlich) erstellt. Das kann in sofern problematisch werden, wenn in einem Plugin oder Theme “versehentlich” etwas wie exec( "rm -rf /" ); drin steht. Dann werden halt mal alle Dateien und Verzeichnisse die vom aktuellen Benutzer, sprich Webserver, angelegt wurden, gelöscht. Ohne Rückfrage versteht sich. Aber auch ein unlink() kann an der falschen Stelle mit dem falschen Pfad ausreichend Schaden anrichten.
Ein weiteres Problem dürfte zwar nur selten auftreten, ist mir persönlich aber durchaus schon mal passiert. Daten die vom Webserver geschrieben worden sind konnte ich als FTP-Benutzer nicht mehr löschen. Sicherlich auch eine Sache der Server-Konfiguration, man sollte aber vor Einsatz dieser Alternative erst einmal ausprobieren ob man denn die Daten die der Webserver geschrieben hat auch wieder löschen kann. Das Selektive Löschen einzelner Dateien oder Verzeichnisse kann sich dann sehr mühsam gestalten.

Die Konstante FS_METHOD kann jedoch auch sehr nützlich sein. Wir erinnern uns an php-cgi bei dem alle Daten unter dem Benutzernamen geschrieben werden. WordPress muss unter php-cgi nicht nachfragen ob es die Methode “direct” oder “ftp” benutzen soll, dadurch kann es gleich loslegen. Das ist vielleicht aber gar nicht immer erwünscht. Mit FS_METHOD können wir WordPress auch dazu zwingen FTP als Methode zu verwenden und jedes mal Benutzernamen und Passwort (und Hostname) abzufragen. Für Blogs die unter php-cgi laufen also ein kleiner Workaround wie man ganz einfach eine Authentifizierung vor dem Schreiben/Löschen von Daten erzwingen kann.

/*
 * force users to use ftp
 *
 * use 'ftpext' for using Apache FTP Extension
 * use 'ftpsockets' for ftp-sockets (Socket-Class or PHP-Extension)
 *
 */

if( ! defined( 'FS_METHOD' ) )
  define( 'FS_METHOD', 'ftpext' );

Obwohl ich hier nur mehr oder minder die Oberfläche angekratzt habe, sieht man schon wie komplex die gesamte Thematik ist. Gänzlich ausgeklammert habe ich z.B. die ganze Thematik um SSH/SSL, SFTP und das WordPress-Filesystem sowieso. Das ist genug Stoff für weitere drei oder vier Artikel.

Eine Plugin-Lösung

Meiner Philosophie zur Folge muss ein Blogartikel nicht komplett und vollständig sein, sondern vielmehr zum Nachdenken, Experimentieren und vor allem Diskutieren anregen. Sicherlich gibt es den einen oder anderen Aspekt den ich übersehen, falsch oder missverständlich dargestellt habe oder der mehr Interesse geweckt hat als der Artikel bedienen kann.
Genauso halte ich es auch mit meinen Plugins. Keine fertige Allroundlösung mit allen erdenklichen Features, sondern ein Lösungsansatz für ein Problem. Das folgende Plugin liegt in der Version 0.1 vor, ist also der erste Entwurf und eher ein PoC (Proof of Concept). Sowohl Artikel als auch Plugin sind beide an einen Tag entstanden, dementsprechend unausgiebig wurde das Plugin von mir getestet. Ich bitte dies beim Ausprobieren zu berücksichtigen.

FTP-Account to UserMeta

Dieses Plugin macht in etwa genau das was der (uninspiriert gewählte) Name aussagt. Es speichert die FTP-Zugangsdaten in den Benutzer-Daten des jeweiligen Benutzers. Damit sind zwei Anforderungen die im Laufe des Artikels aufgetaucht sind erledigt. Zum einen, und wichtigsten, muss man die FTP-Zugangsdaten nicht mehr ständig eintippen. Einmal im Benutzerprofil eingegeben stehen sie ab dann immer zur Verfügung wenn WordPress diese anfordert. Zum anderen können mehrere FTP-Benutzer ihre Daten hinterlegen da für jeden Benutzer separate FTP-Zugangsdaten gespeichert werden. Dadurch kann z.B. verhindert werden das Benutzer A die Dateien von Benutzer B versehentlich löscht, das Plugin kommt also aus der Ecke “Betreutes Bloggen”.

Das Plugin hinkt noch an der einen oder anderen Stelle. So werden die FTP-Passwörter (noch) im Klartext in der Datenbank gespeichert. Es sollte aber kein Problem darstellen eine entsprechende Ver- und Entschlüsselung nachzurüsten.
Auch fehlt noch die Unterstützung für SFTP/SSL da mir hierfür derzeit die nötige Umgebung fehlt (ja, ich habe weder SSL noch sonst was auf meinen lokalen Server. Nicht mal mod_ftp). Gegen Bereitstellung von etwas Platz auf einen entsprechenden Server mit SSL/SFTP bin ich gerne bereit das zu ändern Ansonsten muss man halt warten bis ich das auf meinem lokalen Server nachgerüstet habe.

Die Bedienung des Plugins ist recht simple. Nach der Installation und Aktivierung werden im Benutzerprofil drei Felder für FTP-Hostname, FTP-Benutzername und FTP-Passwort hinzugefügt. Sind die drei Felder ausgefüllt und wird das Profil aktualisiert, verschwindet ab diesen Zeitpunkt für diesen Benutzer die Aufforderung seine FTP-Zugangsdaten einzugeben sofern diese erforderlich sind. Alle anderen Benutzer die FTP benutzen können aber keine Zugangsdaten hinterlegt haben, werden weiterhin aufgefordert ihre Zugangsdaten bei Bedarf einzugeben.
Die Kontrolle darüber welche Benutzer überhaupt die drei Felder zu sehen bekommen, erfolgt hardcodiert im Plugin selber. Voreingestellt sind Administratoren (Role administrator), was wahrscheinlich am meisten Sinn macht. Es können aber auch andere Rollen bzw. Fähigkeiten (Capabilities) angegeben werden, womit eine recht feine Einstellung möglich ist wer seine FTP-Zugangsdaten eingeben kann.
Damit nach der Deinstallation des Plugins keine sensiblen Daten in der Datenbank verbleiben, werden diese bei der Deinstallation (nicht deaktivierung!) gelöscht. Sofern man das Plugin also über das Backend entfernt, kann man es gefahrlos ausprobieren.

Das Plugin findet ihr auf Github. Für diejenigen die es nicht so mit Git haben, als Zip-Datei. Die anderen dürfen gerne forken, pullen und commiten.

Update

Da das Plugin auf  einiges Interesse gestoßen ist, habe ich den Code mal etwas bereinigt und glatt gezogen. Neue Funktionen sind in dieser Version (v0.1.2) nicht hinzugekommen, dafür aber die eine oder andere Funktion für die nächsten Versionen notiert. Es wird sicherlich noch das eine oder andere umgesetzt werden, da ich hierdurch auch die Möglichkeit bekomme verschiedene Sachen auszuprobieren und ggf. darüber etwas zu schreiben.

WordPress lässt sich relativ einfach dazu bringen Login-Daten automatisiert anzunehmen. In erster Linie ist die Funktion wp_signon() dafür zuständig den Login durchzuführen. Dazu übergibt man ihr Benutzername und Passwort, die Funktion gibt daraufhin true zurück bzw. ein WordPress-Fehler-Objekt. Dies kann man bequem mit is_wp_error() abfragen und so mit nur wenigen Zeilen einen Login durchführen.

<?php
require( dirname(__FILE__) . '/wp-load.php' );
is_wp_error(
	wp_signon(
		  array(
			'user_login'=>'YourLoginName',
			'user_password'=>'YoUrAw3s0M3P455W0rD'
			) 
		 )
) ? die('Mooo... :(') : wp_safe_redirect( admin_url() );

Speichert man den Code in einer separaten Datei ab, so muss zuerst wp-load.php eingebunden werden um die WordPress-Funktionen verfügbar zu machen. Hier bitte auf den Pfad achten, iom Gist liegt die Datei im gleichen Verzeichnis wie wp-load.php.  Danach wird direkt wp_signon() mit einem Array aus Benutzername und Passwort gefüttert, welches wiederum direkt als Parameter an is_wp_error() übergeben wird.
Durch Aufruf der Datei ist man direkt eingeloggt und wird ins Backend umgeleitet. Möchte man lieber ins Frontend umgeleitet werden, so ersetzt man einfach admin_url() durch site_url().

Ich habe mir für meine Entwicklungsarbeit ein kleines Plugin geschrieben mit dem ich recht schnell zwischen verschiedenen Benutzern hin- und her wechseln kann. Dazu listet mir das Plugin auf der Login-Seite die Test-User auf, welche ich zuvor angelegt habe. Durch einen Klick auf einen entsprechenden User-Namen kann ich mich dann ohne Eingabe von Benutzername und Passwort anmelden. Auf Optik habe ich verzichtet, da es ein Werkzeug bei der Entwicklung ist. Wer mag, kann dem ganzen ja noch ein bisschen optischen Feinschliff verpassen.
Das Plugin WP-Quicklogin ist auf Github zu finden.

Viele Tests messen einfach das, was man einfach messen kann. Das wäre dann z.B. der Speicherverbrauch. Dann wird auch gerne die Ausführungszeit gemessen, was aber aufgrund der unterschiedlichen Systeme schon kaum noch Aussagekraft hat. Reicht das alles nicht, kommen gerne noch so obskure Faktoren wie Codezeilen oder Anzahl der verwendeten Hooks und Filter hinzu.
Selten bis gar nicht wird die Code-Qualität bewertet. Dies ist für mich aber ein sehr wichtiges Kriterium. Denn ein schlampig programmiertes Plugin läuft oft auch schlampig, wirft Fehlermeldungen und ist nicht zukunftssicher. Häufig sieht man Plugins die über die Jahre gewachsen sind bis der Autor selber den Überblick verliert. Entweder wird das Plugin dann von Grund auf neu programmiert und weiter gepflegt. Oder aber, was häufiger vorkommt, man lässt das Plugin so wie es ist und kümmert sich nicht mehr darum.
Nun ist Code-Qualität nicht ganz so einfach zu “messen”. Man muss den Code bewerten und hierzu eine Reihe von Kriterien heranziehen. das kostet Zeit und Mühe, weshalb es wohl niemand macht. Ein Kriterium wären zum Beispiel die Übersichtlichkeit. Das kann eigentlich jeder bewerten der sich den Code anschaut. Oder aber auch ob der Code ein Wust aus wilden Zeilen darstellt die kaum entzifferbar sind. Ist der Code gut kommentiert damit auch jemand der nicht so viel Ahnung von Programmierung hat versteht was da vor sich geht. Hält der Code sich an gewisse Programmierrichtlinien. Nur um mal einige wenige Kriterien zu nenne die man verwenden kann.
All das kann man mit Noten bewerten, sogar relativ objektiv. Nun werden einige sagen “Hauptsache es rennt!“. Das ist natürlich auch ein Argument. Also zieht man noch die Anzahl an Fehlern, Notices usw. heran die das Plugin wirft wenn man es einsetzt. Auch grausam geschriebener Code kann fehlerfrei laufen. So kommt man schon zu einen recht guten und nachvollziehbaren Ergebnis.
Kennt man sich bei der Programmierung ein wenig besser aus, dann kann man auch noch einzelne Code-Abschnitte genauer unter die Lupe nehmen. Ist der Code gemäß den empfohlenen Vorgaben geschrieben? Wenn nicht, macht es Sinn von den Vorgaben abzuweichen? Gibt es “merkwürdige” Programmiertechniken im Code oder ist alles auf den ersten Blick verständlich?

Für mich sind dies deutlich wichtigere Faktoren als Millisekunden Laufzeit und Megabyte Speicherverbrauch. Denn dies sind Faktoren die ich erklären kann, so dass auch jemand der weniger Ahnung hat versteht wie ich zu meinen Testergebnis gekommen bin. Und vor allem wird schnell deutlich wo noch Potenzial für Verbesserungen besteht. Code der leicht verständlich ist, wird auch gerne von anderen gepflegt, so dass er sich recht schnell verbreitet und mit der Zeit (hoffentlich) besser wird.

Ein ziemlich merkwürdiger Test macht hingegen gerade auf Google+ die Runde. Es geht um den Plugin-Test von MillaN. Sergej Müller hat sich wohl zurecht gefragt wie MillaN auf seine Ergebnisse kommt. Getestet wurden 35 Plugins aus den unterschiedlichsten Kategorien und mit einem Wert von 1 (schlecht) bis 5 (sehr gut) bewertet. Nur wie dieser Wert zustande kommt, bleibt vielen vollkommen unergründlich.
Vielleicht ist weniger Speicherverbrauch besser als mehr? Also FPW Post Instructions bekommt eine 4 bei einem konstanten Speicherverbrauch von 0,1MB. GD Press Tools Pro verbraucht zwar 29 mal so viel Speicher (2,9MB), bekommt aber die Bestnote 5. Es scheint also etwas mit dem Speicherverbrauch im Frontend bzw. Backend zu tun zu haben. Denn GD Press Tools Pro verbraucht im Frontend “nur” 2MB Speicher, während FPW Post Instructions sowohl vorne wie hinten den gleichen Speicherverbrauch hat. So wirklich schlüssig ist das Konzept jedoch nicht. Denn Event Manager bekommt die schlechteste Note 1 bei einem Speicherverbrauch von 5 bzw 3,7MB (Front-/Backend). GD Custom Posts And Taxonomies Tools Lite bekommt für die gleiche Leistung (1,5/1,3MB) eine noch ganz gute 4 verpasst. Event Manager ist also schlechter obwohl es mehr Speicher einspart?
Ich könnte jetzt noch weiter rätseln ob es vielleicht an der Ausführungszeit liegt oder an der Anzahl der verwendeten Hooks. Vielleicht auch am Mondstand beim Test des Plugins. Man weiß es nicht und der Autor trägt auch nicht zur Aufklärung bei.

Grade 2 plugins have only some elements of optimization, but they are close to grade 1. Adminimize plugin shouldn’t even load on the front end except for some elements, and that needs to be optimized.

Das soll also der Grund sein warum einige Plugins schlechter sind als andere? Adminimize soll z.B. im Frontend nur das laden was es benötigt, was es im Prinzip auch macht, dies sollte aber optimiert werden? Hö? Es scheint also darum zu gehen was ein Plugin im Front- bzw. Backend lädt. Da ist es wohl egal welche Aufgabe es hat, wenn es nicht den geheimen Richtlinien des Autors entspricht, ist es schlecht.

Na dann schauen wir uns doch mal eins dieser supertollen Grade-5 Plugins an. Ich habe mich für GD Unit Converter entschieden und es mal unter die Lupe genommen. Was mir beim ersten Blick auffiel, waren folgende Codezeilen:

$this->script = $_SERVER["PHP_SELF"];
$this->script = end(explode("/", $this->script));

Und? Sinn erkannt? Also ich habe erst mal längere Zeit gerätselt was da passiert bis ich den Code kopiert und getestet habe. OK, ich schreibe es mal ein wenig um:

$this->script = basename(__FILE__);

So einfach kann PHP sein. Der nächste Horror folgt sofort:

    private function plugin_path_url() {
        $this->plugin_url = plugins_url("/gd-unit-converter/");
        $this->plugin_path = dirname(dirname(__FILE__))."/";

        define("GDUNITCONVERTER_URL", $this->plugin_url);
        define("GDUNITCONVERTER_PATH", $this->plugin_path);
    }

Da werden also zwei globale Variablen definiert die zwanzig Zeilen später bei einem wp_enqueue_script() wieder verwendet werden. Klar, man hätte auch einfach auf $this->plugin_url zurück greifen können (OOP, u know!?). Aber warum sparsam mit dem Speicher umgehen wenn man doch so schön sinnlos welchen durch Verwendung globaler Variablen verschwenden kann?
Ach ja. Weil man anderen gerne vorschreibt sie sollen doch bitte schön sparsam mit dem Speicher umgehen:

I am sure that many developers will say that these results are not important, but considering that most of the WordPress users are on shared hosting with limited memory and resources available to them, this is most important thing to have plugins they need and still have server running fine.

Also Wasser predigen und Wein saufen. Contactform 7 bekommt übrigens nur eine schwache 2, dafür aber eine extra Erwähnung:

All tested plugins, but one, used the internal WordPress AJAX handling. Contact Form 7 uses own handler and that is not something I can recommend. Using WP handler is best solution considering that it is already written with security concerns in mind and it is very easy to use, making plugin fit better with WP development concepts.

Muss ich extra erwähnen das GD Unit Converter seinen eigenen Caching-Mechanismus mitbringt und mal ganz elegant auf den in WordPress bereits eingebauten Caching-Mechanismus pfeift?
Natürlich darf auch der eigene Logger nicht fehlen, der zwar nicht genutzt wird aber dennoch geladen werden muss (require_once). Über solch lustige Konstrukte wie folgenden wundert man sich dann schon gar nicht mehr.

$js_url = defined("SCRIPT_DEBUG") && SCRIPT_DEBUG ? "js/src/unit-converter.js" : "js/unit-converter.js";

Wenn SCRIPT_DEBUG definiert ist, sollen die JavaScripte aus dem nicht vorhandenen Verzeichnis js/src/ geladen werden. Das gibt lustige Fehlermeldungen wenn man sein Blog im Debug-Modus startet. So lustig, das man das Plugin sofort deaktiviert.

Es ist einfach schlau daher zu reden und dann selber solch einen Mist zu veröffentlichen. Gefühlt die Hälfte des Codes die das Plugin umfasst ist sinnlos, wird nicht benötigt, verstößt gegen Coding Guidelines oder ist schlichtweg Speicherverschwendung. Hier sollte der Herr MilanN vielleicht selber noch mal Hand anlegen und das Plugin um fluffige 90% Code reduzieren bevor er ihm die Bestnote 5 verpasst. Ich habe mich vorhin mal eine Stunde lang hingesetzt und versucht das Plugin von Scratch (also ohne Vorlage) nachzubauen. Nach einer Stunde hatte ich bereits brauchbare Ergebnisse und kam mit einem Zehntel an Code aus. Der Speicherverbrauch dürfte noch sparsamer sein, da ich nicht total unnützes Zeug lade, sondern mich darauf beschränke das zu nutzen, was ich benötige.

Solche Tests die nicht klar machen wie eine Bewertung zu Stande kommt und bei denen der Autor sich die Testbedingungen so zurecht biegt das er sich selbst Bestnoten verpassen kann, kann man getrost außer Acht lassen. Hier muss sich jeder selber fragen wie objektiv der Test sein kann wenn die eigenen Plugins den Maßstab vorgeben. Da sollte man sich als Autor nicht wundern wenn andere einen auf den Zahn fühlen und zeigen wo der Mops die Locken hat.

Fazit

Gute Tests sind objektiv und vergleichen nicht eigene Arbeit mit der von Fremden. Wird die eigene Arbeit dennoch im Test mit einbezogen, dürfen die Testkriterien nicht auf die eigene Optimierung hin zugeschnitten sein.
Die Testkriterien sollten klar und verständlich sein. Was man als Leser nicht nachvollziehen kann, ist nichts wert. Ist es fraglich wie eine Bewertung zu Stande gekommen ist, ist der ganze Test wertlos. Moinka Thon-Soun hat auf Texto in einen Artikel beschrieben wie ein schlecht gemachter Test auf einen Laien wirkt. Nämlich verwirrend, sonst nichts.
Die Tests sollten nachprüfbar sein. Dazu müssen Testscripte zugänglich sein und die Testumgebung erläutert werden.
Test sollten nicht auf einen einzelnen Aspekt fokussiert sein. Jeder Test hat einen Schwerpunkt, dies rechtfertigt jedoch nicht eine schlechte Bewertung weil ein Testkandidat eben nicht genau den Schwerpunkt trifft. Ein guter Tests umfasst mehrere Aspekte und bildet aus den Einzelergebnissen eine Bewertung. Jedes Plugin hat seine Stärken und Schwächen. Ein Plugin das optisch gut gestylt daher kommt, verbraucht eben mehr Speicher (mehr Grafiken, mehr CSS, mehr Code) als ein Plugin welches sehr spartanisch gestaltet ist. Was nützt einem aber ein Plugin das am falschen Ende spart, wenn es durch seinen Purismus nur schwer bedienbar ist?
Tests sollten sich auf das beschränken, was unter anderen Systemen ähnliche (vergleichbare) Ergebnisse liefert. Eine systemunabhängiger Wert sind z.B. Fehlermeldungen (auch Notices und Deprecated Meldungen) . Die werden auf jeden System gleich sein, denn falsch ist hier wie da falsch.
Test sollten realitätsnah sein. Im Labor gelten andere Regeln als in der Wildnis. Selbst wenn ein Plugin im Test wunderbar abschneidet, kann es dadurch versagen das es andere Plugins behindert oder gar komplett ausschaltet. Man kann nicht alle Kombinationen von Plugins prüfen, jedoch gibt es eine Reihe von Regeln für ein friedliches Miteinander die man beachten sollte.

Also bitte nicht jeden Test blauäugig Glauben schenken. Lieber einmal mehr als einmal zu wenig an den Ergebnissen zweifeln. Wir wissen doch alle: Die Statistik die man selber gefälscht hat, ist immer noch die beste

Manchmal bin ich pingelig und mich stört so etwas auch. Logindaten egal welcher Art haben in Links und anderen öffentlich zugänglichen Bereichen einfach nichts zu suchen. Das widerspricht auch der Idee das man neben den Login-Namen auch noch zwei andere Namen in seinem Profil angeben kann und auswählen kann welchen Namen man gerne öffentlich verwenden möchte.

Der Workaround

Um das Problem zu lösen gibt es einen Workaround und eine Möglichkeit mit Filtern zu arbeiten. Zuerst der Workaround. WordPress bietet nämlich die Möglichkeit für jeden Autoren eine eigene Autoren-Seite anzulegen. Dieses Template wird zuerst gezogen bevor das allgemeine Template für alle anderen Autoren verwendet wird. Anders ausgedrückt: Existiert für den Autor X ein spezielles Template, wird dieses verwendet. Existiert kein solches Template, dann wird das allgemeine Template verwendet.
Dabei sucht WordPress in folgender Reihenfolge nach einem passenden Template:

1. author-{autor-name}.php
2. author-{autor-ID}.php
3. author.php

Ist der Login-Name des Autoren z.B. “Klaus” und existiert ein Template author-klaus.php, wird zuerst dieses Template verwendet. Dies hilft uns in diesem Fall jedoch nicht weiter, da weiterhin der Login-Name verwendet wird.
Jedoch kann man auch die ID des Autoren verwenden. Existiert ein Template author-12.php und hat der Autor “Klaus” die ID 12, dann wird dieses Template verwendet. Ändert noch nichts daran das im Link immer noch der Login-Name erscheint.
Um dies zu ändern, greift man in das Template ein in dem die Funktion get_author_posts_url() verwendet wird. Das ist von Theme zu Theme leider immer etwas unterschiedlich, je nach dem wo die Metadaten zum Post ausgegeben werden. Diesen Funktionsaufruf ersetzt man nun mit diesem Monster:

str_replace(
  get_the_author_meta( 'user_nicename' ),
  get_the_author_meta( 'ID' ),
  get_author_posts_url( get_the_author_meta( 'ID' ) )
)

Damit ersetzt man den Login-Namen (user_nicename) durch die ID des Autoren. Nun benötigt man noch ein Template author-xy.php wobei xy die jeweilige ID des Autoren ist.

Das ganze ist ein Workaround der nur sehr begrenzt einsatzfähig ist. Man muss jedes mal am Theme rumfummeln, die ganze Sache ist nicht wirklich übersichtlich und am Ende benötigt man auch noch für jeden Autoren ein eigenes Template. Eignet sich also normalerweise nur für Blogs in denen es 1-2 Autoren gibt und die eher selten ihr Theme wechseln.

Im Grunde genommen bedeutet hier aber, dass es nur auf den ersten Blick so einfach zu sein scheint. Wer sich schon mal mit den Thema Übersetzung von Plugins oder Themes beschäftigt hat, der wird früher oder später die vielen kleinen Haken zu spüren bekommen. Einer dieser kleinen Haken ist der, dass WordPress einen grundlegenden Unterschied bei der Einbindung von Übersetzungen macht. load_theme_textdomain() ist, wie der Name vermuten lässt, für Themes zuständig, während load_plugin_textdomain() für Plugins zuständig ist. Es ist schon mal auffällig das es für die gleiche Aufgabe zwei verschiedene Funktionen gibt. Also schauen wir doch mal in die Core-Datei wo der Unterschied bei diesen beiden Funktionen liegt.

Beide Funktionen finden wir in wp-includes/l10n.php. Beide Funktionen erwarten bei ihren Aufruf die Übergabe einer Domain und eines Pfades. Im Falle von load_plugin_textdomain() können sogar zwei verschiedenen Arten von Pfaden angegeben werden, wobei der absolute relative Pfad veraltet ist und nicht mehr verwendet werden sollte.
Bei genauerer Betrachtung fällt aber auf, dass load_theme_textdomain() bei der Pfadangabe deutlich toleranter ist als load_plugin_textdomain(). Ist kein Pafd angegeben, so verwendet load_theme_textdomain() das Verzeichnis des aktuellen Templates als Pfad. Ansonsten könnte man den Pfad auch sonstwohin zeigen lassen, es würde noch funktionieren.
load_plugin_textdomain() ist da etwas strikter. Egal ob man einen Pfad angibt oder nicht, es wird auf jeden Fall WP_PLUGIN_DIR, also der Pfad zum Plugin-Verzeichnis, im Pfad eingefügt.
Mit load_theme_textdomain() könnte man also auch eine Sprachdatei benutzen die in wp-content steht. Mit load_plugin_textdomain() wäre dies unmöglich.

Nun sind Pfadangaben in WordPress eine Sache für sich an die man sich gewöhnen und mit denen man umzugehen lernen kann. Deutlich mehr Kopfschmerzen bereitete mir in der Vergangenheit ein Umstand, den ich irgendwie nicht verstehe. Und zwar das Format nach dem die Sprachdateien benannt werden müssen.
load_theme_textdomain() erwartet das die Sprachdatei lediglich aus der Locale und der Endung .mo besteht. Also z.B. de_DE.mo oder en_EN.mo. load_plugin_textdomain() hingegen erwartet zu der Locale noch zusätzlich die Domaine als Teil des Dateinamens. Die Datei muss also das Format domain-locale.mo haben.
Für mich recht unverständlich und letzten Endes kann dies auch zu Problemen führen. Denn ändert sich im Plugin die Domaine, z.B. nach einem Update, dann können auch die (alten) Sprachdateien nicht mehr geladen werden. Man müsste also entweder alle Domainen im Plugin ändern oder alle Sprachdateien umbennenen.

Aber man sollte auch immer die Vorteile im Auge behalten. Durch die Verwendung der Domaine im Dateinamen der Sprachdatei kann man auf recht einfache Weise z.B. zwischen der Du- und der Sie-Form wechseln. Etwas was für deutsche Übersetzungen ja nicht ganz unerheblich ist.
Dazu legt man einfach z.B. eine Sprachdatei mit den Namen pluginname_du_form-de_DE.mo und eine mit den Dateinamen pluginname_sie_form-de_DE.mo an. Im Plugin selber kann man mittels define('MeinePluginDomain', 'plugin_xx_form'); eine Konstante definieren die dann in den Übersetzungsfunktionen verwendet wird (z.B. __('This example text', MeinePluginDomain)). Je nachdem ob xx nun ‘du’ oder ‘sie’ ist, schaltet man zwischen Du- und Sie-Form um.

Jetzt hat man aber ein Problem mit Sprachen die nicht zwischen Du und Sie unterscheiden. Mit Englisch zum Beispiel. Denn man müsste nun für jede Sprache zwei Sprachdateien anfertigen. Einmal plugin_du_form-en_EN.mo und einmal plugin_sie_form-en_EN.mo.
Das ganze gestaltet sich an diesen Punkt als etwas zu aufwendig um schön zu sein. Es gibt aber auch eine Lösung für das Problem. Wir benötigen ja eigentlich nur eine Funktion die in einem Verzeichnis nachschaut ob es eine Sprachdatei nach dem Format domaine-locale.mo gibt und diese lädt. Gibt es eine solche Sprachdatei nicht, wird halt eine Sprachdatei nach den Format locale.mo geladen. Gibt es diese auch nicht, wird halt nichts übersetzt.
Nebenbei erledigt sich mit solch einer Funktion das leidige Pfad-Problem. Die Sprachdateien können nun quasi an einen beliebigen Ort abgelegt werden. Ob dies Sinn macht, sei an dieser Stelle mal dahin gestellt.

Hier erst einmal die Funktion:

function flexible_loadtextdomain( $path = false, $domain = 'default' ){

  if( ! $path || ! is_dir( $path ) )

    return false;

  global $l10n;

  $local = get_locale();

  $mofile = $path . $domain . '-' . $local . '.mo';

  // try to find a matching translation

  // first try domain-locale.mo

    if( ! file_exists( $mofile ) ){

    // if not found, try only locale.mo

    $mofile = str_replace( $domain . '-', '', $mofile );

      if( ! file_exists( $mofile ) ){

        // if even this failed, throw an error or do something wired

        return false;

      }

    }

  load_textdomain( $domain, $mofile );

  return isset( $l10n[ $domain ] );

}

Die Funktion erwartet zwei Parameter. Zum einen eine Pfadangabe und zum anderen den Namen der Domain. Die erste If-Abfrage sorgt dafür das überhaupt ein Pfad übergeben wird und das es auch ein Verzeichnis ist. Anstatt einfach nur false zurück zu geben, kann man hier natürlich noch weitere Spielereien unter bringen indem man z.B. einen Pfad vorgibt (WP_PLUGIN_DIR oder get_template_directory).
Der Rest ist das was ich oben schon beschrieben habe. Erst domain-locale.mo suchen, wenn nicht gefunden locale.mo suchen, wenn das auch nicht gefunden irgendwas verrücktes machen, zum Beispiel false zurück geben.
In der letzten Zeile wird dann noch geprüft ob die Domain erfolgreich geladen wurde. Ab WP 3.0 kann man dies durch return load_textdomain(...) abkürzen. In älteren Versionen muss man diesen kleinen Umweg gehen da load_textdomain keine Erfolgsmeldung zurück gibt.

Der Code der Funktion ist ein wenig abgespeckt. Will man es ganz sauber programmieren, dann würde man noch ein paar Sachen anders machen, z.B. nicht $locale = get_locale(); verwenden, sondern $locale = apply_filters( 'xyz', get_locale(), $domain ); (xyz = theme_locale oder plugin_locale, je nachdem ob man die Funktion in einem Theme oder Plugin verwendet).

Vielleicht ist dieser Beitrag ja eine kleine Anregung für alle die Themes oder Plugins schreiben.