Das Putzlowitsch Test- und SEO-Blog

WordPress beim 1&1 Webhosting (1&1 Homepage)

In den aktuellen 1&1 Webhosting-Paketen „1&1 Homepage Perfect“, „1&1 Homepage Business“ und „1&1 Homepage Business Pro“ hat man neben der Nutzung eines 1&1-Fertigblogs auch die Möglichkeit, ein eigenes WordPress zu installieren. Mindestens eine MySQL-Datenbank und PHP können in diesen Hostingpaketen genutzt werden.

Damit das selbstinstallierten WordPress auch ordentlich funktioniert, sind einige Dinge zu beachten, die ich nachfolgend erkläre. In vielen Fällen verweise ich auf die 1&1-FAQ, da dort einzelne Schritte gut beschrieben sind.

Vorbereitung der Installation – Datenbank

Zunächst muß, falls nicht schon geschehen, eine neue MySQL 5 Datenbank angelegt werden. Wichtig sind hier die Daten, welche später in die Datei wp-config.php eingetragen werden müssen (Beispiele):

define('DB_NAME', 'db123456789');
define('DB_USER', 'dbo123456789')
define('DB_PASSWORD', 'rh473256');
define('DB_HOST', 'db1234.1und1.de');

Auf den ersten Blick sehen DB_NAME und DB_USER gleich aus, sind sie aber nicht. Beim User steht zwischen ‚db‘ und der Zahl ein kleines o (für Owner?). Zudem ist der Datenbank-Host eben nicht ‚localhost‘, sondern der nach dem Anlegen der Datenbank in der Übersicht angezeigte dbxxxx.1und1.de.

Vorbereitung der Installation – WordPress-Installationspaket

Die aktuelle deutsche WordPress-Version kann man sich hier herunterladen. In der Installationsanleitung werden als nächste Schritte das Entpacken der ZIP-Datei, Editieren der wp-config.php und das Hochladen aller Dateien per FTP genannt. Für 1&1 empfehle ich eine leicht veränderten, weil schnelleren Weg, der ohne zusätzliches FTP-Programm auskommt.

Mit dem 1&1-WebspaceExplorer wird die wordpress.zip-Datei, so wie sie ist, hochgeladen. Anschließend wird sie direkt auf dem Server entpackt. Beim Entpacken entsteht ein Verzeichnis wordpress, welches man nach eigenen Wünschen umbenennen kann.

Nun holt man sich per Download aus diesem Verzeichnis die wp-config-sample.php auf den Rechner, bennent sie in wp-config.php um, trägt die Konfigurationsdaten ein und lädt sie mit dem WebspaceExplorer in das WordPress-Verzeichnis auf dem Server.

Umstellung auf PHP 5

(nicht erforderlich bei den neuen Paketen SmartWeb L und Dual-Hosting!)
An erster Stelle ist die Umstellung auf PHP5 zu nennen. Mit PHP4 gibt es besonders im WordPress-Backend Probleme, beispielsweise beim Hochladen von Bildern über die Medienverwaltung. Wie man bei 1&1 erreichen kann, daß alle PHP-Skripte mit PHP 5 ausgeführt werden, ist auch in den 1&1-FAQ beschrieben. Man erstellt eine Datei .htaccess oder ergänzt eine bereits vorhandene Datei mit folgenden Zeilen:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Diese Datei kopiert man per FTP oder mit dem 1&1-WebspaceExplorer in das Wurzelverzeichnis der Webpräsenz

WordPress installieren

Nun kann man die WordPress-Installation wie in der Dokumentation beschrieben starten:

http://wp-example.net/wp-admin/install.php

Maximal nutzbarer PHP-Speicher (memory_limit) 32M

Auch wenn für den PHP-Speicher bei 1und1 40M angezeigt werden, so sind doch nur effektiv 32M nutzbar. Deshalb kann durchaus folgende Fehlermeldung auftreten:

Fatal error: Out of memory (allocated 33030144)
(tried to allocate 4600 bytes) in …

Das ist etwas anderes als:

Fatal error: Allowed memory size of 33554432 bytes exhausted
(tried to allocate 4650 bytes) in …

