<link rel="shortcut icon" href="http://meine-seite.de/favicon.ico" 
 type="image/x-icon" />

- der Link natürlich entsprechend an die eigene Domain angepasst. Das bewirkt, dass in der Adressleiste z.B. beim Aufruf meines Blogs erscheint:

Dies funktioniert allerdings nicht immer im Backend, also im Adminbereich. Ich habe keinerlei Regelmäßigkeit feststellen können, wann im Backend ein Favicon erscheint und wann nicht – keine Ahnung, ob es abhängig davon ist, ob die Seite z.B. auf einer Subdomain installiert ist oder in einem Unterverzeichnis, oder ob es gar providerabhängig ist. Bei meinen Blogs funktioniert es teilweise, teilweise nicht. Aber auch für dieses “Problem” gibt es ein kleines Plugin: Admin Favicon.
Das Plugin nach dem Entzippen ins Plugin-Verzeichnis hochladen und aktivieren, anschließend findet sich unter Einstellungen ein neuer Unterpunkt Admin Favicon. Hier wird unter Favicon URL entweder die gleiche URL angegeben, die auch in der header.php steht (s.o.), oder aber eine andere URL, wenn für Backend und Frontend unterschiedliche Favicons verwendet werden sollen. Auf Aktualisieren klicken – und schon hat man auch im Adminbereich ein Favicon.

Wenn nun aber an einer anderen Stelle, zum Beispiel in einem Inhaltsverzeichnis, alle Seiten aufgelistet werden sollen, funktioniert das natürlich nicht mit <?php wp_list_pages(); ?>. Dafür gibt es aber andere Möglichkeiten, zum Beispiel diese:

1
2
3
4
5
6
7

<?php
 $postslist = get_posts('numberposts=-1&order=ASC&orderby=title&post_type=page');
 foreach ($postslist as $post) :
    setup_postdata($post);
 ?>
<li><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></li>
<?php endforeach; ?>

Das ergibt eine Liste der Titel aller Seiten, alphabetisch nach Titeln sortiert.

$h_time = sprintf( __('%s from now'), human_time_diff( $time ) );

Diese Zeile ist für die Datumsangabe der Artikel, die erst später veröffentlicht werden, zuständig. Um dort ein Datum in der Form “24.02.2009, 20:15″ zu erhalten, wird diese Zeile ersetzt durch:

$h_time = mysql2date(__('d.m.Y, h:i'), $m_time);

Für die Datumsanzeige der vor kurzem veröffentlichten Artikel muss Zeile 1352 geändert werden, dieses hier:

$h_time = sprintf( __('%s ago'), human_time_diff( $time ) );

wird ebenfalls ersetzt durch:

$h_time = mysql2date(__('d.m.Y, h:i'), $m_time);

Um auch noch bei allen übrigen Artikeln die gleiche Datumsanzeige mit Zeit zu erhalten, wird Zeile 1354 auch ersetzt durch:

$h_time = mysql2date(__('d.m.Y, h:i'), $m_time);

So gefällt mir die Artikelübersicht besser
Solche Änderungen an Programmdateien müssen dann lediglich nach WordPress-Updates eventuell wiederholt werden, aber das ist ja kein großer Aufwand.

Der neu gestaltete Admin-Bereich ist zunächst einmal die auffallendste Änderung. Zum einen nimmt er nun die gesamte Bildschirmbreite ein, zum anderen befindet sich die Hauptnavigation links, nicht mehr oben. Farblich gefällt mir das Ganze sehr gut, da es insgesamt heller und freundlicher aussieht als vorher. Die Farbeinstellungen können unter Benutzer -> Dein Profil geändert werden, mein Favorit ist das blaue Farbschema.

Eine weitere Neuerung findet sich unter Einstellungen -> Diskussion. Mit WordPress 2.7 sind verschachtelte Kommentare möglich, das heißt, es kann direkt unter einem Kommentar auf diesen geantwortet werden. Außerdem können Kommentare nun auf mehrere Seiten verteilt werden, und es besteht die Möglichkeit, die Kommentarfunktion automatisch nach einer einstellbaren Zeit zu schließen. Alle diese Neuerungen funktionieren allerdings nicht einfach so, denn die comments.php des Themes muss die Funktionen unterstützen. Ich habe die entsprechenden Änderungen hier im Blog bislang noch nicht durchgeführt.

Die Einstellungen für die Mediathek sind jetzt nicht mehr unter Einstellungen -> Verschiedenes zu finden, sondern haben einen eigenen Unterpunkt “Mediathek” in den Einstellungen erhalten. Hier gibt es auch ein paar Neuerungen, unter anderem kann jetzt eine maximale Größe für die Bilder angegeben werden und Standardgröße und -ausrichtung können definiert werden. Hier mal als Test ein Screenshot des neuen Adminbereichs:

