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+.

Beitragsbilder verstehen und richtig einsetzen – 1. Was ist ein Beitragsbild

Für viele WordPress-Einsteiger ist das Prinzip der Beitragsbilder (englisch Featured Images oder Post Thumbnail) etwas schwer verständlich. Das Konzept ist tatsächlich ein bisschen abstrakt.
In dieser kleinen Artikelserie soll es darum gehen, wie Beitragsbilder in einem WordPress-Theme funktionieren und was man so alles damit machen kann.

Was ist ein Beitragsbild?

Ein Beitragsbild ist ein Bild, das man einem Beitrag (post) oder einer Seite (page) fest zuordnen kann. WordPress weiß dann, dass dieses bestimmte Bild mit dem Text verknüpft ist.
Das Besondere dabei: Das Bild wird nicht wie gewohnt in den Text eingebaut und dort deutlich sichtbar angezeigt. Sondern es wird quasi im Hintergrund gespeichert – man sieht es zunächst nur, wenn man weiß, wo man hingucken muss.

Ist ein Beitragsbild ausgewählt, sitzt es als kleines Thumbnail-Bild in einer Box rechts neben dem Texteditor.

Ein Beitragsbild festlegen

Um ein Bild mit einem Beitrag zu verknüpfen, klickt man in der Metabox “Beitragsbild” rechts unten neben dem Editor auf den Link “Beitragsbild festlegen” (s. Screenshot).
Weiterlesen Beitragsbilder verstehen und richtig einsetzen – 1. Was ist ein Beitragsbild

Gutenberg und der Faktor Zeit

Seit einiger Zeit verfolge ich sehr aufmerksam die Entwicklung von Gutenberg. Mir ist klar geworden, dass sich WordPress mit Gutenberg tiefgreifend verändern wird. Das ist eine gute Sache. Aber wo sich Vieles ändert, entsteht auch viel Bewegung.

Gutenberg ist ein anspruchsvolles Projekt und solche Projekte dauern ihre Zeit. Momentan sind wir vielleicht auf halbem Weg angekommen. Ich rechne damit, dass es etwa noch ein Jahr dauern wird, bevor wir etwas haben, das auf einer Live-Seite eingesetzt werden kann.

Ich weiß, es steht der Termin April 2018 im Raum. Den Termin hat Matt Mullenweg in seinem Vortrag „State of The Word“ beim WordCamp US 2017 genannt. Zu diesem Zeitpunkt soll WordPress 5.0 erscheinen und zwar mit Gutenberg als fest integriertem Bestandteil.

Ich halte diesen Termin erstens für unrealistisch und zweitens für unsinnig. Denn nicht nur die Entwicklung von Gutenberg braucht Zeit, auch der Übergang vom alten in einen neuen Zustand.

Der ungeliebte Übergang

Vor vielen, vielen Jahren, als ich frisch gebackene Kommunikations-Designerin war, bekam ich den Auftrag, eine Tageszeitung grafisch zu überarbeiten. Die Zeitung erhielt eine moderne Typografie und ein klareres Layout. Das Ergebnis war richtig gut. Die Redakteure hatten weniger Arbeit, die Abstimmungsprozesse waren schlanker geworden und die Leser bekamen besser lesbare Texte und ein übersichtliches Layout.
Aber alle haben es gehasst. Die Redakteure schimpften über die neuen Strukturen und die Leser fanden ihre Lieblingskolumne nicht wieder.
Weiterlesen Gutenberg und der Faktor Zeit

Morten Rand-Hendriksen: Gutenberg and the WordPress of Tomorrow

Wer sich für Gutenberg interessiert, sollte sich diesen Vortrag vom WordCamp US 2017 von Morten Rand-Hendriksen unbedingt anschauen.

Was wir momentan sehen, ist nur ein sehr kleiner Ausschnitt dessen, was Gutenberg tatsächlich bedeutet. Morten zeichnet das große Bild und erklärt sehr anschaulich, wo es hingehen soll.

Blocks. WYSIWYG. Alles wird anders.
Sehr spannend!

Der nicht ganz so ultimative Page-Builder Vergleich

Vor Kurzem habe ich zum ersten Mal einen Page-Builder für ein Kundenprojekt eingesetzt. Die Anforderungen waren relativ speziell: Innerhalb einer Multisite sollten Redakteure selbst Sites erstellen können, die jeweils aus einer Art Landingpage bestanden. Die Layouts dafür sollten variabel und weitgehend frei gestaltbar sein. 

Das ist ein ungewöhnlich langer Artikel geworden. Wer nicht alles lesen möchte, hier sind ein paar Anchorlinks zum schnelleren Durchlesen:

– Was ich mir angeschaut habe
– Das Testlayout
– Frontend-Editing, Responsiveness und WordPress-Integration
– Die Page-Builder in der Einzelbetrachtung
– WordPress und Page-Builder

