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.

Außerdem kann der (optionale) Auszug verwendet werden. Dieser wird in der Artikel-Bearbeitung unter dem eigentlichen Editor-Textfeld eingetragen.

Manchmal ist es aber sinnvoller anstelle des Tags the_excerpt() das Tag the_content() zu nutzen.
the_content() zeigt z. B. die Links, Bilder und Formatierungen vom Beitrag an. Außerdem lässt sich individuell mit dem <!–more–>-Tag bestimmen, was genau angezeigt werden soll. Der more-Tag, welchen man in der Artikel-Bearbeitung setzen kann, splittet den Beitrag / die Seite in zwei Teile. Auf der Startseite bzw. in Archiven wird dann nur der Teil vor dem more-Tag angezeigt, allerdings mit allen Links, Bildern und Formatierungen.

Für die entsprechende Änderung ist es nötig, an den Template-Dateien deines Themes Hand anzulegen.
Diese Dateien mit der Endung .php findest du in deiner Wordpress-Installation in folgendem Ordner:
/wp-content/themes/name_des_themes/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!).

Welche Dateien geändert werden müssen, hängt vom jeweiligen Theme ab.
Sind schon in der normalen Blogansicht keine Links, Formatierungen und Bilder zu sehen, ändere die Datei index.php, oder falls du den Theme-Editor benutzt, Haupt Index Template.
Ist hingegen die Archivansicht betroffen, so wäre die Datei archive.php zuständig bzw. Archiv zuständig. Im Zweifelsfall einfach alle Dateien des Themes durchsuchen und ändern.

Lasse dein Auge oder die Suchfunktion deines Texteditors in der jeweiligen Datei nach dem Template-Tag the_excerpt suchen. Je nach Theme kommt sie leicht unterschiedlich daher. So könnte er zum Beispiel aussehen:
<?php the_excerpt(); ?>
Dieser Codeschnipsel muss mit dem the_content ersetzt werden. Anstelle des the_excerpt könnte an dieser Stelle dann folgender Code stehen:
<?php the_content('weiter...'); ?>

Benutzt man die Option des more-Tags nicht, so reicht im Normalfall auch einfach der Aufruf ohne den ggf. auftauchenden weiter-Link:
<?php the_content(); ?>

Zu einem kompletten WordPress Backup gehören zwei Teile: Die MySQL-Datenbank und Dateien auf dem Webserver. Das heisst, alle Dateien müssen gesichert werden und es muss ein Backup der Datenbank angelegt werden. Fehlt eines von Beidem ist das Backup nicht vollständig! Viele vergessen auch ein Backup der Datenbank zu machen, dabei ist diese eigentlich der wichtigste Teil, da in Ihr alle Artikel, Seiten, Kommentare etc. – also die eigentlichen Inhalte – gespeichert werden.

Genug der Theorie, jetzt geht’s an die Praxis:

Backup der Dateien:
Mache (mit einem FTP-Client deiner Wahl) ein Backup von allen Dateien, die sich auf deinem FTP-Server bzw. Webspace im WordPress Verzeichnis befinden, in dem du diese Dateien auf deine Computer überträgst. Der Screenshot soll es verdeutlichen. Befinden sich noch andere Dateien oder Ordner im Verzeichnis welche nicht origniär von WordPress stammen, so solltest du sie mitsichern, da sie z.B. von Plugins erstellt wurden.

Backup der Datenbank:
Vor dem Backup solltest du SPAM-Kommentare oder Daten von Statistik Plugins löschen, da sie die Datenbank nur unnötig aufblähen aber für ein Backup vermutlich nicht relevant sind.

Das Backup der Datenbank mittels phpMyAdmin ist in unser Doku in diesem Artikel beschrieben.

