Example usage

<?php if (have_posts()) : ?>

<?php while (have_posts()) : the_post(); ?>

<?php if ( has_parentpage() ): ?>
<p> This page has a parent page. </p>
<?php endif ?>

<?php endwhile; ?>

Dies ist der Start einer kleinen Serie über sogenannte Versionskontrollsysteme. Da CVS das bekannteste und auch älteste Versionskontrollsystem ist, habe ich mich dazu entschlossen es als erstes vorzustellen. In späteren Beiträgen werden SVN, Git, Mercurial sowie Bazaar folgen.

CVS ist die wie bereits erwähnt das älteste Versionskontrollsystem das noch aktiv eingesetzt wird. CVS ist sozusagen die Mutter aller Versionskontrollsysteme. Hierbei ist zu beachten, dass es im Gegensatz zu Git und Mercurial ein sogenanntes zentrales Versionskontrollsystem ist. Dies bedeutet, dass ein CVS-Server dazu benutzt wird den aktuellen Stand vorzuhalten. CVS wird noch von einigen Projekten eingesetzt, und afaik auch noch von Sourceforge als Zugang angeboten.
CVS hat mit anderen Versionskontrollsystemen einiges gemeinsam, so werden unterschiedliche Revisionen abgelegt, die meistens durch eine fortlaufende Nummer gekennzeichnet sind. Bei den sogenannten Check-Outs wird die aktuelle Arbeitskopie des CVS-Repositories auf den Client übertragen. Der Entwickler kann dort dann entsprechende Änderungen am Code vornehmen, und diese mit einem Check-In wieder zum Server übertragen. Dabei kann er zu jedem Check-In einen Logeintrag verfassen, der für alle Benutzer sichtbar ist.
CVS unterstützt die Rechte „darf lesen“, „darf schreiben“ sowie „darf nix“. Meistens erhält ein Gast-Zugang in Opensource-Projekten reinen lesezugriff, damit kann ein x-beliebiger Benutzer jeden vorhandenen Projektstand erhalten, egal ob die gewünschte Version bereits Jahre zurückliegt, oder er den aktuellen Entwicklerzweig (trunk) erhalten möchte.
Natürlich bieten einige Tools eine CVS unterstüzung an. So lässt sich CVS in Eclipse, Visual Studio, XCode, Emacs oder Netbeans (und einigen Weiteren IDEs) einbinden. Auch steht mit TortoiseCVS ein Windows-Client zur Verfügung.
Allerdings wird CVS immer mehr von Subversion (the better CVS) abgelöst.

Links zu CVS

• Introduction to CVS
• CVS Best Practices
• Wikipedia Artikel
• Ximbiot – CVS Wiki

Was ist Subversion?

Subversion ist ein sogenanntes Versions-Kontroll-System welches es ermöglicht einfach und unkompliziert an jede beliebige Version einer bestimmten Datei innerhalb eines Quell-Code-Projekts zu gelangen. Subversion gibt es seit etwa 2000. Alternativen dazu sind unteranderem GIT und CVS. Subversion gilt als Quasi-Standard der Versions-Kontroll-Systeme. Es ist kostenlos (OpenSource) und es gibt unterschiedliche Clients für Windows, Linux und auch MacOS. Unter Windows dürfte das bekannteste wohl TortoiseSVN sein.

Der Sinn hinter Subversion versteckt sich darin, dass man ein Projekt entwickeln kann, und immer wieder zu einem bestimmten Stand zurückkehren kann, auch noch nach Jahren. Dabei ist keine Änderung innerhalb des Subversion-Archives redundant es werden im Endeffekt nur Änderungen gespeichert, und dann solange durchgeführt, bis Subversion die gewünschte Version der Datei zurückgeben kann. So ist die aktuelle WordPress Version 2.6 entpackt und lauffähig 4,36 MB groß, das komplette Subversion Archiv „nur“ 107 MB groß. Dies hört sich nun viel an, ist aber, wenn man bedenkt wirkliche jede Änderung im Quellcode bis Version x rückgängig machen zu können wirklich nicht viel

WordPress und Subversion

