Kurzum: SyntaxHighlighter integriert nun erfolgreich und stark vereinfacht die hervorragenden Funktionalitäten des dp.SyntaxHighlighter in WordPress und umgeht dabei automatisch dessen verworrene Formatierungs-Routinen. Postings werden nach wie vor wie gewohnt dargestellt, lediglich Code Snippets sind von der automatischen Formatierung ausgeschlossen und werden nun auch korrekt ausgegeben.

Zusätzlich dazu sorgt ein Administrations-Menü in den WordPress-Optionen für eine einfache Konfiguration. Hier kann man sich nebst einigen Darstellungs-Möglichkeiten noch zusätzlich auswählen, welche Sprachen unterstützt werden sollen. Nur diese werden auch mitgeladen, um das Skript möglichst effektiv und schlank zu halten.

Anleitung, Beispiele sowie das Plugin selbst befinden sich auf der SyntaxHighlighter-Seite. Fragen, Bugs, Anmerkungen und Ideen bitte wie immer dort in die Kommentare.

Zur SyntaxHighlighter-Seite…  

Um das Ganze nun elegant zu umgehen, eine Menge Zeit und Arbeit zu sparen und dabei trotzdem noch pro Blog eigene Konfigurationen, Templates und Unique Content anbieten zu können, hat sich in der Praxis nun das folgende – sogar recht einfache – Workaround bewährt.

Dazu öffnen wir die wp-config.php, welche sich im Hauptverzeichnis von WordPress befindet. Dort suchen wir jetzt jene Zeile, in der $table_prefix = 'wp_'; zu lesen ist. Dahinter steht meistens noch eine mit zwei Schrägstrichen auskommentierte Anmerkung, welche je nach Verison variiert, aber wichtig ist nur, dass es sich um die Zeile handelt, in welcher der Table-Prefix festgelegt wird.

Die ganze Zeile wird nun ersetzt durch eine von drei möglichen Varianten:

Variante 1: eine Domain, multiple Subdomains
[source:php]
$arrPrefix = explode( “.”, $_SERVER["HTTP_HOST"] );
$table_prefix = $arrPrefix[0].’_';
[/source]

Variante 2: Multiple Domains (pro Domain ein Blog)
[source:php]
$arrPrefix = explode( “.”, $_SERVER["HTTP_HOST"] );
$table_prefix = $arrPrefix[( count( $arrPrefix ) - 2 )].’_';
[/source]

Variante 3: Multiple Domains mit jeweils multiplen Subdomains
[source:php]
$arrPrefix = explode( “.”, $_SERVER["HTTP_HOST"] );
$table_prefix = implode( “_”, $arrPrefix ).’_';
[/source]

Variante 4: Multiple Domains, Subdomains, gleiche Domainnamen mit verschiedenen .tlds inkl. Fix für Bindestriche
[source:php]
$table_prefix = str_replace( array( “.”, “-” ), “_”, $_SERVER["HTTP_HOST"] ).”_”;
[/source]

Da hier bislang nur Variante 1 zum Einsatz kam, musste ich mir die beiden anderen quasi aus dem Ärmel schütteln, aber das Prinzip bleibt auch dort dasselbe. Der Prefix für die Tabellen, welche WordPress in der konfigurierten Datenbank nutzen soll, wird je nach (Sub)Domain dynamisch gesetzt. Sehr einfach, aber sehr effektiv.

Das Ganze lässt sich per SubDomain und einer einfachen switch/case-Routine auch noch erweitern, um – wie Eingangs bereits erwähnt – für verschiedene SubDomains zum Beispiel auch die passende Sprache auszuwählen. Da jedes Blog zwar nun auf der gleichen Instanz aufsetzt, jedoch andere Tabellen nutzt, muss auch jedes Blog zuerst noch regulär installiert und konfiguriert – also komplett neu aufgesetzt – werden. Dazu reicht es, alle betroffenen Domains einmal kurz anzusurfen und den gewohnten Installations-Prozess zu durchlaufen. Alle Blogs teilen sich natürlich sämtliche Plugins, Themes und folgende Updates, Erweiterungen und Änderungen.

