Beachte auch den thematisch ähnlich gelagerten Artikel WordPress trotz Installation in Unterverzeichnis über Hauptverzeichnis aufrufen.

Variante 1

Öffne mit einem Texteditor (Microsoft Word ist keiner!) die Datei wp-config.php, welche sich im Stammverzeichnis deiner WordPress-Installation befindet.
An beliebiger Stelle (jedoch nicht ganz am Anfang oder Ende der Datei) fügst du folgenden Befehl ein:
define('WP_SITEURL', 'http://www.deine-richtige-adresse.xyz');
define('WP_HOME', 'http://www.deine-richtige-adresse.xyz');
Speichere nun die Änderung und lade die Datei hoch. Das sollte es schon gewesen sein.
Im WordPress-Backend in den Allgemeinen Einstellungen sind nun die WordPress-Adresse (URL) / Blog-Adresse (URL) ausgegraut.

Variante 2

Öffne mit einem Texteditor (Microsoft Word ist keiner!) die Datei wp-config.php, welche sich im Stammverzeichnis deiner WordPress-Installation befindet.
An beliebiger Stelle (jedoch nicht ganz am Anfang oder Ende der Datei) fügst du folgenden Befehl ein:
define('RELOCATE', true);
Speichere nun die Änderung und lade die Datei hoch.

Rufe nun im Browser die wp-login.php deines Blogs auf. Diese befindet sich ebenfalls im Stammverzeichnis, also z.B. www.deinblog.de/wp-login.php.
Nach dem die Seite aufgerufen wurde, öffnest du die wieder die wp-config.php und entfernst das define('RELOCATE', true); oder kommentiert es durch vorranstellen von // aus.

Logge dich nun via wp-login.php in deinen Blog ein und ändere noch im Adminmenü unter Optionen / Einstellungen >> Allgemein > WordPress-Adresse (URL) die WordPress-Adresse auf den aktuellen Stand bzw. auf das, was in Blog-Adresse steht.

Variante 3

Für die Bearbeitung der MySQL-Datenbank gibt es eine grafische Oberfläche mit dem Namen phpMyAdmin. Nahezu jeder Webhoster hat diese Oberfläche bereits vorinstalliert.
Falls du nicht weißt, wie du phpMyAdmin aufrufen kannst, so konsultiere deinen Webhoster. Oft ist es über ein Kundenmenü oder per Aufruf über http://www.deinedomain.de/mysqladmin/ erreichbar.

In die Datenbank loggst du dich mit den gleichen Daten (Benutzername und Kennwort) ein, wie du sie auch in der Datei wp-config.php (im Stammverzeichnis von WordPress) eingetragen hast.

In der linken Spalte von phpMyAdmin findest du eine Auflistung der Tabellen, die sich in deiner Datenbank befinden. Die Änderungen müssen in der Tabelle mit dem Namen (sofern das Tabellenprefix nicht geändert wurde) wp_options getätigt werden. Klicke in der linken Spalte also auf wp_options.

Nun sollte sich die rechte Seite der Datenbankoberfläche geändert haben. Ganz oben auf dieser Seite befindet sich die Option Anzeigen bzw. Browse – klicke diesen Menüpunkt an, um den Inhalt der Tabelle anzuzeigen.

Über das Bleistiftsymbol in der zweiten Spalte der Tabellenanzeige kannst du nun all die Datensätze ändern, in denen die URL zum Blog gespeichert ist. Üblicherweise sind es die Datensätze mit dem option_name siteurl und home.
Beachte, dass die Tabelle mehrere Seiten hat, so dass die zu ändernden Werte eventuell nicht auf der ersten Seite zu sehen sind.

Datensatz gefunden und Bleistiftgrafik angeklickt? Dann kannst du nun im Feld option_value die neue URL zum Blog eintragen und per klick auf den Button OK die Änderung speichern.

In dieser Hinsicht auch lesenswert (falls z.B. die Bilderpfade in Artikeln nicht mehr stimmen), ist der Artikel Suchen und Ersetzen in MySQL-Datenbanken von Jowra.
Noch komfortabler dürfte das Suchen und Ersetzen-Plugin von bueltge.de sein.

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.

Achtung: Verwende diese Methode nicht, wenn du das Multi-Site-Feature bzw. Blog-Netzwerk aktiviert hast!

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.

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.

Der Vorteil besteht darin, dass man auch ohne grundlegende HTML-Kenntnisse, Beiträge formatieren und die gemachten Änderungen sofort sehen kann.

Allerdings ist die Verwendung des WYSIWYG-Editors nicht immer ratsam, da er (über den Button HTML) eingefügten Code ganz gerne mal (partitiell) zerstört.
Auch übermäßiges Hinzufügen und Entfernen von Formatierungen oder Copy&Paste aus anderen Anwendungen (insbesondere Office-Software wie Word) kann zu fehlerhaftem Code führen, was unter Umständen sogar Auswirkungen auf das Design hat (Sidebar verschoben, Schrift auf Seite vergrößert etc.).

In solchen Fällen sollte man TinyMCE daher deaktivieren.

Die Einstellung Adminbereich >> Einstellungen >> Schreiben > Benutzer sollen den WYSIWYG-Editor als Standard benutzen bezieht sich nur auf Benutzer, die in Zukunft im Blog registriert werden, betrifft also nicht schon existierende Benutzer und damit das eigene Profil.

Will man den Editor also für sich selber deaktivieren, muss man dies über die Einstellung Adminbereich >> Benutzer >> Dein Profil > Benutze den WYSIWYG-Editor beim Schreiben erledigen und dort die Checkbox deaktivieren.

Ansonsten kann es auch noch hilfreich sein, zusätzlich Adminbereich >> Einstellungen >> Schreiben > WordPress soll falsch verschachteltes XHTML automatisch korrigieren. zu deaktivieren.

Der nun benutzte, weniger funktional erscheinende Editor, bietet trotzdem alle Formatierungsmöglichkeiten, wofür aber Kenntnisse in HTML sehr empfehlenswert sind.

Nichtdestotrotz bietet auch der Normaleditor diverse Quicktags zum Formatieren:

• b macht den markierten Text fett
• i schreibt markierten Text kursiv
• link verlinkt markierten Text mit der einzugebenden URL
• b-quote stellt markierten Text als Zitat dar
• del markiert den Text als ungültig (je nach verwendetem Theme/Style wird die Passage dann durchgestrichen dargestellt)
• ins zeigt eine nachträgliche Einfügung an (ob dies später ersichtlich ist, hängt wieder vom verwendeten Theme ab)
• img zeigt ein Bild mit der einzugebenden Adresse an
• ul kennzeichnet Anfang (<ul>) und Ende (</ul>) einer Auflistung
• ol kennzeichnet Anfang und Ende einer nummertierten Liste
• li Sind Listenpunkte innerhalb einer Liste
• code kennzeichnet Code als diesen, maskiert HTML-Code jedoch nicht (wird ausgeführt)
• more fügt den “weiterlesen”-Link zum Artikel hinzu