Automattic Inc. betreibt einen Subversionserver auf dem unter Anderem die Quelltexte für WordPress abgelegt sind. Darüber gestaltet sich der Zugriff auf die Entwicklerversion („bleeding“) und alle vorherigen Veröffentlichungen der Software recht einfach. Um nun WordPress über Subversion zu aktualisieren müssen mehrere Voraussetzungen erfüllt sein:

• Subversion-Client-Software
  Der Subversion Client muss installiert sein. Dies geschieht unter Debian-Abkömmlingen mit dem als root auszuführenden Befehl „apt-get install subversion“. Für ein manuelles aktualisieren von WordPress empfiehlt sich unter Windows Servern die Installation von TortoiseSVN. Für ein Automatisches Update wird allerdings ein Kommandozeilen-Client benötigt, hier bietet sich der Client von Collab.net an, auf den ich mich im weiteren Verlauf auch beziehe.

• Shellzugriff bzw. Remotezugriff
  Zum Einrichten des Aktualisierungsprozesses wird Shellzugriff (SSH) unter Linux, beziehungsweise Remotezugriff (RemoteDesktop) unter Windows benötigt.

• Cronjobs / geplante Tasks
  Um eine Automatische Aktualisierung einzurichten benötigen Sie entsprechende Rechte um einen geplanten Task unter Windows beziehungsweise einen Cronjob unter Linux einrichten zu können.

Ich biete einen Mirror des WordPress-SVNs an, der im Regelfall jede Stunde aktualisiert wird. Dies dient dazu um die Belastung des Ursprünglichen SVN-Servers zu verringern. Auch wenn es ein OpenSource-Projekt ist, sollte man sich nicht einfach immer nur gedankenlos bedienen. Das Mirrorverzeichnis ist wie folgt zugänglich:

Unter dem Archiv auf http://svn.nyforge.eu/get/WP-Mirror liegt eine direkte stündlich aktuelle Kopie des WordPress SVN Archivs. Hierbei geht die Primäre Auswahl über die sogenannten Tags beziehungsweise nur den Entwickler-Zweig „trunk“. Kommt ein neues WordPress-Release heraus, ist ein manuelles Nacharbeiten notwendig, wenn man trunk nicht verwendet.

Als kleine Randanmerkung: Man sollte nur „trunk“ auswählen wenn man sich den Gefahren einer aktuellen Entwickler-Version bewusst ist, und die Risiken entsprechend in Kauf nehmen will. Hierzu gehören unter Anderem plötzliche Änderungen an der Datenbankstruktur die den Blog temporär zumindest unbrauchbar machen können, sowie einfache Fehler in Quelldateien. (So sind zum Beispiel bei der Entwicklerversion von 2.4 auf 2.5 alle eingepflegten Tags verloren gegangen) Ich rate dringendst davon ab, eine Entwickler-Version im Produktivbetrieb einzusetzen. Dennoch beziehen sich die folgenden Beispiele alle auf „trunk“. Wenn man die letzte Stabile Version verwenden will, benutzt man bitte anstatt „trunk“ die Zeichenfolge „tags/2.6“.

Backup erstellen!
Auch wenn es sich kleinlich anhört, aber es wird dringend das Erstellen eines kompletten Backups eines bereits bestehenden Blogs empfohlen! Dies beinhaltet:

• Die Datenbank
• Alles was sich im Blogverzeichnis befindet
• insbesondere aber den Ordner wp-content, sowie die Datei wp-config.php

Erst wenn dieses Backup existiert, sollte man mit der Einrichtung fortfahren.

Ich gehe nun von folgender Situation aus:

• Der Blog ist oder soll über http://www.example.com/blog erreichbar sein
• Das DocumentRoot liegt unter /home/hosts/example-com bzw c:\inetpub\wwwroot\example-com
• Das SVN Binary ist unter Windows im Pfad vorhanden.

Es geht los!
Als erstes muss das Ursprüngliche Verzeichnis gelöscht werden wenn der Blog bereits existierte, beziehungsweise angelegt werden wenn der Blog neu eingerichtet werden soll.
Unter Linux geschieht dies mit dem Befehl

rm -Rf /home/hosts/example-com/blog ; mkdir /home/hosts/example-com/blog –p

Unter Windows kann man dies komfortabel über den Explorer lösen.
Als nächsten Schritt müssen wir die gewünschte Version von WordPress „auschecken“.
Unter Linux ist dies über den Befehl

svn co http://svn.nyforge.eu/get/WP-Mirror/trunk /home/hosts/example-com/blog 

zu erreichen.
Subversion listet daraufhin alle Dateien auf die heruntergeladen wurden.
Unter Windows muss man entsprechend den Befehl wie folgt ändern:

svn co http://svn.nyforge.eu/get/WP-Mirror/trunk c:\inetpub\wwwroot\example-com\blog

Einrichtung
Handelt es sich um eine neue WordPressinstallation kann man die Einrichtung von WordPress gemäß der Anleitung von WordPress starten. (Mit dem Browser auf http://www.example.com/blog/wp-admin wechseln und 2 Seiten ausfüllen, fertig.)
Wenn es sich um ein Update einer bereits vorhandenen (und vorher gesicherten) WordPressinstallation handelt ist die Sache etwas komplizierter.
Der geneigte Blogbesitzer muss nun seine wp-config.php aus dem Backupverzeichnis in die neue WordPress installation kopieren. Ebenso muss der Ordner wp-content/uploads, diverse plugins aus wp-content/plugins sowie das verwendete theme aus wp-content/themes/meintollestheme aus dem Backup in die aktuelle WordPress installation kopiert werden, also zum Beispiel

cp /home/hosts/example-com/blog.bak/wp-config.php /home/hosts/example-com/blog/wp-config.php
cp –rf /home/hosts/example-com/blog.bak/wp-content/uploads /home/hosts/example-com/blog/wp-content
cp –rf /home/hosts/example-com/blog.bak/wp-content/themes/meintollestheme /home/hosts/example-com/blog/wp-content/themes
cp –rf /home/hosts/example-com/blog.bak/wp-content/plugins/TollesPlugin /home/hosts/example-com/blog/wp-content/plugins/TollesPlugin

Damit ware der Blog nun wieder lauffähig. Im Regelfall muss der Blogeigentümer nun noch die Datenbank aktualisieren, was sich einfach mit einem Klick auf http://www.example.com/blog/wp-admin erledigen lässt.
Aktualisieren kann man den Blog nun über den Befehl

svn up /home/hosts/example-com/blog 

Beziehungsweise

svn up c:\inetpub\wwwroot\example-com\blog

Dies sind auch die Befehle die man entweder in die Crontab unter Linux, oder als geplanten Task einrichtet unter Windows, wenn man in den Genuss einer automatischen Aktualisierung kommen will.

Warum über Subversion aktualisieren?
Die Gründe für ein automatisches Update waren für mich recht simpel: Fehlerbeseitigungen sind schneller eingespielt, und ab 2 Installationen die man zu verwalten hat spart man Zeit . Auch wenn man WordPress testen will, und durch das Verwenden von sogenannten Bleeding-Versionen mithelfen will die Qualität zu verbessern bietet sich dieser Weg nun einmal an. Ein wichtiger Grund dürfte auch einfache stupide Faulheit sein, denn es spart wie gesagt Unmengen an Zeit.
Ich müsste mehrere Blogs händisch auf dem neusten Stand halten, mich um die Sicherheitsupdates kümmern, alles Arbeit die man sich sparen kann.
Sicherlich ist es einmalig ein kleiner Aufwand das ganze einzurichten, aber die Arbeit lohnte sich zumindest für mich.

mailq | tail +2 | grep -v '^ *(' | awk  'BEGIN { RS = "" }
# $7=Absender, $8=Empfänger1, $9=Empfänger2
{ if ($8 == "gibtsnicht@rainerbendig.com" && $7 == "MAILER-DAEMON")
print $1 }
' | tr -d '*!' | postsuper -d -

TMX ist der Standard den ich in “Tyche” entsprechend verwenden werde. Zumal das Zend Framework eine entsprechende Schnittstelle mitsich bringt.

Nach dem Starten von gwservice bot sich mir recht lange das folgende Bild:
shorn:~ # /etc/init.d/gwservices restart
Stopping Groundwork Services [ OK ]
Starting Groundwork Services
Connecting to Foundation listener Host:localhost Port:4913
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Couldn't connect to localhost:4913: IO::Socket::INET: connect: Connection refused
gwservices start failed. [ FAILED ]

Ursache hierfür ist einfach, dass sich Java nicht im Pfad befindet. nach einem kurzen Edit der Datei /etc/init.d/gwservices wo ich die zeilen

export JAVA_HOME=/usr/java
export JRE_HOME=$JAVA_HOME/bin

einfügte lies sich der Service ohne probleme starten:
shorn:~ # /etc/init.d/gwservices restart
Stopping Groundwork Services [ OK ]
Cannot stat file /proc/28148/fd/3: No such file or directory
Cannot stat file /proc/28148/fd/4: No such file or directory
Cannot stat file /proc/28148/fd/5: No such file or directory
Starting Groundwork Services
Connecting to Foundation listener Host:localhost Port:4913
Listener not ready to accept data feeds ....
Listener ready to accept data feeds....
gwservices start [ OK ]

Meine Bekannte stellte nun die folgenden Anforderungen:

• Bilder sollten auf Ihrer Seite präsentiert werden, aber diese will sie mit Picasa weiterhin verwalten
• Ihre Musik die sie hört, soll wie eine Playlist in einer der Sidebars ihres Blogs erscheinen. Natürlich mit so wenig Aufwand für sie wie möglich.

Für die Integration von Picasa kamen nun mehrere Plugins zum Einsatz:

• Picasa Photos um die Bilder in der Sidebar anzuzeigen. Dieses Addon wurde allerdings angepasst, dass es nun nicht mehr auf die Bilder bei Picasa verweist, sondern das jeweils ausgewählte Bild in einer Lightbox auf der Webseite darstellt.
• kPicasa Gallery um die Bilder in einer Art Galerie in dem jeweils ausgesuchten WordPress-Theme darstellt. Und diese auch in einem eigenen „Frame“ auf der eigenen Seite präsentiert.

Beide Plugins speichern oder cachen die Photos leider nicht zwischen, weshalb für jeden Bilderaufruf zu Google umgeleitet wird.
Die Playlist ist etwas komplizierter. Meine bekannte verwaltet ihre Lieder auf dem PC mit Winamp und der dort integrierten Medialibrary. Allerdings gibt es Plugins, die an bestimmte Webseiten Posts-Requests absenden. Und es gibt Plugins für WordPress die die Liedtitel anschaulich präsentieren. Es kommen hier also die folgenden Plugins zum Einsatz:

• Now Playing Plugin for Winamp, damit Winamp die Liedtitel an den Blog postet. Dies geschieht nach einer einmaligen Einrichtung komplett automatisiert. Man muss sich nicht mehr darum kümmern.
• Plastic Tunes in WordPress. Dieses Plugin wertet die von Winamp geschichten Postdaten auf, und speichert sie in einer MySQL Tabelle innerhalb der WordPress installation. Über ein Widget können diese hinterlegten Informationen dann in der WordPress Sidebar präsentiert werden.

Durch die Kombination der unterschiedlichen Services und Plugins muss meine Bekannte ihre bisherigen Tätigkeiten nicht umstellen, sie kann weiterhin Ihre Bilder mit Picasa verwalten und ha diese dennoch in einer schönen Oberfläche innerhalb ihres Blogs. Die Winamp-Anbindung war wie vorher schon beschrieben eine einmalige Install-And-Forget Geschichte.
Da meine Bekannte keine Verlinkung ihres Blogs wünscht, hier nur ein paar Screenshots

2008-04-14T07:50:01+02:00 zetal01 cyrus/imapd[22591]: DBERROR: skiplist recovery /var/imap/user/m/mx0002.seen: ADD at 6FA4 exists
2008-04-14T07:50:01+02:00 zetal01 cyrus/imapd[22591]: DBERROR: opening /var/imap/user/m/mx0002.seen: cyrusdb error
2008-04-14T07:50:01+02:00 zetal01 cyrus/imapd[22591]: Could not open seen state for mx0002 (System I/O error)

kann daran ein “shutdown -rfn now” oder ein “shutdown -rf -t 1 now” schuld sein.

Wenn man nach der Fehlermeldung bei google sucht, wird man hierher geleitet, wo vorgeschlagen wird die datei mx0002.seen umzubenenn oder zu verschieben was dann auch hilft.