• Erstelle mit einem Texteditor (Notepad, Editor etc. aber nicht Wordpad oder Microsoft Word) eine Textdatei die folgenden Text enthält:
  AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
• Speichere die Datei unter einem beliebigen Namen
• Lade diese Datei per FTP in das Stammverzeichnis deiner WordPress-Installation (also z.B. in den Ordner wordpress)
• Benenne diese Datei auf dem Server in .htaccess um. Der Punkt am Anfang ist korrekt und wichtig, die Datei darf keine Dateiendung haben. (Näheres zur Datei .htaccess erfährst du im Forenlexikon)

Dein WordPress wird nun in PHP5 ausgeführt und sollte sich dann installieren oder ausführen lassen.

Wenn du merkst, dass WordPress wegen des Fehlers zuvor nur unvollständig installiert wurde oder rumspinnt, dann musst du WordPress erneut installieren. Dazu solltest du vorher die bereits von WordPress angelegten Datenbanktabellen in der Datenbank löschen. Dies geht z.B. mit der Datenbankadministrationssoftware phpMyAdmin die vorinstalliert ist. Wie du in phpMyAdmin Tabellen löschst, siehst du in folgendem Bild (Anklicken für volle Größe):

1. Im ersten Fall liegen die Daten sehr wahrscheinlich in der Zeichenkodierung (nicht Zeichensatz) ISO-8859-1 bzw. Windows-1252 in der Datenbank, oder das Theme enthält derart kodierte Zeichen. Da muß man genau hinsehen, aus welcher Quelle die Zeichen kommen.
   Wenn es die Datenbank ist, dann sollte sie auf UTF-8 umgestellt werden.
   Wenn es das Theme ist, dann kann man einfach die falsch kodierte Datei öffnen und als UTF-8 ohne BOM abspeichern (siehe letzter Absatz in folgendem FAQ-Artikel).
   Auf keinen Fall sollte man im Backend ISO-8859-1 einstellen! Dann kann man viele Zeichen (€, …, ‰) nicht mehr unmaskiert ausgeben. Langfristig hat man ohne UTF-8 deutlich mehr Probleme als mit. Nicht zuletzt weil der Newsfeed (RSS und ATOM) ja als XML ausgegeben wird und XML-Leser zwar UTF-8 und UTF-16 können müssen, nicht aber ISO-8859-1.

2. Wenn man hingegen ä sieht, also zwei Zeichen, wo nur eines erwartet wird, dann wird vermutlich bei der Ausgabe ISO-8859-1 behauptet, obwohl die Daten in UTF-8 vorliegen. Zur Kontrolle sehe man unter Einstellungen/Ausgabe nach, ob da wirklich UTF-8 unter Zeichenkodierung für Seiten und Feeds eingetragen ist.
   Außerdem kann man die Seite mit dem Websniffer prüfen lassen. Dort bekommt man eine Übersicht der HTTP-Header; einer sollte so aussehen:
   Content-Type: text/html; charset=UTF-8
   Steht in »charset« etwas anderes, obwohl im Backend UTF-8 eingestellt wurde, muß irgendwo im Theme oder in einem Plugin diese Zeile stehen:
   header('Content-Type: text/html');
   oder
   header('Content-Type: text/html;charset=ISO-8859-1');
   Die muß man dann löschen.

Wir danken toscho für die Überarbeitung dieses Artikels.

Zunächst sieh Dir die Fehlermeldung genau an um die Stelle zu finden, an der der Fehler ausgelöst wird:

Cannot modify header information – headers already sent by (output started at /home/www/***/html/wp-config.php:1) in /home/www/***/html/wp-login.php on line 202

Im Beispiel tritt der Fehler in der wp-config.php auf, und zwar in Zeile 1. Hier solltest du nachsehen, ob in Zeile 1 tatsächlich <?php steht, und sich davor keine Leerzeichen, Zeilenumbrüche oder andere Zeichen befinden. Falls du dort solche Zeichen findest, dann lösche diese bitte.