Etwas einfacher ist es, das Plugin WP-DB-Backup zu nutzen, da es fast auf Knopfdruck funktioniert und bei Bedarf auch automatische Backups nach Zeitplänen macht. Nach der Installation des Plugins muss ggf. noch der Ordner wp-content besschreibbar gemacht werden. Das Backup kann dann im Adminmenü unter dem Punkt “Werkzeuge” > “Backup” gestartet werden.

Sind diese beiden Punkte abgehakt ist dein Backup fertig. Hoffentlich wirst du es nie brauchen müssen :)

Eventuell fragt sich jetzt jemand:
Warum nicht die Funktion Daten exportieren nutzen?
Der Grund ist, dass diese Funktion nur die Artikel, Seiten, Kommentare, benutzerdefinierten Felder, Kategorien und Tags sichert. Weitere allgemeine Einstellungen (auch von Plugins) oder die Dateien selber werden nicht gesichert. Bei einem zerschossenen oder gelöschten Blog, insbesondere wenn WordPress garnicht mehr aufrufbar ist, ist dieser Export unbrauchbar.

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.

Aktiviere dafür beim Schreiben oder Editieren des Artikels im Modul Publizieren im Punkt Sichtbarkeit die Option Diesen Artikel auf der Startseite halten. Danach musst du die Änderung natürlich noch speichern.

Die Ursache: du verwendest Microsoft Word um deine Artikel lokal zu erstellen, und kopierst den Text dann in den visuellen Editor.

Was dabei schief geht: Word (bzw. auch andere Office-Produkte aus dem Hause Microsoft) kopieren Meta-Informationen in Form von XML-Code mit in die Zwischenablage. Dieser landet dann – unsichtbar, weil als HTML-Kommentar “getarnt” – ebenfalls im Editor und somit im Blog. Eigentlich wäre das kein großes Problem, da der HTML-Code des Artikels trotzdem fehlerfrei ist. Der Internet Explorer interpretiert diesen Code allerdings, kommt dabei ins Stolpern und bricht dann die Verarbeitung der Seite ab.

Alle anderen Browser ignorieren diese Codes aber, die Verarbeitung der Seite ist nicht beeinträchtigt. Auch ein HTML-Validator wird dieses Problem im Normalfall nicht aufdecken. Du kannst allerdings das Problem schnell erkennen, wenn du in den Browserquelltext deiner Seite schaust. Dort solltest du Codeschnipsel wie diesen in deinen Artikeln finden:

<p><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning />
<w:ValidateAgainstSchemas />
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:Compatibility>
<w:BreakWrappedTables />
<w:SnapToGridInCell />
<w:WrapTextWithPunct />
<w:UseAsianBreakRules />
<w:DontGrowAutofit />
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="156">
</w:LatentStyles>
</xml><![endif]--></p>
<p><!--[if gte mso 10]><br />
<mce:style><!
 /* Style Definitions */
