Deshalb der Appell an jene, die die Bibliothek es falsch verwenden.

FALSCH:

if ($form->isValid) {

$objekt = new Test_Object();
$objekt->property1 = $_POST['property1'];

}

RICHTIG:

if ($form->isValid) {

$objekt = new Test_Object();
$objekt->property1 = $form->getValue('property1');

}

Das Wichtigste dabei ist, dass man den Server in den Einstellungen seines WordPress aktiviert. Dazu benötigt man nur einen kleinen Haken, der sich unter Einstellungen / Schreiben findet. Nachdem die Einstellung gespeichert ist könnt ihr anfangen mit Zend auf die Schnittstelle zuzugreifen.

Das Zend Framework bietet uns hier bereits einen fertigen Client, der all die nervigen Arbeiten abnimmt. Um die Verbindung zur API herzustellen bedarf es dank dieser Hilfe nur einer Zeile.

$xmlClient = new Zend_XmlRpc_Client('http://www.dein-blog.de/xmlrpc.php');

Eine genaue Beschreibung zum XML-RPC-Client des Zend Framework findet man natürlich entsprechend im Reference-Guide. Ich möchte nun von meinem Blog die Posts einer Kategorie abrufen. Dazu gab es bereits die Erweiterung des XML-RPC-Servers. Die Funktionen aufzurufen ist dann nur noch ein kleiner Schritt.

$data = $xmlClient->call(
    'zorta.postsbycategory',
    array(
        'username'	=> 'BENUTZERNAME',
        'password'	=> 'PASSWORT',
        'category'	=> KATEGORIE-ID
    )
);

Als Benutzername und Passwort übergibt man dem Aufruf die Daten seines Benutzers für den WordPress-Blog. Die Daten kann man nun über eine Array-Behandlung einfach ausgeben oder weiterverarbeiten.

Eine eher mangelhafte Aufführung der vorhandenen XML-RPC-Methoden findet man bei WordPress.

Das Einarbeiten in die Schnittstelle ist recht simpel. WordPress selber bietet dafür zwar wenig Hilfe, aber mit etwas Geschick findet man sie im Netz. Leider ist die Schnittstelle aber nicht gerade ausgereift und liefert allerlei Lücken und Unstimmigkeiten. Zum Beispiel ist die Übertragung von Benutzernamen und Passwort unterschiedlich. Es gibt Funktionen, da muss man erst den Benutzernamen und dann das Passwort übertragen, aber wiederum gibt es Funktionen bei denen man erst eine BlogId (Es war wohl einmal angedacht mehrere Blogs über eine Plattform betreiben zu können) und dann erst Benutzernamen und Passwort übertragen. Dann gibt es auch noch Funktionalitäten, die man eigentlich erwartet, die aber gar nicht Verfügbar sind.

Es gibt keine Funktion in der Schnittstelle um die Posts einer Kategorie abzurufen. Um diese Tücken zu umgehen kann man sich auf einen recht einfachen Wege eine Erweiterung der Schnittstelle entwickeln. Ich habe mich entschlossen dieses über ein Plugin zu tun. Das brachte dann auch schnell den Vorteil mit, dass ich Objektorientiert an die Sache herangehen konnte.

Man beginnt also damit, dass man sich ein Plugin anlegt. Das Grundgerüst dafür sieht einfach aus. Eine PHP-Datei. Diese Datei benötigt einen Kommentierten Kopf, damit WordPress sie als Plugin erkennt.

/*
Plugin Name: Zorta XML-RPC
Plugin URI: http://www.zorta.de
Description: The Plugin adds some functions to the WordPress XML-RPC Library
Author: Denis Zunke
Version: 1.0
Author URI: http://www.zorta.de/
*/

include_once(ABSPATH . WPINC . '/class-IXR.php');
include_once(ABSPATH . WPINC . '/class-wp-xmlrpc-server.php');

class Zorta_XMLRPC extends wp_xmlrpc_server {

    public static function zorta_getName()
    {
        return __CLASS__;
    }

}
add_filter('wp_xmlrpc_server_class', array('Zorta_XMLRPC', 'zorta_getName'));

Mit dieser einfachen Datei hat man ein lauffähiges Plugin ohne Funktionalität. Ich habe es nicht ausprobiert, aber würde in diesem Falle davon ausgehen, dass man die XML-RPC-Schnittstelle von WordPress noch nicht überschrieben hat. Sie dürfte also weiter zur Verfügung stehen. Der nächste Schritt war für mich, dass ich eine Art “Hallo Welt”-Funktion einbaue um zu sehen, ob meine Schnittstelle ansprechbar ist. Diese Funktion musste ich aber nun auch offiziell ansprechbar machen, weshalb ich mich entschloss den Konstructor des eigentlichen XML-RPC-Servers zu überschreiben.

public function __construct()
{
    parent::__construct();
    $methods = array(
       'zorta.helloworld'        => 'this:zorta_HelloWorld'
    );
    $this->methods = array_merge($this->methods, $methods);
}

public function zorta_HelloWorld()
{
    return 'Hallo Welt!';
}

Diese Funktion aufgerufen war zu erkennen, dass ich alles richtig gemacht habe und mein “Hallo Welt” als Response-Wert bekam. Jetzt konnte ich versuchen über eine weitere Funktion auf die Methodiken von WordPress zuzugreifen um letztendlich meine Kategorien abrufen zu können. Im Handbuch von WordPress nachgeschlagen fand ich auch eine Funktion um das zu tun. Um die Funktion der Schnittstelle bekannt zu machen musste sie zuerst einmal geschrieben werden.

public function zorta_PostsByCategory($args)
{
    return get_posts(array('category' => $args[0]));
}

Die Variable $args bezeichnet in diesem Moment die übergebenen Parameter. Dies liest WordPress selbstständig aus dem übergebenen XML aus, da wir die grundlegenden Funktionalitäten des XML-RPC-Servers nicht überschrieben haben. Diese Methodik musste nun aber auch im Konstruktor noch hinzugefügt werden.

$methods = array(
     'zorta.helloworld'             => 'this:zorta_HelloWorld',
     'zorta.postsbycategory'    => 'this:zorta_PostsByCategory'
);

Jetzt war es mir möglich von außen meine Posts aus einer beliebigen Kategorie abzurufen. Da dies aber zu unsicher ist brauchte ich auch noch einen Login. Es sollte schließlich nicht jeder auf die Schnittstelle zugreifen können. Auch dafür liefert der WordPress XML-RPC-Server eine Funktionalität, die ich in meiner Klasse verwenden konnte.

if ($this->_zorta_login($args)) {
    if (isset($args[2])) {
        return get_posts(array('category' => $args[2]));
    } else {
        return 'There must be a category (2)';
    }
} else {
   return $this->error;
}

Wie schnell auffällt übergebe ich die kompletten Parameter an eine Funktion, die nicht definiert ist. Eine eigene Login-Funktion. Dies hängt damit zusammen, dass ich eine zentrale Stelle für den Login in meiner Klasse haben wollte. Sie gibt auch vor, dass das erste Argument der Benutzername und das zweite Argument das Passwort sind. Auf diese Weise muss ich dies nicht in jeder neuen Funktion definieren, da ich nur einmal die kompletten Parameter übergebe. Diese Login Funktion ist recht simpel.

private function _zorta_login($args)
{
    $username = $args[0];
    $password = $args[1];

    if ($this->login($username, $password)) {
        return true;
    } else {
        return false;
    }
}

Nun sind alle Funktionen beisamen für eine minimale Erweiterung des XML-RPC-Servers. Alles zusammen gefasst ergibt eine einfache Basis zur Erweiterung der Schnittstelle, die WordPress einem bietet. Es gibt viele Gründe warum man das WordPress-Backend für seine eigene Arbeit nutzen kann, schließlich muss man nicht immer alles neu erfinden.

Nun aber auch noch einmal die gesamte Klasse zum Download: zorta-wp-xmlrpc.zip

Ich hatte kein Plugin, dass Datenbankupdates benötigt, aber dennoch funktionierte es nicht. Ich scheiterte schon daran Redmine neuzustarten. Warum? Dafür wurde keine Beschreibung angegeben. Nachdem ich den Hinweis gefunden hatte und Redmine erfolgreich neustarten konnte war mein Plugin aber immer noch nicht in der Liste der Plugins. Nach etwas suchen habe ich dann die Lösung zusammengefunden. Seltsamerweise musste ich dazu die Anleitung eines gänzlich anderen Plugins bemühen, das dann endlich die ersehnte Erklärung hatte.

Diese Erklärung ist eigentlich recht simpel.

Schritt 1:
Man läd das Plugin in das Verzeichnis /vendor/plugins. Dort muss das gesamte Verzeichnis des Plugins hinterlegen.

Schritt 2:
Man muss die Plugins laden. Dazu verwendet man den Befehl
RAILS_ENV=production rake db:migrate_plugins

Schritt 3:
Redmine muss neugestartet werden. Dazu hinterlegt man im Verzeichnis /tmp eine leere Datei restart.txt. Man läd die Startseite von Redmine neu und der Neustart läuft im Hintergrund.

Nun sollte das Plugin in der Administration unter Plugins auftauchen. Viel Erfolg!

Die Konfiguration basiert auf einer Zend_Acl und wird mit einer Ini Datei über Zend_Config_Ini befüllt. Das ganze funktioniert als Resource mit dem Bootstrapping. Vielleicht ist es für den ein oder anderen eine Anregung.

Erst einmal die Konfiguration. Wie man sieht ist es eine normale Ini-Datei mit Vererbung. Ganz nach dem Kommentar gilt dabei das Muster {|*}.{|*} = {allow|deny}

[guest]
index.* = allow
error.* = allow

[admin : user]
*.* = allow

Diese Konfiguration kann in der Application Ini gesetzt werden. Die Resource unterstützt drei Einstellungen.

resources.acl.active = true
resources.acl.config = APPLICATION_PATH "/configs/acl.ini"
resources.acl.base = deny

Die Einstellungen sind einfach erklärt. Es gibt zuerst einmal eine Einstellung um die Resource zu aktivieren oder zu deaktivieren. Ich finde eine autarke Einstellung abseits der application.ini wertvoll und nutze sie daher gerne. Dann muss natürlich der Pfad zur Konfiguration gesetzt werden und zuletzt was die ACL als Basis macht. Hier ist als Einstellung allow oder deny vorgesehen. Das bedeutet, dass entweder als Basis alle Resourcen verboten werden oder alle erlaubt.

Wie man sehen wird habe ich die Acl überschrieben mit einer Erweiterung der Funktion isAllowed(). Dies nutzt dem Zweck automatisch Rollen und Resourcen zur Acl hinzuzufügen, die noch nicht konfiguriert sind. Diese werden im Standard verboten, da es sich ja eigentlich immer um nicht vorhandene Resourcen oder Rollen handelt.

class Suka_Acl extends Zend_Acl {

	/**
	 * (non-PHPdoc)
	 * @see Zend_Acl::isAllowed()
	 */
	public function isAllowed($role = null, $resource = null, $privilege = null)
	{

		// Wenn die Rolle nicht existiert, dann muss sie angelegt werden
		if (!empty($role) && !$this->hasRole($role)) {
			$roleObj = new Zend_Acl_Role($role);
			$this->addRole($roleObj);
			$this->deny($role);
		}

		// Wenn eine Resource nicht existiert, dann muss sie angelegt werden
		if (!empty($resource) && !$this->has($resource)) {
			$resObj = new Zend_Acl_Resource($resource);
			$this->add($resObj);
			$this->deny($role, $resource);
		}

		// Gehe nun an die Parent-Funktionalität für die normale Funktionalität
		return parent::isAllowed($role, $resource, $privilege);
	}
}

Zuletzt sollte ich euch natürlich noch die Resource geben. Diese ist etwas umfangreicher und umfasst knapp 200 Zeilen. Her wird die gesamte Konfiguration verarbeitet und setzt in die Registry die Acl ein mit dem Key “Suka_Acl”, so dass die Acl in der gesamten Konfiguration aufzurufen ist. Ich persönlich habe das für ein Plugin zur Authorisation genutzt. Hier wird die Zugriffsberechtigung gleich geprüft.

class Suka_Application_Resource_Acl extends Zend_Application_Resource_ResourceAbstract {

	/**
	 * Die ACL KOnfiguration
	 *
	 * @var array
	 */
	protected $_config;

	/**
	 * Die definierte ACL
	 *
	 * @var Suka_Acl
	 */
	protected $_acl;

	/**
	 * Der Basisstatus der ACL
	 * true 	= alles erlaubt
	 * false 	= alles verboten
	 *
	 * @var boolean
	 */
	protected $_baseState = false;