Der Fehler kann z.B. beim automatischen Update von WordPress vorkommen, obwohl WP intern das Speicherlimit auf 256M hochsetzt und das auch so angezeigt wird. Aber egal wie hoch man den Parameter memory_limit konfiguriert, es gibt bei 1&1 derzeit die Grenze bei 32 MB. Hier hilft nur, während des Updates den Speicherverbrauch zu reduzieren, indem man beispielsweise alle Plugins vorher deaktiviert und danach wieder aktiviert.

Auf eine Supportanfrage bei 1&1 bezüglich der 32M-Speichergrenze bekam ich folgende Antwort:

Effektiv liegt das von Ihnen nutzbare Speicherlimit bei 32 MB, da ein Teil der Ressourcen für die Ausführung von PHP selbst benötigt wird.

Nun ja, wirklich glauben kann ich das nicht.

Nachtrag:
Es gibt jetzt eine 1&1-Hilfe-Seite, die die Skript-Limits für die einzelnen alten und aktuellen Hostingpakete auflistet.
Bei den neuen 1&1-Dual-Tarife ist PHP5 standardmäßig aktiv und es gelten folgende Limits:

Memory Limit Scriptlaufzeit Anzahl Prozesse
Smart Web L 32 MB 10 Sec. 5
Dual Basic 60 MB 20 Sec. 10
Dual Perfect 60 MB 30 Sec. 15
Dual Advanced 80 MB 40 Sec. 15
Dual Unlimited 80 MB 60 Sec. 20

Bei den 1&1-Tarifen (ab Oktober 2013) gelten folgende Limits:

Memory Limit Scriptlaufzeit Anzahl Prozesse
Starter 30 MB 20 Sec. 10
Basic 60 MB 20 Sec. 10
Unlimited 80 MB 40 Sec. 15
Unlimited Plus 128 MB 60 Sec. 16
Unlimited Plus (4GB) 256 MB 60 Sec. 16

Bei den neuen 1&1-Tarifen (ab 2015) gelten folgende Limits:

Memory Limit Scriptlaufzeit Anzahl Prozesse
Starter 30 MB 20 Sec. 10
Unlimited 60 MB 20 Sec. 10
Unlimited Plus 80 MB 40 Sec. 15
Unlimited Pro 128 MB 60 Sec. 16

Hinweis: Das Speicher-Limit gilt für einen gestarteten Prozess. Es steht deshalb als PHP-Speicher weniger zur Verfügung, als hier in der Tabelle steht. Von den 60M im Paket Basic sind effektiv ca 55M als PHP-Speicher nutzbar.

PHP-Speichertest-Skript: Memory-Test PHP-Skript

28 Kommentare »

Warum WordPress bei Strato so langsam ist

Eigentlich müßte ich besser sagen, was ist kein Grund dafür, daß WordPress beim Strato-Shared-Webhosting so langsam ist. Denn an einer vermeintlich schlechten Datenbankanbindung bzw. Datenbankperformance, wie man es oft in Foren oder auf Blogs lesen kann, liegt es nicht.

Datenbankgeschwindigkeit, der Test

Bei WordPress kann man sich alle Datenbankabfragen als SQL-String mit Ausführungszeiten und Aufrufhierarchie in Datenbank-Objekt unter $wpdb->queries speichern lassen. Dazu muß man in der wp-config.php die Konstante ‚SAVEQUERIES‘ mit true definieren:

define( 'SAVEQUERIES', true );

Genau das habe ich für die Startseite von schnurpsel.de gemacht und mir die Daten als PHP-Array in eine Datei geschrieben:

global $wpdb;
ob_start();
var_export( $wpdb->queries );
$out1 = ob_get_contents();
ob_end_clean();
plw123_debugfile_write( $out1 );

Diese Liste mit 51 SQL-Abfragen habe ich in ein einfaches PHP-Skript eingebunden und arbeite die Abfragen hintereinander ab. Es wird zunächst ein Connect zur Datenbank ausgeführt und anschließend folgende Schleife durchlaufen:

foreach( $sql_queries as $query ) {
	$dbd = @mysql_query( $query[0], $dbh );

	while( $row = @mysql_fetch_object( $dbd ) ) {
		$last_result[$num_rows] = $row;
		$num_rows++;
	}
	@mysql_free_result( $dbd );
	$num_queries++;
}

