Peruns Weblog - Webwork und Internet

Ich habe das Vergnügen ab dem 10. Juli 2008 einen vierwöchigen Workshop bei Akademie.de zu leiten. Der Titel des Workshops ist:

Einfach zur professionellen Website - mit Wordpress als CMS

Damit betrete ich mit meiner Arbeit ein weiteres Neuland: einen Workshop habe ich bis jetzt nicht gehalten. Aber ich bin zuversichtlich dass das alles ganz gut fluppen wird. Und ja, ihr dürft den Workshop ruhig weiterempfehlen.

Der Hinweis von macx hat mich dann vor einigen Tagen doch dazu gebracht über den Einsatz eines WordPress-Plugins nachzudenken, die Code-Beispiele nicht nur formatieren sondern auch farblich hervorheben (Syntaxhighlightning).

Ich habe mich gegen so ein Plugin immer etwas gesträubt, weil ich sie erstens nicht für unbedingt notwendig hielt und weil ich mich dunkel erinnern konnte, dass ein Plugin in Verbindung mit Syntaxhervorhebung eine Sicherheitslücke in WordPress aufgerissen gehabt hat. Daher war ich etwas skeptisch.

Dann habe ich mich doch entschieden so ein Plugin (in meinem Fall WP-Syntax) einzusetzen, weil ich aus der neueren Zeit von keinen Problemen etwas lesen konnte und weil mich der Komfort dann doch überzeugt hat, hier ein Beispiel:

div#inhalt {
    background: #eee; color:#333;
    margin: 1em; padding: .5em;
    border: 1px dashed #900;
}

Man muss die Code-Sonderzeichen nicht maskieren, dass übernimmt das Plugin automatisch und dadurch, dass der Code innerhalb von einem <pre>-Element eingefügt wird, werden auch die Einrückungen berücksichtigt. Um die Syntaxhervorhebung auch zu erreichen muss man innerhalb des <pre>-Element ein lang-Attribut einfügen, z. B. <pre lang="php"> für ein PHP-Beispiel. Das ganze basiert auf GeSHi. So weit so gut.

Aber es gibt auch ein paar Punkte die mich stören. So wohl bei den WP-Plugins wie auch bei GeSHi werden die Code Beispiele durch span-Elemente und nicht durch code-Elemente ausgezeichnet. Semantisch ist das nicht richtig, weil eben das code-Element für Code-Beispiele vorgesehen ist.

Wenn ich dann noch die Zeilennummerierung einschalte, dann erstellen mir sowohl WP-Syntax wie WP-CodeBox eine Tabelle anstatt eine nummerierte Liste. Gut, jetzt kann man diskutieren, was in so einem Fall richtiger wäre: eine nummerierte Liste oder eine Tabelle. Ich persönlich finde auch eine Definitionsliste sinnvoll, weil ich einer Zeilennummer eine bestimmte Code-Zeile zuweise.

Auf jeden Fall finde ich keine der Lösungen perfekt und keine kommt an die Qualität eines Code-Beispiels ran, der manuell erstellt wurde. Auf der anderen Seite habe ich ehrlich gesagt auch keine Lust mehr, wie in den drei Teilen meiner WordPress-Serie hunderte von Code-Zeilen händisch einzupflegen. Ein Dilemma.

Gut zwei Wochen vor dem eigentlichen Erscheinungstermin ist die Version 2.5.1 von WordPress erschienen. An Hand der Versionsnummer kann man erkennen, dass es sich hierbei um ein kleines Update handelt: üblicherweise werden hier keine neuen Funktionen vorzufinden sein, es werden lediglich Fehler ausgebügelt und evtl. Sicherheitslöcher gestopft. Daher reicht es hierbei, dass "kleine Update" zu fahren, einfach das aktuelle Paket über das bestehende bügeln.

Nachtrag: auch wenn dieses Update klein ist. musste ich eben dennoch die upgrade.php aufrufen, da es (laut dem System) Änderungen an der Datenbank gab.

Folgende Änderungen gab es:

• Die Leistung (Performance) von "Dashboard", "Artikel schreiben" und "Kommentar bearbeiten" wurde verbessert
• Bessere Performance bei Weblogs mit vielen Kategorien
• Verbesserungen bei der Upload-Funktion, bei der Verwaltung von Widgets und bei (ich vermute mal) bei dem Layout des Admin-Bereiches im IE.
• Eine Schwachstelle (XSS) wurde gefixt
• Der WYSIWYG-Editor wurde auf die Version 3.07 aktualisiert
• u.v.m.

Na das wurde ja auch Zeit. Damit ich nicht wieder bei Adam und Eva anfange empfehle ich einfach die Lektüre des ursprünglichen Artikels: Optimaler Seitentitel in Wordpress. Dort habe ich erklärt wie ein "guter" Seitentitel ausschaut, warum so ein Seitentitel gut ist und wie man ihn mit Hilfe eines Plugins realisieren könnte.

In der Zwischenzeit verwendete ich folgenden Code anstatt des Plugins "Optimal Title" (siehe auch "WordPress-Themes verstehen 3"):

<?php if (is_home()) { ?>
    <title><?php bloginfo('name'); ?> - <?php bloginfo('description'); ?></title>
<?php }
elseif(is_category() or is_archive() or is_page() or is_single()) { ?>
<title><?php wp_title(''); ?> &raquo; <?php bloginfo('name'); ?></title>
<?php } else { ?>
    <title><?php bloginfo('name'); ?><?php wp_title(); ?> - <?php bloginfo('description'); ?> | <?php bloginfo(); ?></title>
<?php } ?>

Der obere Code war deswegen so lang, weil man vor Version 2.5 das Trennzeichen (Standard: ») nur ausblenden, aber nicht positionieren konnte. Seit der Version 2.5 gibt es eine viel einfachere Möglichkeit.

Zuerst die kurze Fassung:

<title><?php wp_title('&raquo;', true, 'right'); bloginfo('name'); ?></title>

Die wichtige Stelle habe ich hervorgehoben. Mittlerweile sind hier drei Parameter zulässig. Der erste ist für das Trennzeichen, der zweite Parameter bestimmt ob der Titel ausgegeben wird und mit dem dritten Parameter positioniert man das Trennzeichen.

Und hier dann die ausführlichere Fassung:

<?php if (is_home()) { ?>
    <title><?php bloginfo('name'); ?> - <?php bloginfo('description'); ?></title>
<?php } else { ?>
    <title><?php wp_title('&raquo;', true, 'right'); bloginfo('name'); ?></title>
<?php } ?>

Gefunden bei Mark.

Seit Juli 2007 läuft hier das Plugin "WordPress.com Stats". Das sind die 25 am häufigsten besuchte bzw. aufgerufene Beiträge und Seiten seit dem das Plugin aktiv ist:

Seit WordPress 2.5 wird man nicht nur, wie in der Vorgängerversion, benachrichtigt, dass es für ein Plugin ein Update gibt, sondern es wird die Möglichkeit angeboten das Plugin über das Admin-Menu zu aktualisieren. in beiden Fällen - Benachrichtigung und das Update - ist es notwendig, dass das Plugin auf der offiziellen Plattform gehostet wird.

Jetzt hat man drei Möglichkeiten: man ignoriert den Hinweis, man aktualisiert manuell oder man ruft den Link "aktualisiere automatisch" auf:

In die entsprechenden Felder gibt man dann die jeweiligen Infos ein und wählt aus ob das Update durch SSL gesichert wird oder nicht. Zur Info: die Hosting-Pakete von all-inkl.com unterstützen FTP über SSL (explizite Verschlüsselung). Wenn man das ganze dann abschickt, kümmert sich Wordpress um den Rest. Ist das Plugin zu dem Zeitpunkt aktiv, dann deaktiviert WP das Plugin und aktiviert es auch nach dem Update. Sehr komfortabel.

Wie schaut es mit der Sicherheit aus?

Das ist eine wichtige Frage. Sicherlich, die Funktion ist wirklich komfortabel, aber wie schaut es hier mit der Sicherheit aus (mit und ohne SSL)? Da ich kein Server-Admin und auch kein ausgewiesener Sicherheits-Experte bin, leite ich die Frage an die entsprechenden Personen?

Anscheinend bin ich nicht der einzige, der mit den Farben im Admin-Bereich von WordPress nicht so ganz zufrieden ist. Das Standard-Farbschema ist mir persönlich zu kontrastarm, es sind zu viele Farben und vor allem sind viele Farben kaum von einander zu unterscheiden.

Der Farbwechsel: "Benutzer" » "Dein Profil"

Daher wechselte ich zu dem "klassischen" Farbraum, der an die Farben aus den Versionen 2.0-2.3 angelehnt ist. Damit komme ich persönlich besser zu Recht. Frank bietet in seinem Weblog eine Plugin-Lösung an, die es einem ermöglicht weitere Farbschematas zuzufügen.