Ich hatte mir zu Beginn des Projekts vier Page-Builder ausgesucht und verschiedene Szenarien durchgespielt. Ich wollte sehen, was die Redakteure machen können und ob vielleicht wichtige Funktionen fehlen.
Dabei war mir wichtig, dass auch wenig erfahrene Nutzer gut zurechtkommen und ein „Knöpfchen“ für jede Funktion vorfinden, die für die Umsetzung meines konkreten Projekts wichtig war.
Ein Beispiel: Hintergrundbilder, auf denen ein Text platziert wird, müssen immer ein bisschen abgetönt werden, damit der Text auch lesbar ist. Wer sich mit HTML und CSS zu helfen weiß oder mal eben schnell Photoshop anschmeißen kann, kriegt das natürlich hin. Aber Redakteure ohne Vorkenntnisse nicht.

Die Kandidaten

Für diesen Artikel habe ich noch zwei weitere Plugins mit aufgenommen:

  1. Tailor, das einzige mir bekannte OpenSource-Projekt unter den Page-Buildern.
  2. Visual Composer, the elephant in the room

Von allen Plugins habe ich jeweils die kostenlose Version installiert.

Zum Vergleich treten an:

Das hier ist kein systematischer Test, eher eine Stichprobe. Mein Ziel war, ein Gefühl dafür bekommen, wie es sich mit dem jeweiligen Page-Builder arbeitet.

Wer einen gründlichen und umfassenden Vergleich lesen möchte, dem empfehle ich den Artikel von Pippin Williamson (en)

Weiterlesen Der nicht ganz so ultimative Page-Builder Vergleich

MAMP: WordPress-Themes und Plugins über Symlinks zentral verwalten

Vor ein paar Monaten hatte ich eine Weile mit Local von Flywheel als lokale Entwicklungsumgebung gearbeitet. Inzwischen bin ich wieder zurück zu MAMP gewechselt. Mehr dazu in diesem Artikel.

Eine Eigenschaft von Local, die mir besonders gut gefiel, war der Volumes Manager. Damit konnte man Themes und Plugins für alle Hosts zentral verwalten. Alle lokalen Sites und alle WordPress-Installationen greifen dann auf dieselben Themes und Plugins zu. Das ist zum Entwickeln sehr praktisch, weil es keine Doubletten gibt und keine Verwirrung mit Versionen.

Diese Funktion kann man auch in MAMP nachbilden. Man muss dafür ins Terminal wechseln, aber was man dort tun muss, ist denkbar einfach.

  1. Plugins und Themes an zentraler Stelle ablegen.
    In meinem Fall ist das der Ordner sites
  2. Im Terminal zum Verzeichnis navigieren, in der die lokalen Sites liegen, die mit MAMP verwaltet werden.
    Bei mir ist es das Verzeichnis sites und ich navigiere dort hin mit cd sites
  3. Einen Symlink für das Theme-Verzeichnis setzen
    ln -s ~/Sites/themes ~/Sites/name-des-projekts/wp-content
  4. Einen Symlink für das Plugin-Verzeichnis setzen
    ln -s ~/Sites/plugins ~/Sites/name-des-projekts/wp-content

Im wp-content-Verzeichnis des Projekts erscheint dann jeweils ein Alias des zentralen Theme- bzw. Plugin-Verzeichnisses.

Damit es keine Fehlermeldung gibt, muss man die Verzeichnisse themes und plugins im wp-content-Verzeichnis vor der Aktion umbenennen. Es reicht ein kleiner underscore vor dem Namen, z.B. so: _themes.
Weiterlesen MAMP: WordPress-Themes und Plugins über Symlinks zentral verwalten

Browsercache für die style.css deaktivieren

Es gibt ein Sache, die mich bei Änderungen in der style.css regelmäßig zum Wahnsinn treibt. Egal, wie oft ich auf Reload klicke, der Browser zeigt meine Änderungen im CSS nicht an.

Das hat den Grund, dass die style.css im Browser-Cache gespeichert ist. Eigentlich eine gute Sache, denn so muss die Datei nicht bei jedem Aufruf neu geladen werden. Aber für’s Arbeiten ist das lästig.

Den Browsercache deaktivieren

Wer viel mit den Developer Tools arbeitet, kann in den Einstellungen das Caching deaktivieren. Das kleine Häkchen schaltet den Cache aus so lange die Console offen ist.

Ich kann den Browsercache auch umgehen, indem ich ein Inkognito-Fenster öffne oder einen harten Refresh mache.
Aber da ist ja auch noch die Kundin vor ihrem Rechner. Es ist sehr unpraktisch, wenn ich ihr jedesmal erklären muss, dass sie zuerst ihren Browsercache löschen muss bevor sie etwas zu sehen kriegt.

Das muss anders gehen.
Weiterlesen Browsercache für die style.css deaktivieren

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 jedes Bild 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).

Im Nachhinein wundere ich mich, dass mir das nicht schon früher aufgefallen ist. Denn der Unschärfe-Effekt ist ein bekanntes Phänomen, das jeder kennt, 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 – mehr der Vollständigkeit halber – 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/'));
});