Hierbei wird die Anfrage (Request) statt über eine serverseitige Scriptsprache mittels JavaScript an den Server gestellt. Der Vorteil liegt darin begründet, dass JavaScript auf der Clientseite ausgeführt wird. Der Webbrowser muss die aktuelle Seite daher nicht Neu laden sondern kann die DOM-Elemente direkt manipulieren.

In diesem Artikel soll gezeigt werden, wie man ohne Plugin mit Hilfe von jQuery, jQuery.UI und einigen WordPress-Tricks eine AJAX Suche in WordPress realisiert.

Hintergrund

Bevor wir mit der Umsetzung beginnen, werfen wir einen Blick auf das Endergebnis. Ziel ist es, ein Suchformular wie in untenstehender Abbildung zu erstellen.

1. Mittels jQuery.ui.autocomplete wird dem Suchfeld eine Event zugeordnet, welcher ausgelöst wird sobald etwas in das Textfeld eingegeben wurde.
2. Wurde ein Event registriert, wird durch jQuery ein AJAX-Request an WordPress gestellt. Als Wert wird der eingegebene Text übermittelt.
3. WordPress prüft zunächst, ob die angegebene Aktion existiert.
4. Und führt anschliessend den an die Aktion registrierten Callback aus.
5. Der Callback selbst erledigt nun die eigentliche Arbeit. Anhand des mitgegebenen Wertes werden die Daten aus der Datenbank ausgelesen und zurück an den Client gesendet.
6. Als letzten Schritt erfolgt die Aufbereitung und Anzeige der Daten.

Schritt 1,2 und 6 werden hierbei auf Clientseite abgehandelt und müssen daher in JavaScript erfolgen. Schritt 3,4 und 5 sind serverseitige Aufgaben und werden in unserem Fall mittels PHP durchgeführt.

Schritt 1: HTML Gerüst

In diesem Tutorial wird das Standard Suchformular von WordPress ersetzt. Falls du dies nicht willst, kannst du das Ganze auch in ein eigenes Page-Template speichern und einer Seite deiner Wahl zuweisen. Wie das geht, erfährst du hier.

Öffne nun die Datei searchform.php innerhalb deines Themeverzeichnisses. Sollte die Datei nicht existieren, erstelle Sie. Passe den Inhalt nachfolgendem Beispiel an:

<?php
/**
 * Template for displaying the search form
 */
?>
<form id="searchForm" action="<?php echo home_url(); ?>" method="get">
    <input id="searchKeyword" title="<?php __('Search'); ?>" type="text" name="s" value="" />
    <button id="searchSubmit" type="submit"><?php _e('Search'); ?></button>
</form>

Wichtig hierbei ist, dass die Datei im Root-Verzeichnis deines Themes liegt und der Name der Datei searchform.php trägt. Somit gehen wir sicher, dass WordPress die Datei korrekt lädt und über die internen Funktionen wie bspw. get_search_form() aufgerufen werden kann.

Ebenfalls zu beachten ist die ID des Textfeldes. Diese muss mit der ID in der späteren JavaScript-Datei übereinstimmen.

Schritt 2: CSS Styling

Da jedes Theme unterschiedlich daher kommt, verzichte ich an dieser Stelle auf ein Stylesheet. Einzig die HTMl-Liste, in welche später die Vorschläge aus der Datenbank anzeigen werden, muss Design technisch etwas angepasst werden. Da diese durch jQuery.ui.autocomplete generiert wird, sind die CSS-Klassen bereits vorgegeben. Eine genaue Auflistung findest du auf der jQuery.ui.autocomplete API Seite.

Binde nun nachfolgendes CSS-Snippet in das CSS-Stylesheet deines Themes ein (bspw. in style.css).

.ui-autocomplete {
    width: 10em;
    padding: 10px;
    background: #f4f4f4;
    border: 1px solid #ccc;
}

.ui-autocomplete li {
    background: none;
    padding-left: 0;
    border-bottom: 1px solid #ccc;
}

Schritt 3: Serverseitige Logik (PHP/WordPress)

Obwohl abweichend vom eigentlichen AJAX-Ablauf, fangen wir nun als Erstes mit der serverseitigen Logik an. Hierbei werden wir nun eine Klassen namens Webeo_Searchform erstellen.

Dabei ist es dir freigestellt, ob du die Klasse als Plugin oder innerhalb des Themes einbindest. Zur vereinfachten Darstellung verwende ich hier die übliche functions.php innerhalb des Themeverzeichnisses.

// functions.php

/**
 * Webeo_Searchform class
 *
 * @package     Webeo
 * @author      Roman Wünsche
 * @copyright   2011 Webeo GmbH. All rights reserved.
 */
class Webeo_Searchform {

    /**
     * Constructor
     *
     * @return void
     */
    public function __construct() {
        // Attach init method to init action hook
        add_action('init', array($this, 'init'));
    }

    /**
     * Init - Fires on init action hook
     *
     * @return void
     */
	public function init() {
	    // Attach AJAX method to privileged and non-privileged action hook
	    add_action('wp_ajax_nopriv_webeo_searchform', array($this, 'getAjaxData'));
	    add_action('wp_ajax_webeo_searchform', array($this, 'getAjaxData'));

	    // Register and enqueue JS
	    $this->enqueueScripts();

	    // Print additional JS var to sourcecode
	    $this->printAjaxConfig();
	}

	/**
	 * Deregister/Register and enqueue custom JavaScripts
	 *
	 * @return void
	 */
	public function enqueueScripts() {
	    // Deregister builtin jQuery
	    wp_deregister_script('jquery');

	    // Register custom searchform JS and some jQuery libraries from the Google CDN
	    wp_register_script('jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js', array(), '1.6.2', false);
	    wp_register_script('jqueryui', 'https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.15/jquery-ui.min.js', array('jquery'), '1.8.15', false);
	    wp_register_script('webeo.searchform', get_stylesheet_directory_uri() . '/js/webeo.searchform.js', array('jquery', 'jqueryui'), '1.0', false);

	    // Enqueue custom searchform JS
	    wp_enqueue_script('webeo.searchform');
	}

	/**
	 * Print additional JavaScript vars to sourcecode, which we can use
	 * on the client side JavaScript file.
	 *
	 * @return void
	 */
	public function printAjaxConfig() {
	    // Check for SSL
	    $protocol = (is_ssl()) ? 'https://' : 'http://';

	    // Generate data for the client side JavaScript file
	    $params = array(
	        'ajaxurl' => admin_url('admin-ajax.php', $protocol),
	        'ajaximg' => get_stylesheet_directory_uri() . '/images/ajaxloader.gif',
	        'ajaxaction' => 'webeo_searchform',
	        'ajaxnonce' => wp_create_nonce('webeo_searchform_nonce')
	    );

	    // Print data to sourcecode
	    wp_localize_script('webeo.searchform', 'webeo_searchform', $params);
	}