Es werden natürlich nicht nur die SQL-Abfragen ausgeführt, sondern auch die Ergebnisdatensätze mit mysql_fetch_object abgeholt. Nur die Ausgabe der Daten spare ich mir, das hat dann aber sowieso nichts mehr mit der Datenbank zu tun.

Datenbankgeschwindigkeit, das Ergebnis

Mal von ein paar Lastspitzen abgesehen, werden die 51 Abfragen und 539 Ergebnisdatensätze vom Strato MySQL 5 Server in etwa 0,2 Sekunden abgearbeitet. Man kann das hier [test-db-mysql5] live testen.

Ich habe das auch mal mit MySQL 4 probiert, da sind die Werte sogar noch etwas besser und liegen meist bei 0,1 Sekunden oder darunter [test-db-mysql4].

Und als dritten Test habe ich eine externe Datenbank (bei Host-Europe) eingebunden [test-db-ext]. Die 0,5 bis 0,6 Sekunden sind gar nicht mal so schlecht wenn man bedenkt, daß alle Daten über das Internet von Strato (Karlsruhe/Berlin) zu Host-Europe (Köln) und wieder zurück befördert werden müssen.

Mein Fazit

Die schlechte Geschwindigkeit von WordPress (und anderen umfangreichen PHP-Applikationen wie z.B. Joomla) liegt ursächlich nicht an einer schlechten Datenbankperformance, sondern vielmehr an einem nicht besonders schnellen Webserver/PHP.

Was hier nun im einzelnen das Problem ist, kann ich nicht sagen. Ein Geschwindigkeits-Nachteil ist sicher die Tatsache, daß PHP bei Strato als CGI läuft. Das bedeutet, daß für jeden Seitenaufruf ein neuer PHP-Prozeß gestartet werden muß. Konfigurationen, bei denen PHP als Apache-Modul läuft, haben da natürlich einen Geschwindigkeitsvorteil.
Vielleicht muß ja auch jede PHP-Datei bei Strato erst einen Sicherheitcheck durchlaufen, bevor sie geladen wird oder was auch immer.

Ein weiterer Hinweis für die mäßige PHP/Webserver-Performance sind auch die nicht besseren Ladezeiten des Strato Weblog-Basic, denn da ist überhaupt kein MySQL-Datenbankserver im Spiel. Die Daten liegen auf dem Webspace des Users und werden per SQLite eingebunden.

Trotz eigentlich nicht schlechter MySQL Datenbankgeschwindigkeit wird meine Startseite hier nicht schneller als in etwa 3,5 Sekunden geladen, dabei verwende ich fast eine WP-Standardkonfiguration ohne umfangreichen Plugins.

Meine Ausführungen tragen zwar nicht zur Lösung des Geschwindigkeitsproblems bei, aber vielleicht zum Verständnis der Ursache und Problematik an sich.

57 Kommentare »

Das Ende der WordPress-Hacker

Wordpress 2.8 - Einstellungen > VerschiedenesFällt Euch bei dem Bild hier links (anklicken zum Vergrößern) etwas auf? Es zeigt die Einstellungs-Seite für „Verschiedenes“ der neuen WordPress-Version 2.8. Diese kann man sich vorab schon herunterladen und testen. Darauf gestoßen bin ich beim WordPress-Deutschland Blog im Artikel „WordPress 2.8 Feature Freeze„. Und da dachte ich mir so, schau ich mir die neue Vorabversion von WordPress 2.8 doch schon mal an. Auf den ersten Blick und nach dem Durchklicken aller Menüpunkte im Adminbereich (Backend) habe ich so auf die Schnelle keine wesentlichen Änderungen entdecken können.

Nur gaaaanz unten, auf der letzten Einstellungsseite „Verschiedenes“ traf mich fast der Schock. Die Option

[x] Die veraltete my-hacks.php-Datei unterstützen

ist verschwunde. Ein schwerer Schlag ins Kontor, für mich als bekennenden Fan der my-hacks.php-Datei.
Nachtrag: Hier findet man, warum es dazu kam.

