Das Ziel ist eine eigene PEAR-Installation auf einem Hosting-Account von domainfactory unter PHP 5.3 inklusive PEAR Web-Frontend um die spätere Verwaltung und Pflege der Installation etwas zu erleichtern.

Da der „go-pear“ Webinstaller (http://pear.php.net/go-pear) mit PHP 5.3 leider nicht mehr funktioniert, müssen wir den Umweg über die Konsole gehen. Das heißt Voraussetzung ist ein Shell-Zugang (SSH).

1. Download go-pear.phar

Statt des alten Web-Installers laden wir uns als erstes den Installer für die Konsole als PHAR-Archiv herunter:

wget http://pear.php.net/go-pear.phar


2. Installationspfade anpassen

Wir starten den Installer auf der Shell mit dem PHP 5.3 Binary

php53 go-pear.phar


und bekommen im ersten Schritt eine Liste der Konfigurationsvariablen und die Möglichkeit diese anzupassen. Über die Ziffernauswahl „1“ passen wir den Wert „1. Installation base ($prefix)“ an und geben dort den Pfad zum Verzeichnis an, in dem PEAR installiert werden soll. Analog passen wir über die Zifferneingabe „2“ und „3“ die Werte „2. Temporary directory for processing“ und „3. Temporary directory for downloads“ an und geben dort den Pfad zu einem temporären Verzeichnis innerhalb unseres Accounts an. Wenn sie noch nicht existieren, legt der Installer diese Verzeichnisse selbst an. Den Wert „11. Name of configuration file“ mit dem Pfad zur Konfigurationsdatei merken oder notieren wir uns für später.

Mit „Return“ bestätigen wir die Konfigurationswerte und starten die Installation. Die folgende Frage „Would you like to alter php.ini “ beantworten wir mit „n“ für „Nein“.

3. pear Shell-Skript anpassen

Im nächsten Schritt wechseln wir in das Verzeichnis der PEAR-Installation und dort in das Unterverzeichnis bin und bearbeiten das Shell-Skript pear indem wir am Beginn von Zeile 28

exec $PHP -C -q $INCARG


durch

exec php53 -C -q $INCARG


ersetzen.

4. PEAR Web-Frontend installieren

Wir installieren nun mit dem angepassten Shell-Skript das PEAR Package für das Web-Frontend

./pear install PEAR_Frontend_Web


Wenn das Package immer noch im BETA-Status sein sollte, muss die konkrete Versionsnummer angegeben werden, z.B. so

./pear install PEAR_Frontend_Web-0.7.5


5. Web-Frontend anpassen und absichern

Wenn die Installation funktioniert hat, wechseln wir in das Verzeichnis share/pear und finden dort die Datei pearfrontendweb.php Diese muss nun ebenfalls noch etwas angepasst werden. Wir bearbeiten die Datei und fügen nach der Zeile:

define('PEAR_Frontend_Web',1);


die folgenden beiden Zeilen ein:

error_reporting(E_ALL &~E_DEPRECATED);
$pear_user_config = '/pfad-zur-konfigurationsdatei/.datei';


Den Wert /pfad-zur-konfigurationsdatei/.datei ersetzen wir durch den Pfad, den wir uns in Schritt 2 „Installationspfade anpassen“ gemerkt oder notiert haben.

Abschließend schützen wir das Verzeichnis share/pear mit einem Passwort bzw. einer .htaccess-Datei vor unberechtigten Zugriffen.

Danach rufen wir das Web-Frontend über die Datei pearfrontendweb.php im Browser auf und können dann die PEAR-Installation wie gewohnt komfortabel pflegen und aktualisieren.

Fertig

Herausfinden, ob MySQL und PHP in der richtigen Version laufen

Wenn die Mindestvoraussetzungen nicht gegeben sind, ist ein automatisches Update auf WordPress 3.2 nicht möglich und man erhält statt eine entsprechende Fehlermeldung. Wenn man selbst herausfinden möchte in welcher Version PHP und MySQL laufen, kann man dazu ein sog. Health Check Plugin installieren und sich dann im WordPress-Backend die entsprechenden Versionsnummer anzeigen lassen. Oder man holt sich diese Infos auf schnellerem Weg über die entsprechende PHP und MySQL-Befehle.

Unter PHP lautet der Befehl

Wenn man diesen Befehl in einer PHP-Datei abspeichert und diese dann über die entsprechende Domain aufruft, erhält man ausführliche Infos zur installierten PHP-Version inklusive der Versionsnummer. Wichtig ist, dass man diese Datei tatsächlich über den Webbrowser aufruft und nicht über die Konsole, da PHP auf der Shell (PHP CLI) nicht unbedingt in der selben Version laufen muss bzw. manchmal für diesen Zweck eine anderer PHP-Interpreter verwendet wird. Wichtig ist außerdem, dass man die phpinfo-Datei wieder löscht wenn man sie nicht mehr benötigt, weil diese ausführlichen Infos auch ein gefundenes Fressen für einen potenziellen Angreifer sein könnten.

Bei MySQL lautet eine Befehl zum Ermitteln der Versions-Nummer:

Wenn hier nicht mindestens eine 5.0 ausgegeben wird, ist der Umzug in eine neue Datenbank notwendig.

PHP 5 aktivieren bzw. auf PHP 5 umschalten

Einige Webhoster bieten eine mehr oder minder bequeme Funktion zum Umschalten der PHP-Version in Ihrem Kundenmenü an. Bei anderen geht das nur über eine angepasste .htaccess -Datei. Dazu ergänzt man in der .htaccess im WordPress-Verzeichnis die Zeilen

MySQL Datenbank umziehen

Wenn die aktuellen WordPress-Installation noch auf einer MySQL 4 – Datenbank läuft, ist ein Umzug der Datenbank nötig. Dazu erstellt zunächst eine Backup z.B. über die Export-Funktion von phpMyAdmin oder über den Shell-Befehl:

Danach erstellt man sich eine neue MySQL 5 – Datenbank und importiert die eben erzeugte Backup-Datei entweder wieder über phpMyAdmin oder mit dem Shell-Befehl

WordPress-Konfiguration anpassen

Danach muss nur noch die WordPress-Konfiguration entsprechend angepasst werden. Hierzu editiert man im WordPress-Verzeichnis die Datei wp-config.php

Fertig! Danach sollt das automatische Update auf WordPress 3.2. möglich sein.
Fragen oder Hinweise bitte in die Kommentare

Am letzten Samstag Nachmittag prasselte es plötzlich Seitenaufrufe im Minutentakt. Zwischen 15 und 17 Uhr insgesamt über 1.000 Besucher von Yahoo, MSN und AltaVista (ja, die gibt es auch noch). Und alle waren auf der Suche nach einer Erklärung für den kurzen Satz “Diese Website kann ihren Computer beschädigen”.

Der Hinweis wurde wegen eines Bugs im besagten Zeitraum bei allen Google-Suchergebnissen angezeigt und hat scheinbar für einige Verwirrung gesorgt.

Ursprünglich war ich der Meinung, dass sich so ein solcher Artikel-Titel eher negativ auf die Klickrate auswirkt – sieht man mal wieder, wie man sich irren kann. Dumm nur, dass ich am Samstag unterwegs war, sonst hätte ich schnell eine paar Layer oder Banner auf die Seite geklatscht und wäre ganz schnell ganz doll reich geworden

Peinlich ist es also und auch ein bißchen bemerkenswert, dass mir das nun passiert ist. Zu meiner Ehrenrettung sei gesagt, dass es keine Werbung für blaue Pillen oder einsame Frauenherzen war, die mich da überrumpelt hat. Nein, “SSL-Zertifikate für 29 Euro” haben mich schwach werden lassen – eine Werbemail für einen Webhoster im perfekten Deutsch und auf den ersten Blick 100% seriös. Nur SpamAssassin war der Meinung, dass da etwas faul sein müsse und sollte dann auch Recht behalten. Nach dem Klick durfte ich nämlich mit runterklappender Kinnlade meinem Virenscanner bei der Arbeit zuschaunen und hatte dann endlich auch mal eine Gelegenheit, die aktuelle Knoppicilin-CD zu testen.

Hätte ich Goggle vorher gefragt, hätte ich gewusst: “Diese Website kann meinen Computer beschädigen”.

Merke also: Das nächste Mal erst denken, im Zweifelsfall nochmal Googlen und erst dann klicken.

Scheinbar wirft das DSL-Geschäft – trotz der achso gemeinen Deregulierung und des achso furchtbaren Konkurrenzdrucks – immernoch genug Geld ab, dass man solche Beträge aus der Portokasse zahlen kann.

Dem ist nicht so. Das Prefetching-Feature existiert bereits seit Firefox 1.2 und es werden auch nur Seiten vorgeladen, wenn der entsprechende Link mit dem Attribut relation=”prefetch” gekennzeichnet ist. Google markiert zum Beispiel bei bestimmten Suchanfragen das erste Ergebnis mit diesem Attribut, wenn es sehr wahrscheinlich ist, dass der User auch auf dieses erste Ergebnis klicken wird – etwa bei so genannten navigational queries.

Google tut das bereits seit 2005 und als Google damals dieses neue Feature ankündigte, gab es auch die erste große Diskussion über das Prefetching und seine möglichen Nachteile und Risiken.

Alter Wein in neuen Schläuchen und nicht der Rede wert, könnte man also meinen. Das Problem dabei ist allerdings: Kaum verweist ein A-Blooger in einem Twitter-Posting auf den Artikel, schon finden sich andere, die den Artikel völlig unreflektiert aufgreifen, den Faden weiterspinnen und am Ende steht die große Story vom Firefox-Datenschutz-Skandal.

Soviel also zum Qualität in Blogs – dabei hätte ein einfacher Blick in die Firefox-FAQ genügt.

Der Teil der Magie von Twitter ist, dass er Sie auf 140 Buchstaben pro den Pfosten begrenzt und Sie zwingt, markige Erklärungen schnell abzugeben.

Klingt komisch, ist aber so

[via irgendein SPAM-Blog]

-