Mit den Piraten im Theme-Meer unterwegs

Pirate Rogue: Das WordPress Theme der Piratenpartei Deutschland
Keine Kommentare

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.

Abb. 1: Die Seite www.piratenpartei.de nach dem Relaunch

Abb. 1: Die Seite 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.

Abb. 2: Pads zur Ideensammlung

Abb. 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 werden.

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 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 . 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 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 der zum fast unverzichtbaren Werkzeug geworden ist. Daher bestand die erste Aufgabe darin, das vorhandene CSS in Sass umzuwandeln. Hierzu wurde das Onlinetool CSS2SCSS  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 aufgespaltet und es wurden einige hilfreiche Mixins hinzugefügt.

Abb. 3: Übersicht Sass-Dateistruktur

Abb. 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 hart kodierten Schriftangaben parametrisierte und die jeweils zur Schriftgröße passende Line-Height errechnet (Listing 1).

@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 WordPress Theme Piratenkleider wurde zuletzt etwa drei Dutzend Mal von verschiedenen Entwicklern weltweit geforkt, um eigene Änderungen einzuführen oder um am Projekt durch Codeeinreichungen teilzuhaben. Diese Community soll auch mit dem neuen Theme Pirate Rogue zurechtkommen können. Eine übersichtliche Struktur für die SCSS-Dateien ist daher an dieser Stelle genauso wichtig wie bei der Aufteilung der PHP-Dateien.
Mit einem geeigneten Editor werden die SCSS-Dateien bei einer Änderung automatisch kompiliert, sodass als Ergebnis eine CSS-Datei entsteht. Diese kann man wiederum so in style.css einbinden:

@import url(css/style.css);

Mit dem Umstieg auf Sass wurden die bisherigen Optionen im Theme abgeschafft, mit denen sich weitere CSS-Dateien über wp_enqueue_style() einbinden ließen. Ebenso entfernt haben wir alle Customizer-Optionen, die in die Gestaltung eingriffen, z. B. die Option, das Hauptmenü links, mittig oder rechts auszurichten. Im Sinne des gemeinsamen Erscheinungsbilds sollten diese Freiheiten nicht mehr gegeben sein. Dies gilt auch für die Auswahl von Farben für Hintergründe und Schriften sowie die Positionierung des Logos. Gleichzeitig sorgt es dafür, dass keine Inline-Stylesheets mehr erzeugt werden müssen. Dort, wo man Optionen im Design belassen wollte, ließ sich dies über das Setzen von CSS-Klassen im <body>-Element mittels der Funktion pirate_rogue_body_class() regeln. Diese wird als Filter aufgerufen, so dass die nativen WordPress-Klassen ergänzt werden:

add_filter( 'body_class', 'pirate_rogue_body_class' );

So wurde beispielsweise für das Setzen des Farbstils der Social-Media-Icons folgende Bedingung eingebaut:

if ('colorful' != get_theme_mod( 'pirate_rogue_socialmedia_style' ) ) {
  $classes[] = 'socialmedia-'.get_theme_mod( 'pirate_rogue_socialmedia_style' );
}

Im Customizer wurde zuvor die Option geschaffen, eine Hauptfarbe für das Theme festzulegen. Die bisherige freie Wahl von Farben aus einer Palette steht nicht mehr zur Verfügung. Stattdessen sind die zwei möglichen Standardfarben des Designs fest vorgegeben: Orange und Lila. Bei der Konfiguration bleibt dem Administrator somit nur noch die Wahl, eine der Hauptfarben zu wählen. Für die Icons in der Suche und das Hamburger-Symbol besteht lediglich noch ein Fallback in Form eines dunklen Graus; bei der Anzeige der Social-Media-Icons gibt es zudem noch die Option, diese „bunt“ anzuzeigen, also in der Farbe, die die jeweilige Social-Media-Plattform für ihr Icon üblicherweise nutzt (Listing 2).

$wp_customize->add_setting( 'pirate_rogue_socialmedia_style', array(
  'default'            => 'colorful',
  'sanitize_callback'  => 'pirate_rogue_sanitize_socialmedia_style',
) );