Gut, wenn man die Option nicht mehr im Backend einstellen kann heißt das ja noch nicht unbedingt, daß sie nicht mehr vorhanden ist. Und tatsächlich, die Option ‚hack_file‘ gibt es noch immer und die my-hacks.php wird in wp-settings.php auch noch geladen, sofern die Option aktiv ist. Allerdings ist die von mir getestete Version von WordPress 2.8 eine noch recht frühe Version, also nicht Beta oder gar RC. Wenn alles schief läuft, fliegt die Unterstützung für die my-hacks.php doch noch ganz raus, was ich sehr bedauern würde.

Vielleicht überlebt sie aber doch noch im Hintergrund und für diesen Fall habe ich schnell ein kleines Plugin geschrieben, welches die Option wieder auf der Einstellungsseite „Verschiedenes“ zum Leben erweckt läßt :-)

Download: Plugin 123 Hackfile Option 0.12

Weitere Artikel mit Bezug zu diesem:
2 Kommentare »

WordPress 2.7 – Wartungsmodus ohne Plugin

Seit WordPress 2.7.x gibt es die Möglichkeit, WordPress selbst aus dem Backend (Admin-Bereich) heraus zu aktualisieren. Damit während des Aktualisierungsprozesses, der je nach Umfang länger dauern kann und möglicherweise eine Datenbankaktualisierung erforderlich macht, auf Grund inkonsistenter Zustände keine Fehler auftreten, versetzt WP sich selbst in einen Wartungsmodus. Der Nutzer, der das Blog aufruft, bekommt einen kurzen Hinweis angezeigt, daß gerade eine Wartung läuft und die Seite bald wieder verfügbar ist.

Diesen Maintenance-Modus kann man ganz ohne WP-Coreupdate auch manuell aktivieren. Vielleicht sind ja irgendwelche Abeiten an der Datenbank erforderlich oder man möchte das Blog aus anderen Gründen vorübergehend vom Netz nehmen.

So funktionierts

WordPress legt beim Start des Aktualisierungsprozesses einfach im WP-Wurzelverzeichnis eine Datei .maintenance an. In der Datei steht nur eine Zeile PHP-Code drin, in welchem die Variable $upgrading mit der Funtion time() den Startzeitpunktes fest zugewiesen bekommt. Nach erfolgreichem Update wird diese Datei einfach wieder gelöscht. Sollte was schief laufen und die Datei ist nach 10 Minuten ab Start immer noch da, wird der Maintenance-Modus beendet und der Admin erhält im Backend einen entsprechenden Hinweis angezeigt.

Um WordPress direkt in den Wartungsmodus zu versetzen, reicht es also, eine Datei mit folgendem Inhalt in das WordPress-Wurzelverzeichnis zu kopieren:

<?php $upgrading = time(); ?>

Am einfachsten ist es, diese maintenance.txt-Datei per FTP in das WordPress-Wurzelverzeichnis zu kopieren und dort in .maintenance umzubenennen.
Das war es schon, ab sofort gibt die Seite nur noch diese Meldung aus:

Die Seite ist ganz kurz nicht erreichbar. In einer Minute sollte wieder alles klappen.

Auch das Backend ist nicht erreichbar, man kann sich also nicht anmelden noch sonst etwas im Adminbereich machen.
Um den Wartungsmodus zu beenden, muß man einfach die Datei .maintenance löschen oder z.B. wieder in maintenance.txt umbenennen.

Wartungsmodus mit Adminzugriff

Nun möchte man aber vielleicht trotz Wartungsmodus auf den Adminbereich zugreifen. Dafür muß man die .maintenance-Datei dahingehend erweitern, daß überprüft wird, ob Seiten aus dem Adminberich oder die wp-login.php aufgerufen wurden. Ich habe das wie folgte realisiert:

<?php
$url_parts = parse_url( $_SERVER['REQUEST_URI'] );
$path_parts = pathinfo( $url_parts['path'] );
$dir_parts = explode( "/", $path_parts['dirname'] );
$dirname = end($dir_parts);
$filename = $path_parts['basename'];

$is_admin =	'wp-admin'==$dirname || 'wp-admin'==$filename;
$is_login =	'wp-login.php'==$filename;

if( $is_admin || $is_login )
	unset( $upgrading );
else
	$upgrading = time();
?>

Download: maintenance admin

