• Dkret-Widgets können mehrfach genutzt werden
• verbesserte Sicherheit durch Unterstützung der neuen “escaping”-Funktionen
• Unterstützung alle neuen Theme-Funktionen, Unterstützung von ARIA-Roles …)
• vollständig neue und (auch optisch) verbesserte jQuery Drop-Down-Navigation (Superfish)
• komplett neuer Admin-Bereich
• integrierte Unterstützung von Google AdSense Werbung
• …

Auf jeden Fall stecken mehrere Monate “harter Arbeit” in der Entwicklung und im Prinzip habe ich alles neu gemacht – nur nicht das Design.

Wie immer bei grundsätzlichen Änderungen können  alte WordPress-Versionen nur mit viel zusätzlichem Auwand unterstützt werden. Da WordPress 2.8 alles so gut wie 2.7 macht und vieles einfach noch viel besser geworden ist, erfordert Dkret3 3.0 die aktuelle WordPress-Version 2.8.

Alle Änderungen können im Changelog des Themes nachgelesen werden.

Supportfragen beantworte ich gerne im neuen Dkret3-Forum. Da das Theme auch in anderen Ländern eingesetzt wird, ist Englisch dort die bevorzugte Sprache. Wer des Englischen überhaupt nicht mächtig ist, kann gerne im deutschen Subforum posten.

Wer sich die vielen kleinen Änderungen seit der ersten Beta anschauen möchte kann im WordPress Trac nachschauen.

Ich kann das Release kaum erwarten, weil in der Zwischenzeit auch das Dkret Theme Framework große Fortschritte gemacht hat. Praktisch alles ist neu programmiert und viele, viele neue Funktionen, Filter und SHORTCODES wurden ergänzt.

Obwohl bislang kaum Fehler auftreten, werde ich nach dem Release von WordPress erst einmal eine vorläufige Beta von Dkret3 3.0 veröffentlichen.

Ich selbst setze bereits seit mehreren Wochen die Version 2.8 ohne erkennbare Probleme ein. Nach wie vor sind noch “Tickets” im Trac offen und täglich kommen neue hinzu, allerdings sind dies in erster Linie Fehler, die nichts mit dem neuen Release zu tun haben, sondern bereits seit einigen WordPress-Versionen vorliegen.

Während Version 2.7 eine radikal neue und meiner Menung nach bedeuted bessere Administrationsoberfläche auszeichnet, steht die Version 2.8 vor allem für Verbesserungen in Bezug auf die Stabilität.

Nachtrag vom 17.05.09:

Das Wichtigste habe ich wie immer vergessen: Interessierte können sich die Beta-Version jetzt natürlich auch herunterladen.

Im Trac ist heute noch einmal deutlich gemacht worden, dass die “Server Voraussetzungen” sich in nächster Zeit nicht ändern werden. Aktuell wird noch immer PHP 4.3 vorausgesetzt. Erst wenn weniger als 10% der WordPress Nutzer PHP 4.3 nutzen, werden die Erfordernisse vorsichtig auf PHP 4.4 angehoben.

Die Entwickler wissen ziemlich genau, welche PHP Versionen im Einsatz sind, da seit der Einführung der Updatefunktion aus dem Admin-Bereich heraus, die aktuell installierte PHP Version ausgelesen wird.

Ich habe die Entwicklung von WordPress 2.8 in den letzten Monaten genau verfolgt, da ich parallel mein Theme dkret3 3.0 entwickele. Über die großen Änderungen ist schon hinreichend informiert worden, sodass ich mich auch einigen der unzähligen kleinen Verbesserungen widmen möchte.

Da alle Änderungen genauestens im Trac protokolliert werden, ist dies die beste Anlaufstelle für Wissbegierige und absolut unverzichtbar für Entwickler. Für die neue Version wurden knapp 700 “Tickets” eingereicht, wovon über 550 bereits erledigt wurden. Viele dieser “Tickets” sind bereits vor längerer Zeit eingereicht worden und immer wieder von Version zu Version verschoben worden.

Darstellung von Umlauten in RSS-Feeds

Seit vielen Versionen werden vor allem Umlaute in RSS-Feeds gerne NICHT dargestellt, sondern erscheinen unleserlich und zerhackstückt. UTF-8 kodierte RSS-Feeds werden nun endlich im WordPress Backend und vom RSS-Feed-Widgets korrekt ausgegeben.

Code-Bereinigung

