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.

Ich habe drüben auf WordPress-Buch.de einen 14 DIN-A4-Seiten langen Artikel veröffentlicht: WordPress als "klassisches" CMS: ein Beispiel. In dem Artikel erkläre ich an Hand meiner früheren Portfolio-Website, wie man WordPress auch für Websites ohne Blogcharakter einsetzen kann. Ich bewusst ein einfaches Beispiel gewählt, damit man sieht dass es sich dabei um kein Hexenwerk handelt.

Bevor jetzt, die Hinweise kommen, das WordPress schon immer ein CMS war: ja, dass weiß ich. Aber "WordPress als 'klassisches' CMS" ist einfach griffiger als "WordPress im Einsatz auf Projekten ohne Blog-Charakter". Oder will mir hier jemand widersprechen?

Viel Spaß beim Lesen.

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.

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.

Wer seit dem Update auf WordPress 3.0 im Backend den Menüpunkt Einstellungen → Verschiedenes vermisst, denn kann ich beruhigen: die Einstellungen für den Upload-Ordner – Pfad und die Ordner-Organisation – befinden sich jetzt in Einstellungen → Mediathek.

Wohin es die Einstellung Verfolge die Aktualisierung der Links verschlagen hat, kann ich leider nicht sagen, wer es weiß, möge sich bitte zum Kommentar-Formular begeben.