Auch hier einfach die ZIP-Datei entpacken, die enthaltene Datei maintenance_admin.txt per FTP in das WP-Wurzelverzeichnis kopieren und in .maintenance umbenennen.

Nun wird beim Aufruf des Blogs der Wartungshinweis angezeigt, man kann sich aber im Backend anmelden und dort alles machen, was sich innerhalb des Admin-Breiches abspielt. Demzufolge funktionieren z.B. aber die Artikelvorschau und die Themevorschau nicht.

Es ist natürlich möglich, weitere Bedingungen zu prüfen und die Zugriffsmöglichkeiten zu erweitern. Man muß aber beachten, das innerhalb der .maintenance-Datei kein Zugriff auf irgendwelche WordPress-Funktionen besteht und man weitestgehend mit dem auskommen muß, was PHP zur Verfügung stellt. So kann man nicht etwa die Anmeldung mit den Nutzerdaten überprüfen, wohl aber das vorhandensein des Anmelde-Cookies.

Wartungsmeldung anpassen

Wem die schlichte Meldung nicht gefällt, die WordPress im Wartungsmodus ausgibt, kann auch hier selbst Hand anlegen. Dazu prüft WordPress, ob es im wp-content-Verzeichnis eine Datei maintenance.php gibt und wenn ja, wird diese anstelle der Standardmeldung geladen und ausgeführt.

Als Beispiel habe ich den Code aus der wp-settings.php genommen und leicht angepaßt:

<?php
	$retry = 120;
	$protocol = $_SERVER["SERVER_PROTOCOL"];
	if ( 'HTTP/1.1' != $protocol && 'HTTP/1.0' != $protocol )
		$protocol = 'HTTP/1.0';
	header( "$protocol 503 Service Unavailable", true, 503 );
	header( 'Content-Type: text/html; charset=utf-8' );
	header( "Retry-After: $retry" );
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<title>Wartungsarbeiten</title>
</head>
<body>
	<h1>Wartungsarbeiten</h1>
	<p>Die Seite ist für kurze Zeit nicht erreichbar. In ein paar Minute sollte wieder alles klappen.</p>
</body>
</html>

Download: maintenance.zip
Die ZIP-Datei entpacken, die enthaltene Datei maintenance.php gegebenfalls nach eigenen Wünschen anpassen und per FTP in das wp-content-Verzeichnis kopieren.

Wichtig ist das korrekte Setzen vom HTTP-Status im Antwort-Header. Für Wartungsarbeiten oder sonstige, zeitweilige Ausfälle sieht HTTP den Status 503 vor. Zudem sollte auch ein Wert für Retry-After gesetzt werden. Ich habe da jetzt 120 Sekunden genommen, es kann aber auch ein konkreter Zeitpunkt eingetragen werde, zu dem das Blog voraussichtlich wieder verfügbar ist.

Nach dem PHP-Block kann man seiner Phantasie HTML-technisch freien Lauf lassen. Aber auch hier gilt, man hat keinen Zugriff auf irgendwelche WordPress-Funktionen.

Fazit

Seit WordPress 2.7 ist es mit einfachen Hausmitteln ohne Plugin möglich, das Blog in einen Wartungsmodus zu versetzen, um Zugriffe während Arbeiten am System oder der Datenbank zu unterbinden. Optional kann auch der Zugriff auf das Backend (wp-admin) gewähleistet werden.

Vorteil dieser einfachen Lösung ist es, daß sie bereits greift, bevor WP selbst geladen wird und auch bevor irgendwelche Zugriffe auf die Datenbank erfolgen. Kleiner Nachteil ist, daß innerhalb der .maintenance-Datei und der optionalen Meldungsseite maintenance.php kein Zugriff auf WordPressfunktionen besteht.

7 Kommentare »

Mit WordPress per E-Mail bloggen

Mit meinem schon etwas betagten Handy Siemens S 65 kann ich im Web surfen, allerdings nur auf WAP-Seiten. Um mal eben schnell einen kurzen Blogartikel zu verfassen, ist der integrierte Mini-Browser nicht geeignet. Ich kann mit dem Handy aber auch E-Mails verschicken und WordPress kann Artikel per E-Mail einlesen. Für kleine Texte ist das also ein durchaus gangbarer Weg, um die geneigte Leserschaft auch von Unterwegs auf dem Laufenden zu halten.