Eine deutsche Sprachdatei zu Version 2.7 gibt es auch schon bzw. ist in Bearbeitung, die jeweils aktuelle Version ist hier zu finden.
Die Plugins, die ich verwende, scheinen keine Probleme mit WP 2.7 zu haben, zumindest konnte ich bislang noch nichts feststellen. Eine Liste kompatibler Plugins gibt es hier, von manchen Plugins wird es eine neue Version speziell für WP 2.7 geben, z.B. von NextGen Gallery.

Mir gefällt WordPress 2.7 sehr gut – nur nochmal als Hinweis: 2.7-RC1 ist keine endgültige Version (das RC steht für “Release Candiate”), wer also Bedenken hat, diese Version zu nutzen, sollte lieber die endgültige Version abwarten, deren Veröffentlichung ja bald sein wird.

Nummer eins:
Das TinyMCE-Plugin erweitert den Editor um Funktionen wie z.B. horizontale Linien, Tabellen, Fullscreen-Modus, Suchen & Ersetzen und andere. Nach dem Hochladen des Plugins in den Plugin-Ordner und anschließendem Aktivieren ist eine zusätzliche zweite Zeile mit Textformatierungs-Buttons über dem Schreibfenster zu sehen. Durch Klick auf den Button unten rechts “Show/Hide Advanced Toolbar” öffnet sich eine dritte Zeile. (Dies soll auch durch die Tastenkombination ALT+b möglich sein, hat bei mir aber nicht funktioniert.) Nach jedem Zwischenspeichern des Beitrags muss diese Taste erneut betätigt werden, wenn die dritte Zeile geöffnet sein soll.
Unter der Dropdown-Liste “Styles” kann direkt auf das Stylesheet zugegriffen werden und einzelne Textausschnitte mit den im Stylesheet definierten Klassen versehen werden.
Der Button “Media” soll laut Pluginautor nicht im Internet Explorer funktionieren.
Beim Hochladen der Plugin-Dateien werden einige Originaldateien überschrieben, daher ist es – wie immer bei solchen Änderungen – sinnvoll, vorher alle Dateien zu sichern. Ich konnte zwar nicht feststellen, dass nach dem Deaktivieren des Plugins irgendetwas am WordPress-eigenen TinyMCE nicht mehr funktionierte, aber sicher ist sicher.

Mein Fazit: Der Editor ist allemal besser als der mitgelieferte, abgespeckte TinyMCE-Editor.

Nummer zwei:
Das Plugin für den FCKeditor wird ebenfalls in den Plugin-Ordner kopiert und anschließend aktiviert. Hier im Bild sieht man die Standardeinstellung des Editors mit der Default Toolbar (mit allen Formatierungsmöglichkeiten) und dem Default Skin. Im Admin-Bereich unter Einstellungen findet sich nun ein neuer Unterpunkt FCKeditor, dort können diverse Einstellungen vorgenommen werden, z.B. kann die Größe des Schreibfeldes verändert werden, unterschiedliche Designs (“Skins”) sowie Verzeichnisse für Upload und Smileys können gewählt werden, erlaubte und verbotene Filetypen und -endungen können angegeben werden.

Mit der Basic Toolbar sind nur die Funktionen Quellcode zur HTML-Bearbeitung, Fettschrift, Kursivschrift, nummerierte und unnummerierte Liste, Link einfügen bzw. entfernen, Smiley einfügen, die “Read More”-Funktion sowie ein Infofeld über den FCKeditor sichtbar.

Hier ist die komplette Toolbar (Default) im “Office 2003″-Skin zu sehen.

Und hier die komplette Toolbar (Default) im “Silver”-Skin.

Der FCKeditor hat für mich zwei große Vorteile:
1. Der Filemanager. Darüber lassen sich Bilder und andere Medien verwalten, sie können hochgeladen und eingefügt werden, neue Ordner lassen sich anlegen, Bilder können in der Größe verändert werden, mit Rahmen versehen und unterschiedlich ausgerichtet werden oder auch mit einer im Stylesheet hinterlegten Klasse versehen werden, ein Vorschaubild kann zu einem großen Bild linken etc.
2. Die integrierte Smiley-Verwaltung. In den Einstellungen des Plugins wird das Verzeichnis, in dem sich die Smileys befinden, angegeben. Beim Schreiben lassen sie sich dann einfach per Klick in den Text einfügen.

Mein Fazit: Der FCKeditor ist mein klarer Favorit. Wenn ich einen Editor benutzen würde, wäre es auf jeden Fall dieser.
Wer nicht alle Buttons benötigt, kann den Editor übrigens auch simpel anpassen. In der Datei custom_config_js.php können die Toolbars bearbeitet werden. So würde ich hier z.B. die Zeilen ['Style','FontFormat','FontName','FontSize'] und ['TextColor','BGColor'] komplett löschen, da die Formatierungen hierfür ja sowieso im Stylesheet hinterlegt sind.
Weitere Informationen zum Open Source FCKeditor gibt es hier.