Sehr praktisch übrigens auch, möchte man einen Blog-Hosting-Service für WordPress anbieten. Durch weitere, einfache Konfigurationsänderungen lässt sich auf diese Weise sogar die DB-Last verteilen, indem man hier mehrere (Mirror-)Server angibt. Da die Änderungen sich nur auf die wp-config.php beziehen, lässt sich WordPress auch weiterhin noch problemlos updaten.

Nachtrag vom 28.09.2006:
Nach einem sehr überraschenden und nicht minder erfreulichen Anruf von Robert Basic noch eben eine kurze viel zu lang geratene Randnotiz hinterher:

Es ist natürlich wichtig, dass sämtliche Domains, die auf der WordPress-Instanz aufsetzen sollen, in ein und dasselbe Verzeichnis auf dem Server zeigen. Liegen die WordPress-Skripte also in /home/htdocs/blog auf dem Server, so müssen auch entsprechend die Domains dorthin gelenkt werden. Beim Apache sähe das Ganze z.B. in der Konfigurationsdatei so aus:

ServerName domain.tld
ServerAlias *.domain.tld
DocumentRoot /home/htdocs/blog

In diesem Falle zeigen sämtliche Subdomains von domain.tld in ein einziges Verzeichnis mit genau einer WordPress-Instanz, die sich aber wiederum liebevoll per oben genannter Variante 1 um jegliche Subdomains kümmert, die hier so anfallen. Surft man nun also tolle.domain.tld an, so nutzt WordPress nach erfolgreicher Modifikation sämtliche Tabellen mit “tolle_” als Prefix und legt somit augenscheinlich ein komplett neues Blog an, obgleich es auf der einen Instanz aufsetzt, welche auch www.domain.tld und schnieke.domain.tld nutzen. Plugins und Templates wiederum teilen sich alle Blogs und können je nach Subdomain einzeln konfiguriert werden, da diese Daten wiederum in der jeweiligen DB-Tabelle gespeichert werden. Jedes Blog fungiert also autonom, nutzt aber den gleichen WordPress-Kern.

Viel Spaß damit.

Ebenfalls möglich ist es, wahlweise Sprachdateien zu laden, auf eine anderssprachige Blog-Instanz weiterzuleiten und dergleichen mehr. Für ein reguläres Durchschnittsblog – so wie auch dieses hier – nicht unbedingt notwendig, für Business Blogs hingegen eine sehr praktische Erweiterung.

Anleitung, Beispiele sowie das Plugin selbst befinden sich auf der getBrowserLanguage-Seite. Fragen, Bugs, Anmerkungen und Ideen bitte wie immer dort in die Kommentare.

Zur getBrowserLanguage-Seite…  

Das Ergebnis einer Nachtschicht liegt nun seit heute Morgen vor und ist bereits erfolgreich produktiv im Einsatz: is_child in Version 1.1 1.1.1

Die Funktion kann nach Aktivierung des Plugins ganz bequem in sämtlichen Templates genutzt werden. Unterstützt werden Categories, Postings und Pages. Der Parent kann wahlweise mit seiner ID, dem Titel oder dem Slug (“Titelform”) angegeben werden. Sämtliche Suchen erfolgen rekursiv durch sämtliche Elterngenerationen oder wahlweise nur mit den direkten Parents. Bei Postings werden sämtliche Kategorien, in denen das Posting eingetragen wurde, durchforstet.

Als Beispiel:

Man befindet sich derzeit hier:
Reviews -> Music -> CDs -> Artists -> JAMMIN*INC -> Mit Anlauf

Nun möchte man zum Beispiel Amazon Ads für die gesamte Musik-Kategorie – inklusive aller Unter-Kategorien und Postings – schalten. Einfacher geht’s nicht mehr:
if( is_child( "Music" ) ) include( "amazon-ads.php" );

Das war’s. Kein lästiges is_page()- oder is_site()-fischen mehr. Kein Hakeln durch letztlich nicht vorhandene Parent-Funktionen der Categories mehr.

Mehr Beispiele sowie Anleitung und Plugin selbst finden sich auf der is_child-Seite. Fragen, Bugs, Anmerkungen und Ideen bitte dort in die Kommentare.

Zur is_child-Seite…