table.MsoNormalTable
 {mso-style-name:"Normale Tabelle";
 mso-tstyle-rowband-size:0;
 mso-tstyle-colband-size:0;
 mso-style-noshow:yes;
 mso-style-parent:"";
 mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
 mso-para-margin:0cm;
 mso-para-margin-bottom:.0001pt;
 mso-pagination:widow-orphan;
 font-size:10.0pt;
 font-family:"Times New Roman";
 mso-ansi-language:#0400;
 mso-fareast-language:#0400;
 mso-bidi-language:#0400;} --></p>
<p><!--[endif]-->

Diese Codes siehst du auch in der HTML-Ansicht des WordPress-Editors. Dort kannst du ihn auch bequem wieder aus den Artikeln löschen.

Um das Problem in Zukunft zu vermeiden hast du mehrere Optionen:

• Schreibe deine Artikel direkt im WordPress-Editor und nicht in Word
• Verwende zum Vorschreiben ein anderes Office-Programm
• Verwende zum Einfügen des in Word geschriebenen Textes nicht Strg+V, sondern benutze den “aus Word einfügen”-Button in der erweiterten Werkzeugleiste des WordPress-Editors

Aus verschiedenen Gründen möchte man aber dennoch Artikel aus einer oder mehreren Kategorien auf einer statischen Seite auflisten. Dazu erstellst Du dir zunächst ein Template für die statische Seite. Wie das geht ist hier in der Doku erklärt. Als Vorlage für Dein neues Seitentemplate kannst du im Normalfall die index.php deines Themes her nehmen.

In deinem neuen Seitentemplate suchst du jetzt die Zeile, in der der Loop gestartet wird. Diese sieht meist etwa so aus:

<?php while ( have_posts() ) : the_post(); ?>

Vor dieser Zeile fügst Du nun folgenden Befehl ein:

<?php query_posts('category_name=Allgemein'); ?>

Durch diese Zeile wird die Artikelschleife beeinflusst, und gibt jetzt die Artikel der Kategorie “Allgemein” aus. Das war’s schon! Jetzt musst du nur noch eine neue statische Seite anlegen, ihr einen Titel geben und dein Seitentemplate zuweisen. Fertig.

Wenn du mehr über das Voodoo-Werkzeug query_posts() wissen möchtest, dann schau doch einfach mal in die Doku (dt.) und den Codex (engl.).

Geht das nicht etwas dynamischer?

Natürlich ist das ganze noch ziemlich statisch. Es gibt nun verschiedene Möglichkeiten:

• für jede Kategorie ein eigenes Seitentemplate anlegen
• den Namen oder die ID an die Seite übergeben, zum Beispiel über ein benutzerdefiniertes Feld
• gleichnamige Kategorien und statische Seiten anlegen

Alle diese Methoden haben ihre Vor- und Nachteile. Beispielhaft sei im folgenden die Methode 2 näher erklärt. Als erstes wird dazu eine statische Seite angelegt, die die Kategorie auflisten soll. Diese Seite erhält zusätzlich ein benutzerdefiniertes Feld mit dem Schlüssel “category_name” und dem Namen der auszugebenen Kategorie als Wert, z.B. “Allgemein”.

Das Template erhält nun zusätzlich einen Abruf dieses benutzerdefinierten Feldes und dessen Übergabe an query_posts():

<?php $listCategory = get_post_meta($post->ID, 'category_name', true); ?>

In der Variablen $listCategory befindet sich jetzt der Name Deiner Kategorie, im Beispiel also “Allgemein”. Diesen kannst Du jetzt an query_posts() übergeben:

<?php query_posts( 'category_name=' . $listCategory ); ?>

Jetzt kannst Du weitere Seiten anlegen, die andere Kategorienamen per benutzerdefiniertem Feld übergeben.

Die Variante “gleiche Namen für Seite und Kategorie” funktioniert ähnlich. Hier liest du den Namen der statischen Seite aus, z.B. mittels get_the_title(), und übergibst diesen dann in gleicher Weise an query_posts(). Das Ganze funktioniert in ähnlicher Weise natürlich auch mit Tags.

Eine weitere Variante gibts bei Monika.

Wenn Du weitere Fragen dazu hast, dann stell diese bitte im Forum. Benutze bitte vor dem Posten die Forensuche, da es schon einige Threads zu dieser Frage gibt.

• Hast du vor dem Upgrade alle Plugins deaktiviert? Einige Plugins können in neueren WP-Versionen Probleme machen, und u.a. das Einloggen verhindern.
  Du kannst die Plugins notfalls per FTP deaktivieren. Benenne dazu einfach das Plugin-Verzeichnis um, z.B. in “__plugins”. Wenn der Login geklappt hat, dann machst du das Umbenennen wieder rückgängig.
• Logge dich einmal explizit aus. Rufe dazu in deinem Blog folgende URL auf: /wp-login.php?loggedout=true
• Hast du beim Upgrade die Secret Keys für die Cookieverschlüsselung mit einer beliebig langen, möglichst schwer zu erratenen Zeichenkette in die wp-config.php eingetragen?
• WordPress setzt die Cookies nur für das Adminverzeichnis. Manche Browser (z.B. Opera) haben damit ein Problem. Für diese Browser füge folgende Zeile in der wp-config.php ein:

  define('ADMIN_COOKIE_PATH', '/');

• Lösche die Cookies in deinem Browser.
• Versuche dich mit einem anderen Browser einzuloggen.

Funktioniert der Login dann noch immer nicht, dann könnte u.U. auch ein Programm auf deinem PC verantwortlich sein, z.B. eine Personal Firewall. Wende dich dann mit deiner Problembeschreibung ans Forum, z.B. in diesem Sammelthread zum Thema.

( ) Deine letzten Artikel
(•) Eine statische Seite (unten auswählen)
     • Startseite: [Start    [▼]]
     • Artikelseite: [Blog    [▼]]

Das ist weitestgehend selbsterklärend. Mit “Eine statische Seite” aktiviert man die statische Startseite. Bei “Startseite” wählt man, ja genau, die künftige Startseite aus den bisher erstellten statischen Seiten aus.

Nun möchte man aber bestimmt den Lesern auch die Blogartikel in der gewohnten Form präsentieren, und nicht nur auf das Archiv, den Kalender oder die Kategorien verweisen. Genau hier kommt die zweite Auswahlmöglichkeit “Artikelseite” ins Spiel. Am besten man erstellt sich eine weitere Seite und gibt ihr z.B. den Titel “Blog”. Diese kann man nun für “Artikelseite” auswählen und fortan wird das Blog wie sonst auf der Startseite auf eben dieser Seite angezeigt, inklusive der Möglichkeit, seitenweise vor- und zurückzublättern.

Danke an Ingo für den Artikel!

<?php
function my_widget_hello_world($args) {
extract($args);
echo $before_widget;
echo $before_title . __('Hello World') . $after_title;
echo 'Hallo';
echo $after_widget;
}
// register the custom widgets
$my_class = array('classname' => 'widget_hello_world');
wp_register_sidebar_widget('hello_world', __('Hello World'), 'my_widget_hello_world', $my_class);
?>

So sieht es für das erste Widget aus. Statt “Hallo” kannst du da natürlich ausgeben, wonach dir gerade ist, incl. WP-Funktionen wie wp_list_categories() oder so.

Wenn du mehr als eines registrierst, brauchst du das Array nicht immer neu zu bauen:
$my_class['classname'] = 'widget_bonjour';

Danke an Johannes für den Code!

Seit WordPress Version 2.3 sind Widgets Bestandteil von WordPress, in älteren Versionen musste ein Plugin installiert werden, um Widgets nutzen zu können.

Viele Themes besitzen eine oder 2 widget-fähige Sidebars, oder gar mehrere Bereiche, an denen du Widgets einsetzen kannst. Wenn dein Theme keine Widget-Bereiche hat, dann kannst du die Sidebar recht einfach widgetfähig machen.

Beachte: Wenn du das 1. Widget auf deine Sidebars ziehst, dann verschwinden die standardmäßig in der Sidebar vorhandenen Inhalte. Im Normalfall kannst du nur entweder statische Inhalte in der Sidebar haben, oder Widgets.

Wie finde ich heraus, ob mein Blog Widgets benutzt?

Seit WordPress Version 2.5 wird im Dashboard angezeigt, ob deine Sidebar Widgets enthält:

Dein aktuelles Theme ist Kubrick DE-Edition mit 0 Widgets. Du nutzt WordPress 2.6 DE-Edition.

In WordPress 2.3 findest du im Adminbereich im Menü “Themes” unter dem Punkt “Widgets” deine widgetfähigen Sidebars und die darauf liegenden Widgets.

Wie kann ich Widgets umsortieren oder konfigurieren?

Die Widgets-Einstellungen findest du im Adminbereich im Menü “Themes” (in neueren WP-Versionen auch “Design”) im Untermenü Widgets. Hier kannst du Widgets per “Ziehen und Ablegen” auf deine Sidebar bringen oder diese umsortieren.

Bei vielen Widgets kannst du die Ausgabe mit verschiedenen Einstellungen anpassen. Wenn du das Widget auf deine Sidebar gezogen hast, dann kannst du es mit einem Link auf den Pfeil rechts aufklappen und die Einstellungsmöglichkeiten erscheinen.

Viele weitere Informationen über Widgets findest du auf der Widgets-Entwicklerseite (englisch) bei
Automattic sowie im WordPress Codex.

.entry ul li:before, #sidebar ul ul li:before {
content: "0BB 020";
}

