Im Zuge der Aufräumarbeiten nach der Geburtstagsparty habe ich mir die w3c-Konformität des Blogs (mal wieder) vorgenommen.

Prinzipiell ist der Code von webrocker.de auf striktes XHTML ausgelegt und validiert auch in der Basisversion richtig. Allerdings nicht, sobald einige Plugins in die Ausgabe eingreifen.

Aus diesem Grund habe ich gerade das "Eselsohr" des Arbeitskreises Vorratsdatenspeicherung gekickt. Ok, nicht nur aus diesem Grund, vor allem hat mich die Ecke, so wichtig und richtig auch die Thematik dahinter ist, genervt. Ich werde einen Ersatz als Banner oder so in meine Linkleiste aufnehmen, über ein Jahr lang eselohrte es nun hier im Blog, nun ist's auch mal gut, vor allem, wenn der Eselsohrspaß mir die Validierung bricht.

Das Plugin "Codebox" ist ebenfalls nicht in der Lage, strikt XHTML konformen Code abzugeben; schon die Einbindung der benötigten Javascripte wird mit language="javascript" gemacht, obwohl das ebenfalls angegebene type="text/javascript" völlig ausreichen würde und obendrein richtig validiert. Da ich das Plugin, bzw. dessen Ausgabe für Quellcodeschnipsel, nicht missen möchte, habe ich von einer Deaktivierung abgesehen und stattdessen die main.php des Plugins entsprechend abgeändert. Und dabei auch die (für meine Installation) redundante Einbindung von jQuery rausgeschmissen. Ist halt blöd, wenn das Plugin aktualisiert wird, dann darf ich diese Änderungen erneut vornehmen.

Update

Ich habe gerade bei Stefan Esser gesehen, dass er das "wp_syntax" Plugin zur Darstellung von Code einsetzt. Also wenn _der_ Sicherheitsguru schlechthin ein Plugin verwendet, kann es so schlecht nicht sein, dachte sich meinereiner, und da es die gleiche Syntax wie "codebox" verwendet, ist die Umstellung völlig problemlos. Bang. Goodbye codebox.
/update end

Zur komfortablen Verwaltung der Bilder setzte ich bislang den "iimage-Browser" ein - mit der neuen Bild- und Medienverwaltung ist WordPress nun dessen Funktionen recht nahe gekommen, sodass ich überlege, das Plugin ebenfalls zu kicken. Ich zögere noch, weil der iimage-Browser individuelle Thumbnail-Größen zulässt, und auch jederzeit neue Thumbnails in verschiedenen Größen und Qualitätsstufen erzeugt werden können, das ist schon eine gute Sache. Dafür residiert ein Teil der benötigten Dateien im wp-admin Verzeichnis, was ebenfalls bei Updates etwas nervt. Ausserdem ist das Plugin uralt und gibt alleine deshalb schon ein nocht-ganz-so-gutes-Gefühl.

Das thickbox-Script erzeugt nicht-validen CSS-Code, damit muss ich im Moment leben. Grmpf. Bzw doch wieder das Thickbox-Plugin einsetzen, denn dort kann man auf das w3c-konforme "smoothbox" umstellen. Allerdings müsste ich dann alle class="thickbox" Anweisungen in allen Beiträgen auf class="smoothbox" abändern, und darauf habe ich im Moment keine Lust.