Falls der Fehler in der ersten Zeile auftritt, dort aber keine Zeichen zu finden sind, dann ist die Datei möglicherweise UTF-8-codiert abgepeichert und enthält ein sogenanntes “Byte Order Mark”, abgekürzt “BOM”. Dieses Steuerzeichen für UTF-8-Dateien erkennt PHP fälschlich als auszugebendes Zeichen, so dass es dann zur genannten Fehlermeldung kommt. Suche in diesem Fall in deinem Editor nach einer Möglichkeit, die Datei als “UTF-8 ohne BOM” oder “ANSI” (nur wenn die Datei keine Umlaute enthält, wie z.B. die wp-config.php) abzuspeichern. Meist findet man diese Option im “Speichern unter…”-Dialog des Editors.

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.

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. Alternativ kannst du auch
define('WP_MEMORY_LIMIT', '32M');
schreiben. Eventuell sollte auch ein höherer Wert wie 40 oder 64 MB probiert werden (soweit vom Hoster unterstützt).

Wir haben übrigens festgestellt dass je nach Hoster bzw. Serverkonfiguration WordPress unterschiedlich viel PHP-Arbeitsspeicher verbraucht. Die Unterschiede scheinen teilweise dramatisch zu sein – bei manchen Benutzern verbraucht ein WordPress 2.8 samt deutscher Sprachdatei und einer Vielzahl von Plugins nicht einmal 20 MB (ein “nacktes” WordPress gerade mal 10 MB) und bei anderen ist schon nach einer WordPress 2.8 Installation mit Sprachdatei und wenigen aktivierten Plugins die Grenze von 32 MB schnell überschritten. Teilweise scheint es auch einzelne Plugins zu geben, die sehr viel Speicher verbrauchen.
Vor allem 64-Bit-Systeme verbrauchen bei identischer Installation deutlich mehr Speicher – In diesem Artikel findest du näheres dazu.

Des weiteren kann man in WP 2.8 den Verbrauch der Sprachdatei durch eine gepachte mo.php verringern.

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

Aber du kannst den Safe Mode umgehen. Hierzu benötigst du nur dein FTP-Programm. Mit Hilfe des FTP-Programm löscht du erst die Ordner, in die du hochladen möchtest und es nicht funktioniert. Dann legst du die Ordner neu an und gibst diesen die Rechte 777. Jetzt sollte es gehen.

Alternativ kannst du in den Einstellungen (Unterpunkt Verschiedenes) auch die Organisation in jahres- und monatsbasierten Ordnern deaktivieren.

Hinweis:
Die Datei ist derzeit leider nicht beschreibbar.
Das ist auch der Grund, warum es dir nicht möglich ist, deine Veränderungen abzuspeichern.
Diesen Zustand kannst du allerdings ändern, indem du der Datei andere Rechte zuweist…

Dass eine Datei verschiedene Rechte (Lesen – Schreiben – Ausführen) besitzt, ist eine Eigenart in der Unix-Welt. Und da Webserver für gewöhnlich auf Linux/Unix-Derivaten laufen, müssen diese Dateirechte für bestimmte Zwecke mit chmod geändert werden.

Praktisch jedes FTP-Programm, also das Programm, mit dem du die Dateien auf deinen Webspace lädst, hat auch die Möglichkeit, die Datei- und Ordnerrechte zu ändern. Meist befindet sich diese im Kontextmenü und ist mit chmod, permissions oder attributes benannnt.

Logge dich mit deinem FTP-Programm auf deinen Webspace ein und markiere (z.B. per Klick) die Ordner oder Dateien, deren Rechte du ändern willst. Im Falle des Theme-Editors wären es z.B. die Dateien im Ordner /wp-content/themes/name_deines_themes, oder für den Upload von Dateien der von dir festgelegte Upload-Ordner.

Mit Rechtsklick auf diese Dateien siehst du für gewöhnlich (das kann sich je nach Programm unterscheiden) das Kontextmenü und musst dort chmod auswählen. Bei anderen Programmen gibt es evtl. an anderen Stellen Buttons oder der Aufruf muss über das Menü erfolgen.

In dem nun erscheinenden Fenster musst du für alle drei Gruppen (Owner/Besitzer – Group/Gruppe – Public/Öffentlich) die Rechte jeweils auf Read/Lesen – Write/Schreiben – Execute/Ausführen ändern. Manche Programme akzeptieren/verlangen auch die Eingabe eines Zahlencodes – er lautet 666.
Willst du einen Ordner beschreibbar machen, so muss der Code 777 lauten (überall Ausführen, Lesen, Schreiben erlaubt).

Nachdem du diese Schritte abgeschlossen hast, sollte die Fehlermeldung der Vergangenheit angehören.

Deaktiviere alle Plugins, sollte der Fehler dann nicht mehr auftauchen, ist ein Plugin entweder fehlerhaft oder zu anderen Plugins inkompatibel.

Vielleicht hast Du dein Theme bearbeitet und es hat sich ein Fehler eingeschlichen. Aktiviere das Standardtheme und prüfe ob der Fehler immer noch erscheint. Manchmal hilft es auch, das Standardtheme kurz zu aktivieren und danach sofort wieder auf Dein Theme zurückzuwechseln.

Überprüfe, ob sich im zuletzt bearbeiteten Beitrag eventuell ein Fehler eingeschlichen hat, vielleicht hast Du vergessen einen Befehl abzuschliessen.

Eventuell hat auch Dein Provider etwas an den Servereinstellungen geändert. In der Regel wirst Du von deinem Anbieter darüber informiert, schaue doch mal in Dein Postfach.

Tritt der Fehler direkt nach dem Hochladen per FTP auf, dann überprüfe ob die Dateien im richtigen Modus hochgeladen wurden. Stelle sicher, dass “Automatisch” eingestellt ist, und in den Einstellungen des FTP-Programms .php-, .html-, .js- und .css-Dateien im Textmodus und Grafiken im Binärmodus hochgeladen werden. Näheres dazu findest du in der Hilfefunktion deines FTP-Programmes.

Vielleicht will dir auch Dein kleiner Bruder einen Streich spielen und hat hinter Deinem Rücken etwas an Deinem Blog geändert. Überprüfe Deinen kleinen Bruder. Wenn Du sicher bist, dass er unschuldig ist wende dich ans Forum.

Wenn Du alles probiert hast und der Fehler immer noch auftritt, wende Dich an das Forum. Benutze zuerst die Suchfunktion des Forums, vielleicht wurde das Problem schonmal gelöst. Bitte poste in jedem Fall eine möglichst ausführliche Fehlerbeschreibung inklusive der auftretenden Fehlermeldung.

»Es erscheint keine Fehlermeldung sondern nur eine weiße Seite!«

Erscheint nur eine weiße Seite statt einer Fehlermeldung, dann schau im error.log deines Webpaketes nach. Viele Hoster stellen ihre Webs so ein, dass Fehlermeldungen nicht öffentlich angezeigt werden, sondern statt dessen in einer nicht-öffentlichen Fehlerdatei gesammelt werden. Diese »error.log«-Datei erreichst du entweder über die Domain-Verwaltungsoberfläche oder im »/log«-Verzeichnis, welches du z.B. per FTP erreichst (eventuell musst du hier mit »..« in das Stammverzeichnis deines Webs wechseln, bis du das Log-Verzeichnis siehst).

Im error.log findest du dann ganz unten den zuletzt aufgetretenen Fehler, z.B. so etwas:

[03-Feb-2007 01:11:14] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 10100001 bytes) in /home/www/…/httpdocs/…php on line 974

Bitte suche erst in der FAQ und dann im Forum, ob diese Fehlermeldung bekannt ist. Meistens gibt es bereits ähnliche Probleme mit vielen Lösungsansätzen. Wenn du keine Ergebnisse gefunden hast, eröffne einen neues Thema. Beschreibe wann und wo der Fehler auftritt, welche Fehlermeldung erscheint und gib einen Link zum Problemblog an. Je detaillierter Du das Problem beschreibst, desto besser kann man Dir helfen.

Einen detaillierten Beitrag zum PHP-Error-Reporting hat Johannes in seinem Blog erstellt. Zusätzlich stellt er ein kleines Script zur Verfügung, mit dem Du ermitteln kannst, welche Fehler von PHP mitgeschnitten werden, und wo es diese Meldungen auf deinem Server ablegt.