Diesen Eintrag löschst du einfach.

(In der Version 1.6 des Themes findes du den Eintrag in Zeile 406 der style.css)

Zunächst muss folgender Code in die functions.php des Themes kopiert werden:

<?php
if ( function_exists('register_sidebar') )
register_sidebar();
?>


Dies ist der mindestens benötigte Code um die Sidebar widgetfähig zu machen. Die minimalistische sidebar.php dazu sieht so aus:

<ul>
<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : endif; ?>
</ul>


Die Sidebar selbst kann noch Code enthalten, um zusätzliche Elemente zu den Widgets zu enthalten, oder eine Standard-Sidebar anzuzeigen, wenn keine Widgets auf die dynamische Sidebar gezogen wurden. Dazu beispielhaft der folgende Code für die Sidebar:

<ul id="sidebar">
<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : ?>
<!-- Standard-Sidebar, wenn keine Widgets vorhanden sind -->
<?php endif; ?>
<!-- zusätzliche statische Sidebar-Elemente -->
</ul>


2 oder mehr dynamische Sidebars

Wenn man 2 oder mehr dynamische Sidebars in seinem Theme haben möchte, dann verwendet man statt register_sidebar() die Funktion register_sidebars($n), wobei $n die Anzahl der Sidebars enthält. In der Sidebar wird dann die dynamische Sidebar mit dynamic_sidebar($i) angesprochen (beginnend mit $i = 1).