Noch zwei Anmerkungen zum Schluss:
Beide Editoren haben in meinem Test fehlerfreien, teilweise aber durch unnötige Formatierungen etwas aufgeblähten Code ausgegeben.
Der Seitenaufbau beim Zwischenspeichern dauert mit dem TinyMCE-Editor merkbar länger als mit dem FCKeditor.

Dazu muss die quicktags.js im Ordner wp-admin bearbeitet werden, natürlich erst nachdem vorher eine Sicherungskopie von ihr erstellt wurde. Oben in der Datei steht neben function edButton eine kurze Erklärung, und dementsprechend erstelle ich mir nun einen neuen Quicktag. Hierzu kopiere ich den Fettschrift-Quicktag, der so aussieht:

edButtons[edButtons.length] =
new edButton('ed_strong'
,'b'
,'<strong>'
,'</strong>'
,'b'
);

und füge ihn an der Stelle ein, an der der neue Quicktag erscheinen soll (ich habe ihn nach dem Blockquote-Tag eingefügt). Wenn ich nun beispielsweise ständig das ®-Zeichen benutze und dieses als Quicktag haben möchte, ändere ich den obigen Code wie folgt:

• Das 'ed_strong' in der zweiten Zeile ist die sogenannte Button-ID, das ändere ich in 'ed_r'.
• Das ,'b' in der dritten Zeile ist das, was auf dem Quicktag selbst als Text erscheint – hierhin schreibe ich ,'R'.
• In die vierte Zeile kommt der HTML-Code des Sonderzeichens, also ,'®'.
• Die fünfte Zeile wird nur benutzt, wenn es sich um einen Tag handelt, der mit </> geschlossen werden muss, dort wird nichts eingetragen: ,''.
• In der sechsten Zeile wird die Taste definiert, die zum Einfügen des Zeichens mit einer Tastenkombination benutzt wird, hierhin schreibe ich ,'r', was bedeutet, dass ich mein Sonderzeichen auch mit alt + r aufrufen kann.
• Eine siebte Zeile mit dem Inhalt ,-1 muss noch hinzugefügt werden, da es sich hier nur um ein Sonderzeichen handelt, nicht um einen Tag, der geschlossen werden muss.

Nun kann ich die quicktags.js speichern, hochladen und anschließend einfach meinen neuen Quicktag anklicken oder die Tastenkombination alt + r drücken, wenn ich ein ® schreiben will.

Noch ein weiteres Beispiel für einen Tag, der geschlossen werden muss:
Wenn ich häufiger einzelne Wörter in rot schreiben möchte, ändere ich den Code so:

• Zeile 2: 'ed_rot' als Button-ID
• Zeile 3: ,'rot' als Text für den Quicktag-Button
• Zeile 4: ,'<span style="color: #ff0000;">' hier fängt der rote Text an
• Zeile 5: ,'</span>'hier endet der rote Text
• Zeile 6: ,'y' für die Tastenkombination in Verbindung mit der alt-Taste
• Eine siebte Zeile gibt es in diesem Fall nicht.

Nun ergibt:

ein ®.

Ich habe dann noch mehrere Versuche gestartet, es hinzukriegen, indem ich z.B. eine leere .htaccess erstellt, in mein Blog-Verzeichnis hochgeladen und per CHMOD auf 666 gesetzt habe. Hat aber alles nichts genutzt. Aufklärung brachte schließlich ein Anruf bei meinem Webhoster Candan (der übrigens nicht nur günstig ist, sondern auch einen kompetenten und sehr schnellen Support bietet), bei dem ich erfuhr, dass ich “Passwortschutz” aktivieren müsse (so heißt das zumindest in meinem Web-Paket). Das habe ich getan und daraufhin nochmals die Permalinkstruktur angegeben – und es funktioniert!

Was ich allerdings manuell ändern musste, waren die einzeln verlinkten (also nicht über wp_list_pages eingebundenen) Seiten, d.h. das Inhaltsverzeichnis und die “Was soll das”-Seite.

Dazu habe ich in der Datei menu.php im Ordner wp-admin in Zeile 7 die Bezeichnung “Dashboard” ersetzt durch “Startseite”, ebenso in der index.php im gleichen Ordner in Zeile 3 (nachdem ich natürlich zuerst Kopien der Dateien gemacht habe).

All die mehr oder weniger aktuellen WordPress-News, die auf der “Tellerrand-Startseite” zu lesen sind, finde ich nicht wirklich interessant, und Neuigkeiten WordPress betreffend erfahre ich bei wordpress.de. Daher habe ich die index.php noch weiter angepasst, damit diese News nicht mehr geladen werden (was übrigens manchmal auch recht lange dauert). Hierzu müssen einfach die entsprechenden Stellen in der index.php im wp-admin-Ordner gelöscht werden. Solange die Kopie der Originaldatei vorhanden ist, kann eigentlich nicht viel passieren… Wer sich nicht selbst darantraut, kann eine geänderte index.php unter dem Link im dritten Beitrag auf dieser Seite herunterladen.