Eine Frage, die immer wieder – auch im s9y-Forum – gestellt wird, ist die nach dem Verzeichnis, in welchem statische Seiten abgelegt werden.

Die Antwort ist kurz: Nirgends.

Statische Seiten werden in s9y (wie meines Wissens in den meisten Blogsystemen) nicht als HTML-Datei auf dem Server erzeugt, sondern – genau wie Blogeinträge und die Seiten, welche von Plugins erzeugt werden – dynamisch aus der Datenbank generiert.

Wenn man also z.B. eine statische Seite /pages/impressum.html anlegt, dann gibt es nirgends im serendipity-Verzeichnis eine Datei namens impressum.html, auch wenn die Einstellungen des Plugins „Statische Seiten“ hier anderes vermuten lassen.

Die „statische“ Eigenschaft einer statischen Seite ist zumindest theoretisch eher die Tatsache, dass ihre Inhalte statischer Natur sind, also tendenziell eher selten bis nie geändert werden, z.B. bei einem Impressum oder einer „Über mich“-Seite.

Könnten diejenigen unter meinen Lesern, die den Mimbo-Port benutzen, mal überprüfen, ob das Kontaktformular bei ihnen auch jede Email, die darüber verschickt wird, mehrfach rausschickt? (Eigene Versuche ergeben 2 Emails, mir berichtet jemand von 4 pro Anlauf.) Und das dann bitte hier in den Kommentaren vermelden, idealerweise unter Angabe der Versionsnummer von s9y und Kontaktformular-Plugin?

Das wäre wirklich ganz reizend. Danke.

(Extrapunkte gibt es für Leute, die vielleicht ein „Sandkisten“-Blog – z.B. auf xampp-Basis – haben und das auch mal ausprobieren.)

Manchmal braucht man etwas, was eigentlich totaler Schwachsinn ist: Ein Bildschirmfoto, ugs. auch »Screenshot« genannt, einer Webseite. Die gängigen Werkzeuge dafür können aber nur einen tatsächlichen Screenshot, also einen Abzug des Bildschirms bzw. des aktuell dort sichtbaren Bereiches als Grafik, machen – was tun jedoch, wenn man eine Grafik der gesamten Webseite inklusive des Bereiches, in den man erst noch scrollen muss, braucht?

Man nehme Screengrab!, eine Extension für Firefox, die genau das und noch mehr kann: Die gesamte Seite, den sichbaren oder einen auswählbaren Bereich der Seite als Grafik (PNG oder JPG) speichern oder in die Zwischenablage kopieren.

Grob gesagt unterteilen sich die Nutzer von Serendipity bei der Erstellung von Einträgen meiner Erkenntnis nach in zwei Gruppen: Nutzer eines WYSIWYG-Editors und diejenigen, die reinen (X)HTML-Code in die Textkästen zur Eintragserstellung schreiben. Generell ist der zweite Ansatz vorzuziehen, wenn man Wert auf »sauberes« (lies: valides, semantisch korrektes) Markup legt, allerdings kann man das durchaus auch mit einem WYSIWYG-Editor erreichen, wenn man ein paar Spielregeln befolgt.

Eine echte, aber (soweit ich das mitbekomme) von s9y-Nutzern nur selten eingesetzte Alternative ist das Textile-Plugin (wird mit s9y ausgeliefert). Auch ohne Pluginaktivierung kann man Textile zunächst auf textism.com mal generell ausprobieren und sich von der schlichten Schönheit der Markup-Befehle überzeugen lassen. (Die wahre Schönheit von Textile besteht allerdings darin, dass es diese Auszeichungen stets in sauberes (X)HTML umsetzt.)

»Vorreiter« in puncto Textile mit Serendipity ist Robert, der seit einiger Zeit Textile benutzt. Bei Robert findet man bereits einige interessante Einblicke in die Arbeit mit Textile, u.a. den wichtigen Hinweis, Textile nicht mit dem Serendipity-Markup-Plugin zu mischen. (Zu dem anzumerken wäre, dass das Serendipity-Markup durch Textile ohnehin 100% überflüssig wird.)

Nachtrag: Auch das Plugin Typographic Smart Quotes (serendipity_event_typoquote) beißt sich mit Textile. Es verhindert die korrekte Auszeichnung von Hyperlinks, da es die in der Textile-Syntax notwendigen Anführungszeichen ebenfalls umwandelt.

Nachdem die notwendigen Anpassungen der Kern-Plugins in Serendipity so ziemlich abgeschlossen sind, geht es nun schrittweise an die sogenannten »additional plugins« – dabei handelt es sich, wie der Name bereits sagt, um zusätzliche Plugins, welche über Spartacus (bzw. das dazugehörige Plugin) nachinstallierbar sind.

Die Schwierigkeit in der Code-Aktualisierung jeglicher Plugins besteht in der Anforderung, die Ausgabe des Plugins möge mit dem veränderten Code idealerweise genau so aussehen wie vorher, damit möglichst wenige Templates aktualisiert werden müssen. Ein klassisches, leider sehr oft vorzufindendes Code-Beispiel in Plugins für s9y ist etwa so etwas:

<a href="...">...</a>
<br />
<a href="...">...</a>
<br />
[...]

Ich weiß nicht, wie man darauf kommt, so etwas zu verwenden – es ist doch ziemlich eindeutig, dass der semantisch korrekte Code für sowas eine ungeordnete Liste wäre:

<ul>
    <li><a href="...">...</a></li>
    <li><a href="...">...</a></li>
    [...]
</ul>

Nun gilt es jedoch, bei ungeordneten Listen (ul) die Bullets (•) und bei geordneten Listen (ol) die Numerierung zu vermeiden, um die »alte« Darstellung in s9y zu erhalten. Dafür haben wir auf Vorschlag von Garvin die neue CSS-Klasse plainList eingeführt. Diese erfordert folgenden Codeschnipsel in der style.css des verwendeten Templates:

.plainList {
    list-style: none;
    margin-left: 0;
    padding-left: 0;
}

Wichtig: Unbedingt die korrekte Groß-/Kleinschreibung beachten, plainlist und PlainList beispielsweise würden in CSS nicht erkannt!

Nun werden Listen, denen die Klasse plainList zugewiesen wurde (<ul class="plainList>, <ol class="plainList">), ohne Bullets oder Numerierung sowie ohne Einrückung und damit in (Seitenleisten-)Plugins genau so wie vorher dargestellt. (Wobei man natürlich diese Klasse auch z.B. in Blogeinträgen einsetzen kann.)