	/**
	 * AJAX processing
	 *
	 * @return string
	 */
	public function getAjaxData() {
	    // Check nonce
	    check_ajax_referer('webeo_searchform_nonce');

	    if(isset($_REQUEST['action'])) {
	        // Filter $_REQUEST vars
	        $value = esc_attr($_REQUEST['value']);

	        // Retreieve data from database
	        global $wpdb;
	        $posts = $wpdb->get_results($wpdb->prepare("SELECT `ID`, `post_title` FROM $wpdb->posts WHERE `post_status` = 'publish' AND `post_title` REGEXP %s LIMIT 10", $value));

	        if(!empty($posts)) {
	            // Add the permalink to the postdata
	            foreach($posts as $post) {
	                $post->post_permalink = get_permalink($post->ID);
	            }

	            // Save post array in response var
	            $response = $posts;
	        } else {
	            // Save error message in response var, if no post was found
	            $response = __('No items found.', 'webeo-searchform');
	        }

	        // Encode the response var and print the result
	        echo json_encode($response);
	    }

	    // Close AJAX request
	    die();
	}
}

// Initialize Webeo_Searchform
new Webeo_Searchform();

Schauen wir uns den Code etwas genauer an:

Definieren der AJAX-Callback Action-Hooks

public function init() {
    // Attach AJAX method to privileged and non-privileged action hook
    add_action('wp_ajax_nopriv_webeo_searchform', array($this, 'getAjaxData'));
    add_action('wp_ajax_webeo_searchform', array($this, 'getAjaxData'));

    // Register and enqueue JS
    $this->enqueueScripts();

    // Print additional JS var to sourcecode
    $this->printAjaxConfig();
}

Innerhalb der init-Methode fügen wir zwei neue WordPress-Actions hinzu, registrieren unsere noch nicht existierende JavaScript-Datei und geben zusätzlich einige Parameter für das spätere Script aus.

add_action('wp_ajax_nopriv_webeo_searchform', array($this, 'getAjaxData'));
add_action('wp_ajax_webeo_searchform', array($this, 'getAjaxData'));

Die Namen der Action-Hooks sind keineswegs frei gewählt, zumindest nicht gänzlich. Über wp_ajax_ teilen wir WordPress mit, dass es sich hierbei um eine AJAX-Action handelt. Damit der Action-Hook auch ausgeführt wird wenn der Besucher über keine Rechte verfügt, definieren wir zusätzlich noch die Action beginnend mit wp_ajax_nopriv_.

Alles was danach folgt, kannst du frei wählen. Den Bezeichner musst du dir jedoch merken, da wir ihn später noch für den AJAX-Request benötigen.

Registrieren und Einbinden der JavaScript-Dateien

public function enqueueScripts() {
    // Deregister builtin jQuery
    wp_deregister_script('jquery');

    // Register custom searchform JS and some jQuery libraries from the Google CDN
    wp_register_script('jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js', array(), '1.6.2', false);
    wp_register_script('jqueryui', 'https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.15/jquery-ui.min.js', array('jquery'), '1.8.15', false);
    wp_register_script('webeo.searchform', get_stylesheet_directory_uri() . '/js/webeo.searchform.js', array('jquery', 'jqueryui'), '1.0', false);

    // Enqueue custom searchform JS
    wp_enqueue_script('webeo.searchform');
}

Als nächsten Schritt registrieren und laden wir nun die benötigten JavaScript-Dateien. WordPress kommt bereits mit einer jQuery und jQuery-Core Version daher. Da diese von WordPress Version zu WordPress Version unterschiedlich sind, verwenden wir fürs Tutorial die zum Zeitpunkt dieses Artikels aktuellsten Versionen der beiden Bibliotheken direkt von der Google Cloud.

wp_register_script('webeo.searchform', get_stylesheet_directory_uri() . '/js/webeo.searchform.js', array('jquery', 'jqueryui'), '1.0', false);

Als letztes Script registrieren wir unter dem Bezeichner webeo.searchform unsere eigene JavaScript-Datei, in welchem wir später unser AJAX-Request erstellen. Hierbei ist es wichtig, dass du die Abhängigkeiten als dritten Parameter mitgibst. In unserem Fall wird unser eigenes Script später jQuery und jQuery.UI benötigen. Daher geben wir als dritten Parameter folgendes Array mit: array('jquery', 'jqueryui').

// Enqueue custom searchform JS
wp_enqueue_script('webeo.searchform');

Nun können wir das Script mittels wp_enqueue_script() einbinden. Wurde alles korrekt durchgeführt, wird WordPress die Abhängigkeiten nun von alleine auflösen und jQuery sowie jQuery.UI ebenfalls einbinden.

Zusätzliche Parameter für die JavaScript-Datei

public function printAjaxConfig() {
    // Check for SSL
    $protocol = (is_ssl()) ? 'https://' : 'http://';

    // Generate data for the client side JavaScript file
    $params = array(
        'ajaxurl' => admin_url('admin-ajax.php', $protocol),
        'ajaximg' => get_stylesheet_directory_uri() . '/images/ajaxloader.gif',
        'ajaxaction' => 'webeo_searchform',
        'ajaxnonce' => wp_create_nonce('webeo_searchform_nonce')
    );

    // Print data to sourcecode
    wp_localize_script('webeo.searchform', 'webeo_searchform', $params);
}

Was nun folgt, wird in vielen Tutorials oftmals von Hand in der späteren JavaScript-Datei niedergeschrieben. Die Rede ist von den Parametern, welche während des AJAX-Requests benötigt werden. Da jedoch nicht jede WordPress Version gleich ist, sollte dies generell über PHP abgehandelt werden. Die Parameter werden nun serverseitig erstellt und über die Funktion wp_localize_script() in den Sourcecode ausgegeben. Somit kann später in der JavaScript-Datei darauf zugegriffen werden.

• ajaxurl: Gibt den URL zum Serverscript an, welches den AJAX-Request entgegen nimmt und verarbeitet.
• ajaxaction: Gibt den registrierten AJAX-Action-Hook an. Hier muss nun der oben gewählte Bezeichner angefügt werden.
• ajaximg: Gibt den URL zu einem Loading-Bild aus, welches später als Platzhalter angezeigt werden kann.
• ajaxnone: Generiert einen Nonce-Token, um die Sicherheit zu erhöhen.

wp_localize_script('webeo.searchform', 'webeo_searchform', $params);</pre>

Der eigentliche AJAX-Callback: getAjaxData

public function getAjaxData() {
    // Check nonce
    check_ajax_referer('webeo_searchform_nonce');

    if(isset($_REQUEST['action'])) {
        // Filter $_REQUEST vars
        $value = esc_attr($_REQUEST['value']);

        // Retreieve data from database
        global $wpdb;
        $posts = $wpdb->get_results($wpdb->prepare("SELECT `ID`, `post_title` FROM $wpdb->posts WHERE `post_status` = 'publish' AND `post_title` REGEXP %s LIMIT 10", $value));

        if(!empty($posts)) {
            // Add the permalink to the postdata
            foreach($posts as $post) {
                $post->post_permalink = get_permalink($post->ID);
            }

            // Save post array in response var
            $response = $posts;
        } else {
            // Save error message in response var, if no post was found
            $response = __('No items found.', 'webeo-searchform');
        }

        // Encode the response var and print the result
        echo json_encode($response);
    }

    // Close AJAX request
    die();
}

Bisher haben wir lediglich über das korrekte Laden und einbinden der JavaScript Dateien gesprochen. Nun folgt die Definition der Methode, welche wir bei den beiden wp_ajax_ Actions als Callback angegebenen haben. Diese soll den AJAX-Request verarbeiten.

check_ajax_referer('webeo_searchform_nonce');

Zu aller erst prüfen wir, ob der übermittelte Nonce-Token identisch ist. Für eine besser Sicherheit, könnte man den Token selbst immer neu generieren lassen. Dies ist jedoch nicht Teil des Tutorials.

global $wpdb;
$posts = $wpdb->get_results($wpdb->prepare("SELECT `ID`, `post_title` FROM $wpdb->posts WHERE `post_status` = 'publish' AND `post_title` REGEXP %s LIMIT 10", $value));

Wurde im $_REQUEST Array eine action angegeben, filtern wir die übergebenen Daten und senden ein SQL-Query an die Datenbank. Hierbei verwenden wir die globale Varibale $wpdb, welche bereits eine Instanz der Klasse WP_Query enthält. Üblicherweise sollten Benutzereingaben nie blindlinks vertraut werden, weshalb wird das Query mittels der Methode prepare zuerst vorbereiten. Hierbei verhält sich die Methode ähnlich der eingebauten PHP-Funktion sprinft(). Mittels  %d (Decimal) oder %s (String) wird im Query ein Platzhalter definiert, welcher später mit dem angefügten Parameter ersetzt wird.

Tipp:
Da das Prefix der Datenbank-Tabellen bei der Installation durch den Benutzer frei gewählt werden kann, sollte auf die direkte Angabe (bspw. FROM wp_posts) verzichtet werden. Stattdessen kann das WP_Query Objekt verwendet werden, welches das Prefix korrekt ausgibt. Obiger Aufruf wird daher durch FROM $wpdb->posts ersetzt.

Wurde das Query mittels $wpdb->get_results() ausgeführt und enthält Daten, wird zusätzlich noch der Permalink anhand der ID generiert und an das Array angehängt. Sollten keine Posts vorhanden sein, so wird eine entsprechende Fehlermeldung zurückgegeben.

echo json_encode($response);

Als letzten Schritt muss die Antwort noch encoded und ausgegeben werden. Vergewissere dich, dass du am Ende den AJAX-Request mittels einem die() beendest.

Schritt 4: Clientseitige Logik (JavaScript)

/**
 * Webeo Searchform JavaScript
 *
 * @package     Webeo
 * @author      Roman Wünsche
 * @copyright   2011 Webeo GmbH. All rights reserved.
 */

(function($) {
	$(document).ready(function() {
		webeoAjaxSearch();
	});

	/**
	 * AJAX Search
	 */
	function webeoAjaxSearch() {
		var formConfig = webeo_searchform;
		var $searchField = $('#searchKeyword');

		$searchField.autocomplete({
			source: function(request, response) {
				$.ajax({
					url: formConfig.ajaxurl,
					type: 'post',
					data: {
						action: formConfig.ajaxaction,
						value: $searchField.val(),
						_ajax_nonce: formConfig.ajaxnonce
					},
					timeout: 1500,
					beforeSend: function() {
						$('#ajaxmessage').hide();
						$searchField.after('<img id="ajaxloading" src="' + formConfig.ajaximg + '" alt="" />');
					},
					success: function(data) {
						$('#ajaxloading').hide();

						data = $.parseJSON(data);

						if(data instanceof Array) {
							response($.map(data, function(item) {
								return {
									label: item.post_title,
									id: item.ID,
									permalink: item.post_permalink
								}
							}));
						} else {
							$searchField.after('<span id="ajaxmessage">' + data + '</span>');
						}
					},
					error: function() {
						$('#ajaxloading').hide();
						$searchField.after('<span id="ajaxmessage">Request timed out. Please try again.</span>');
					}
				});
			},
			select: function(event, ui) {
				$(location).attr('href', ui.item.permalink);
			},
			minLength: 1
		});
	}
})(jQuery);

Kommen wir nun zum clientseitigen JavaScript, der letzten Komponente für die AJAX Suche.

(function($) {
	$(document).ready(function() {
		webeoAjaxSearch();
	});
})(jQuery);

Da unter WordPress jQuery standardmässig im noConflict-Modus läuft, erstellen wir uns als aller Erstes einen noConflict-Wrapper. Somit können wir trotz noConflict-Modus weiterhin das Dollarzeichen $ anstelle des sonst üblichen jQuery Bezeichners verwenden. Das Prinzip wird von Rob Cherny auf seinem Blog näher beschrieben.

Danach folgt die übliche $(document).ready() Anweisung, welche die Funktion webeoAjaxSearch() aufruft.

Laden der zusätzlichen Parameter aus dem Serverscript

Hat das Laden der JavaScript-Dateien geklappt, müsste im Sourcecode nachfolgender CDATA-Block ersichtlich sein:

<script type='text/javascript'>
/* <![CDATA[ */
var webeo_searchform = {"ajaxurl":"http:\/\/example.com\/wp-admin\/admin-ajax.php","ajaximg":"http:\/\/example.com\/wp-content\/themes\/webeo\/images\/ajaxloader.gif","ajaxaction":"webeo_searchform","ajaxnonce":"8a8ae165d6"};
/* ]]> */
</script>

In der Funktion webeoAjaxSearch() definieren wir zuerst einige Variablen.

var formConfig = webeo_searchform;
var $searchField = $('#searchKeyword');

Entscheidend hierbei ist die Variable formConfig. Diese erhält ihre Daten nun vom obigen CDATA-Block bzw. der Variable webeo_searchform welche durch den Aufruf von wp_localize_script() generiert wurde. Daneben setzen wir noch eine Variable für das Suchfeld. Da es sich hierbei um ein jQuery-Element handelt, wird absichtlich ein Dollarzeichen davor gesetzt.

$searchField.autocomplete({
    source: function(request, response) {
        // ...
    }
    select: function(event, ui) {
        // ...
    }
    minLength: 1
});

Als nächstes wird dem Suchfeld der autocomplete Event von jQuery.UI angefügt, womit die eigentliche Autovervollständigung auf diesem Feld aktiv wird. Nachfolgend eine kurze Auflistung der verwendeten Optionen. Eine abschliessende Liste kannst du der jQuery.ui.autocomplete API Seite entnehmen.