Beispiel functions.php für 3 dynamische Sidebars:
<?php
if ( function_exists('register_sidebar') )
register_sidebars(3);
?>


“Meine Sidebar ist keine Liste!” – Widget-Ausgabe beeinflussen

Ist deine Sidebar keine verschachtelte Liste, oder möchtest du den generierten HTML-Code aus anderen Gründen beeinflussen, dann kannst du den obigen Code wie folgt erweitern:
if ( function_exists('register_sidebar') )
register_sidebar(array(
'before_widget' => '<div id="%1$s" class="widget %2$s">',
'after_widget' => '</div>',
'before_title' => '<div class="title">',
'after_title' => '</div>',
));
Mit diesem Code solltest du genügend CSS-Selektoren bekommen, um jedes Widget individuell stylen zu können.

Mehr Infos über WordPress-Widgets gibts bei automattic.

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.

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.

Von blogsecurity.net gibt es eine englischsprachige Anleitung, wie man WordPress auf diversen Wegen sicherer machen kann. Die deutsche Übersetzung des Whitepapers kann als PDF-Datei (690 KB) heruntergeladen werden.

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

Auch Michael hat eine Liste mit Über 35 Möglichkeiten zur Absicherung eines WordPress Blogs zusammengestellt.

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 sind 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.

In der Regel bieten wir auch keine Upgrade-Paket für Major-Releases (beispielsweise 2.8.6 auf 2.9), da sich bei solchen Versionssprüngen für gewöhnlich die Mehrheit der Dateien ändert und ein Upgrade-Paket keinen Vorteil brächte.

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
(Seit WordPress 2.5 muss aber dazu ein Plugin installiert werden.)

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 alle Unterseiten nicht eingerückt anzeigen.
depth=0 alle Unterseiten hierarchisch eingerückt anzeigen.
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).
Alternativ gibt es auch das Plugin Exclude Pages.

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.

Bei Verwendung von Widgets

Werden Widgets benutzt, so können direkt in den Optionen des Seiten-Widgets (Adminbereich >> Design >> Widgets >> Seiten > bearbeiten) die IDs der auszuschließenden Seiten eingetragen werden.
Auch hier gilt, dass diese per Komma getrennt auf aufsteigend angeordnet werden müssen.

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.

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

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.

Teil 0 – simples Plugin, Basiswissen
Teil 1 – Plugin schreiben, Tutorial, innerhalb “the loop”
Teil 2 – Plugin schreiben, außerhalb “the loop”
Teil 3 – Plugin schreiben, außerhalb “the loop”

Siehe auch:
→ Asymptomatic: How to Write a Simple WordPress Plugin
→ WordPress Codex: Plugin API

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

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.

$table_prefix = 'wp_'; // Nur Zahlen, Buchstaben und Unterstriche bitte!

Du könntest also für die erste Installation wp1_ nennen und dann für die Zweite wp2_ usw.
Beachte aber, dass das Präfix einer bestehenden Installation nicht geändert werden darf.

<h1><a href="<?php echo get_settings('home'); ?>/"><?php bloginfo('name'); ?></a></h1>
<div class="description"><?php bloginfo('description'); ?></div>

Diese beiden Zeilen musst du löschen.

Dadurch ist dein Header aber nicht mehr “klickbar”, solltest du diesen trotzdem verlinken wollen, findest du hier eine Anleitung dazu.

<div id="header">...</div>

und ergänzt den Code folgendermaßen:

<div id="header" onclick="location.href='<?php bloginfo('url') ?>';" style="cursor: pointer;">...</div>

Beachte aber, dass ID (hier im Beispiel header) bei gewissen Themes anders lauten kann. Denkbare Varianten neben header wären z.B. top und logo.

Diese Variante ist schnell und einfach, hat aber den Nachteil, dass nur Besucher mit aktiviertem JavaScript den Link benutzen können. Auch Suchmaschinen finden den Link wahrscheinlich nicht.

Eine sauberere, auf aufwändigere Lösung ist diese:

<div id="header">
  <a href="<?php bloginfo('url') ?>/" style="display:block; width:100%; height:100%;">
    <span style="visibility:hidden"><?php bloginfo('name') ?></span>
  </a>
</div>

Das funktioniert aber so nur in Themes, die einen “leeren” Header haben, bei dem das Hintergrundbild per CSS eingebunden wird. Die hier angegebenen Inline-Styles werden optimalerweise natürlich in die style.css des Themes ausgelagert.

Das kannst du aber in deiner Sidebar.php ändern. Dort suchst du den Befehl wp_list_cats. Eine Beschreibung des Befehls findest du hier.
Für den speziellen Fall hier ist der Parameter hide_empty wichtig. Um also leere Kategorien auch anzeigen zu lassen, sollte der Befehl wp_list_cats folgendermaßen aussehen:

<?php wp_list_cats('hide_empty=false&deineweiterenEinstellungen'); ?>

In einigen Themes kann es auch noch vorkommen, dass anstelle von dem Befehl wp_list_cats der Befehl list_cats benutzt wird. Eine Beschreibung dieses Befehls findest du hier.
Der Befehl enthält die gleichen Paramter, nur in einer anderen Schreibweise, d.h. bei wp_list_cats werden die Parameter nur angegeben, wenn diese gebraucht werden. Bei list_cats sind immer alle Parameter angegeben, d.h. hier ist auch die Reihenfolge wichtig.

Mit XAMPP lässt sich problemlos ein Server auf dem heimischen Rechner einrichten. Mit XAMPP kann WordPress lokal installiert werden, das ist nützlich wenn man zum Beispiel Themes oder Plugins testen möchte, bevor sie auf den Webserver hochgeladen werden. Wie XAMPP eingerichtet und danach WordPress installiert wird, ist Schritt für Schritt in einem illustrierten Tutorial erklärt.

