© bazzier/Shutterstock.com, © Color Symphony/Shutterstock.com
Pirate Rogue: Das WordPress Theme der Piratenpartei Deutschland

Mit den Piraten im Theme-Meer unterwegs


Die Piratenpartei Deutschland nutzt seit 2012 WordPress als CMS für ihre zentrale Website. Im Wahlkampfjahr 2017 war es höchste Zeit, das alte, gewachsene und in die Jahre gekommene Theme durch etwas Neues zu ersetzen. So ist das Theme Pirate Rogue entstanden.

Im Wahlkampf 2017 erhielt die Website der Piratenpartei Deutschland ein neues Theme: Pirate Rogue (Abb. 1). Das geschah natürlich unter den besonderen Herausforderungen der Piraten: Mit einem Budget von ganzen 0 Euro, einem unerschöpflichen Schatz an Visionen und Meinungen von Teammitgliedern sowie ganz konkreten Leitplanken bei verfügbarer Technik und Privacy-Anforderungen.

wiese_pirate_rogue_1.tif_fmt1.jpgAbb. 1: Die Seite https://www.piratenpartei.de/ nach dem Relaunch

Die Sammlung der Anforderungen an Design, Inhalte und Funktionen für den Relaunch fand, wie für die Piraten üblich, nicht etwa im kleinen Team statt. Stattdessen konnte sich jeder mit eigenen Vorschlägen daran beteiligen. Hierzu wurden diese zunächst in öffentlich beschreibbaren Pads gesammelt (Abb. 2). Nach einer Weile sichtete man alle Vorschläge und fasste sie nach Themengebieten zusammen: Inhalte und deren Taxonomie, Design, Technik, Erfahrungen u. a. Mit diesen Grundlagen konnte das Projekt in einer kleineren Gruppe starten.

wiese_pirate_rogue_2.tif_fmt1.jpgAbb. 2: Pads zur Ideensammlung

Am Anfang der Entwicklung stand die Frage im Vordergrund, ob man ein eigenes neues Theme baut, ein vorhandenes Theme mit einem Page Builder oder eigenen Anpassungsmöglichkeiten nutzt oder ob man ein vorhandenes Theme als Grundlage nimmt und dann ändert. Das Theme sollte nicht nur für die zentrale Website Anwendung finden, sondern allen Gliederungen der Partei und Interessierten offenstehen, unabhängig von dem jeweils vorhandenen oder nicht vorhandenen Know-how. Da davon auszugehen ist, dass das Theme in vielen Fällen von Ehrenamtlichen und Laien nebenher eingerichtet werden soll, durfte es die jeweiligen Administratoren nicht durch eine Fülle von Funktionen erschlagen. Ein zu großer Funktionsumfang und viele unterschiedliche Konfigurationsmöglichkeiten zur Darstellung hätten somit kontraproduktiv gewirkt. Grundsätzlich musste das Theme out of the box auf bereits bestehenden WordPress-Instanzen funktionieren, ohne dass umfangreiche Änderungen oder der Einsatz von Plug-ins notwendig wurden.

Laut Statistik wird die Website derzeit zu 48,2 Prozent über Smartphones aufgerufen, soweit identifizierbar. 44,7 Prozent der Aufrufe stammen von Desktopgeräten. Die am meisten verwendeten Bildschirmauflösungen sind 360 x 640 (27,9 Prozent), 1 920 x 1 080 (11,9 Prozent), 375 x 667 (8,9 Prozent) und 1 366 x 768 (6,4 Prozent). Das Design musste somit nicht etwa nur Smartphones unterstützen, sondern gleichzeitig auch große Bildschirmauflösungen von modernen Monitoren, die Auflösungen über 1 366 Pixel anzeigen.

Dass das Theme auf technischer Ebene die wesentlichen Anforderungen der Barrierefreiheit erfüllen musste, war eine Selbstverständlichkeit. Schließlich fragen wir beim Kauf eines Autos auch nicht, ob es denn Bremsen habe. Zuallerletzt sollte es soweit möglich performant sein und Suchmaschinen durch eine sinnvolle Semantik und den Einsatz von strukturierten Daten via Schema. org unterstützen. Die konkreten Anforderungen lauteten somit wie folgt:

  • Klares, übersichtliches Design, das die Inhalte in den Vordergrund stellt; kein Design, das nur von schönen Bildern lebt

  • Nutzbarkeit auch für gesonderte Kampagnenwebsites

  • Leicht auch von Ehrenamtlichen und Laien zu verwenden

  • Barrierefrei

  • Performance und Nutzung von strukturierten Daten

  • Offen für Weiterentwicklung

  • Kein Tracking durch externe Quellen