$wp_customize->add_control( 'pirate_rogue_socialmedia_style', array(  
  'label'         => esc_html__( 'Social Media Icon Style', 'pirate-rogue'),
  'description'   => esc_html__( 'Choose the color of the social media icons.', 'pirate-rogue'),
  'section'   => 'pirate_rogue_header',
  'priority'  => 3,
  'type'      => 'select',
  'choices'   => array(
    'colorful'      => esc_html__( 'Colorful Social Media Icons', 'pirate-rogue'),
    'maincolor'     => esc_html__( 'Use main color', 'pirate-rogue'),
    'secondcolor'   => esc_html__( 'Use second color', 'pirate-rogue'),
  ),
) );
function pirate_rogue_sanitize_socialmedia_style( $pirate_rogue_socialmedia_style ) {
  if ( ! in_array( $pirate_rogue_socialmedia_style, array( 'colorful', 'maincolor', 'secondcolor' ) ) ) {
    $pirate_rogue_socialmedia_style = 'colorful';
  }
  return $pirate_rogue_socialmedia_style;
}  

Für die Darstellung musste nun noch eine entsprechende CSS-Klasse definiert werden (Listing 3). Sie findet sich in der Datei css/sass/elements/_social-media.scss.

socialmedia-maincolor .social-nav ul li {
  a {
    color: $color-main;
    background-color: $color-page-background;
    border-color: $color-page-background;
    &:focus,
    &:hover {
      background:  $color-second;
      color: $color-page-background;
      border-color: $color-second;
    }
  }
}

Das komplette Theme und alle dazugehörigen Komponenten, wie beispielsweise Fonts und JavaScript-Skripte, müssen vollständig vom eigenen Server geladen werden. Fonts von https://fonts.google.com zu laden, ist darum nicht möglich. Im Original von Uku wurden die Fonts in der functions.php so eingebunden:

wp_enqueue_style( 'uku-fonts', uku_fonts_url(), array(), null );

Ausgehend von der Konfiguration des Themes berechnet die Funktion uku_fonts_url() dazu die URLs der jeweiligen Fonts. Das Theme verwendet die Fonts Noticia Text, Kanit, Source Serif Pro, Poppins und Cormorant Garamond. Der Admin kann im Customizer durch die Wahl des Designstils die Fonts für das Frontend festlegen. Beim Standarddesign von Uku ist Noticia Text voreingestellt, wie in Listing 4 zu sehen ist.

if ( 'off' !== esc_html_x( 'on', 'Noticia Text font: on or off', 'uku' ) && 'standard' == get_theme_mod( 'uku_main_design' ) || '' == get_theme_mod( 'uku_main_design' ) ) {
  $fonts[] = 'Noticia Text:400,400italic,700,700italic';
}

if ( $fonts ) {
  $fonts_url = add_query_arg( array(
    'family' => urlencode( implode( '|', $fonts ) ),
    'subset' => urlencode( $subsets ),
  ), 'https://fonts.googleapis.com/css' );
}
return $fonts_url;

Im Frontend erzeugte der Code aus Listing 4 dann die folgenden HTML-Anweisungen:

<link rel='stylesheet' id='uku-fonts-css' href='https://fonts.googleapis.com/css?family=Noticia+Text%3A400%2C400italic%2C700%2C700italic%7CKanit%3A400%2C500%2C600%2C700&subset=latin%2Clatin-ext' type='text/css' media='all' />

In der hier referenzierten CSS-Datei finden sich Anweisungen wie die in Listing 5.