• source: Gibt an, woher die Daten für die Autovervollständigung kommen sollen. In unserem Fall wird hier der eigentliche AJAX-Request gestellt.
• select: Gibt an, was passieren soll wenn ein Item aus der Liste ausgewählt wurde. Mittels $(location).attr('href', url) wird automatisch auf den erhaltenen Permalink weitergeleitet.
• minLength: Gibt an, ab wievielen Zeichen der Event ausgelöst werden soll.

Der eigentliche AJAX-Request

$.ajax({
	url: formConfig.ajaxurl,
	type: 'post',
	data: {
		action: formConfig.ajaxaction,
		value: $searchField.val(),
		_ajax_nonce: formConfig.ajaxnonce
	},
	timeout: 1500,
	beforeSend: function() {
		$('#ajaxmessage').hide();
		$searchField.after('<img id="ajaxloading" src="' + formConfig.ajaximg + '" alt="" />');
	},
	success: function(data) {
		$('#ajaxloading').hide();
		data = $.parseJSON(data);

		if(data instanceof Array) {
			response($.map(data, function(item) {
				return {
					label: item.post_title,
					id: item.ID,
					permalink: item.post_permalink
				}
			}));
		} else {
			$searchField.after('<span id="ajaxmessage">' + data + '</span>');
		}
	},
	error: function() {
		$('#ajaxloading').hide();
		$searchField.after('<span id="ajaxmessage">Request timed out. Please try again.</span>');
	}
});

Über die jQuery Funktion ajax() wird der eigentliche AJAX-Request erzeugt. Auch hier wieder eine kurze Auflistung der verwendeten Optionen. Alle Weiteren findest auf der jQuery API Seite.

• url: Den URL zum Script, welches den Request verarbeitet. In unserem Fall der Pfad zur admin-ajax.php von WordPress innerhalb der formConfig Variable.
• type: Die Transport-Methode GET oder POST.
• data: Ein Array an Daten, welche an den Server geschickt werden soll. Hierbei muss die action zwingend mit dem Bezeichner innerhab des registrierten AJAX-Action-Hooks (wp_ajax_) übereinstimmen. Ebenfalls übergeben wir hier den eingegebenen Suchwert value sowie den generierten Nonce-Token _ajax_nonce.
• timeout: Das Timeout in Millisekunden, bevor der Request abbricht.
• beforeSend: Dieser Event wird ausgeführt, bevor der eigentliche AJAX-Request gestartet wird. Ideal um das Loading-Bild anzeigen zu lassen.
• success: Wurde der AJAX-Request erfolgreich abgeschlossen, wird dieser Event ausgelöst. Die Daten müssen als aller erstes dekodiert und anschliessend an das response Objekt von jQuery.ui.autocomplete zurückgegeben werden. Da wir im Normalfall ein Array als Antwort erhalten, erstellen wir mittels map() ein Array Objekt mit unseren eigenen Identifiern. Wurde als Antwort kein Array empfangen, so handelt es sich um eine Fehlermeldung und wird in einem Span-Tag ausgegeben.
• error: Ging während des AJAX-Requests etwas schief oder lief dieser in ein Timeout, wird der Error-Event ausgeführt. In unserem Fall wird eine Span-Tag mit dazugehöriger Fehlermeldung an das Suchfeld angefügt.

Debugging

Um JavaScript zu debuggen, lohnt es sich Firefox oder Safari mit der Firebug Extension zu installieren. Im Konsolen-Fenster siehst du dann direkt, ob ein Parse-Fehler vorliegt. Daneben hast du die Möglichkeit, über den Aufruf der Funktion console.log() eine Ausgaben direkt in der Konsole zu tätigen. Vorbei sind die Tage, wo du eine Ausgabe mittels alert() überprüfen musstest.

Download

Damit du schnell zum Ziel kommst, habe ich dir sämtliche Dateien als ZIP-Datei angefügt. Test es aus!

Nun bist du an der Reihe

Hat alles geklappt? Ist irgend etwas unklar? Melde dich über die Kommentarfunktion und lass uns Wissen was du von der Lösung hälst. Auch Verbesserungen oder Erweiterungen sind gerne gesehen.

Das System ist relativ komplex und erfordert einiges an Einarbeitungszeit. Leider gibt es von Seiten Varien, der Hersteller von Magento, nur eine kostenpflichtige Anleitung in Englisch. Für deutschsprachige Nutzer existieren einige mehr oder weniger gute Alternativen. Zu den guten gehört sicherlich das E-Book von Techdivision mit über 350-Seiten.

Meistens ist ein Kunde jedoch nicht bereit, ein dickes Handbuch zu wälzen und hierfür noch Geld auszugeben. Aus diesem Grund habe ich mich entschlossen unser Einstiegs-Benutzerhandbuch für Magento der Öffentlichkeit zur Verfügung zu stellen.

Jetzt herunterladen (11.5 MB)

Das Handbuch beschreibt auf knapp 50 Seiten die notwendigsten Schritte um Kategorien, Attribute und Artikel zu verwalten. Hinzu kommt die Erklärung des Bestellprozederes aus Kunden- und Betreiberssicht. Damit auch wirklich jeder zum Ziel kommt, wurde grossen Wert auf das visuelle Element gelegt. Mittels detallierten Screenshots wird versucht, die Administrationsoberfläche auch für wenig versierte Benutzer verständlich zu erläutern.

Das Handbuch kann frei weitergegeben werden, sofern ein entsprechender Vermerk angegeben wird. Ebenfalls würde es mich freuen wenn die Anleitung gemeinsam mit der Community wachsen würde.

Hierbei wird neben einem generellen Überblick auch Schritt für Schritt aufgezeigt werden, wie man den Dienst für seine eigenen Bedürfnisse nutzt und so bspw. das fehlende Feature für Custom Post Types hinzufügt.

Hintergrund

XML-RPC (Extensible Markup Language Remote Procedure Call) definiert hierbei, wie die Anfrage (Request) und die Antwort (Response) auszusehen hat. Da somit das Ergebnis immer das Gleiche ist, kann man ein System per XML-RPC von nahezu allen Programmiersprachen anzapfen, welche diesen Standard implementieren.

Das Request&Response-Verfahren (Transport) wird hierbei über das HTTP-Protokoll abgewickelt. Bei der Darstellung der Daten kommt, wer hätte es gedacht, XML zum Einsatz.

Funktionsweise

Die Idee dahinter ist simpel. Der Dienst oder genauer gesagt der XML-RPC-Server wird von WordPress initialisiert und nimmt nun an ihn gerichtete Anfragen entgegen.

Via XML-RPC-Client wird nun eine Anfrage (methodCall) an den Server gestartet. Dieser prüft, ob die übergebene Methode existiert, führt diese aus und sendet das Ergebnis (methodResponse) zurück.

WordPress Unterstützung