So funktionierts

Man schickt eine E-Mail an eine konfigurierte E-Mail-Adresse, WordPress fragt diese ab und stellt neue Mails als Artikel im Blog ein. Eigentlich ganz einfach, man sollte jedoch einige Dinge beachten.

Damit nicht jeder einfach per E-Mail auf dem Blog Artikel veröffentlichen kann, sollte man eine neue, geheime E-Mail-Adresse einrichten. Diese kann dort liegen, wo auch das Blog gehostet ist, muß sie aber nicht. In jedem Fall sollte sie einen möglichst „kryptischen“ Namen haben, damit dieser nicht einfach zu erraten ist. Also nicht etwa mailblog@schnurpsel.de, sondern besser SuXiy2zt8k@schnurpsel.

Konfiguration in WordPress

Nun können die Daten für den neu erstellten E-Mail-Account bei den Einstellungen->Schreiben im Bereich „Via E-Mail schreiben“ eingetragen werden:

Neben den E-Mail-Daten kann man hier auch eine Kategorie festlegen, in der die Artikel erscheinen sollen. Man könnte sich ja z.B. eine spezielle Kategorie „Unterwegs“ anlegen, die dann die E-Mail-Artikel aufnimmt und vielleicht gar nicht auf der Hauptseite angezeigt wird.

Artikel per E-Mail bloggen

Jetzt kann es losgehen, einfach eine E-Mail an die konfigurierte E-Mail-Adresse schicken. Das was als Betreff (Subject) in der E-Mail steht, wird zum Titel des Artikels. Der eigentlich Inhalt der Mail wird, ja richtig, zum Inhalt des Artikels im Blog.
Da WordPress aber von sich aus nicht merkt, daß ein neuer Artikel via E-Mail angekommen ist, muß es zum Abrufen der E-Mails aufgefordert werden. Das geht im einfachsten Fall manuell durch Aufrufen der Datei wp-mail.php im WordPress-Wurzelverzeichnis. Bei mir wäre das also z.B. schnurpsel.de/wp-mail.php. Falls neue Artikel vorhanden waren, wird dies etwa wie folgt bestätigt:

Author: 1
Posted title: Ein Beitrag per E-Mail
Mission complete, message 1 deleted.

Wenn nichts angekommen ist, gibt es nur ein einfaches:

There doesn’t seem to be any new mail.

Das Abrufen der E-Mails durch WP kann man auch zeitgesteuert automatisieren, eine umfangreiche englische Beschreibung findet man hier: Post to your blog using email

Neu ab WordPress 2.5

Bis zu WordPress 2.3.x war es egal, woher die Artikel-E-Mail gekommen ist, also welche Absender-Adresse im From: steht, der Artikel erschien unmittelbar auf dem Blog.
Mit WordPress 2.5 ist das nicht mehr so. Von der Absender-E-Mail-Adresse hängt es ab, ob der Artikel direkt veröffentlicht wird (Status: ‚publish‘) oder nur als Enwurf (Status: ‚pending‘) gespeichert wird.

WordPress versucht an Hand der Absender-Adresse einen registrierten Nutzer zu finden, der dieselbe E-Mail-Adresse hat. Wird ein solcher gefunden und dieser ist zudem berechtigt, Artikel zu veröffentlichen, dann erscheint der Artikel mit dem Nutzer als Autor direkt auf dem Blog. Gibt es jedoch keinen passenden Nutzer, landet der Artikel nur im Backend und erscheint in der Artikelliste mit dem Status „Ausstehender Review“.

Damit wurde die Hürde für einen Mißbrauch der E-Mail-To-Blog-Funktion ein klein wenig höher gelegt, den der „Angreifer“ muß nicht nur die kryptische WP-Blog-E-Mail-Adresse kennen, sondern zudem noch die eines befugten Autors.

Fazit

Bloggen von Unterwegs z.B. mit dem Handy ist durchaus möglich. Aus Sicherheitsgrunden sollte man aber einige Punkte beachten. Beim Unstieg auf WordPress 2.5 von einer älteren Version sollte man das geänderte Veröffentlichungsverhalten beachten.

61 Kommentare »