	/**
	 * Zentrale Verwaltung der ACL Resource
	 *
	 * @return void
	 */
	public function init()
	{
		// Prüft die Existenz
		if (!isset($this->_options['active'])) {
			$this->_options['active'] = false;
		}

		// Prüft, ob die ACL greifen soll
		if (is_bool($this->_options['active']) && $this->_options['active'] === false) {
			return;
		}

		// Die Konfiguration der ACL einlesen, wenn sie existiert, ansonsten Abbruch
		if (isset($this->_options['config']) && is_file($this->_options['config'])) {
			$this->_config = new Zend_Config_Ini($this->_options['config']);
		} else {
			return;
		}	

		// Die Acl definieren
		$this->_acl = new Suka_Acl();

		// Standard der ACL setzen
		if (!isset($this->_options['base'])) {
			// Alles verbieten
			$this->_acl->deny();
			$this->_baseState = false;
		} else {
			if ($this->_options['base'] == 'allow') {
				// Alles erlauben
				$this->_acl->allow();
				$this->_baseState = true;
			} elseif ($this->_options['base'] == 'deny') {
				// Alles verbieten
				$this->_acl->deny();
				$this->_baseState = false;
			} else {
				// Alles verbieten
				$this->_acl->deny();
				$this->_baseState = false;
			}
		}

		// Rollen einlesen samt ihrer Resourcen
		$this->_createAclData();

		// Berechtigungen setzen
		$this->_setPermissions();

		// Zuletzt setze die ACL in die Registry
		Zend_Registry::set('Suka_Acl', $this->_acl);
	}

	/**
	 * Liest die Daten der ACL ein
	 *
	 * @var void
	 */
	protected function _createAclData()
	{
		// Wandel die Config in ein Array um
		$rolesArray = $this->_config->toArray();

		// Füge alle Variationen der ACL hinzu
		foreach ($rolesArray as $role => $ressources) {

			// Prüfe zuerst, ob die Rolle schon existiert
			if (!$this->_acl->hasRole($role)) {
				// Existiert nicht. Füge sie hinzu
				$roleObj = New Zend_Acl_Role($role);
				$this->_acl->addRole($roleObj);
			}

			// Prüfe, ob die Rolle Resourcen hat
			if (empty($ressources)) {
				continue;
			} 		

			// Lade die Ressourcen
			foreach ($ressources as $resource => $actions) {
				// Prüfe, ob die Ressource schon existiert
				if (!$this->_acl->has($resource)) {
					// Existiert nicht. Füge sie hinzu
					$resObj = new Zend_Acl_Resource($resource);
					$this->_acl->addResource($resObj);
				}
			}
		}
	}

	/**
	 * Setzt die Berechtigungen der ACL
	 *
	 * @return void
	 */
	protected function _setPermissions()
	{
		// Wandel die Config in ein Array um
		$rolesArray = $this->_config->toArray();

		// 

		// Gehe die Daten durch um die Berechtigungen zu setzen
		foreach ($rolesArray as $role => $ressources) {

			// Prüfe, ob es überhaupt Ressourcen gibt
			if (empty($ressources)) {
				continue;
			}

			// Wenn eine Wildcard erstellt wurde, dann gib alle Ressourcen frei
			if (isset($ressources['*'])) {
				$this->_setAllowedOrDenied($role);
				continue;
			}

			// Gehe die Resourcen der Rolle durch
			foreach ($ressources as $ressource => $actions) {

				// Gehe die Actions durch und nutze den status
				foreach ($actions as $action => $state) {
					// Prüfe, ob die Ressource auch Actions hat
					if ($action == '*') {
						// Hat keine Actions, alles freigeben
						$action = null;
					}

					// Prüfe, ob Erlaubt oder Verboten werden soll
					if ($state == 'allow') {
						$state = true;
					} else {
						$state = false;
					}

					// Setze die Berechtigung
					$this->_setAllowedOrDenied($role, $ressource, $action, $state);
				}
			}

		}
	}

	/**
	 * Setzt je nach Basisstatus eine Erlaubnis oder ein Verbot
	 *
	 * @param 	Zend_Acl_Role_Interface|string|array 		$roles
	 * @param 	Zend_Acl_Resource_Interface|string|array 	$resources
	 * @param 	string|array 								$privileges
	 * @return 	void
	 */
	protected function _setAllowedOrDenied($roles = null, $resources = null, $privileges = null, $allow = null)
	{
		// Setze das Allow und Deny zu einer Struktur
		if ($allow == false) {
			$this->_acl->deny($roles, $resources, $privileges);
		} else {
			$this->_acl->allow($roles, $resources, $privileges);
		}
	}
}