→ zum Tutorial: WordPress unter XAMPP installieren

Wenn WordPress nur im öffentlich zugänglichen Teil des Blogs englischen Text ausgibt, liegt das möglicherweise daran, dass du ein englisches Theme benutzt. Die Sprachdatei kann nur greifen, wenn der Autor sein Theme dafür vorbereitet hat. Viele Autoren machen sich jedoch nicht die Mühe. Um dein Blog komplett auf Deutsch anzuzeigen, kannst du entweder im Theme selbst Hand anlegen oder du kannst dir eines der vielen deutschen Themes herunterladen und nutzen.

Wenn WordPress auch im Adminbereich trotz Sprachdatei englischen Text anzeigt, kann das daran liegen, dass entweder die Sprachdatei nicht richtig eingebunden ist (auf Groß-Kleinschreibung achten!), nicht im BINARY-Modus auf den Server übertragen wurde oder dein Weblog auf einem 64bit-System liegt. Auf diesen Systemen gibt es Probleme mit gettext, dem Programm, das WordPress für die Übersetzungen verwendet.

Im Forum hat Gagget einen Lösungsansatz beschrieben:

mit folgenden Codeänderungen läuft es:

wp-includes/gettext.php (Zeile 101 -121)

PHP-Code:

// Caching can be turned off
$this->enable_cache = $enable_cache;// $MAGIC1 = (int)0×950412de; //bug in PHP 5
$MAGIC1 = (int) – 1794895138;
// $MAGIC2 = (int)0xde120495; //bug
$MAGIC2 = (int) – 569244523;
$MAGIC3 = (int) 2500072158; // ÄNDERUNG 64 BIT$this->STREAM = $Reader;
$magic = $this->readint();
if ($magic == $MAGIC1 || $magic == $MAGIC3) { // ÄNDERUNG 64 BIT
$this->BYTEORDER = 0;
} elseif ($magic == $MAGIC2) {
$this->BYTEORDER = 1;
} else {
$this->error = 1; // not MO file
return false;
}

Hast du die Pingadresse richtig angegeben und darauf geachtet, dass am Ende ein Slash (”/”) vorhanden ist? Hast du die Anweisungen der Anleitung befolgt?

WordBlog hat eine ganze Reihe von Massnahmen um Spamblogs und Blogs mit pornographischen Inhalten auszufiltern. Eventuell ist dein Blog in einem Filter hängengeblieben.

PS: Bitte beachte, dass die “frisch gebloggt”-Liste von WordBlog bereitgestellt wird. WordPress Deutschland ist für den technischen Teil nicht verantwortlich.

Ohne Permalinks:
Rufe eine Kategorie in deinem Browser auf, jetzt brauchst du nur am Ende der URL ein “&feed=rss2″ anhängen.

deinblog.de/?cat=1&feed=rss2

Mit Permalinks:
Rufe eine Kategorie in deinem Browser auf, jetzt brauchst du nur am Ende der URL ein “feed” anhängen.

deinblog.de/kategorie/allgemein/feed

PS: Es ist nicht möglich mehrere Kategorien in einem Feed anzuzeigen.

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.

Willst du zum Beispiel das Datum im Format Dienstag, 28. März 2006 ausgeben, so wäre folgender Code im Feld Standard-Datumsformat einzutragen: l, j. F Y

Fehlt noch die Uhrzeit, welche im Feld Standard-Zeitformat eingegeben wird.
Als Beispiel soll 14:57 Uhr ausgegeben werden. Damit das Uhr nicht fälschlich als Variable erkannt wird, muss dem Buchstabe jeweils ein Backslash voran gestellt werden:
G:i Uhr

Wird in deinem Blog trotzdem noch das falsche Datumsformat verwendet, so musst du an den Template-Dateien deines Themes Hand anlegen.
Diese Dateien mit der Endung .php findest du in deiner Wordpress-Installation in folgendem Ordner:
/wp-content/themes/name_des_themes/
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 aktualisierte Version auf deinen Webspace übertragen.

Nun wirst du im Ordner deines Themes mehrere Dateien finden. Beginne mit der Datei index.php, oder falls du den Theme-Editor benutzt, mit Haupt Index Template.
Suche Dort nach einer Funktion mit dem Namen the_time oder the_date, die wie folgt aussehen kann:
<?php the_time('F jS, Y') ?>

In der Klammer erfolgt wie im Adminmenü die Angabe des Datums- und Zeitformats durch die entsprechenden Variablen. Willst du also eine Ausgabe wie Samstag, 25. März 2006, 0:53 Uhr, benutze folgenden Code:
<?php the_time('l, j. F Y, G:i Uhr') ?>

Analog dazu gehst mit (falls vorhanden) weiteren relevanten Dateien im Ordner deines Themes vor. Kandidaten wären beispielsweise archive.php, single.php oder search.php.

Wenn du das WordPress Script von einer der offiziellen Seiten runterlädst, findest du immer eine Kopie der Lizenz im Hauptverzeichnis (licence.txt).

Du kannst die Orginallizenz auch jederzeit auf der Seite http://www.gnu.org/copyleft/gpl.html einsehen.

Eine deutschsprachige Übersetzung findest du auf der Seite http://www.gnu.de/gpl-ger.html. Diese Übersetzung wird mit der Absicht angeboten, das Verständnis der GNU General Public License (GNU-GPL) zu erleichtern. Es handelt sich jedoch nicht um eine offizielle oder im rechtlichen Sinne anerkannte Übersetzung.

Weitere Informationen über Die GNU-Lizenz findest du in der Wikipedia.

• Alex King`s Theme Browser
• How To Blog: list of WordPress Themes
• WordPress Theme Browser
• WordPress Codex: Theme List

Deutschsprachige Themes:

• WordPress Deutschland Themepool

→ A directory of all of WordPress’ hooks
→ Comprehensive List of WordPress Action Hooks

Siehe auch:
→ WordPress Codex: Plugin API

Den Webspace auf php5 umstellen, Beschreibung aus der strato-faq.de

—

Ausführliche Antwort von UMeisen: (übernommen aus dem Wordpress.de Forum)

In den Kundenservice-Bereich für den eigenen Account einloggen dann

> Homepagegestaltung
>> Website-Configurator

anklicken.

Im rechten Auswahlbereich auf

>>> PHP-Konfiguration

gehen. Es öffnet sich dann ein neues Fenster. Dort entweder die gesamte Homepage (”/”) oder aber das Wordpress-Unterverzeichnis “auswählen” und in dem Abschnitt “PHP-Version” in der Zeile “*.php” in dem Ausklappmenü “PHP 5.1.1″ auswählen.

Achtung: Strato schreibt daraufhin in das jeweilige Verzeichnis eine neue .htaccess-Datei. Ggfs. also vorher die bestehende .htaccess sichern und die Einträge nachher in die von Strato neu geschriebene .htaccess kopieren.

Die gewählte Einstellung gilt angeblich auch für alle Unterbereiche. Tatsächlich verschwand bei mir der 500-Fehler aber erst, nachdem ich, da in dem Konfigurationsmenue von Strato immer nur die erste Verzeichnisebene anwählbar ist, die so geänderte .htaccess-Datei auch in die weiteren Unterverzeichnisse (wp-admin, wp-content sowie plugins etc.) kopiert hatte.

Der 500er beim Abspeichern von Beiträgen erledigt sich ebenfalls, wenn in den Benutzer-Optionen der WYSIWYG-Editor abgeschaltet wird.

• Official WordPress Plugin Directory
• WordPress Plugin Database
• WordPress Plugin Repository
• Codex List of Plugins

In unserem Downloadbereich findest du Plugins die von der deutschen Benutzergemeinschaft erstellt oder übersetzt wurden.