Serie: Effizienteres Bloggen mit WordPress dank XML-RPC
- Teil 1: Vorstellung einer neuen Serie
- Teil 2: Das Grundgerüst des XML-RPC-Scripts
- Teil 3: Blogpost-Metadaten auslesen
- Teil 4: Bilder hochladen und problematischen Code ersetzen
- Teil 5: Blogpost absenden und ein notwendiger Hack
- Teil 6: Skript Multi-Blog fähig und konfigurierbar machen
Hier habt ihr ihn nun: den letzte Artikel einer Serie, die sich nun doch über knapp 2 Monate erstreckt hat. Ich habe gezeigt, wie man den Inhalt der Zwischenablage mit Keyboard Maestro (fortan KM genannt) in ein Shell-Skript bekommt, wie man in Bywords HTML-Output Code-Beispiele umschreibet und wie man Bilder sowie den eigentlichen Blogpost hochlädt. Was noch übrig bleibt, habe ich ja bereits im vorherigen Teil angekündigt:
- URL, Benutzername und Passwort in eine Config-Datei auslagern,
- Skript Multi-Blog fähig machen,
- es per KM aufrufen und
- inkl. aller notwendigen Dateien zur Verfügung stellen.
Das Ergebnis von allem wird letztendlich Auf geht’s!
Konfigurationsdaten gehören in eine Konfigurationsdatei
Wir wollen Konfigurationsparameter in ein ini-File schreiben und dieses während der Laufzeit des Skripts auslesen. Also ab in den inc-Ordner und eine config.ini angelegt. Die Notation der notwendigen Daten sollte folgendermaßen erfolgen:
[senaeh]
url = 'http://www.senaeh.de'
user = 'Benutzername'
pass = 'ç00l€$ P@$$wø®†'
min_width = 520
max_width = 520
Der String in den eckigen Klammern – bezeichnen wir ihn als Blognamen – ist recht beliebig. Er wird nachher als Parameter übergeben, deswegen macht etwas kurzes, alphanumerisches durchaus Sinn. Die eckigen Klammern kennzeichnen eine Sektion. Wichtig für die Unterscheidung mehrerer Blogs. url ist die Adresse zu eurem WordPress-Root (ohne abschließenden Slash!). Benutzername und Passwort sollte klar sein, die Maximalhöhe und -breite hatte ich auch schonmal angesprochen (Abschnitt Bild-Dimensionen berechnen).
ini-File parsen
Wie parst man jetzt ein ini-File? Antwort: parse_ini_file(). Die Funktion nimmt 2 Parameter entgegen. Der Erste gibt den Dateipfad an. Der Zweite ist ein Boolean und gibt an, ob die Sektionen ebenfalls geparst werden sollen oder nicht. Ist dieser Parameter nicht gesetzt, defaultet er auf false. Unser ini-File würde mit parse_ini_file(‘config.ini’); wie folgt geparsed:
array(
'url' => 'http://www.senaeh.de',
'user' => 'Benutzername'
'pass' => 'ç00l€$ P@$$wø®†'
'min_width' => 520
'max_width' => 520
);
Ihr seht: die Sektion wird komplett ignoriert, senaeh taucht außerhalb der URL nicht noch mal explizit auf. Problem dabei: sobald wir eine weitere Sektion, d.h. einen weiteren Blog, in unsere config.ini einfügen…
[senaeh]
url = 'http://www.senaeh.de'
user = 'Benutzername'
pass = 'ç00l€$ P@$$wø®†'
min_width = 520
max_width = 520
[ienno]
url = 'http://www.ienno.de',
user = 'Benutzername2'
pass = '@nd€®€$ P@$$wø®†'
min_width = 530
max_width = 530
würden die neuen Werte einfach die vorher deklarierten überschreiben. Doof! Lösung: Verschachtelung der Sektionen. Das erreichen wir, indem der zweite Parameter auf true gesetzt wird. Wenn unsere config.ini also Konfigurationsdaten für einen zweiten Blog enthält, sieht das Ergebnis von parse_ini_file(‘config.ini’, true); so aus:
array(
'senaeh' => array(
'url' => 'http://www.senaeh.de',
'user' => 'Benutzername'
'pass' => 'ç00l€$ P@$$wø®†'
'min_width' => 520,
'max_width' => 520,
),
'ienno' => array(
'url' => 'http://www.ienno.de',
'user' => 'Benutzername2'
'pass' => '@nd€®€$ P@$$wø®†'
'min_width' => 530,
'max_width' => 530,
)
);
Strike! So können wir uns die zur jeweiligen Sektion gehörenden Konfigurationsparameter auslesen.
Zuweisung der Variablen
Bisher haben wir den privaten Variablen ihre Werte direkt bei ihrer Deklarierung oberhalb der construct()-Methode zugewiesen. Ihr erinnert euch?
private $_user = 'Benutzername';
private $_pass = 'ç00l€$ P@$$w®†';
private $_url = 'http://www.senaeh.de/xmlrpc.php';
private $_imgMaxWidth = 520;
private $_imgMaxHeight = 520;
Diese Variablen bekommen ihren Wert fortan erst in besagter construct()-Methode.
public function __construct($htmlString, $identifier)
{
$config = parse_ini_file('config.ini', true);
if (!isset($config[$identifier])) {
var_dump($config);
exit("could not find identifier '$identifier'");
}
$config = $config[$identifier];
$this->_user = $config['user'];
$this->_pass = $config['pass'];
$this->_url = $config['url'];
$this->_imgMaxWidth = $config['min_width'];
$this->_imgMaxHeight = $config['max_width'];
$this->_client = new IXR_Client($this->_url."/xmlrpc.php");
$this->_content = $htmlString;
}
Die Zuweisungen der Variablen erfolgt nun – wie angekündigt – nicht mehr direkt bei der Deklaration, sondern in der construct()-Methode.
2 weitere Änderungen:
- die neue Variable
$identifier(beinhaltet die zu parsende Sektion in der config.ini) sowie - das Extrahieren von /xmlrpc.php aus der URL (wäre Unsinn den String mit in die URLs in der config.ini zu stecken, Redundanz und so).
Wo kommt $identifier her?
$identifier dient der Multi-Blog-Fähigkeit des Skripts und – ich wiederhole mich – beinhaltet die zu parsende Sektion in der config.ini. Doch wo kommt der Wert der Variable ursprünglich her? Antwort: aus KM.
Dort müsst ihr vorher auswählen, für welchen Blog der Blogpost gedacht ist. Der in einer KM-Variable gespeicherte Blogname wird in der index.php ausgelesen und an die EnnoAutoPost-Klasse weitergeleitet. Comprende?
Gehen wir schrittweise rückwärts. Die fertige index.php sieht so aus:
<?php
require_once 'inc/EnnoAutoPost.php';
$htmlString = $_SERVER['KMVAR_blogString'];
$identifier = $_SERVER['KMVAR_blogIdentifier'];
$obj = new EnnoAutoPost($htmlString, $identifier);
$obj->setMetadata();
$obj->replaceCode();
$obj->replaceImageMarkup();
echo $obj->createPost();
Der aufmerksame Leser stellt fest: wir brauchen andere Variablen in KM. Sehr gut!
Das aktualisierte KM-Makro
Wir haben an dieser Stelle eigentlich 2 Arten von Makros:
- das Makro, das unser Skript aufruft, sowie
- ein Makro, das dem Anderen sagt, zu welchem Blog der Blogpost gehören soll.
Schauen wir uns das Makro an, das unser Skript aufruft:
Aktualisiertes Keyboard-Maestro-Makro
Ok, den Teil bis zum Shell-Skript dürftet ihr schon kennen. Die Zwischenablage wird einer Variable zugewiesen und anschließend wird die index.php aufgerufen. Einzige Änderung hier: der Name der Variablen (vorher: temp, jetzt blogString).
Doch was ist das da drunter? Dieser Teil führt dazu, dass der gerade erstellte Blogpost direkt im WordPress-Backend aufgerufen wird. Sieht man auch, oder? Chrome wird aktiviert, per ⌘T ein neuer Tab geöffnet, der Rückgabewert aus unserem Skript eingefügt (dazu gleich mehr) und Enter gedrückt, um die Seite auch tatsächlich aufzurufen. Anschließend werden die temporären Variablen (blogString und blogIdentifier) gelöscht.
So, 2 Sachen, die hier getan werden müssen:
- Unser Skript muss eine URL zurückgeben, nicht wie bisher die ID des erstellten Blogpost.
- Die Variable blogIdentifier muss irgendwo herkommen.
Neues, vorgeschaltetes Makro, das den Identifier festlegt
Die Überschrift sagt’s, oder? Hier ist das kleine Ding:
Makro, das Blog auswählt
Die fehlende Variable blogIdentifier wird gesetzt (remember: muss mit der Sektion in der config.ini übereinstimmen!) und anschließend das Makro aufgerufen, das unser PHP-Skript anstößt.
Irgendwie verwurschtelt? Ja. Hier eine kurze Zwischenzusammenfassung:
- Makro 1 setzt Identifier und ruft Makro 2 auf.
- Makro 2 ruft PHP-Skript (konkret: index.php) auf.
- index.php bedient sich der
EnnoAutoPost-Klasse um Blogpost hochzuladen. - KM öffnet Rückgabewert des PHP-Skripts (eine URL) in Chrome.
Was jetzt also final noch fehlt, ist ein kleiner Umbau um die angesprochene URL zurückzugeben.
Umbau des Rückgabewertes der createPost()-Methode
Keine Angst, keine Magie, die hier passiert. Die createPost()-Methode wird einfach wie folgt abgeändert:
public function createPost()
{
$user = $this->_user;
$pass = $this->_pass;
$this->_postData['post_content'] = $this->_content;
$this->_postData['comment_status'] = 'open';
if (!$this->_client->query('wp.newPost', 1, $user, $pass, $this->_postData))
$this->_displayError('creating post');
$id = $this->_client->getResponse();
return $this->_url."/wp-admin/post.php?post=".$id."&action=edit";
}
FERTIG!
Gib mir den verdammten Source-Code!!!!einseinself
Jaja, is ja gut. Guckst du hier: ich bin ein Projekt auf GitHub. Dort gibt es sowohl die PHP-Klasse als auch das zugehörige KM-Makro.
Noch zur abschließenden Erklärung der Workflow:
- Blogpost in Byword schreiben.
- Fertig mit 1.? Sicher? Korrektur gelesen? Dann ⌘⌥C drücken, um aus dem Markdown-Text HTML zu generieren und in der Zwischenablage zu speichern.
- In der Menüleiste das KM-Makro aufrufen.
- Kurz warten, bis der Blogpost in Chrome aufgerufen wird.
Seid ihr zufrieden mit dem Ergebnis der Marathon-Serie, die euch das Bloggen erleichtern soll? Funktioniert alles? Stellt Fragen, gebt Anregungen, was auch immer. Enno freut sich 😉