Da WordPress bereits einige Jahre entwickelt wird und immer neue Funktionen hinzugefügt werden, ist es in Abständen notwendig, Funktionen zusammenzufügen und zu überdenken, damit das Gesamtsystem auch zukünftig zügig verbessert und weiterentwickelt werden kann.

Ein Beispiel für Änderungen in diesem Bereich ist Updatefunktion. Zunächst wurde die Möglichkeit geschaffen, Plugins im Admin-Bereich zu aktualieren. Später wurde diese Funktion auf das Gesamtsystem übertragen, sodass WordPress in wenigen Sekunden aktualisiert werden kann. In der aktuellen Version können jetzt auch Themes im Admin-Bereich aktualiert werden.

Erst in WordPress 2.8 werden diese Funktionen in einer eigenen Klasse zusammengeführt, die die Aktualierungen übernimmt. Solche Änderungen sind nicht trivial, sondern haben weitreichende Folgen haben. Sind erst einmal alle Fehler ausgeräumt, müssen zukünftig nicht drei unterschiedliche Bereiche gewartet werden. Verbesserungen bei der Aktualisierung von Plugins kommen zum Beispiel auch den Themes zugute.

Für Entwickler ist darüber hinaus von Bedeutung, dass mit jeder WordPress-Version der Code besser dokumentiert wird. Um die Funktionsweise einer WordPress-Funktion zu verstehen, ist immer häufiger ein Blick in der Quellcode erhellend.

Multiclass Widgets

Schon seit WordPress 2.6 (oder auch früher) können Widgets so programmiert werden, dass sie mehrfach hinzugefügt werden können. Das Text-Widget ist allerdings das einzige WordPress-Widget, dass von dieser Möglichkeit Gebrauch gemacht hat. Ich selbst bin mehrfach daran gescheitert, die in Dkret3 integrierten Widgets entsprechend anzupassen.

Ab WordPress 2.8 ist das Programmieren von Multi-Widgets ein Kinderspiel, da alle notwendigen Funktionen von einer zentralen Klasse zur Verfügung gestellt werden. Die Verwendung einer generischen Klassen kommt auch den Entwicklern entgegen, da wesentlich weniger Code programmiert werden muss, was sicherlich zu größerer Stabilität führen wird.

Widget-Programmierer müssen ab sofort nicht mehr alle Optionen selber in die Datenbank schreiben, sondern überlassen dies der neuen Klasse. Wenn Widgets entfernt werden, kümmert sich die Klasse auch darum, die Optionen wieder zu entfernen, wodurch die Datenbank auch nach längerer Nutzung nicht “zugemüllt” wird.

Verbesserte Handhabung von Javascript

Mit jeder neuen WordPress-Version steigt der Anteil an Javascript. Die mit WordPress 2.5 eingeleitete Wende zum schlanken jQuery Framework hat uns bereits viele Verbesserungen im Adminbereich beschert, die so richtig erst wahrgenommen werden können, wenn man Javascript einmal deaktiviert.

Auch im Blog selber spielt Javascript im Allgemeinen eine immer größere Rolle. Allerdings leidet unter dieser Entwicklung zunehmend auch die Geschwindigkeit. Viele Verbesserungen sind vor allem in diesem Bereich gemacht worden, sodass WordPress 2.8 insgesamt schneller geworden ist.

Während die Funktionen zum Einbinden von Javascript bislang nur den HEAD-Bereich der Seite berücksichtigten, kann Code nun explizit im Footer eingebunden werden. Selbstverständlich muss der Code auch dort geladen werden, allerdings wird der Seitenaufbau beschleunigt, weil nicht auf die einzelnen Skripte gewartet wird.

Eine deutliche Beschleunigung ist natürlich nur dann zu messen, wenn auch die Plugins und Themes an den neuen Mechanismus angepasst werden. Dkret3 bindet bereits seit einigen Versionen Javascript mit Hilfe der WordPress-Funktionen ein. In der kommenden 3.0 Version selbstverständlich im Footer.

Neue Funktionen für Theme-Autoren

Wie in jeder neuen Version üblich, kommen auch in Version 2.8 neue Funktionen für Theme-Autoren hinzu. In Dkret3 3.0 habe ich, sofern sinnvoll, diese eingebunden. Einerseits ist Dkret3 dadurch nicht mehr abwärtskompatibel, andererseits jedoch wesentlich “zukunftskompatibler”.