WordPress unterstützt XML-RPC bereits seit seinen Anfängen. Über die Jahre wurde das System jedoch immer wieder ausgebaut und aus Abwärtskompatibilität viel Redundanz in den Code eingeschleust. Die Dokumentation ist ebenfalls sehr minimal ausgefallen.

Die Prioritäten scheinen wohl definitiv wo anders zu liegen. Dies zeigt sich auch in der fehlenden Unterstützung von Custom Post Types oder den Taxonomies.

Schritt für Schritt

Schritt 1: Server Initalisierung xmlrpc.php

Über die Datei xmlrpc.php, welche sich im Root-Verzeichnis von WordPress befindet, wird der eigentliche Server initialisiert. Hierzu muss dieser zuerst über die Administrationsoberfläche aktiviert werden.

Setze hierzu die Checkbox bei der Option:
Settings > Writing > XML-RPC > Enable the WordPress, Movable Type, MetaWeblog and Blogger XML-RPC publishing protocols.

Schritt 2: Client Initialisierung, Testen der Verbindung

Um nun Anfragen an den Server zu stellen, fehlt noch der eigentliche Client. Glücklicherweise ist unter WordPress bereits eine Client-Komponente in der Server-Klasse enthalten, welche auch unabhängig von WordPress funktioniert. Alternativ wäre hier noch das PHPXMLRPC Projekt zu nennen, welches ebenfalls ein einfaches Interface zur Verfügung stellt.

1. Kopiere nun die Datei class-IXR.php aus dem Verzeichnis /wp-includes/ in ein eigenes, lokales Verzeichnis deines Webservers (bspw. /var/www/rpc/). Das Ganze könnte man auch direkt in der functions.php von WordPress testen, doch dann wäre der eigentliche Sinn dahinter verfehlt. Immerhin sollen später die Anfragen an WordPress auch von unterschiedlichen Quellen aus erfolgen können.
2. Im eben erzeugten Verzeichnis erstellst du nun eine index.php mit nachfolgendem Inhalt. Bitte passe den Pfad entsprechend deiner Installation an.

require_once 'class-IXR.php';
$rpc = new IXR_Client('http://hostname.tld/path/to/wordpress/xmlrpc.php');

$result = $rpc->query('demo.sayHello');

if(!$result) {
    echo 'Error [' . $rpc->getErrorCode() . ']: ' . $rpc->getErrorMessage();
    exit();
}

print_r($rpc->getResponse());

Nach Ausführen des obigen Scripts, müsste der XML-RPC Server nun eine kleine "Hello"-Willkommensmeldung ausgeben. Schauen wir uns das Script genauer an:

require_once 'class-IXR.php';
$rpc = new IXR_Client('http://hostname.tld/path/to/wordpress/xmlrpc.php');

Zuerst wird die XML-RPC Klasse eingebunden und ein neues Objekt erzeugt. Hier muss als Parameter der relative Pfad zur xmlrpc.php Datei im Root-Verzeichnis von WordPress angegeben werden.

$result = $rpc->query('demo.sayHello');

Als nächstes wird ein Query an den XML-RPC Server geschickt. Als ersten Parameter wird hier der Identifier demo.sayHello mitgegeben. Hierbei handelt es sich um eine registrierte Methode innerhalb des Servers.

if(!$result) {
    echo 'Error [' . $rpc->getErrorCode() . ']: ' . $rpc->getErrorMessage();
    exit();
}

print_r($rpc->getResponse());

Als Letztes erfolgt die Prüfung und Ausgabe der Antwort.

Schritt 3: Alle verfügbaren Methoden ausgeben

Um nun mit dem Dienst arbeiten zu können, müssen wir wissen welche Methoden existieren. Hierzu passen wir das Query wie folgt an:

$result = $rpc->query('system.listMethods');

Als Ausgabe präsentiert sich uns nun eine Liste aller registrierten Methoden.

Schritt 4: Authentifizierung

Bisher war es uns möglich, den Dienst ohne Authentifizierung anzusprechen. Da wir nun jedoch alle verfügbaren Seiten abrufen möchten, müssen wir uns vorher bei WordPress anmelden. Hierzu definieren wir uns nun einige Parameter, welche anschliessend ans Query übergeben werden.

$params = array(
    1,
    'admin',
    'P@ssW0rd',
    10
);

$result = $rpc->query(
    'wp.getPages',
    $params
);

Die Parameter sehen wie folgt aus:

• BlogID: Angabe der BlogID. Wird momentan Intern noch nirgends verwendet. Später soll hier vermutlich das Multisite-Feature unterstützt werden. Da ein Parameter erwartet wird, wird hier eine 1 mitgegeben.
• Benutzername: Angabe des Benutzernamens, welche die notwendigen Rechte mitbringen muss.
• Kennwort: Das zum Benutzer dazugehörige Kennwort.
• Limit: Die SQL-Limite für das spätere Query. Optional. Defaultwert: 10, Unbegrenzt: -1

Als Methode wird nun wp.getPages() aufgerufen, welche uns ein Array mit den letzten 10 Seiten ausgibt.

Methoden anpassen und erweitern

Kommen wir nun zum interessanten Teil, dem Anpassen und Erweitern der Server Methoden. WordPress verwaltet alle eigenen Methoden und die der unterstützen Webservices (Blogger, MetaWeblog, etc.) in der Klasse wp-xmlrpc-server, zu finden unter /wp-includes/class-wp-xmlrpc-server.php.

class wp_xmlrpc_server extends IXR_Server {
	function wp_xmlrpc_server() {
		$this->methods = array(
			'wp.getUsersBlogs'		=> 'this:wp_getUsersBlogs',
			'wp.getPage'			=> 'this:wp_getPage',
			'wp.getPages'			=> 'this:wp_getPages',
			// ...
			'demo.sayHello' => 'this:sayHello',
			'demo.addTwoNumbers' => 'this:addTwoNumbers'
		);

		$this->initialise_blog_option_info( );
		$this->methods = apply_filters('xmlrpc_methods', $this->methods);
	}

	function serve_request() {
		$this->IXR_Server($this->methods);
	}

	function wp_getPage($args) {
	    // do the magic
	}
}

Sehen wir uns obigen Auszug der Klasse genauer an, merken wir auch gleich dass es sich hierbei um eine abgeleitete Klasse von IXR_Server handelt. Mit anderen Worten: Der eigentliche XML-RPC Server Kram ist in seiner eigenen Klasse gekapselt. In der wp-xmlrpc-server Klasse sind lediglich die eigenen Methoden enthalten. Der Konstruktor setzt hierbei die Klassenvariable $this->methods, welche über die Methode serve_request an die Vaterklasse weitergegeben wird.

$this->methods = array(
    'wp.getPages' => 'this:wp_getPage',
)

Über das Array in der Klassenvariable $this->methods werden nun also die eigenen Methoden registriert. Findinge Programmierer könnten nun auf die Idee kommen, dieses Array direkt zu erweitern. Somit würden wir aber eine WordPress-Core Datei anpassen, welche beim nächsten Update wieder überschrieben würde.

