Artikel von Kirsten

Hallo, mein Name ist Kirsten Schelper. Ich bin Webdesignerin aus München mit einer Passion für italienischen Kaffee, vegetarische Küche und Fahrradfahren. Ihr findet mich nicht bei Facebook, dafür aber auf Twitter und auf Google+.

Unscharfe Beitragsbilder nachschärfen

WordPress erzeugt zu jedem Bild, das man hochlädt, eine kleine Serie von verkleinerten Versionen. Das ist sehr praktisch, weil man dadurch alle Bilder in verschiedenen Größen zur Hand hat. Das spart Ladezeit.

Nun war mir in letzter Zeit aufgefallen, dass die heruntergerechneten Bild-Varianten im Vergleich zum Originalbild unscharf aussehen. Ich hatte zuerst den Verdacht, dass der Unschärfe-Effekt durch eine Skalierung im Browser (CSS) entsteht.

Aber bei den Projekten, bei denen mir die Unschärfe aufgefallen war, war keine Verkleinerung per Browser im Spiel. Das verkleinerte Bild war einfach ein Stück unschärfer als das Originalbild (das selbstverständlich ordentlich scharf war). Diesen Effekt kennt jeder, der schon Mal mit einem Bildbearbeitungs-Programm wie Photoshop gearbeitet hat. Verkleinert man ein Bild, verliert es an Schärfe. In der Bildbearbeitung gehört das Nachschärfen daher zur Routine.

Beitragsbilder schärfer machen

Man könnte jetzt alle Bilder der Reihe nach mit Photoshop öffnen und mit dem „Unscharf Maskieren“-Filter behandeln. Das ist aber nicht so richtig praktisch und nachhaltig ist es auch nicht.

Bei den WordPress Plugins gibt es ein paar, die sich des Themas annehmen. Leider konnte ich keines davon zum Laufen bringen. Die einfacheren wollten nicht funktionierten (sind durchweg schon etwas älter) und die ImageMagick-Maschinerie war mir einen Tick zu wuchtig.

Ich habe dann noch ausprobiert, ob es etwas hilft, wenn ich die JPG-Kompressionsrate auf 100% setze. Aber das hat nichts bewirkt, die Unschärfe bleibt.

add_filter( 'jpeg_quality', create_function( '', 'return 100;' ) );

Weiterlesen Unscharfe Beitragsbilder nachschärfen

Ist WordPress sicher?

„Nimm bloß nicht WordPress! Mein Kumpel arbeitet in der IT und der sagt, WordPress ist wahnsinnig unsicher!“

Stimmt das? Nein, das stimmt so nicht. WordPress ist eine Software und um Software muss man sich kümmern. Indem man regelmäßig Updates macht und indem man sichere Passwörter verwendet. Das war’s aber auch schon. Der Kumpel liegt also falsch, WordPress ist ein sicheres System.

Webseiten, die keine Pflege brauchen, gibt es schon auch. Das sind statische HTML-Seiten bei denen keine Scriptsprachen am Werk sind. Folglich kann dort auch niemand Unfug treiben.

Wer lieber ein komfortables CMS haben möchte, der muss sich kümmern. So wie das Betriebssystem auf dem Laptop bekommt auch WordPress regelmäßig Updates. Jedes Update bringt neue, praktische Funktionen und nebenbei werden Sicherheitslücken geschlossen.
Ein Redaktionssystem ist also nichts, dass man einmal installiert und dann vergessen kann. Das System ist ein Stück Software und das braucht Aufmerksamkeit.

2 Regeln für die Sicherheit

Dabei ist es denkbar einfach, WordPress sicher zu machen. Wer die beiden wichtigsten Faustregeln beachtet, ist weitgehend raus aus der Schusslinie.

  1. Sichere Passwörter = lange Passwörter, am besten ganze Sätze (12 Stellen und mehr)
  2. Updates, Updates, Updates

Sicherheit ist immer relativ

In einem kleinen Dorf wo jeder jeden kennt, schließt niemand seine Haustür ab, wenn er aus dem Haus geht. In der Großstadt wäre das wahrscheinlich ein Fehler, denn hier leben viel mehr Menschen und darunter sind auch solche mit unlauteren Absichten, die sich in der Masse verstecken.

Bei WordPress ist das ganz ähnlich. Weil WordPress sehr weit verbreitet ist und es viele WordPress-Installationen gibt, sind diese Installationen ein lohnendes Ziel. Einfach weil es so viele davon gibt. Die Chance ist groß, dass sich in der großen Masse ungepflegte Systeme finden, die einmal installiert und dann vergessen wurden. Die mit einfachen wirkungslosen Passwörtern abgesichert sind und bei denen niemand jemals ein Update gemacht hat.

Die Ziele der Hacker

Weiterlesen Ist WordPress sicher?

Local von Flywheel und MAMP 4.x im Schnell-Vergleich

Diesen Artikel habe in ursprünglich im Oktober 2016 geschrieben. Inzwischen ist viel passiert, so dass ich die Informationen noch einmal aktualisiert habe.

Local von Flywheel hat in der Zwischenzeit mehrere Updates bekommen. Leider haben die Entwickler beim letzten Update den Volumes Manager vergessen. („Sorry for the inconvenience! We underestimated the amount of people using this add-on.“ Tja, so verspielt man Vertrauen.)

Mit dem Volumes Manager konnte man Themes und Plugins in je einem Verzeichnis für alle Hosts zentral verwalten. Alle Installationen greifen dann auf dieselben Themes und Plugins zu, es gibt keine Doubletten und unklaren Versionszustände.
Flywheel hat zwar auf Github einen Fix für das Mapping AddOn nachgeliefert, aber der läuft bei mir nicht zuverlässig. Nach vielen Stunden Fehlersuche musste ich einsehen, dass das AddOn einfach nicht sauber arbeitet.

Ich habe ich mich entschieden zurück zu MAMP zu gehen. Local war superschnell und komfortabel. Aber ein Tool, das mich mitten in der Arbeit für Kundenprojekte für viele Stunden ausbremst und dann keine brauchbare Lösungen hat, das kann ich nicht gebrauchen. Dafür sind diese Setups zu wichtig.
Kommt dazu, dass Flywheel’s Hauptgeschäft das Hosting ist und Local ist ein Baustein in ihrem Business. Es ist z.B. nicht möglich, eine externe Seite zu klonen und in Local rüberzukopieren. Ich hab’s jedenfalls nicht geschafft. Für Flywheel-Kunden gehen solche Sachen selbstverständlich ganz einfach.

Das Mapping von Verzeichnissen z.B. für Themes und Plugins, kriegt man bei MAMP Pro übrigens auch hin (Über Symlinks, die man übers Terminar erzeugt hier ein Artikel dazu)

UPDATE 3. Dezember 2016
Pressmatic wurde von Flywheel aufgekauft und heisst jetzt Local by Flywheel. Die Software ist ab sofort kostenlos und Ihr könnt sie hier herunterladen.

Was ist Local?
Local tut das Gleiche wie MAMP, es ist eine Serverumgebung für lokale Rechner. Man kann damit WordPress lokal auf seinem Rechner installieren.
Weiterlesen Local von Flywheel und MAMP 4.x im Schnell-Vergleich

Eine CSS-Datei ausmisten und überflüssigen Code entfernen

Wenn ich mir eine CSS-Datei anschaue, die ich vor fünf Jahren geschrieben habe, wird mir anders. Aber das ist ein gutes Zeichen, denn wenn es nicht so wäre, hätte ich in der Zwischenzeit nichts gelernt.
Also tief durchatmen und einmal kräftig entrümpeln.

Es gibt einige Möglichkeiten, über Browser-Extensions oder über die Chrome Developer Tools herauszufinden, welches CSS auf einer Seite gerade nicht verwendet wird. Aber diese Methode taugt nur für einen schnellen, ersten Überblick. Denn anschließend müsste man das überflüssige CSS mühsam per Hand mit der CSS-Datei abgleichen. Kommt dazu, dass man nur das Ergebnisse für die aktuell aufgerufene Seite sieht.

Wir brauchen also ein kluges Script, das in der Lage ist, mehrere Seiten durchzugucken und das ein praxistaugliches Ergebnis in Form einer „bereinigten“ CSS-Datei ausspuckt.

Ausmisten mit Uncss

Ein Script, das das sehr gut macht, ist uncss von Giacomo Martino.

Ich habe mich für die Gulp-Variante entschieden. Geht aber auch via Grunt und npm.
Und so geht’s:

  1. Gulp und uncss installieren (falls nicht schon vorhanden)
  2. Im Theme-Verzeichnis einen Ordner namens uncss anlegen. Dort landet später die bereinigte CSS-Datei, die uncss erzeugt hat. Das Verzeichnis kann auch anders heissen, der Name wird im gulpfile.js angegeben.
  3. Das gulpfile.js erzeugen (Beispiel s.u.) und in das Verzeichnis legen, in dem man arbeiten will. Also z.B. das Verzeichnis, das das WordPress-Theme enthält.
  4. Per Terminal in dieses Verzeichnis navigieren und gulp tippen – und ab geht die Post.
    Das Ergebnis ist eine verschlankte CSS-Datei im Verzeichnis uncss.

Inhalt gulpfile.js

var gulp = require('gulp');
var uncss = require('gulp-uncss');

gulp.task('default', function() {
  return gulp.src([
  //Pfad zur CSS-Datei, die entruempelt werden soll
      '/Users/kirsten/Sites/my-blog/wp-content/themes/my-blog-theme/style.css',
      //hier kann noch ein Pfad hin
    ])
    .pipe(uncss({
     //URLs der Seiten, die das Script durchgucken soll

      html: [
        'http://my-blog.local/',
        'http://my-blog.local/category/tipps-und-tricks/',
        'http://my-blog.local/some-post/headline/',
        'http://http://my-blog.local/category/stories/',
  
      ]
    }))
    .pipe(gulp.dest('uncss/'));
});

Das Plugin WP-Accessibility

Wer sich mit Barrierefreiheit und WordPress beschäftigt, begegnet früher oder später dem Plugin WP Accessibility von Joe Dolson. Ich habe mir angeschaut, was das Plugin macht und was man damit erreichen kann.

Das Plugin WP Accessibility ist für Seiten gedacht, die ein Theme nutzen, das nicht schon „von Haus aus“ accessibility-ready ist und das ein Stück barrierefreier werden soll.
Je nachdem wo das Theme noch Lücken hat kann man mit dem Plugin folgende Eigenschaften ergänzen:

  • Skip-links einbauen für die Navigation per Tastatur
  • ARIA landmark roles
  • Labels hinzufügen für das WordPress-Such-Formular
  • Target-Attribute aus Links entfernen (Links nicht in einem neuen Fenster öffnen)
  • Änderungen im Tabindex entfernen
  • Links immer unterstrichen darstellen
  • Überflüssige Title-Attribute entfernen
  • CSS für a:focus nachrüsten (wichtig für die Tastatur-Navigation)
  • Lange Beschreibungen für Bilder erlauben
  • Post-Titles für „read more“ Links ergänzen

Das Plugin installiert ausserdem zwei Toolbars, mit denen man die Schriftgröße und die Farb-Kontraste verändern kann. Ich persönlich empfinde das eher als Spielerei – die Toolbars tun nichts auf Code-Ebene, es verändert sich nur kurzfristig die Darstellung.
Weiterlesen Das Plugin WP-Accessibility

Recap WordCamp Berlin 2017

Vergangenes Wochenende waren wir in Berlin. Wir waren schon am Donnerstag angereist um beim Contributor Day dabei zu sein.  

Den WPAdminDay am Mittwoch vor dem Camp haben wir damit prompt verpasst. Der WPAdminDay war ein kleines Barcamp für Profi-Admins. Also diejenigen, die Tag für Tag im Hintergrund dafür sorgen, dass die WordPress-Seite stabil und sicher läuft. So weit man hört, kam der WPAdminDay gut an und wir dürfen auf eine Wiederholung hoffen.

Beim Contributor Day am Freitag sind Elisabeth und ich mit „unserem“ Thema Accessibility beim Design-Team untergeschlüpft. Spannend war der Austausch mit Kollegen über die Herausforderungen, die ein barrierefreier Online-Shop in der Praxis so mit sich bringt. Mehrsprachig versteht sich.

Anschließend gab es noch einen kleinen Feuerwehr-Einsatz: Das Team vom WordCamp Kopenhagen hatte einen Hilferuf an die Community gesendet, nachdem zwei Wochen vor dem Start der Veranstaltung das Orga-Team auf eine Person geschrumpft war.

So durfte ich mal eben schnell ein Logo für das WordCamp Kopenhagen entwickeln. Am Samstag hatte das WordCamp Kopenhagen eine überarbeitete Website samt ganz ansehnlichem Logo.

Weiterlesen Recap WordCamp Berlin 2017

Pseudo-Klassen a:visited, a:hover, a:focus und a:active

Was a:hover bedeutet, weiss jeder, der mal die Nase an eine CSS-Datei gehalten hat. Die Pseudo-Klassen a:visited, a:focus und a:active sind weit weniger bekannt. Mir war jedenfalls lange nicht klar, was die Angaben genau bewirken.

a:hover

Über den Selektor a spricht man im CSS einen Link an, mit a:hover lässt sich dem Link ein Effekt mitgeben, der auftritt, sobald die Maus drüberfährt. In Beispiel unten ändert sich die Farbe des Links von Rot in Blau.

a {color: red;}
a:hover {color: blue;}

For the record: Auf Touch-Geräten funktioniert der hover-Effekt nicht.

Was ist der Unterschied zwischen a und a:link?

In manchen CSS-Dateien findet man die Schreibweise a:link {…} anstatt von a {…}.
Die Pseudo-Klasse a:link bezieht sich auf Anchor-Elemente, die ein href-Attribut haben. Was ein bisschen sinnfrei ist, denn dieses Attribut sollte jeder Link haben. Ein Link ist – ein Link und verweist immer auf eine interne oder externe URL.
Wenn nur eine Aktion durch Anklicken ausgelöst werden soll, ist button das Tag der Wahl. Ein Button triggert eine JavaScript-Aktion oder ist Teil eines Formulars.

Wer korrektes HTML pflegt, kann also getrost a statt a:link schreiben.
Weiterlesen Pseudo-Klassen a:visited, a:hover, a:focus und a:active

Was ist eigentlich dieser “Skip to content”-Link?

In den WordPress-Standard-Themes der Twenty-Reihe sitzt in der header.php kurz nach dem body-tag ein Skip-To-Content-Link.

<a class="skip-link screen-reader-text" href="#content">Skip to content</a>

Diesen Link sieht man normalerweise nicht. Er wird erst sichtbar und aktiv, wenn jemand die Tastatur nutzt um durch die Seite zu navigieren. Probiert es mal aus, den Skip-Link gibt es auch hier auf dieser Seite.

Zugang per Tastatur

Die Navigierbarkeit per Tastatur ist ein zentrales Kriterium für Barrierefreiheit. Mit der Tastatur bewegen sich nicht nur Screenreader über die Seite. Auch Menschen, die keine Maus bedienen können, bewegen sich via Tab-Taste. Weil sie Arthritis in den Händen haben, weil sie keine Arme haben oder weil sie den rechten Arm vier Wochen lang im Gips tragen.

Und wozu braucht es diesen Link jetzt?

Angenommen, ich habe das Excerpt eines Artikels gelesen und möchte jetzt die ganze Version lesen. Ich steuere mit der Tastatur den Read-More-Link an, der Browser öffnet die Seite mit der Einzelansicht des Artikel.

Gäbe es nun den Skip-to-Content-Link nicht, müsste ich mich in der Einzelansicht erst mal durch den gesamten Header-Bereich durchackern. Ich müsste alle Elemente – Logo, Seitentitel, Navigation, Suchfeld – der Reihe nach anklicken bevor ich endlich beim Artikel landen würde. Die Tab-Taste arbeitet sich stur von links oben nach rechts unten durch den Code.
Ist dagegen ein Skip-Link vorhanden, kann ich sofort an die Stelle springen, die mich interessiert.

Aus diesem Grund sollte jede Webseite einen Skip-Link zur Verfügung stellen.
Ein Codebeispiel gibt’s im Accessibility-Handbuch.

WordPress-Templates für Übersetzung vorbereiten

Texte in einem WordPress-Theme, die übersetzbar sein sollen, müssen in den Templates gekennzeichnet werden. Dar Code dazu sieht ein wenig ungewöhnlich aus und es gibt viele verschiedene Schreibweisen für diese Funktion. Ich hab eine Weile gebraucht, bis ich mir einen Reim drauf machen konnte.

Der Aufbau eines übersetzbaren Strings ist immer gleich:
__( 'Der zu übersetzende Text', 'text-domain' );

Am Anfang stehen zwei Unterstriche. Die Syntax __() ist ein Kürzel für die translate()-Funktion und setzt das Signal „Achtung, hier gibt’s was zu übersetzen“. Danach kommt der zu übersetzende Textschnipsel, am Ende steht die Textdomain.
An der Stelle, wo die zwei Unterstriche platziert sind, können ganz unterschiedliche Funktionen stehen. Ich möchte vier Varianten vorstellen, die ich im meinem Theme-Alltag am Häufigsten verwende.

Es gibt natürlich noch viel mehr Funktionen. Eine vollständige Übersicht mit ausführlichen Code-Beispielen gibt es im WordPress Theme Handbook.

1. Einfacher Text

esc_html_e('Ich bin ein Text, sonst nix' , 'text-domain');
Damit kennzeichne ich einen einfachen Text.
Im Prinzip würde diese Schreibweise ausreichen:
_e('Ich bin ein Text, sonst nix' , 'text-domain');
Ich bin nicht sicher, wie hoch das Risiko tatsächlich ist, aber theoretisch könnte bei der zweiten Variante ein Übersetzer HTML-Codeschnipsel oder Übleres in die Übersetzung reinschmuggeln. Die Escape-Funktion schmeisst solche Sachen raus.

2. Text innerhalb eines Attributs

Ist ein Text Teil eines Attributs und sitzt z.B. im title-Attribut innerhalb eines Links, dann sieht das Ganze so aus:
esc_attr_e( 'Skip to content', 'text-domain' );
Auch hier ist das Escapen wichtig, damit niemand über die Übersetzung Schadcode einschleusen kann.
Weiterlesen WordPress-Templates für Übersetzung vorbereiten