Während bislang die Datenbank zum Beispiel noch direkt abgefragt werden musste, um zu überprüfen, ob Kommtare zu einem Beitrag vorhanden sind, wird dies jetzt bequem von einer Funktion erledigt. Selbst zukünftige Änderungen an der Datenbankstruktur gefährden nicht mehr die Funktionsweise des Themes.

Auch die aus früheren Dkret-Versionen dynamischen BODY-Klassen des Sandbox-Themes sind in modifizierter Form in WordPress 2.8 integriert. Dkret3 3.0 fügt so dynamisch unterschiedliche Klassen dem BODY hinzu. Child-Themes können so z.B. mit ein paar Zeilen CSS das Headerbild in Abhängigkeit der Seite ändern.

Darüber hinaus habe ich die Worpress-Funktion mit Hilfe eines Filters um dynmische Brwoser-Klassen erweitert. Ein Child Themes kann so speziell an Besonderheiten einzelner Browser (z.B. Internet Explorer 6) angepasst werden.

WordPress 2.8 steht vor der Tür und damit wie immer die Frage, wird dkret3 kompatibel sein. Da ich dkret immer mit der aktuellsten Entwicklerversion von WordPress entwickele, wird dkret3 selbstverständlich vollständig zu WordPress 2.8 kompatibel sein. In WP2.8 stehen Theme-Entwicklern einige interessante neue Möglichkeiten offen, die ich bereits in dkret3 aufgenommen habe.

Alle Dkret-Widgets habe ich an die neue Multiwidget-Klasse von WordPress 2.8 angepasst und vollständig neu programmiert. Für den Benutzer bedeutet diese Änderung beispielsweise, dass er jedes Widget beliebig oft benutzen kann. In Verbindung mit dem Custom Widget Plugin lassen sich so noch leichter außerordentlich interessante Dinge veranstalten. Außerdem ist es leichter, weitere Optionen in die Widgets aufzunehmen.

Die beiden RSS-Feeds werden nicht mehr statisch in den Header der Seite eingebunden, sondern dynamisch mit Hilfe der neuen WordPress-Funktion <code>automatic_feed_links();</code>. Vorteile für den Benutzer ist ein leicht verbesserte Ladeverhalten des Blogs, da die Links nur auf den Seiten hinzugefügt werden, wenn sie benötigt werden.

Während WordPress 2.7 lediglich dynamische Klassen für die einzelnen Beiträge mit Hilfe der Funktion <code>post_class()</code> erzeugen konnte, unterstützt die Version 2.8 jetzt auch dynamische Klassen für den <code>body</code> durch die Funktion <code>body_class()</code>. Ich selbst verwende diese Klassen bislang nicht, Child Themes können so jedoch leicht sehr schöne Effekte erzielen. Beispielsweise können für die verschiedenen WordPress-Seiten unterschiedliche Headerbilder angezeigt werden.

In meinem eigenen Blog verwende ich neben der Navigation im Headerbereich ein spezielles Seiten-Widget, das Unterseiten – sofern gewünscht – nur dann anzeigt, wenn die zugehörige Hauptseite angezeigt wird. Bislang habe ich diese Funktionalität mit Hilfe des Foldable-Sidebar-Navigation-Widget-Plugins ermöglicht. Ab dkret3 2.8 ist dieses Plugin nicht mehr nötig. Stattdessen werden Unterseiten mit Hilfe von ein paar Zeilen jQuery Javascript ausgeblendet – sofern dies in den Optionen des Seiten-Widgets gewählt wird.

Dkret3 2.8 werde ich zeitnah mit dme Relase von WordPress 2.8 veröffentlichen. Eine frühere Veröffentlichung ist nicht möglich, da dkret3 2.8 die neue Version von WordPress voraussetzen wird.

Alle Änderungen können wie immer im ausführlichen Changelog nachgelesen werden.

Ein großes Problem stellt der sogenannte Box model bug in älteren Internet Explorer Versionen dar. Außerdem wurde Spaltendarstellung früher meist mit Hilfe von HTML umgesetzt. Moderne Webseiten sollten jedoch “barrierefrei” programmiert werden, weshalb statt HTML lieber CSS benutzt werden sollte. CSS sieht allerdings keine Spaltendarstellung vor.

Alle “Divisions” (DIV) von dkret werden durch das DIV #wrapper umschlossen.

Das Headerbild und der Name des Blogs werden innerhalb von #header angezeigt.

