olshtyn.com - WordPress Projekt | WPPoland

#Zwei Leserschaften auf einer Startseite

olshtyn.com ist ein Stadtportal für Olsztyn, geschrieben für die Menschen, die dort leben, und für die, die einen Besuch planen. Olsztyn ist die Hauptstadt der Woiwodschaft Ermland-Masuren, hat rund hundertsiebzigtausend Einwohner, liegt an mehreren Seen innerhalb der Stadtgrenzen und hat eine Tourismussaison, die sich deutlich um den Sommer legt. Das klingt nach Landeskunde und war tatsächlich die Grundlage aller technischen Entscheidungen.

Der Einwohner kommt wegen der Aktualität zurück. Ihn interessiert, was gestern passiert ist und was am Wochenende stattfindet; er besucht das Portal oft und bleibt kurz. Der Gast kommt einmal, meist vom Telefon, meist von außerhalb der Region, und sucht das Dauerhafte: was sehenswert ist, wie man hinkommt, wo was liegt. Die erste Gruppe braucht einen Strom, die zweite eine Struktur. Ein Portal, das nur den Strom bedient, hat nach einem Jahr ein unlesbares Archiv. Ein Portal, das nur die Struktur bedient, gibt niemandem einen Grund zur Rückkehr.

Das Projekt wurde 2012 umgesetzt, umfasste auch die visuelle Identität und dauerte etwa sechs Wochen. An dieser Stelle steht in Fallstudien üblicherweise eine Tabelle mit Ergebniszahlen. Hier steht keine, und zwar bewusst: Reichweitenzahlen gehören dem Herausgeber des Portals, nicht unserer Projektbeschreibung. Erzählbar sind die Entscheidungen und ihre Folgen, und genau die lassen sich auf das nächste Projekt übertragen.

#Das Inhaltsmodell war die eigentliche Arbeit

Layout und Platzierung der Elemente kamen vom Kunden. Auf unserer Seite lag die Übersetzung in Templates, responsives Verhalten und eine Datenstruktur, die eine Redaktion ohne Entwickler pflegen kann.

Die Inhalte eines Stadtportals leben in drei verschiedenen Geschwindigkeiten. Eine Meldung hat wenige Tage Wert und interessiert danach nur noch Suchmaschinen. Eine Veranstaltungsankündigung ist bis zum Veranstaltungstag wertvoll und dreht danach ihr Vorzeichen um: Sie ist keine Einladung mehr, sondern Archiv. Ein Beitrag über ein Baudenkmal oder einen Uferweg altert überhaupt nicht und holt über Jahre Suchverkehr. Standard-WordPress wirft alle drei in denselben Topf und sortiert nach Datum, womit ausgerechnet das Beständigste zuerst aus dem Blickfeld verschwindet.

Es gibt deshalb drei Inhaltstypen: die Meldung, die Veranstaltung mit Datum und Ort, und das Ratgebermaterial ohne Verfallsdatum. Die Konsequenz zeigt sich erst nach einem Betriebsjahr. Eine abgelaufene Veranstaltung verschwindet von allein aus den Übersichten, statt dort zu hängen, bis jemand sie manuell entfernt. Ratgebermaterial konkurriert nicht mehr mit der Tagesmeldung um Platz, also muss niemand es monatlich mit einem künstlich erneuerten Datum nach oben schieben. Die Redaktion beantwortet die Frage nach der Materialart einmal beim Anlegen, statt die Sichtbarkeit wöchentlich zu überwachen.

Die Taxonomie wurde absichtlich schmal gehalten. Das verlockende Modell beschreibt alles gleichzeitig nach Stadtteil, Thema, Ereignis, Person und Ort. Am Starttag wirkt das flexibel, im sechsten Monat zerfällt es, weil zwei Redakteure dasselbe Material unterschiedlich einsortieren und das Archiv sich nicht mehr sinnvoll filtern lässt. Der Kategoriensatz ist kurz und geschlossen; alles wirklich Bewegliche steckt in freien Schlagwörtern, auf die keine Navigation aufbaut.