@font-face {
  font-family: 'Noticia Text';
  font-style: italic;
  font-weight: 700;
  src: local('Noticia Text Bold Italic'), local('NoticiaText-BoldItalic'), url(https://fonts.gstatic.com/s/noticiatext/v6/-rQ7V8ARjf28_b7kRa0Julh3o8VkC1exAYQ700cRowo.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215;
}

Kurzum: Bei jedem Aufruf jeder Seite der Website wird eine Verbindung zu Google aufgebaut, um von dort eine CSS-Datei zu laden. In der CSS-Datei sind dann wiederum die jeweils notwendigen Schriften referenziert, die dann ebenfalls von Google geladen werden. Und dass Google jeden Zugriff auf seine Server speichert und auswertet, dürfte kaum zu bezweifeln sein.

Die Konsequenz ist klar: Sowohl das CSS als auch die Fontdatei müssen auf dem eigenen Server liegen. Und erfreulicherweise ist Google nicht wirklich böse, sondern erlaubt unter https://fonts.google.com/ den Download und den Einsatz der Schriften auf eigenen Servern.

Das Theme verwendet die Schrift Roboto von Google und die freie Variante der Schrift DejaRip von Anatoletype. Die entpackten Schriftdateien liegen im Theme-Ordner fonts/. Die Implementierung der Schriften in das Theme erfolgt nicht mehr über ein eigenes wp_enqueue_style(). Stattdessen sind die Fonts fest in das CSS des Themes integriert. Die freie Auswahl der Schriften via Customizer ist nicht mehr möglich. Die Referenzierung der Schrift im CSS erfolgt in der SCSS-Datei css/sass/fonts/_font_roboto.scss. In Listing 6 ist ein Auszug aus der Datei zu sehen.

font-face {
  font-family: 'roboto';
  src: url('../fonts/roboto/Roboto-Regular-webfont.eot');
  src: url('../fonts/roboto/Roboto-Regular-webfont.eot?#iefix') format('embedded-opentype'),
     url('../fonts/roboto/Roboto-Regular-webfont.woff') format('woff'),
     url('../fonts/roboto/Roboto-Regular-webfont.ttf') format('truetype'),
     url('../fonts/roboto/Roboto-Regular-webfont.svg#robotoregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

Bessere Barrierefreiheit

Obwohl Uku an den meisten Stellen schon sauber strukturiert ist, gab es noch ein paar Dinge zu verbessern. In der header.php wurden Skip-Links eingebaut (Listing 7). Diese helfen Menschen, die mit Screenreader surfen, schnell zu wichtigen Bestandteilen des Inhalts zu springen. Zudem sind die Links nützlich für verschiedene Bots, die damit ebenfalls Bestandteile der Seite einordnen können.

<nav id="skiplinks" aria-label="<?php _e('Skiplinks', 'pirate-rogue'); ?>">
  <ul>
    <li><a href="#overlay-wrap" data-target="#overlay-wrap" data-firstchild="0" class="jumplink-content"><?php _e('Content','pirate-rogue'); ?></a></li>
    <li><a href="#masthead" data-target="#desktop-navigation" data-firstchild="1" class="jumplink-nav"><?php _e('Main Menu','pirate-rogue'); ?></a></li>
    <li><a href="#footer-search" data-target="#footer-search" data-firstchild="1" class="jumplink-nav"><?php _e('Search','pirate-rogue'); ?></a></li>
    <li><a href="#colophon" data-target="#colophon" data-firstchild="1" class="jumplink-nav"><?php _e('Footer','pirate-rogue'); ?></a></li>
  </ul>
</nav>

Über eine CSS-Anweisung ist der Bereich mit der id=“skiplinks“ für die normale Desktopdarstellung unsichtbar. An weiteren Stellen wurden WAI-ARIA Roles eingefügt, um Inhaltsbereiche entsprechend ihrer Funktion kenntlich zu machen oder um sie für Screenreader zu verbergen, so zum Beispiel bei den Thumbnails (Listing 8).

<div class="entry-thumbnail fadein" aria-hidden="true" role="presentation" tabindex="-1">
  <a href="<?php the_permalink(); ?>"><span class="thumb-wrap"><?php the_post_thumbnail('pirate-rogue-standard-blog'); ?></span></a>
</div><!-- end .entry-thumbnail -->

Bei dem Thumbnail einer Blogroll handelt es sich um ein repräsentatives Element, das zumeist aus Usabilitygründen mit dem Artikel verlinkt ist. Für die Nutzer von Screenreadern ist das Bild jedoch nicht hilfreich, im Gegenteil sogar: Da durch the_post_thumbnail() das alt-Attribut mit der Bildbeschreibung gefüttert wird, erfährt der Zuhörer zwar, was das Bild ausdrücken soll, aber nicht, wohin es verlinkt. Wenn ein grafisches Element ein Link ist, muss das Linkziel im Alternativtext stehen und nicht die Bildbeschreibung. Die Lösung, den Link wegzunehmen, ist nicht ratsam, da sich dies auf die Usability der sehenden Nutzer negativ auswirkt, die gewohnt sind, auf das Bild zu klicken.

<div class="entry-thumbnail fadein" aria-hidden="true" role="presentation" tabindex="-1">

Das Problem ließ sich dadurch lösen, dass Screenreader an den Attributen aria-hidden=“true“ und role=“presentation“ erkennen, dass der Inhalt des div-Bereichs nur der Präsentation dient und nicht angezeigt, sprich vorgelesen, werden soll. Gemäß W3C sollte eigentlich das Attribut aria-hidden=“true“ allein ausreichen. Da aber manche Screenreader-Software noch nicht so weit ist und stattdessen auf die role=“presentation“ zurückgreift, sind hier beide Attribute integriert. Der Web-Accessibility-Veteran John Foliot hat hierzu eine weiterführende Analyse durchgeführt.

Schließlich wurde noch das Attribut tabindex=“-1″ eingefügt, damit Tastaturbenutzer den Link um das Bild herum überspringen können. Für diese wäre der Link redundant und daher störend, weil direkt danach noch einmal derselbe Link mit der Überschrift des Artikels steht. Ein weiterer kleiner Trick zur Verbesserung der Barrierefreiheit findet sich bei der Datumsanzeige. Auch hier besteht das Problem, dass das Datum verlinkt und wegen dem danach folgenden verlinkten Titel des Blogposts redundant ist.

<span class="entry-date" aria-hidden="true">
<a href="<?php the_permalink(); ?>"><?php echo get_the_date(); ?></a>
</span><!-- end .entry-date -->

Die Verlinkung des Datums mit dem Artikel wollen wir auch beibehalten. Sie ist in Blogs etabliert und wird daher von vielen erwartet. Für Screenreader-Nutzer haben wir daher wieder aria-hidden=“true“ gesetzt. Damit Screenreader-Nutzer nun das Datum trotzdem mitgeteilt bekommen, ohne dass dadurch redundante Links entstehen, gibt es eine Ergänzung im Titel:

echo '<h2 class="entry-title"><a href="'.esc_url( get_permalink() ).'" rel="bookmark">';
echo get_the_title();
echo '</a><span class="screen-reader-text"> ('. get_the_date().')</span></h2>';

Die CSS-Klasse screen-reader-text sorgt wie oben die ID skiplinks dafür, dass das Datum in der Desktopansicht unsichtbar ist.

Shortcodes und Optimierungen

Da die Website kein klassischer Blog ist, fehlt auch eine normale Blogroll. In der vorherigen Version der Website war diese auf der Startseite zwar noch vorhanden, jedoch zeigten Analysen und gesammeltes Feedback, dass dies nicht optimal war: Die Besucher der Webseite hatten weniger Interesse daran, die Meldungen zu verfolgen als konkrete Informationen abzufragen. Wer hingegen nur auf die Meldungen zugreifen wollte, rief diese meist nicht über den häufigen Besuch der Startseite ab, sondern via RSS oder eigene Inhaltsaggregatoren.

Daher haben wir entschieden, dass die Startseite zu den wichtigsten Inhalten und Kampagnen leiten soll. Zwar soll auch ein Auszug aus einer Blogroll vorhanden sein, diese sollte aber ans Ende der Seite wandern. Zudem gab es den Wunsch, dass auch auf anderen statischen Seiten ein Teil der Blogroll enthalten sein soll (vgl. auch hier), meist gefiltert anhand einer Kategorie oder eines Tags. Die normale Kategorieansicht war hierzu nicht ausreichend.

Um einen entsprechenden Shortcode anzulegen, haben wir zunächst einen Template-Part (template-parts/content-blogroll.php) für die einzelnen Artikel der Blogroll angelegt. Als Eingabeparameter akzeptiert der Shortcode Attribute für Kategorien, Schlagworte und die Anzahl der anzuzeigenden Artikel. Diese werden nach einer optionalen Umwandlung in IDs für die Query genutzt (Listing 9).

$pirate_rogue_blogroll_query = new WP_Query( array(
  'posts_per_page'  => $num,
  'tag_id'          => $posttag,
  'cat'             => $postcat,
  'post_status'     => 'publish',
  'ignore_sticky_posts'   => 1,
) );


$out = '<section class="blogroll '.$divclass.'">';
if($pirate_rogue_blogroll_query->have_posts()) :
while($pirate_rogue_blogroll_query->have_posts()) :
  $pirate_rogue_blogroll_query->the_post();  
    $out .= pirate_rogue_load_template_part('template-parts/content-blogroll' );
endwhile;
endif; // have_posts()

wp_reset_postdata();
$out .= '</section>';

Neben der Blogroll wurde zusätzlich für die Verwendung in der Sidebar und an anderen Stellen im Text, in denen keine großen Artikelblöcke gewünscht wurden, noch ein Shortcode für Artikellisten angelegt. Dieser gibt die Blogroll in Form einer einfachen Liste zurück, die keine Bilder oder andere Daten enthält, sondern nur die Titel der jeweiligen Artikel. Weiterhin haben wir Shortcodes für die Darstellung von Inhaltsboxen und von Accordions eingebaut. Letzteres widerspricht den Coding-Standards von WordPress, die solche Funktionen als Plug-in-Domäne ansehen. Der Grund für diese Entscheidung ist hier jedoch der enge zeitliche Horizont und die Erwägung, dass das Theme möglichst auch ohne obligatorisches Plug-in-Bundle zum Einsatz kommen soll. An dieser Stelle kann es jedoch in Zukunft Änderungen geben, um die Regelkonformität wiederherzustellen.

Bei einer gut besuchten Website ist das Thema Performance von zentraler Bedeutung. Dies betrifft allerdings nicht nur die Serverseite, sondern auch die des Browsers. Im Theme verzichtete man daher an verschiedenen Stellen so weit wie möglich auf unnötigen HTML-Code oder versuchte, diesen zu reduzieren. Auch die Anzahl der zu ladenden Dateien sollte möglichst gering ausfallen. Die Nutzung von Sass sorgt bereits dafür, dass die erzeugte CSS-Datei komprimiert ist. Auch der Customizer lädt nicht mehr alle weiteren CSS-Dateien, die von den Optionen abhängig sind. Änderungen am Stil funktionieren stattdessen über das Ergänzen einer CSS-Klasse im <body>-Element.

Die im ehemaligen Uku Theme getrennten JavaScript-Dateien werden nicht mehr einzeln geladen, sondern in einer einzigen JavaScript-Datei vereinigt. Davon ausgenommen sind nur die JavaScript-Datei slick.min.js für den Slider mit herausragenden Artikeln und eine Datei mit jQuery-Bibliotheken. Die JavaScript-Datei für den Slider wird zudem nur auf solchen Seiten geladen, auf denen dieser auch tatsächlich erscheint (Listing 10).

if (is_home() &&
  ( '' != get_theme_mod( 'pirate_rogue_featuredtag' )  || '' != get_theme_mod( 'pirate_rogue_featuredcat' ) )) {
    wp_enqueue_script( 'pirate-rogue-slick' );
}

Eine weitere Maßnahme, um die Performance der Website zu verbessern, bestand darin, dafür zu sorgen, dass die verschiedenen Autoren keine riesigen Bilder hochladen und bereitstellen können. Schließlich ist es nicht sinnvoll, im Frontend um jedes einzelne Byte zu kämpfen und dann festzustellen, dass ein Autor mal eben so ein über 5 000 Pixel breites Bild hochlädt – einfach weil dieser nicht dran denkt, dass das ein Problem sein könnte, oder auch, weil dies von einer Quasiliveberichterstattung via Smartphone geschieht, wo ein vorheriges Skalieren mit einem Bildbearbeitungsgrogramm nicht möglich ist.

Hierfür wird das Plug-in Imsanity verwendet. Imsanity (Abb. 4) sorgt dafür, dass ein Bild nach dem Hochladen eine vorgegebene maximale Höhe und Breite einnimmt. Zu große Bilder werden entsprechend verkleinert. Der Vorteil von Imsanity gegenüber anderen Plug-ins besteht darin, dass Autoren weiterhin auch große Bilder hochladen können, diese aber automatisch ohne weiteres Zutun herunterskaliert werden. Andere Plug-ins, die schlicht den Upload abbrechen und eine Warnmeldung ausgeben, stören dagegen nur den Arbeitsablauf.

Abb. 4: Screenshot: Imsanity

Abb. 4: Screenshot: Imsanity

Plug-in Pirate-Crew

Für die Darstellung von Personenprofilen haben wir ein Plug-in namens Pirate-Crew entwickelt. Dieses Plug-in unterscheidet sich nicht sonderlich von anderen Plug-ins für Profile oder Teamseiten: Daten von Personen werden als Custom Post Type abgelegt und angezeigt, wenn ein Shortcode im Content oder in die Sidebar eingebaut wird.

Den meisten Plug-ins ist aber zu eigen, dass sie eigenes CSS und oft auch eigenes JavaScript laden. Dieses wird dann auch auf jeder Seite geladen, egal, ob notwendig oder nicht. Viele Themes ändern zwar die Ausgabeoptik von bekannten Plug-ins durch eigene CSS-Anweisungen, greifen aber nicht in das Ladeverhalten der Plug-ins ein. Die CSS-Anweisungen im Theme überschreiben nur die CSS-Anweisungen des Plug-ins. Im Endeffekt kann dies dazu führen, dass das Plug-in überflüssigen Code lädt und der Browser auch unnötig Zeit mit der Interpretation von Darstellungen verschwendet, die danach vom Theme-CSS doch wieder ausgeblendet oder anders dargestellt werden. Um dies zu vermeiden, prüft das Plug-in, welches Theme aktiv ist (Listing 11).

public function embed_front_script_styles() {

  $my_theme = wp_get_theme();  
  $my_theme_name = $my_theme->get( 'Name' );


  if (!in_array($my_theme_name, Pirate_Crew::$themeswithowncss)) {
  wp_enqueue_script('pirate-crew', plugins_url('js/team.min.js', $this->settings['plugin_file']), array('jquery'), $this->settings['plugin_version'], true);
  wp_enqueue_style('pirate-crew', plugins_url('css/team.css', $this->settings['plugin_file']), false, $this->settings['plugin_version'], 'all');
  }
}

Der Name des Themes wird in den Defaultwerten des Objekts angegeben:

public static $themeswithowncss = array('Pirate Rogue');

In anderen Worten: Wenn das Theme Pirate Rogue aktiv ist, bindet das Plug-in kein eigenes JavaScript und CSS ein. Wird das Plug-in hingegen von anderen Themes verwendet, laden das mitgelieferte JavaScript und CSS ganz normal. Im Theme wiederum sind die nötigen Anweisungen enthalten, dort jedoch im Falle des CSS als Teil der Sass-Dateien und im Fall des JavaScripts in der komprimierten JavaScript-Datei, die auch alle anderen JavaScript-Anweisungen enthält. Alle oben genannten beispielhaften Performanceoptimierungen machen für sich genommen wenig aus. Zusammengenommen ist die Wirkung dann aber doch mess- und spürbar. Die durchschnittliche Dauer des Herunterladens pro Seite sank laut Google-Webmasters-Tools von etwas über einer Sekunde auf 311 Millisekunden. Bei einer ausgewählten statischen Testseite mit nur einem Artikelbild, aber mit aktivierten Plug-ins, sank die Anzahl der Requests zum Laden von JavaScript, CSS, Bildern etc. von 48 auf 15 und die Ladezeit auf 176 Millisekunden.

Dies wurde allein durch den Wechsel des Themes und unabhängig von Performancemaßnahmen (wie z. B. Caching) des Servers erreicht. Zum Vergleich: Die Demoseite des Divi-Themes erzeugte 109 Requests und benötigte eine Ladezeit von 1 706 Millisekunden.

Damit das Theme durch verschiedene Beteiligte und Interessierte weiterentwickelt werden kann, steht es mittlerweile auf GitHub zur Verfügung. Die Dokumentation und Demo des Themes finden sich unter http://www.pirate-rogue.de/.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -