WordPress bietet die Möglichkeit, sprechende URLs aus Kategorie- und Beitragsnamen zu erzeugen. Die Struktur der Permalink-URLs für Blog-Artikel lässt sich im Backend auch sehr gut einstellen, zum Beispiel basierend auf Datum und Beitragstitel. Hier lässt sich sehr schön eine zeitliche Hierarchie einrichten, wie hier dargestellt:

• http://example.com/2008/06/23/mein-erster-beitrag/ - Mein erster Beitrag (23.06.2008)
• http://example.com/2008/06/23/ - Tagesarchiv: alle Artikel vom 23.06.2008
• http://example.com/2008/06/ - Monatsarchiv: alle Artikel vom Juni 2008
• http://example.com/2008/ - Jahresarchiv: alle Artikel des Jahres 2008

Für persönliche Blogs oder Blogs ohne tiefere Struktur sind diese Permalinks sicher sehr gut, zumal man hier sofort das Datum des Artikels sieht.

Kategoriebasierte Permalinks

Leider ist diese Struktur nicht für jede WordPress-Website geeignet. Viele WordPress-Nutzer wollen ihre Website klar strukturieren, zum Beispiel mittels Kategorien und Unterkategorien. Hierzu kann man zum Beispiel folgende benutzerdefinierte Permalink-Struktur für die Blogartikel einstellen:
/%category%/%postname%
Hier werden die Permalinks für Blogartikel zum Beispiel so generiert:

• http://example.com/meine-hauptkategorie/mein-erster-beitrag/

Auch Kategoriehierarchien mittels Ober- und Unterkategorien ist so möglich und sieht dann zum Beispiel so aus:

• http://example.com/meine-hauptkategorie/meine-unterkategorie/mein-erster-beitrag/

Nachteile und Probleme kategoriebasierter Permalinks

Leider funktioniert hier aber die URL-Hierarchie wie bei den datumsbasierten Permalinks nicht mehr, ein Link auf:

• http://example.com/meine-hauptkategorie/

würde ins Leere führen. Standardmäßig wird Kategorie-URLs ein „/category/ vorangesetzt:

Abgesehen davon, dass dies für deutschsprachige Seiten unschön aussieht, wird so auch die URL so unnötig verlängert und es wird ein Element eingefügt, welches in den Artikel-URLs nicht mehr vorhanden ist. Die URL-Struktur der Seite wird also inkonsistent.

Abhilfe: die Permalink-Option „Kategorie-Basis“

Hier kommt jetzt die Permalink-Option „Kategorie-Basis“ ins Spiel. Hier kann man eine eigene URL-Basis für die Kategorie-URLs festlegen. Um das Wort „category“ zum Beispiel einzudeutschen, könnte man hier „/kategorie/“ eintragen. Das ändert aber nichts daran, dass die URL-Struktur inkonsistent wird. Mit einem kleinen Trick kann man aber die Kategoriebasis aus der URL entfernen. Man trägt einfach einen Verweis auf das eigene Verzeichnis ein:
./

Dieser Trick funktioniert, allerdings sind einige Seiteneffekte zu beachten, auf die ich im folgenden kurz eingehen möchte.

Seiteneffekt 1: „./“ in URLs

WordPress generiert die Links im HTML-Quelltext wie folgt:

• http://example.com/./meine-hauptkategorie/
• http://example.com/./meine-hauptkategorie/meine-unterkategorie/

Alle mir bekannten Browser sowie die großen Suchmaschinen interpretieren das „./“ in den Kategorie-URLs korrekt und haben keine Probleme diesen Verweisen zu folgen. Die meisten Browser und Suchmaschinen-Roboter entfernen den (eigentlich überflüssigen) Verweis auf das aktuelle Verzeichnis aus der URL, und zeigen die URL in der Adressleiste, Statuszeile oder in Tooltips ohne das „./“ an:

• http://example.com/meine-hauptkategorie/
• http://example.com/meine-hauptkategorie/meine-unterkategorie/

Lediglich ältere Internet Explorer belassen die URLs wie sie sind. Es handelt sich aber höchstens um einen kleinen Schönheitsfehler, da auch diese Browser problemlos mit diesen Links klar kommen und die gewünschte Kategorie aufrufen.

Seiteneffekt 2: Probleme bei gleichnamigen statischen Seiten

WordPress bietet mit Bordmitteln keine Möglichkeit, die Permalinkstruktur von statischen Seiten (im Sinne von WordPress) zu beeinflussen. WordPress-Seiten haben immer folgende URL-Struktur:

• http://example.com/hauptseite/unterseite/

Wenn man nun eine statische Seite und eine Kategorie hat, die beide den gleichen Titel besitzen, dann hätten beide dieselbe URL:

• http://example.com/mein-toller-titel/ - URL der Seite mit dem Titel „Mein toller Titel“
• http://example.com/./mein-toller-titel/ - URL der Kategorie mit dem Titel „Mein toller Titel“

Da der Punkt „.“ auf das aktuelle Verzeichnis verweist sind beide URLs also äquivalent. Da aber 2 verschiedene Ressourcen (Webseiten) aber nicht dieselbe URL haben können gibt es hier offensichtlich Probleme. Gleichnamige Kategorien und statische Seiten muss man bei der Kategoriebasis „./“ also vermeiden. Es genügt dass der URL-Name (engl. „Post Slug“) unterschiedlich ist, diesen kann man beim Anlegen der Seite bzw. Kategorie bequem ändern.

Seiteneffekt 3: Artikel-Permalinks

Der Trick mit „./“ funktioniert nur, wenn man die Permalinkstruktur der Blogartikel so einstellt, dass sie mit /%category%/ beginnen, und zusätzlich die Artikel-ID mittels %post_id% enthalten. Eine funktionierende Permalinkstruktur für Artikel wäre also z.B. die folgende:
/%category%/%post_id%-%postname%
Eine Permalinkstruktur, die die Artikel-ID enthält hat aber den Nachteil, dass sämtliche URLs, die die ID enthalten, auf den Artikel mit dieser ID verweisen. Es droht unter Umständen doppelter Inhalt (engl. „duplicate content“, „DC“). Ein Beispiel für die oben genannte Permalinkstruktur:

• http://example.com/meine-kategorie/123-mein-toller-titel/
• http://example.com/meine-kategorie/123-mein-titel/
• http://example.com/meine-kategorie/123-mein-toller/
• http://example.com/meine-kategorie/123-mei…tel/

Diese URLs verweisen alle auf den selben Artikel. Auftreten kann das Problem, wenn jemand mit einer falschen, aber nach der o.g. Permalinkstruktur formal gültigen URL auf den Artikel verlinkt. Allerdings unterstützt WP ab Version 2.3 kanonische URLs und leitet „falsche“ Artikel-URLs auf den korrekten URL weiter. In der Praxis sollte dieses Problem daher keine Rolle spielen.

Abschließend möchte ich noch auf einen Thread im Forum hinweisen, der diese Problematik zum Thema hat: http://forum.wordpress-deutschland.org/konfiguration/32318-url-category.html

Danke an alle, die in diesem Thread mit ihren Erfahrungen und Hinweisen geholfen haben. Ganz speziellen Dank an Ingo für die vielen Tests und Hinweise.

Auch auf das Plugin „Top Level Categories“ möchte ich noch hinweisen, manche WordPresser haben allerdings von Problemen mit diesem Plugin seit WP 2.5 berichtet.

Ähnliche Tipps gibt auch Frank Bültge in seinem Artikel WordPress sicherer machen.

Einer der wichtigsten Tipps lautet: Immer die aktuelleste Version von WordPress verwenden. Auch Plugins sollten aktuell gehalten werden.

Diese Pakete sind dazu gedacht, um direkt und leicht von der davor aktuellen, zur nun neuesten Version upgraden zu können. Also z.B. von Version 2.2.2 auf Version 2.2.3.

Die Upgradepakete identisch zur ebenfalls immer angebotenen “Vollversion”, mit jedoch einem großen Unterschied - sie enthalten nur die geänderten Dateien.

Der Sinn dieser Pakete liegt also nur in der Ersparnis von Dateivolumen. Man muss weniger runterladen und auch weniger hochladen - für eine insgesamt schnellere Update-Prozedur. Und der Profi sieht auf dem ersten Blick, welche Dateien geändert wurden. Das kann nützlich sein, falls er einige der Systemdateien von WordPress geändert hat.

Mit der “Vollversion” der jeweiligen Version ist deshalb genauso gut und unproblematisch ein Upgrade möglich - nur dass eben auch Dateien ersetzt und erneuert werden, die sich garnicht verändert haben.

Es sei an dieser Stelle deutlich darauf hingewiesen, dass man für größere Versionssprünge (z.B. von 2.1 auf 2.2.3) deshalb immer mit der Vollversion upgraden sollte und nicht fünf Upgradepakete hintereinander verwendet.

Die Beschreibung geht übrigens von einer existierenden Installation aus, die sich bisher im Hauptverzeichnis befindet. Aber es macht in dem Sinne auch keinen Unterschied, wenn der Blog schon in einem Unterverzeichnis installiert wurde.

1. Belasse die Dateien und Ordner erstmal so, wie sie sind. Das Verschieben erfolgt später.
2. Gebe in Adminbereich >> Einstellungen >> Allgemein > WordPress-Adresse (URL): die (neue) Adresse zu den WordPress-Dateien mit Unterverzeichnis an. In diesem Beispiel also http://example.com/wordpress.
3. Gebe in Adminbereich >> Einstellungen >> Allgemein > Blog-Adresse (URL): die (neue) Adresse zum Blog ohne Unterverzeichnis an. In diesem Beispiel also http://example.com. Über diese Adresse soll dein Blog später aufgerufen werden.
4. Klicke auf Einstellungen aktualisieren.
5. Logge dich nun via FTP-Programm auf deinem Webserver ein verschiebe alle (!) zu WordPress dazugehörigen Dateien und Ordner in das neue Verzeichnis (welches bei WordPress-Adresse angegeben wurde). In diesem Fall also das Verzeichnis /wordpress/.
   Und alles meint wirklich alles, inklusive den Dateien (wie wp-config.php etc.) die nicht in den Ordnern /wp-admin/, /wp-content/, /wp-admin/ usw. liegen.
6. Kopiere die index.php und, falls vorhanden, .htaccess aus deinem neuen WordPress-Verzeichnis (hier /wordpress) in das Hauptverzeichnis/Stammverzeichnis deines Webspaces, also dem, was du bei Blog-Adresse (URL) angegeben hast.
7. Öffne diese ins Hauptverzeichnis kopierte index.php mit einem Texeditor (Microsoft Word ist keiner).
8. Ändere folgende Zeile: require('./wp-blog-header.php'); Es muss das Verzeichnis eingetragen werden in dem nun die WordPress-Dateien liegen.
   In diesem Beispiel also zu:
   require('./wordpress/wp-blog-header.php');
9. Nun ist dein Blog wieder erreichbar. Logge dich ins Adminmenü ein und aktualisiere, falls vorhanden, die Permalinks:
   Adminbereich >> Einstellungen >> Permalinks > Permalink-Struktur aktualisieren
   Falls WordPress wegen fehlender Dateirechte die .htaccess nicht beschreiben konnte, so kannst du die angezeigten Änderungen auch manuell in die Datei eintragen.

Den Parameter exclude nutzen

Um im Blog alle statischen Seiten aufzulisten, benutzt nahezu jedes Theme den Template Tag wp_list_pages (Infos dazu in der Doku).

Will man nicht, dass bestimmte Seiten aufgelistet werden, so bietet der Parameter exclude die entsprechende Möglichkeit dazu.

Als erstes musst du herausfinden, wo bei deinem Theme der Code <?php wp_list_pages('parameter'); ?> zu finden ist. Nutze dazu einen Texteditor oder den Theme-Editor im Adminmenü. Beachte, dass der Inhalt in der Klammer je nach Theme variiert.
Meistens wird man in der sidebar.php fündig, manchmal auch in der header.php, index.php, footer.php oder functions.php - es hängt vom jeweiligen Theme ab.

Die weitere Vorgehensweise hängt davon ab, ob die Klammer leer ist, also keine Parameter eingetragen sind, oder ob schon Anweisungen vorhanden sind.
Ist also die Klammer leer, dann sieht der Code so aus:
<?php wp_list_pages(); ?>
In diesem Fall genügt es, in die Klammer 'exclude=bla' einzutragen, wobei bla für die Seiten-ID steht. Mehrere IDs werden einfach durch ein Komma - ohne Leerzeichen - getrennt.
Die Seiten-IDs findest du übrigens hier angezeigt:
Adminbereich >> Verwalten >> Seiten

Willst du also die Seiten mit der ID 2, 10 und 22 von der Auflistung ausschließen, dann muss der gesamte Code so aussehen:
<?php wp_list_pages('exclude=2,10,22'); ?>

Sind Bereits Parameter vorhanden, so musst vor dem schließenden Apostroph in der Klammer folgenden Schnipsel einfügen:
&exclude=bla
Das & ist übrigens wichtig, da es die unterschiedlichen Parameter von einander trennt. bla steht selbstredend wieder für die Seiten-IDs.
Auch hier ein Beispiel:
<?php wp_list_pages('title_li=<h2>Seiten</h2>'); ?>
wird zu <?php wp_list_pages('title_li=<h2>Seiten</h2>&exclude=2,10,22'); ?>

Will man stattdessen generell alle Unterseiten (ab einer bestimmten Ebene) ausschließen, so wird dazu in gleicher Weise der Parameter depth anstatt exclude verwendet:
depth=-1 zeigt keine Unterseiten.
depth=2 zeigt Unterseiten bis zu einer Ebene unter der übergeordneten Seite.
depth=3 zeigt Unterseiten bis zu zwei Eben unter der übergeordneten Seite.

Auschließen via Plugin

Will man das Ausschließen von Seiten etwas einfacher gestalten, so kann man sich auch das Plugin Page Link Manager anschauen (und benutzen).

Seiten mittels des Status “privat” verstecken

Diese Möglichkeit macht sich den Umstand zu nutze, dass als privat markierte Seiten nicht in der Seitenauflistung (und auch so nicht) angezeigt werden und diese Eigenschaft auch auf untergeordnete Seiten übertragen wird - obwohl diese nicht auf privat gesetzt sind.

Erstelle also eine neue, leere Seite und wähle in der rechten Box Status die Eigenschaft privat.
Der Inhalt privater Seiten kann nicht eingesehen oder aufgerufen werden - außer du bist als Administrator eingeloggt. Dementsprechend werden sie auch nie aufgelistet.

Die Seiten, die nun nicht angezeigt, aber aufgerufen können werden sollen, werden als Unterseite dieser privaten Seite konfiguriert.
Bearbeite dazu einfach die bereits vorhandene Seite (oder erstelle eine neue, falls nötig) und wähle in der Box Übergeordnete Seite die auf privat gesetzte Seite. Der Status der zu versteckenden Seiten bleibt auf veröffentlicht!
Das war es schon.

Fatal error: Allowed memory size of 654321 bytes exhausted (tried to allocate 12345 bytes) in /srv/www/user/bla/blub/file.php on line 123

Die Werte für die Bytes, vorkommende Datei und Codezeile sind dabei beliebig.
Was aber bedeutet diese Fehlermeldung, die direkt vom Server kommt?

Bei PHP gibt es in der Konfiguration einen Wert memory_limit. Dieser Wert definiert den maximal erlaubten Speicherplatzverbrauch (im Arbeitsspeicher) eines PHP-Scripts. Dies soll den Server davor bewahren, dass ein schlecht oder fehlerhaft programmiertes Script den Arbeitsspeicher “auffrisst”.

Erscheint also in deinem Blog die Fehlermeldung, dann will das WordPress (inklusiver seiner Plugins) mehr Speicher für sich reservieren, als ihm zusteht.
Speicherfresser gibt es viele. So kann es sein, dass du in deinem Blog einfach zu viele (speicherhungrige) Plugins laufen hast, deine Galerie gerade zuviele Thumbnails auf einmal erzeugen will (und dazu je erstmal ein großes Bild laden muss) oder eine Anweisung zuviele Beiträge auf einmal verarbeiten will - soll heißen: Es gibt nicht den Übeltäter, den man beseitigen kann.

Durch testweises Abschalten von Plugins kann man jedoch versuchen, besonders speicherhungrige Plugins ausfindig zu machen und sie ggf. durch ein ähnliches Plugin ersetzen oder auf ihren Einsatz verzichten.

Manchmal scheint es auch vorzukommen, dass die deutsche Sprachdatei den Fehler erzeugt. Dies kannst du prüfen, in dem du in der wp-config.php Die Zeile define ('WPLANG', 'de_DE'); mit der Zeile define ('WPLANG', ''); ersetzt.

Es gibt allerdings Webhoster, bei denen das memory_limit unnötig/ungewöhnlich niedrig gesetzt ist.
Du solltest dich also ruhig mit Verweis auf die bei dir auftretende Fehlermeldung, an deinen Webhoster wenden und fragen, ob es möglich wäre, den Wert des memory limits in der php.ini zu erhöhen.
Im Zweifelsfall bleibt dann nur ein Hosterwechsel übrig.

Bevor du dich allerdings an deinen Hoster wendest, kannst du auch versuchen, den Wert selber zu erhöhen.
Öffne dazu deine wp-config.php und schreibe in den Anfang der Datei (nach <?php) folgenden Code:
@ini_set("memory_limit",'32M');
und speichere die Änderung.

Solltest du bei STRATO hosten, so dürfte dieser Forenbeitrag interessant für dich sein.

<?php printf("MySQL-Version: %s\n", mysql_get_client_info()); ?>

Die Backup-Routine erstellt einen MySQL-Dump der WordPress-Tabellen in der Datenbank, erstellt eine Liste alle WordPress-Dateien und packt alles zusammen in ein Zip-Archiv, das man dann bequem herunterladen kann. Das Upgrade lädt die neuste WordPress-Version runter, entpackt sie, löscht die alten WP-Dateien und installiert die neuen. Anschließend wird das Upgrade-Script ausgeführt. Für all das werden keine besonderen PHP-Erweiterungen etc. benötigt, sondern WP-Manage bringt alle nötigen Werkzeuge selbst mit.

Das Backup und das Upgrade arbeiten unabhängig voneinander.

Für die entsprechende Änderung ist es nötig, an den Template-Dateien des Themes Hand anzulegen.
Diese Dateien mit der Endung .php findest du in deiner Wordpress-Installation in folgendem Ordner:
/wp-content/themes/default_de/

Bearbeiten kannst du die Theme-Dateien im Theme-Editor des Adminmenüs, wofür es notwendig ist, per FTP-Programm den Dateien im Theme-Ordner die Rechte (chmod) 666 zu verleihen.
Alternativ kannst du auch dein Theme offline ändern und dann die veränderten Dateien auf deinen Webspace übertragen, wodurch die alten Dateien überschrieben werden (ggf. Backup anlegen!).
Etwaige Zeilenangaben beziehen sich auf das unmodifizierte Theme in Version DE 1.6.

Zuerst ist die sidebar.php an der Reihe.
In Zeile 55 muss folgender Code entfernt werden:
<?php /* If this is the frontpage */ if ( is_home() || is_page() ) { ?>
Und in Zeile 70 ist dieser Befehl zu entfernen:
<?php } ?>

Nun erscheint auch in den Archivseiten die vollständige Sidebar.
Will man in der Artikelansicht die Sidebar anzeigen (die sonst vollständig fehlt), so muss man die single.php des Themes löschen (es wird dann die index.php des Themes genutzt) oder sich die single.php wie folgt vorknöpfen:
In Zeile 3 ersetzt man
<div id="content" class="widecolumn">
mit diesem Code:
<div id="content" class="narrowcolumn">

Anschließend fügt man in Zeile 65 VOR
<?php get_footer(); ?>
diesen Code hinzu:
<?php get_sidebar(); ?>
so dass die letzten beiden Zeilen so aussehen:
<?php get_sidebar(); ?>
<?php get_footer(); ?>

Zum Schluss ist noch ein Eingriff in die header.php des Themes von Nöten.
Ab Zeile 17 muss der folgende Code:
<?php
// Checks to see whether it needs a sidebar or not
if ( !$withcomments && !is_single() ) {
?>
#page { background: url("<?php bloginfo('stylesheet_directory'); ?>/images/kubrickbg.jpg") repeat-y top; border: none; }
<?php } else { // No sidebar ?>
#page { background: url("<?php bloginfo('stylesheet_directory'); ?>/images/kubrickbgwide.jpg") repeat-y top; border: none; }
<?php } ?>
mit diesem Code ersetzt werden (bis WP 2.1.3):
#page { background: url("<?php bloginfo('stylesheet_directory'); ?>/images/kubrickbg.jpg") repeat-y top; border: none; }
Beziehungsweise diesem Code, wenn man ein neueres Kubrick (ab WordPress 2.2) einsetzt:
#page { background: url("<?php bloginfo('stylesheet_directory'); ?>/images/kubrickbg-ltr.jpg") repeat-y top; border: none; }