Auch die Adressen wurden als langfristiger Wert behandelt. Die Adresse eines Beitrags enthält den lesbaren Titel, kein Datum und keine numerische Kennung, und die Kategorie ist nicht Teil des Pfades. Kategorien werden irgendwann umsortiert, und die Adressänderung eines vor einem Jahr veröffentlichten Textes kostet Sichtbarkeit und erzwingt eine Weiterleitung. Eine Adresse, die nicht von redaktionellen Aufräumarbeiten abhängt, übersteht jede Umsortierung ohne Aufwand.

#Migration eines Archivs, das älter ist als die Seite

Ein Teil der Inhalte stammte aus früheren Ausbaustufen des Angebots und musste samt Historie übernommen werden. Der Import aus archivierten Beständen, unter anderem aus dem Web Archive, sieht nach einer Stunde Arbeit aus und dauert mehrere Tage, immer aus denselben Gründen.

Ältere Systeme arbeiteten mit anderen Zeichenkodierungen, weshalb polnische Diakritika aus einem Import als Bytesalat zurückkommen, sichtbar erst dann, wenn jemand den betreffenden Absatz tatsächlich liest. Alte Adressen haben eine andere Form als neue, also braucht jeder importierte Beitrag eine Weiterleitung von seiner früheren Adresse, sonst wirft die Seite jeden eingehenden Link und jede über Jahre aufgebaute Position weg. Archivierte Bilder sind oft unvollständig, und ihre Bildunterschriften stecken im Fließtext statt in einem Feld.

Die Reihenfolge war entscheidend: erst die Abbildung alter auf neue Adressen, dann der Inhaltsimport, zuletzt die manuelle Prüfung einer Stichprobe auf einer Produktionskopie. Die umgekehrte Reihenfolge endet in einem zweiten Import, denn Adressen nach dem Livegang zu korrigieren heißt, dass ein Teil des Verkehrs bereits ins Leere gelaufen ist.

#Caching und der Widerspruch, den ein Nachrichtenportal aushalten muss

Der Stack besteht aus WordPress auf PHP mit MySQL, Redis und Memcached als Zwischenspeicher, einem CDN davor sowie HTML5, CSS3, SASS und JavaScript auf der Browserseite. Der Code liegt versioniert in Git, der Datenaustausch mit dem Frontend läuft über AJAX und REST-Endpunkte.

Gegenüber einem Shop hat ein Nachrichtenportal beim Caching einen großen Vorteil: Fast jede Ansicht ist für alle Besucher identisch. Es gibt keinen Warenkorb, keine kundenspezifischen Preise, keine Sitzung, die in die Seite durchschlägt. Der überwiegende Teil der Seitenaufrufe lässt sich also ausliefern, ohne PHP überhaupt zu starten. Schwierig ist nicht das Caching, sondern die Invalidierung.

Eine zeitbasierte Ablauffrist ist hier das falsche Werkzeug. Setzt man sie lang, sieht die Redaktion ihren eigenen Artikel nicht und verlangt die Abschaltung des Caches, üblicherweise in der verkehrsstärksten Stunde des Jahres. Setzt man sie kurz, hilft der Cache genau dann nicht mehr, wenn er gebraucht wird. Invalidiert wird deshalb über ein Ereignis statt über eine Uhr: Das Speichern eines Beitrags leert die Startseite, die betroffenen Kategorieübersichten und die Adresse des Beitrags selbst, der Rest der Seite bleibt unberührt. Die Veröffentlichung wird zum Auslöser, die Redaktion sieht ihr Ergebnis sofort, und niemand muss den Wirkungsbereich auf die gesamte Seite ausdehnen.

Redis und Memcached tragen unterschiedliche Aufgaben. Der Objektcache verkürzt die Abfragen, die jede Anfrage ohnehin bezahlt, also Menüs, Kategorielisten und die schwereren Archivabfragen. Flüchtige Daten, die einen Neustart nicht überleben müssen, liegen getrennt davon. Diese Trennung hat einen betrieblichen Nutzen: Das Leeren des Objektcaches im Störungsfall wirft niemanden aus dem Redaktionsbereich.

Das CDN bildet die dritte Schicht und zählt vor allem für den auswärtigen Leser. Wer aus einer anderen Stadt oder vom Telefon im Roaming liest, bekommt statische Dateien von einem nahen Knoten, und der Anwendungsserver sieht diese Anfragen gar nicht erst. Beim bildlastigen Ratgebermaterial ist das die größte Einzelersparnis der gesamten Umsetzung.

#Nachladen von Inhalten und die Kosten, die man nicht sieht

Meldungslisten laden weitere Einträge asynchron über AJAX und eigene REST-Endpunkte nach, statt die Seite neu aufzubauen. Der Komfortgewinn ist offensichtlich, die zwei Kosten weniger, und 2012 waren sie leicht zu übersehen.

Die erste betrifft die Auffindbarkeit. Inhalt, der erst nach einem Klick erscheint, kann für einen Crawler unsichtbar sein. Die erste Portion jeder Liste steht deshalb direkt im Seitenquelltext, das Nachladen betrifft nur die Folgeseiten, und eine nummerierte Seitennavigation bleibt im Markup, auch wenn die Oberfläche sie nicht zeigt. Sie ist der Weg für den Crawler und für jeden Besucher ohne JavaScript.

Die zweite Kostenstelle ist der Cache. Ein Endpunkt, der einen Listenausschnitt zurückgibt, ist eine eigene Adresse. Entweder er hat eine eigene Cache-Politik, oder er wird zu dem Loch, durch das der Spitzenverkehr in PHP läuft. Die Antworten dieser Endpunkte werden deshalb wie Seiten zwischengespeichert und vom selben Veröffentlichungsereignis invalidiert.

Karten und Galerien folgen derselben Logik. Eine Karte eines externen Anbieters sind einige hundert Kilobyte Skript plus eine Verbindung zu einem fremden Server, bezahlt unabhängig davon, ob jemand die Karte überhaupt ansieht. Sie lädt erst, wenn der Besucher den Abschnitt mit dem Standort erreicht; bis dahin steht dort ein statisches Bild mit der Adresse. Für den mobilen Leser, der auf der Straße eine einzige Information prüfen will, entscheidet dieser Unterschied darüber, ob die Seite überhaupt aufgeht.

Bilder verdienen einen eigenen Satz, denn sie machen in einem Stadtportal den Großteil der übertragenen Bytes aus. Die Redaktion veröffentlicht direkt aus der Kamera, in einer Größe, die jede Ansicht der Seite um ein Vielfaches übersteigt. Die Verarbeitung beim Hochladen erzeugt Varianten für Liste, Beitragsansicht und Galerie, und das Template teilt dem Browser mit, welche Variante bei welcher Bildschirmbreite gilt. Ohne das lädt der mobile Leser ein Foto in Monitorgröße, bezahlt es mit Datenvolumen und Zeit, und die Redaktion erfährt nie davon, weil auf ihrer Leitung alles schnell wirkt.

#Wortmarke für einen Kopfbereich, nicht für eine Präsentation

Zum Projekt gehörte die visuelle Identität, und das Zeichen entstand für den Ort, an dem es wirklich lebt. Ein Portallogo verbringt den größten Teil seiner Zeit in einer Kopfleiste von wenigen Dutzend Pixeln Höhe, auf einem Telefon, neben einer Menüschaltfläche, und muss außerdem als Symbol im Browsertab erkennbar bleiben. Das dreht die Anforderungen gegenüber einem Druckzeichen um: Lesbarkeit im Kleinen, Verhalten auf einfarbigem Grund und eine vereinfachte Variante, die bei einem Dutzend Pixeln Breite nicht zerfällt. Ein rein horizontales Zeichen mit feinen Details sieht in der Präsentation gut aus und verschwindet im echten Kopfbereich, weshalb die Varianten zusammen mit den Templates entstanden und nicht vorher.

#Betrieb, Wartung und eine Regel zu Plugins

Ein Nachrichtenangebot kennt keinen Ruhezustand, deshalb wurde die Wartung zusammen mit der Umsetzung geplant und nicht danach: Aktualisierungen von Kern, Theme und Plugins, Durchsicht der Systemprotokolle, Sicherungen, deren Wiederherstellung tatsächlich geprobt und nicht nur eingerichtet ist, sowie kleine funktionale Anpassungen an die reale Arbeitsweise der Redaktion.

Eine Regel sei ausdrücklich genannt. Sicherheit wird hier im Code und in der Serverkonfiguration hergestellt, nicht durch ein weiteres Schutz-Plugin. Ein solches Plugin läuft innerhalb von PHP, also erst nachdem die Anfrage die Anwendung bereits gestartet hat, es wird regelmäßig selbst zur Schwachstelle, und es belastet jede einzelne Anfrage. Bei einem Portal mit ungleichmäßigem Verkehr, das den Ausschlag am Tag eines Stadtereignisses überstehen muss, ist das ein schlechter Tausch. Filterung am Eingang, Rechteprüfung im Code und eine harte Serverkonfiguration kosten weniger und greifen früher.

Die Entfernung eines Kommentars zu einer kommunalen Angelegenheit ist eine redaktionelle und keine technische Entscheidung. Deshalb bekam die Redaktion Moderationswerkzeuge und eine Warteschlange für zurückgehaltene Beiträge und ausdrücklich keinen Automatismus.

Die Diskussion unter Lokalnachrichten ist der lebendigste Teil eines Stadtportals und zugleich der Teil, der am häufigsten einen Menschen braucht. Ein automatischer Filter wäre billiger im Betrieb gewesen und hätte genau in den Fällen falsch entschieden, auf die es ankommt, nämlich dort, wo ein Einwohner der Verwaltung etwas vorwirft. Moderation ist damit ein dauerhafter Wartungsposten und keine einmalige Einrichtung.

Getestet wurde vor dem Start gegen eine Produktionskopie und nicht gegen eine leere Installation. Eine leere Installation hat zehn Beiträge, also passt jede Liste auf einen Bildschirm, jede Abfrage ist sofort fertig und ein Archiv existiert nicht. Die Probleme eines Portals beginnen bei einigen tausend Einträgen, wenn Kategorieseiten langsamer werden, die interne Suche nutzlos sortierte Treffer liefert und die Seitennavigation bis Seite zwanzig reicht, die im Test niemand geöffnet hat. Eine Produktionskopie zeigt all das in wenigen Minuten.

#Zusammenfassung und die Festlegungen der Analysephase

Die Analyse schloss vier Fragen, die danach jede weitere Entscheidung ordneten. Die Zielgruppe wurde doppelt definiert, als Einwohner und als Gast, mit der ausdrücklichen Annahme, dass beide Unterschiedliches wollen und die Startseite beide bedienen muss. Der Funktionsumfang umfasste Inhaltsverwaltung, Veranstaltungskalender, Standortkarten, Galerien und Kommentare. Der Zeitplan wurde in Etappen geteilt, sodass die Redaktion mit dem Befüllen beginnen konnte, bevor die letzten Arbeiten abgeschlossen waren. Als Referenz nannte der Kunde Portale mit starkem Gemeinschaftsbezug, weshalb Kommentare und Veranstaltungen hoch und dekorative Schichten niedrig eingestuft wurden. Keine dieser vier Festlegungen war technisch, und jede von ihnen entschied später über eine technische Frage.

Für eine spätere Umsetzung trägt die technische Schicht, und ebenso die Denkweise über Caching bei redaktionellen Inhalten. Nicht übertragbar ist das Inhaltsmodell dieses Projekts, denn es entstand für eine Stadt, eine Redaktion und einen Publikationsrhythmus, weshalb das nächste Portal mit der Frage beginnt, wer es liest und wie oft, und erst danach mit der Frage, was in die Datenbank gehört.