Peruns Weblog - Webwork und Internet

Jens Grochtdreis hat mich auf etwas interessantes hingewiesen. Da hat jemand tatsächlich ein freies WordPress-Theme entwickelt, mit welchem man in der Lage ist ein einfaches Ticket-System bzw. einen Bugtracker zu betreiben.

Hier geht es zum beschreibenden Artikel und hier zur freien Demo.

Nehmen wir mal an, man überführt eine recht umfangreiche statische Website nach WordPress. Die Website hat viele Unterseiten und auf den einzelnen Unterseiten sind die Überschriften lang. Lang sind die deswegen, weil meiner Meinung nach eine Überschrift keine Zierde ist, sondern eine starke Aussagekraft haben muss und wenn es geht schon die Kernaussage der Unterseite bzw. eines Artikels in sich tragen sollte.

Bei WordPress bekommt man dabei ein Problem, weil die Überschrift bei sprechenden Permalinks gleichzeitig in der URL abgebildet wird. Das ist aber ein vergleichsweise kleines Problem, da man die URL, so bald sprechende Permalinks aktiviert sind, schon bei der Erstellung des Artikels/Seite komfortabel verändern kann. (weiterlesen…)

Ich habe im Februar diesen Jahres beschrieben, wie man mit Hilfe der Conditional-Tags is_home() und is_front_page() abfragen kann ob man sich auf der Startseite befindet um zum Beispiel auf der Startseite eine zusätzliche Meldung einzubinden.

Es könnte aber sein, dass die Startseite vom Rest sehr stark abweicht und da könnte es schnell unübersichtlich werden, wenn man mit Conditional-Tags arbeitet. Deswegen gibt es schon seit längerem die Möglichkeit eine Template-Datei mit dem Namen home.php zu erstellen. Diese Datei kümmert sich ausschließlich um die Ausgabe der Startseite und den folgenden Unterseiten der Startseite und "überschreibt" dabei die Angaben in der index.php.

Die home.php wirkt aber nur so lange auch die Auflistung der aktuellen Blog-Artikel auf der Startseite erscheinen. Bestimmt man unter Einstellungen → Lesen → Startseite eine Seite (Page) als Startseite, dann kommt die home.php gar nicht zum Zuge.

Deswegen gibt es seit WordPress 3.0 die Möglichkeit eine Template-Datei mit dem Namen front-page.php zu erstellen. Angaben in dieser Datei beziehen sich auf die Startseite egal ob hier eine Seite bzw. Page oder ob klassischerweise, die Auflistung der letzten Blog-Artikel zum Einsatz kommt.

Die Angaben in der front-page.php "überschreiben", die Angaben in der home.php und in der index.php.

Ich bin da ganz ehrlich, diese Mini-Neuerung ist völlig an mir vorbeigegangen. Worum geht es? Wenn man WordPress über die die eingebaute Aktualisierungsfunktion ("automatisches Update") updatet, dann wird WordPress für die Dauer des Update-Prozesses in den Wartungsmodus versetzt bzw. folgendes wird dann im Frontend angezeigt:

Während der Aktualisierung wird folgendes im Frontend angezeigt

Somit werden, zumindest in solchen Fällen, Wartungsmodus-Plugins überflüssig.

Gerade vorhin wollte ich WordPress exportieren bzw. einen Backup des Inhalts anlegen und als ich den Export startete bekam ich folgende Fehlermeldungen um die Ohren gehauen:

Warning: Illegal offset type in isset or empty in [...]/wp-includes/taxonomy.php on line 176
Warning: Cannot modify header information – headers already sent by (output started at [...]/wp-includes/taxonomy.php:176) in [...]/wp-admin/includes/export.php on line 44
Warning: Cannot modify header information – headers already sent by (output started at [...]/wp-includes/taxonomy.php:176) in [...]/wp-admin/includes/export.php on line 45
Warning: Cannot modify header information – headers already sent by (output started at [...]/wp-includes/taxonomy.php:176) in [...]/wp-admin/includes/export.php on line 46

Nach dem ich vorsichtshalber sowohl die /wp-includes/taxonomy.php als auch die /wp-admin/includes/export.php auf Leerzeichen bzw. -Zeilen vor dem öffnenden <?php geprüft habe, habe ich einfach das Plugin Simple Tags deaktiviert und der Export funktionierte wie gewohnt.

Ich hatte das Vergnügen für die c't extra 01/2010 – Webdesign einen WordPress-Artikel zu schreiben. Die Überschrift des Artikels ist "Gut gepresst: WordPress absichern und anpassen" (Linkliste zum Artikel), der Artikel beginnt auf der Seite 100 und ist 3,5 Seiten lang.

Das Thema des Artikel ist nicht nur die Sicherheit, sondern auch wie die ersten Schritte bezüglich der Erstellung eines eigenen Themes aussehen könnten. So weit so gut.

Karsten Busch hat mich in seinem Blog-Artikel darauf hingewiesen, dass an einer Stelle im Artikel eine zusätzliche Info fehlt bzw. hilfreich gewesen wäre. (weiterlesen…)

Ich nutze seit längerem das WordPress-Plugin Cleaner Gallery. WordPress produziert leider bei der Ausgabe der Galerie etwas unsauberen Code: der style-Block wird im sichtbaren Bereich (body) eingebunden. Die Erweiterung korrigiert dies und bindet den CSS-Block als externe Datei ein.

So weit ist dies in Ordnung, aber eine zusätzliche Datei nur für die Galerie ist in meinen Augen zu viel des Guten, immerhin handelt sich hier um eine nicht unbedingt notwendige Anfrage an den Server. Das Problem ist das es leider in den Einstellungen des Plugins keine Option gibt die Ausgabe der extra Datei zu unterdrücken.

In der Dokumentation (readme.html) wird folgender Code angegeben:

<?php remove_action( 'wp_head', 'cleaner_gallery_css' ); ?>

Diesen Code muss man in die functions.php einfügen. Allerdings funktioniert dieser Code nicht und daher kann man ihn getrost vergessen. Kurze Recherche brachte mich zum folgenden Code:

<?php
// Entfernt die CSS-Datei von Cleaner Gallery
wp_deregister_style("cleaner-gallery");
?>

Auch dieser wird in die functions.php eingetragen und im Gegensatz zum ersten Beispiel funktioniert er auch. Anschließend die Regeln aus der cleaner-gallery.css in die style.css übertragen und das war's.

Der Kopfbereich des HTML-Dokuments ist etwas schlanker und man spart sich einen unnötigen HTTP-Request. Ist imho interessant für Leute, die mit recht wenig Einsatz noch ein bisschen mehr aus ihrer Performance-Optimierung raus holen wollen.