Prinzipiell funktioniert die Sache auch bei anderen Themes die ein ähnliches Verhalten zeigen - dort reicht meist der Eingriff in der sidebar.php.

Achtung! Bitte den Code lesen! Erst ausführen, wenn man verstanden hat, was hier passiert.
Backups sind Pflicht. Der Autor übernimmt keine Gewähr für etwaige Fehler.

Wenn man einen virtuellen oder dedizierten Root-Server hat, kann man ein kleines Bash-Script benutzen, um mehrere WordPress-Installationen automatisch zu aktualisieren. Das ganze passiert natürlich auf der Kommandozeile (bash).

#!/bin/bash

# Copyright (c) 2007 Alex Guensche http://www.zirona.com
#
# Permission is hereby granted, free of charge, to any person
# obtaining a copy of this software and associated documentation
# files (the "Software"), to deal in the Software without
# restriction, including without limitation the rights to use,
# copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following
# conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.

# where are working data stored
WORKDIR="/root/wpupgrade/"

# a file with the absolute path to the WordPress installation and the URL
# to the website, both separated only by an equation mark, no other characters
# example lines in that file:
# /var/www/example.org/htdocs/blog/=http://example.org/blog/
# /var/www/localhost/htdocs/=http://127.0.0.1/
WPDIRS_FILE="${WORKDIR}installations"

# derive the affected WP installations from that file
WPDIRS=$(cat ${WPDIRS_FILE})

# WordPress website and path to download package
WORDPRESS="http://www.wordpress.org/"

# download package file name
LATEST="latest.tar.gz"

# script to call in order to finish the upgrade
UPGRADESCRIPT="wp-admin/upgrade.php?step=1"

# get it on
cd ${WORKDIR}

# remove old versions
[ -e "wordpress" ] && rm -r wordpress
[ -e "latest.tar.gz" ] && rm latest.tar.gz

# get latest version, unpack and prepare
wget ${WORDPRESS}${LATEST}
tar -xzf $LATEST
rm -r wordpress/wp-content
rm -r wordpress/wp-config-sample.php
[ -d "languages" ] && cp -r languages wordpress/wp-includes

# upgrade each webhost
for i in ${WPDIRS}; do

	DIR=$(echo $i | cut -f 1 -d “=”)
	WEBSITE=$(echo $i | cut -f 2 -d “=”)
	USER=$(ls -l ${DIR}/wp-config.php | cut -f 3 -d ‘ ‘)
	GROUP=$(ls -l ${DIR}/wp-config.php | cut -f 4 -d ‘ ‘)

	echo “Upgrading WP installation in ${DIR} for host ${WEBSITE}…”
	echo -n “Do you have backups and want to continue? [y/N] ”
	read DOITBABY
	[ "${DOITBABY}" == "y" ] || exit

	cd $DIR;
	echo “Upgrading…” > index.html
	mv wp-content wordpress_content
	mv wp-config.php wordpress_config.php
	rm -r wp-* xmlrpc.php index.php

	cp -r ${WORKDIR}/wordpress/* .
	mv wordpress_content wp-content
	mv wordpress_config.php wp-config.php

	wget “${WEBSITE}${UPGRADESCRIPT}” -O -
	chown -R ${USER}:${GROUP} ${DIR}
	rm index.html

	echo “Upgrade for ${DIR} finished.”
done

Benutzung:

1. Als Root anmelden und nach /root/ wechseln
2. Ein Verzeichnis namens wpupgrade anlegen
3. In das Verzeichnis wpupgrade wechseln und das obige Script dort speichern
4. Das Script mit chmod +x ausführbar machen
5. Empfohlen: Ein Verzeichnis languages mit allen benötigten Sprachdateien anlegen
6. Eine Datei installations anlegen, in das zeilenweise der absolute Verzeichnispfad sowie die Web-URL getrennt durch ein Gleichheitszeichen eingegeben werden (keine Leer- oder sonstige Zeichen!). Bspw.:

/var/www/example.org/htdocs/blog/=http://example.org/blog/
/var/www/localhost/htdocs/=http://127.0.0.1/

Wenn man dann das obige Script ausführt, werden alle in installations aufgeführten WordPress-Installationen automatisch aktualisiert.