Alle Links des “Suckerfish”-Menus (die Links unterhalb des Seitenkopfes) befinden sich innerhalb von #access.

Die einzelnen Beiträge schließlich werden in #content dargestellt. Dieses DIV ist selber von #container umschlossen.

Das #container DIV ist ein wichtiger design trick. Dadurch ist dkret in der Lage, die Seitenleiste (Sidebar) beliebig auszurichten. Außerdem kann dadurch der oben erwähnte Box-Mode-Bug des Internet Explorers umgangen werden.

Alle Widgets, die man im WordPress-Admin-Bereich der “Primary Sidebar” hinzufügt, werden in #primary dargestellt. Alle Widgets der “Secondary Sidebar” werden #secondary hinzugefügt. Im Verlaufe dieses Beitrags werde ich noch erklären, wie die Seitenleisten plaziert werden können und wie ihre Größe geändert werden kann.

Alle Widgets, die man “Bottombar Column1″, “Bottombar Column2″ oder “Bottombar Column3″ hinzufügt, werden innerhalb der dazu passenden DIVs innerhalb #bottombars hinzugefügt.

Obwohl einige DIVs nebeneinander als Spalten dargestellt werden, sind sie innerhalb des Sourcecodes nacheinander plaziert.

Ändern der festen Breite von Dkret

Kein DIV kann breiter als #wrapper sein, weil alle DIVs ja in dieses eingeschlossen sind.

Um ein 600 Pixel breites Blog zu erhalten, muss nur die Breite des DIVs #wrapper entsprechend angepasst werden.

#wrapper { width: 600px; }

Sollte eine flexible Breite gewüscht werden, muss die Breite auf “auto” eingestellt werden.

#wrapper { width: auto; }

Der Schlüssel zu Layout-Änderungen: Ändern von CSS

Ein Blick in die style.css ist notwendig, um nachvollziehen zu können, wie das Dkret-Layout erzeugt wird.

Alle CSS-Stile des Dkret-Layouts sind in der style.css gruppiert:

/*
LAYOUT: Two-Column (Right)
DESCRIPTION: Two-column fluid layout with one sidebar(s) right of content
*/
div#wrapper {
	margin: 0 auto;
	width: 890px;
	min-width: 650px;
}
div#container {
	clear: both;
	float: left;
	margin: 0 -320px 50px 0;
	width: 100%;
}
div#content {
	margin: 25px 320px 0 0;
	overflow: hidden;
	padding: 0 20px;
}
div.sidebar {
	float: right;
	overflow: hidden;
	padding: 0 15px;
	width: 290px;
}
div#primary	{
	margin: 15px 0 0;
}
div#secondary	{
	margin: 0 0 20px;
	clear: right;
}

Stylen von #wrapper

#wrapper { width: 890px; }

Das Blog ist 890 Pixel breit.

#wrapper { min-width: 650px; }

Sollte mit Hilfe einer Scheme-Datei eine automatische Breite von #wrapper erzwungen werden, bewirkt die Angabe “min-width”, dass das Blog zwar unendlich vergrößert werden kann, mindestensaber 650 Pixel breit ist. Auch “min-width” kann auf “auto” gestellt werden, die Seitenleiste kann dann aber nicht immer neben dem Inhalt dargestellt werden und “rutscht” möglicherweise nach unten.

#wrapper { margin: 0 auto; }

Die “margin”-Definition zentriert das Blog. Die Abstände des Blogs nach oben und unten werden auf 0 Pixel gesetzt. Der rechte und linke Rand von #wrapper wird je nach Auflösung automatisch gesetzt.

The “margin”-Definition ist eine Kurzform. Der oben dargestellte CSS-Code bewirkt das gleiche wie:

#wrapper {
margin-top: 0;
margin-right: auto;
margin-bottom: 0;
margin-left: auto;
}

Stylen von #container

#container { clear: all; }

Kein DIV No vor und außerhalb #container (z.B. #access) kann neben #container vorbeifließen (float).

#container { width: 100%; }

Das DIV soll genauso groß sein, wie #wrapper. Da #wrapper 890 Pixel breit ist, ist #container so ebenfalls 890 Pixel breit.

#container { float: left; }

Beide Seitenleisten (#primary und #secondary) werden nicht vom DIV #container umschlossen. Damit sie später neben #content vorbeifließen (floaten) können, muss #container die “float”-Definition zugewiesen werden. Wenn diese Definition gelöscht wird, “rutschen” die Seitenleisten unter die Beiträge.

#container { margin: 0 -320px 50px 0; }

Diese Definition ist sehr wichtig für das Layout von dkret. Anhand einer kleinen Grafik möchte ich das verdeutlichen:

Es soll keine Lücke zwischen den Beiträgen und der Top-Navigation entstehen. Deshalb muss die “top-margin” auf 0 gesetzt werden.

Der zweite Wert ist besonders wichtig. Der rechte Abstand (margin-right) wird auf -320px eingestellt, was der Breite der Seitenleiste entspricht.

Der untere Abstand kann vergrößert und verkleinert werden, um den Abstand zwischen den Beiträgen und dem Fußteil der Seite anzupassen.

Da beide Seitenleisten am rechten Rand dargestellt werden sollen, muss links kein Rand gelassen werden (left-margin = 0). Ergänze einen negativen linken Rand, falls Du Seitenleisten auf beiden Seiten wünschst.

Die negativen Ränder sind unsichtbar, weil sie außerhalb #container ergänzt werden. Dieser Hack ist erforderlich, um den bereits erwähnten Box-Model-Bug zu umgehen.

Stylen von #content

Alle Beiträge werden dem DIV #content hinzugefügt.

#content { margin: 25px 320px 0 0; }

Wahrscheinlich ist Dir schon alles klar. Der zweite Wert (margin-right) ist wieder wichtig. Ohne einen rechten Abstand wäre kein Platz für die Seitenleisten vorhanden. Der Wert entspricht deshalb exakt dem negativen rechten Rand von #container (allerdings positiv, da der Rand ja innen hinzugefügt werden soll).

#content { padding: 0 20px; }

Mit Abstand zwischen den Beiträgen und den Seitenleisten sieht es einfach besser aus. Hier setzte ich erneut eine Kurzform für ”padding-top”, “padding-right” usw. ein.

Stylen von  .sidebar

Obwohl sowohl #primary als auch #secondary mit CSS verändert werden können, ist es einfacher für gemeinsame Stile, die gemeinsame Klasse “sidebar” anzupassen.

.sidebar { padding: 0 15px; }

Etwas Abstand zwischen den Widgets der Seitenleiste und den Beiträgen ist definitiv besser.

.sidebar { width: 290px; }

Die Seitenleisten sollen exakt 320 Pixel breit sein. Warum muss also die Breite aber auf 290 Pixel festgelegt werden? Wegen des hinzugefügten extra Abstandes (padding) oben. Etwas einfache Mathematik wird helfen: 15 Pixel (padding-left) + 15 Pixel (padding-right) = 30 Pixel. Füge diese den 290 Pixel hinzu und du bekommst —–> 320 Pixel!

.sidebar { float: right; }

Diese letzte Definition macht die “Magie”. Beide Seitenleisten fließen nach rechts und springen in die geschaffene Lücke im DIV #container.

Alle Galerien in WordPress 2.5 sind Beiträge. Statt Bilder einzeln hochzuladen und dann eines nach dem anderen in den Beitrag einzufügen, kann man ab WordPress 2.5 sie komplett als Galerie einfügen.

Der Dialog zum Hochladen eines Bildes befindet sich prominent oberhalb des Beitragseditors. Es spielt keine Rolle, ob die visuelle Ansicht oder der Codeeditor benutzt wird.

Sofern das aktuelle Flash-Plugin von Adobe auf dem Rechner installiert ist, können mehrere Bilder auf einmal ausgewählt und hochgeladen werden. WordPress legt dabei drei verscheidene Versionen der Bilder auf dem Server ab: Vorschaubild, Medium und vollständige Größe.

Alle Bilder eines Beitrages bilden eine Galerie. Der Dialog zum Hochladen von Bildern wird auch zur Verwaltung der Galerie verwendet. Im Normalfall lädt man eine Anzahl von Bilder hoch und fügt sie mit Hilfe des Galerie-Tabs in den Beitrag ein.

Der WYSIWYG-Editor zeigt allerdings nur den sogenannten “SHORTCODE” [ gallery ] an, der später durch die einzelnen Vorschaubilder ersetzt wird. Im WordPress Codex gibt es darüber hinaus eine Anleitung für fortgeschrittende Anwender, wie man diesem SHORTCODE weitere Attribute hinzufügen kann.

Galerien mit Dkret3 1.9

Was der WordPress-Galerie derzeit noch fehlt, ist eine automatische Übersicht aller angelegten Galerien. Dkret3 1.9 kann diese Lücke (fast) füllen.

Zunächst muss eine Kategorie angelegt werden, die allen Galerie-Beiträgen zugewiesen wird. Den Namen der Kategorie kann man frei wählen.

Danach kann diese Kategorie im Admin-Bereich von Dkret als Galerie-Kategorie festgelegt werden. Außerdem wird dort entschieden, ob der Top-Navigation ein Link zur Galerie-Übersicht hinzugefügt wird und wie die Beiträge der Galerie-Kategorie auf der Startseite (dem Blog) dargestellt werden sollen.

Die Galerie-Übersicht listet nicht einfach alle Beiträge der Galerie-Kategorie auf, sondern zeigt zusätzlich das erste Bild jeder Galerie und die Anzahl der Bilder.

Auf meiner Seite setze ich außerdem das Plugin Cleaner Gallery ein. Das Plugin behebt ein paar Fehler der derzeitigen Galerie-Funktion von WordPress und bietet den Support für eine Vielzahl von Anzeige-Plugins (z.B. Thickbox, Lightbox). Auch das von mir seit mehreren Monaten eingesetzte Shutter Reloaded funktioniert damit ohne Probleme.

Warning: unpack() [function.unpack]: Type V: not enough input,
need 4, have 0 in /***/wp-includes/gettext.php on line 85

zieren die “Seite”.

Seit einigen Monaten behelfe ich mir damit, auf die Lokalisation meiner Seite zu verzichten, da der Fehler scheinbar ausschließlich im Zusammenhang mit den Übersetzungsfunktionen (gettext) von WordPress auftritt. Für mich war diese “Lösung” jedoch auf Dauer nicht annehmbar, da ich möglicherweise zukünftig nicht ausschließlich private Seiten hosten möchte.

Dass ich nicht der einzige bin, der unter diesem Fehler zu leiden hat, wird bei einer Suche im Internet schnell deutlich. Ich empfehle allen den Beitrag von Mathias Brusdeylin zum diesem Thema.

Eine Suche in den Supportforen zu WordPress brachte zwar viele Hinweise, jedoch keine Lösung. Auch der sonst immer vorzügliche Support meines Hosters “all-inkl” versagte. Im Zuge der Vorbereitungen meines “Umzugs” zu einem amerikanischen Hoster, bin ich auf eine kleine Konfigurationshilfe in den Hilfedateien von “all-inkl” gestoßen. Ein kleiner Eintrag in die .htaccess Datei meiner WordPress-Installation genügt, um von PHP5 auf PHP4 umzustellen:

AddHandler php4-cgi .php

Auch diese “Lösung” ist mit einem Verzicht verbunden. Allerdings wird PHP5 derzeit noch nicht von WordPress offiziell unterstützt, es sollte nur unter PHP5 zu nutzen sein. Einzelne (sehr wenige) Plugins erfordern PHP5, sodass für mich eine Rückkehr zum alten PHP4 gegenüber dem Verzicht auf eine deutsche Übersetzung das kleinere Übel darstellt.

Mein “Fix” sollte grundsätzlich für alle bei “all-inkl” gehostete Seiten funktionieren. Andere Anbieter lassen aber normalerweise ebenfalls einen Wechsel der PHP Version zu. Ob die beschriebene Fehlermeldung überhaupt bei anderen Hostern auftritt, ist mir jedoch nicht bekannt.

Damit der Eintrag in .htaccess nicht von WordPress überschrieben werden kann, muss mein Fix unbedingt nach

# END WordPress

eingefügt werden.

Das Foldable Page List Plugin bietet genau die gewünschte Funktionalität. Ich habe für Dkret 1.7 extra ein neues “Seiten”-Widget erstellt, welches das Standard-Seiten-Widget von WordPress 2.5 ersetzt.

Mein Widget bietet gegenüber dem Original zusätzlich die Funktionen,

• den Seitentitel vollständig auszublenden,
• die Seitennavigation nur anzuzeigen, wenn die aktuelle Seite über Unterseiten verfügt,
• und zeigt nur Unterseiten der aktuellen Seiten an.

Das Subpages-Widget ist ab sofort nicht mehr Bestandteil des Dkret-Themes, da mein neuen Seiten-Widget dessen Funktionen in besserer Form erledigt.