Wer genau hinschaut, sieht im Konstruktor den Aufruf eines Filter-Hooks:

$this->methods = apply_filters('xmlrpc_methods', $this->methods);

Dieser ermöglicht es uns, eigene Methoden in das Array hinzuzufügen. Hierzu muss man bspw. in der functions.php einen eigenen Filter schreiben und diesen an WordPress übergeben.

// functions.php
function addWebeoXMLRPCMethods($methods) {
    $methods['webeo.getPost'] = 'webeo_getPost';
    $methods['webeo.getPosts'] = 'webeo_getPosts';
    return $methods;
}
add_filter('xmlrpc_methods', 'addWebeoXMLRPCMethods');

function webeo_getPost($args) {
    // do the magic
}

function webeo_getPosts($args) {
    // do the magic
}

Wer mich kennt weiss, dass ich all meinen Code in Klassen auslagere. Bei WordPress stosst man hier leider immer wieder auf Hindernisse. So auch bei der Übergabe der obigen Methoden. Denn im Array kann als Parameter lediglich ein Funktionsname mitgegeben werden.

Moment! In der wp-xmlrpc-server Klasse wurde doch auch auf eine Klassenmethode verwiesen? Richtig, lieber Leser, doch leider wird man mal wieder eines besseren belehrt wenn man die call Methode der IXR_Server Klasse näher betrachtet. Diese verarbeitet später das Array und führt die darin enthaltenen Methoden aus. Wer genau hinsieht, merkt bald wie hier der String this:methodName verarbeitet wird. Via substr werden hierbei einfach die ersten 5 Zeichen des Strings (this:) entfernt und der Rest an die $this-Referenz der Klasse angefügt. Urghs. Nicht sonderlich hübsch.

Eigene Server-Klasse erstellen und ableiten

Nun denn, eine Möglichkeit besteht allerdings noch. Und zwar kann man sich eine eigene Klasse schreiben, welche von IXR_Server oder wp_xmlrpc_server ableitet. Glücklicherweise bietet WordPress hier einen anderen Filter-Hook namens wp_xmlrpc_server_class an. Zu finden in der xmlrpc.php Datei, welche zu Beginn des Artikels kurz erwähnt wurde.

Mit diesem Filter ersetzen wir nun die von WordPress verwendete wp_xmlrpc_server Klasse durch unsere eigene. Da somit auch die Methoden von WordPress nicht mehr funktionieren würden, ist es ratsam nicht von IXR_Server sondern von wp_xmlrpc_server abzuleiten. Ein Beispiel:

// Webeo_XMLRPC.php
class Webeo_XMLRPC extends wp_xmlrpc_server {
    public function __construct() {
        parent::__construct();

        $methods = array(
            'webeo.getPost' => 'this:webeo_getPost',
            'webeo.getPosts' => 'this:webeo_getPosts'
        );

        $this->methods = array_merge($this->methods, $methods);
    }

    public static function webeo_getName() {
        return __CLASS__;
    }

    public function sayHello($args) {
        return 'Hello Commander!';
    }

    public function webeo_getPost($args) {
        // do the magic
    }

    public function webeo_getPosts($args) {
        // do the magic
    }
}

Obige Klasse erbt nun sämtliche Methoden von wp_xmlrpc_server und kann frei erweitert werden.

Nun müssen wir WordPress noch mitteilen, dass wir für alle XML-RPC Anfragen unsere eigene Klasse verwenden möchten. In der functions.php oder im eigenen Pluginloader wird daher folgender Filter registriert:

add_filter('wp_xmlrpc_server_class', array('Webeo_XMLRPC', 'webeo_getName'));

Damit der Filter eine Instanz der Klasse Webeo_XMLRPC erstellen kann, müssen wir hier den eigenen Klassennamen zurückgeben. Denn der Filter führt nicht wie sonst üblich die PHP interne call_user_func() Funktion aus, sondern erzeugt direkt über new $filterContent eine neue Instanz der Klasse. Ebenfalls unschön gelöst.

Wir behelfen uns hier mit der PHP internen Konstante __CLASS__ welche uns in der Methode webeo_getName den Namen der eigenen Klasse zurück gibt.

Führen wir nun als Test das erste Hello-Query nochmals aus...

$result = $rpc->query('demo.sayHello');

... erscheint nun anstelle von "Hello" eine "Hello Commander!". Das Überschreiben der sayHello Methode hat also ohne Probleme geklappt.

Nun können wir eigene Methoden schreiben, diese über das Array $methods im Konstruktor "registrieren" und via XML-RPC abfragen.

Jetzt bist du an der Reihe

Hat dir der Artikel weitergeholfen? Hast du selber einen besseren und elegateren Weg gefunden das Problem zu lösen? Für Feedback aller Art haben wir immer ein offenes Ohr. Nutzer hierzu unsere Kommentarfunktion.

Oftmals hat man jedoch das Problem, dass man zwar über den WordPress Codex den richtigen Filter- oder Action-Hook gefunden hat, dieser aber gewisse Parameter verlangt. Wenn diese nicht direkt in der Dokumentation angegeben sind, bleibt einem nichts anderes übrig als den PHP-Code zu durchkämmen.

Einfacher gehts mit nachfolgendem Shell-Befehl.

$ cd /path/to/wordpress/
$ find . -type f -exec grep -n "do_action('save_post" {} \; -print

Obiges Beispiel durchsucht im aktuellen Verzeichnis (.) alle Dateien (-type f) und filtert hierbei den Inhalt (-exec grep -n) nach dem Vorkommen von "do_action('save_post" und gibt die jeweilige Zeile auf der Konsole aus. Über die "-print" Anweisung wird hierbei noch zusätzlich der Pfad zur PHP-Datei ausgegeben.

Dies Ausgabe sieht dann wie folgt aus:

2389:    do_action('save_post', $post_ID, $post);
2481:    do_action('save_post', $post_id, $post);
./wp-includes/post.php

Die erste Spalte liefert die Zeilenummer im Dokument gefolgt vom Action-Hook. Nun sieht man die gesuchten Paramter, welchem dem Hook übergeben werden müssen.

Möchte man sich nun alle verfügbaren Action-Hooks anzeigen lassen, so gibt man folgendes ein:

$ cd /path/to/wordpress/
$ find . -type f -exec grep -n "do_action(" {} \; -print

Für alle Filter-Hooks entsprechend:

$ cd /path/to/wordpress/
$ find . -type f -exec grep -n "apply_filters(" {} \; -print

Natürlich waren wir in der Zwischenzeit nicht untätig. Neu in die Referenzliste hinzugekommen sind folgende Unternehmen:

• Tutti.ch, der Schweizer Inseratemarkt. Diverse Werbebanner wurden in verschiedenen Formanten nach Google- und iAB-Richtlinien umgesetzt.
• Absolvententag ZHAW. Ganz nach dem Motto "campus meets business", können Unternehmen nach geeigneten Fachkräften suchen oder Absolventen den Schritt in Richtung Business wagen. Um dem neuen Corporate Identity gerecht zu werden, wurde die Webseite einem Facelift unterzogen. Als CMS wird Typo3 eingesetzt. Die Umsetzung erfolgte hierbei durch die Firma luginbuehl.com.

Dies muss nicht schlecht sein. Im Gegenteil. Auch in einer Entwicklungsumgebung kann etwas mehr Sicherheit sicherlich nicht verkehrt sein. Dennoch gibt es einige Punkte, die die Usabillity etwas einschränken. Aus diesem Grund gibts hier nun immer wieder einige Quicktipps zu finden.

Da ich gewisse persönliche Seiten in meinem eigenen Benutzerverzeichnis unter "/Users/webeo/Sites/" lagere, ist es nur naheliegend diese direkt mit dem Apache zu verknüpfen. So können anschliessend alle Seiten über http://localhost/~webeo/ aufgerufen werden. Damit dies unter Zend Server CE möglich ist, müssen drei Schritte unternommen werden.

Schritt 1: Anpassen der httpd.conf

Als erstes navigiert man in das Konfigurations-Verzeichnis des Apaches. Unter Mac OS X ist dies:

/usr/local/zend/apache/conf

Anschliessend müsst ihr in der httpd.conf den Include-Befehl der User-Home Konfiguration wieder einbinden:

Apfel:~ webeo$ cd /usr/local/zend/apache2/conf
Apfel:conf webeo$ sudo vi httpd.conf
Password: ********

// httpd.conf
# User home directories
Include conf/extra/httpd-userdir.conf

Schritt 2: Anpassen der httpd-userdir.conf

Nachdem ihr die Datei gespeichert habt, erfolgt nun die Anpassung der User-Home Direktive in der httpd-userdir.conf. Diese ist im Unterverzeichnis "extra" zu finden:

Apfel:conf webeo$ sudo vi extra/httpd-userdir.conf

Passt diese anschliessend wie folgt an:

// extra/httpd-userdir.conf

#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites

#
# Control access to UserDir directories.  The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory "/Users/*/Sites">
    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

Schritt 3: Neustarten von Zend Server CE

Als letzten Schritt müsst ihr den Apache2 noch neustarten. Dies geschiet über den Aufruf des "zendctl.sh" Shell-Skripts im bin-Verzeichnis des Zend Servers CE.

Apfel:conf webeo$ sudo /usr/local/zend/bin/zendctl.sh restart-apache
/usr/local/zend/bin/apachectl stop [OK]
/usr/local/zend/bin/apachectl start [OK]

Nun seit ihr an der Reihe

Hat bei euch alles wie gewünscht funktioniert oder habt ihr sonstige Tipps und Tricks rund um den Zend Server CE? Lasst es uns wissen.

Hauptgrund war, dass wir nun vermehrt mit dem Zend Framework arbeiten. Generell hat der Webserver dank dem optimierten PHP Stack aber auch eine spürbar bessere Performance. Hinzu kommt, dass der Webserver bereits nahtlos mit dem Zend Studio arbeitet. So wird bspw. der Server automatisch gestartet wenn die IDE läuft.

Zend Server CE verwendet hierbei für die Administrations-Oberfläche den Port 10081. Das htdocs-Verzeichnis liegt bei Mac OS X unter

/usr/local/zend/apache2/htdocs

und ist über den Port 10088 erreichbar. Wer hier gerne normal "http://localhost" ohne den zusätzlichen Port aufruft, kann dies über die httpd.conf ändern. Ebenso können dort zusätzliche VirtualHosts eingerichtet werden, was insbesondere bei der Entwicklung mehrere ZF-Projekten das Leben erleichtert.

Beispiel

Ich arbeite mit drei Projekten, welche ich mit der Standard-Installation wie folgt aufrufen muss:

http://localhost:10088 (Htdocs-Index)
http://localhost:10088/webeo/public (Projekt Webeo)
http://localhost:10088/shift/public (Projekt Shift)
http://localhost:10088/shift/public (Projekt Berta)

Neu soll das Ganze wie folgt aufgerufen werden:

http://localhost (Htdocs Index)
http://webeo.local (Projekt Webeo)
http://shift.local (Projekt Shift)
http://berta.local (Projekt Berta)

Der schöne Nebeneffekt dabei, bei der Entwicklung von Anwendungen mit dem Zend Framework kann ich nun relativ vom Root-Verzeichnis ausgehen und muss nicht zwingend das Basis-Verzeichnis über den Front-Controller auslesen:

// Angabe der Basis-URL
foreach ($stylesheets as $stylesheet) {
$this->view->headLink()->appendStylesheet(Zend_Controller_Front::getInstance() ->getBaseUrl() . '/skins/' . $skin . '/css/' . $stylesheet);
}

// Relativ zum Root-Verzeichnis
foreach ($stylesheets as $stylesheet) {
$this->view->headLink()->appendStylesheet('/skins/' . $skin . '/css/' . $stylesheet);
}

Wobei man hier erwähnen muss, dass erstere Variante prinzipiell schönerer Programmierstil ist. Immerhin funktioniert das Projekt dann auch bei einer lokalen Installation ohne VirtualHosts.

Schritt 1: httpd.conf anpassen

Ich verwende hier das eingebaute Terminal von Mac OS X. Zu finden unter:

Programme -> Dienstprogramme -> Terminal.app

Die httpd.conf liegt im Verzeichnis "/usr/local/zend/apache2/conf". Da diese dem Webbenutzer gehört, muss der Befehl "sudo" vorangestellt werden um daran Änderungen als Superuser vornehmen zu können.

Apfel:~ rofflox$ cd /usr/local/zend/apache2/conf
Apfel:conf rofflox$ sudo vi httpd.conf
Password:

Anschliessend sucht man nach dem ersten Vorkommen von "Listen" und fügt einen zweiten Eintrag hinzu. Mittels "Listen" gibt man dem Apache-Webserver an, auf welchem Port er laufen soll. Bei Zend Server CE ist dies standardmässig der Port 10088. Da wir den Webserver ebenfalls unter http://localhost ansprechen wollen, fügen wir hier zusätzlich den HTTP-Standardport 80 mittels "Listen 80" hinzu.

Tipp:
Um im vi-Editor nach einem Wort zu suchen, kann im Terminal ein / gefolgt von dem Suchwort eingegeben werden. Um weitere Vorkommen zu finden, drückt man anschliessend lediglich die Taste "n" um weiter zu springen.

Vorher:

// httpd.conf
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 10088

Nachher:

// httpd.conf
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 10088
Listen 80

Die virtuellen Hosts werden bei Zend Server CE in einer separaten Konfigurations-Datei abgelegt. Diese gilt es nun noch zu aktivieren. Hierfür entfernt man das Kommentar-Zeichen in der httpd.conf.

Vorher:

// httpd.conf
# Virtual hosts
# Include conf/extra/httpd-vhosts.conf

Nachher:

// httpd.conf
# Virtual hosts
Include conf/extra/httpd-vhosts.conf

Schritt 2: httpd-vhosts.conf anpassen

Kommen wir nun zum eigentlich erfassen unserer virtuellen Hosts. Diese werden in der Datei "httpd-vhosts.conf" hinzugefügt. Zu finden unter:

/usr/local/zend/apache2/conf/extra/

Apfel:conf rofflox$ cd extra/
Apfel:extra rofflox$ sudo vi httpd-vhosts.conf

Die Datei enthält bereits einige vorkonfigurierte virtuelle Hosts. Diese kann man getrost löschen, da ansonsten beim Starten vom Apache unnötige Fehlermeldungen erscheinen. Am besten ersetzt ihr die Datei mit der von mir angehängten.

// httpd-vhosts.conf
#
# Virtual Hosts
#
# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.2/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.

<VirtualHost *:80>
    DocumentRoot "/usr/local/zend/apache2/htdocs"
</VirtualHost>

# webeo.local VirtualHost
<VirtualHost *:80>
    DocumentRoot "/usr/local/zend/apache2/htdocs/zf_webeo/public"
    ServerName webeo.local
    <Directory "/usr/local/zend/apache2/htdocs/zf_webeo/public">
        Options FollowSymLinks
        AllowOverride All
        Order deny,allow
        Allow from all
    </Directory>
</VirtualHost>

# shift.local VirtualHost
<VirtualHost *:80>
    DocumentRoot "/usr/local/zend/apache2/htdocs/zf_shift/public"
    ServerName shift.local
    <Directory "/usr/local/zend/apache2/htdocs/zf_shift/public">
        Options FollowSymLinks
        AllowOverride All
        Order deny,allow
        Allow from all
    </Directory>
</VirtualHost>

# berta.local VirtualHost
<VirtualHost *:80>
    DocumentRoot "/usr/local/zend/apache2/htdocs/zf_berta/public"
    ServerName berta.local
    <Directory "/usr/local/zend/apache2/htdocs/zf_berta/public">
        Options FollowSymLinks
        AllowOverride All
        Order deny,allow
        Allow from all
    </Directory>
</VirtualHost>

Wichtig hierbei: Der erste VirtualHost muss zwingend auf das eigentliche htdocs-Verzeichnis zeigen. Ansonsten erhält man beim Aufruf über http://localhost nicht die Standard-Indexseite von Zend Server CE angezeigt sondern die des ersten VirtualHosts den man definiert hat.

In den eigenen VirtualHosts müsst ihr anschliessend nur noch den DocumentRoot sowie die Directory-Direktive auf euer gewünschtes Verzeichnis setzen. Als ServerName gibt ihr zudem den Namen ein, über welchen ihr das Verzeichnis anschliessend im Browser ansprechen wollt.

Schritt 3: Hinzufügen der ServerNamen in der hosts Datei

Nun müssen wir die vorher definierten Servernamen noch der lokalen hosts-Datei bekannt machen. Zu finden unter:

/etc/hosts

Beim Aufruf eines Domainnamens im Browser, fragt der Computer normalerweise den DNS-Server eures Providers ab um den Domainnamen in eine IP-Adresse aufzulösen. Bevor dies jedoch geschieht, überprüft er ob in seiner lokale /etc/hosts Datei bereits ein Eintrag vorhanden ist. Dies machen wir uns nun zunutze und fügen dort unsere Servernamen ein:

Apfel:extra rofflox$ vi /etc/hosts

// hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
127.0.0.1       apfel
127.0.0.1       localhost.local
255.255.255.255 broadcasthost

# Apache VHosts
127.0.0.1       webeo.local
127.0.0.1       shift.local
127.0.0.1       berta.local

Schritt 4: Neustarten des Apache-Webservers

Als letzten Schritt müssen wir nur noch den Webserver neustarten. Gebt hierzu folgenden Befehl im Terminal ein:

Apfel:extra rofflox$ sudo /usr/local/zend/apache2/bin/apachectl restart
/usr/local/zend/apache2/bin/apachectl restart [OK]

Testen

Wenn ihr nun eine der oben definierten Namen in euren Browser eingebt, müsste dort eure Projektseite geladen werden. Falls nicht, läuft entweder ein anderer Webserver auf Port 80 (Insbesondere wenn ihr Websharing unter Mac OS X aktiviert habt) oder aber ihr habt in einer Datei irgend einen Tippfehler drin. Normalerweise sollte dann jedoch bereits beim Neustart des Apache-Webservers eine entsprechende Meldung ausgegeben werden.

Nun seid ihr dran

Hat bei euch alles auf Anhieb geklappt? Benutzt ihr ebenfalls eigene VirtualHosts für eure Projekte oder habt ihr gar eine andere, einfachere Variante?

Möglich macht dies ein eigenes entwickeltes Themeframework auf Basis von WordPress 3.0 und PHP5. Für den Besucher nicht zu sehen, die zahlreichen administrativen Möglichkeiten für den Seitenbetreiber.

Wir freuen uns auf Euer Feedback!

Seite besuchen

Fakt ist jedoch, dass Manuela Pfrunder den Auftrag zugesprochen bekam und nun bis Mitte 2010 Zeit hat, die anfänglichen Entwürfe näher auszuarbeiten. Man darf also gespannt sein. Mir persönlich gefiehl bereits der Roh-Entwurf, wenn mans denn so nennen kann. Generell bin ich über die meisten Vorschläge positiv überrascht.

Obwohl ich mit den bisherigen Banknoten von Jörg Zintzmeyer mehr als zufrieden bin, gibts einen Punkt der mir nie wirklich gefiel. Auf jeder Banknotenserie waren Portraits von mehr oder weniger bekannte Personen abgebildet. Die neuen Entwürfe gehen hier endlich einen Schritt weiter und zeigen (natur)wissenschaftliche "Wunder" und Phänomene (Embryo, DNA, Gehirnsynapsen usw.).

Leider fehlte mir als Informatiker auch hier ein Zeichen der vernetzten, modernen Welt, weshalb ich mir einen kleinen Exkurs ins Banknotendesign gegönnt habe.

Das Ganze soll die globale Vernetzung verdeutlichen, welche in der modernen Welt tagtäglich Einzug hält. Für die Einen mag es einen Fluch sein, für die Anderen ist es eine neue Art der Kommunikation und des Geschäftens. Auf jedenfall betrifft es heutzutage jede Person und ist in meinen Augen daher perfekt für ein Banknoten-Motiv geeignet. Hinzu kamen gewisse Sicherheitsrelevante Aspekte wie Wasserzeichen oder der RFID-Chip, welcher breits im biometrischen Pass zu finden ist. Schlussendlich soll mit zwei Schweizerkreuzen die Herkunft symbolisiert werden.