Uku: Ein mustergültiges Theme wird angepasst

Ein vorheriges Projektteam hatte sich zuvor für die Nutzung von Divi von Elegant Themes [1] ausgesprochen, war jedoch von dessen Möglichkeiten überfordert. Weder konnte damit vom Team ein fertiges Design bereitgestellt werden noch ein funktionierender Pilot, der auch nur ansatzweise die Mindestanforderungen an Performance oder den Verzicht auf fremde Datenquellen erfüllte. Ein weiteres Theme, das in der Diskussion stand, war Aaika [2]. Aber auch bei Aaika sorgten sowohl die mangelhafte Performance als auch die für ehrenamtliche Administratoren aufwendige Konfiguration dafür, dass es nach ersten Tests verworfen wurde. Es blieb die Wahl zwischen einer kompletten Eigenentwicklung oder der Anpassung eines existierenden Themes. Aufgrund der begrenzten Zeit (für die Entwicklung des Themes sowie des dazugehörigen Relaunches der Website blieben aus organisatorischen Gründen nur drei Monate) wurde entschieden, ein anderes Theme als Vorlage zu benutzen. Das Theme Uku von Elmastudio [3] bot die perfekte Grundlage.

Uku verfügt über ein minimalistisches Design, das gut an die eigenen Bedürfnisse angepasst werden kann. Noch besser ist jedoch, dass der Code aufgeräumt und sehr gut strukturiert ist. Wiederkehrende Codefragmente werden im Verzeichnis template-parts/ abgelegt und lassen sich mithilfe von get_template_part() einbinden. Funktionen des Themes werden aus der functions.php in Libraries im Verzeichnis inc/ ausgelagert. Andere Bestandteile des Themes, wie JavaScript-Code, Fonts, Seitentemplates und Sprachdateien, finden sich an gewohnter Stelle. Zur Konfiguration des Themes wird auf den Customizer gesetzt, kurzum: ein mustergültiges Theme.

Auch wenn Uku schon viele Wünsche erfüllte, gab es dann doch einige Dinge, die geändert werden mussten, um die oben genannten Anforderungen zu erfüllen. Insgesamt haben wir 170 Änderungen und Korrekturen vorgenommen, was sich auf ca. 150 000 Lines of Code auswirkte. Aktuell warten noch 20 Änderungsvorschläge auf Behandlung.

Ein weiteres eingesetztes Tool für die Entwicklung des Webdesigns ist der CSS-Präprozessor Sass [4], der zum fast unverzichtbaren Werkzeug geworden ist. Daher bestand die erste Aufgabe darin, das vorhandene CSS in Sass umzuwandeln. Hierzu wurde das Onlinetool CSS2SCSS [5] verwendet, bei dem man das vorhandene CSS einfügen kann und einen SCSS-Code erhält. Der erzeugte Sass-Code wurde danach in verschiedene Dateien und Verzeichnisse aufgespalten, und es wurden einige hilfreiche Mixins hinzugefügt.

wiese_pirate_rogue_3.tif_fmt1.jpgAbb. 3: Übersicht Sass-Dateistruktur

Aktuell besteht die Struktur der SCSS-Files (Abb. 3) aus mehreren Dutzend Dateien. Einzelne Elementdefinitionen liegen in einzelnen Dateien und sind von den Struktur- und Blockdefinitionen getrennt (Stichwort: atomares Design). Für die Normalisierung der Schriften wurde eine mixin px2rem() eingebaut, die alle bisherigen hartcodierten Schriftangaben parametrisierte und die jeweils zur Schriftgröße passende Line Height errechnet (Listing 1).

Listing 1: Normalisierung der Schriften

@function px2rem($font-size, $base-font-size: 16) { @return $font-size / $base-font-size + rem; } @mixin px2rem($font-size, $base-font-size: 16, $line: $font-size * 1.4) { font-size: $font-size + px; // für den IE8 line-height: ($line) + px; font-size: px2rem($font-size, $base-font-size); line-height: ($line / $base-font-size) + rem; }

Ebenso wurden Anweisungen für die Anpassung der Ausgaben diverser Plug-ins in eigenen Dateien abgelegt. Der Aufwand begründet sich darin, dass das Theme während der Umstellung und danach nicht von einer Person allein bearbeitet wird. Auch in einem Jahr noch sollen andere Entwickler und Webdesigner einen leichten Einstieg in das Theme finden, um es ändern oder weiterentwickeln zu können. Auch das von den Piraten vorher verwendete WordPr...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang