Category: WordPress

Ein neuer Editor für WordPress?

Typewriter

Mal ehrlich, wie gefällt Euch eigentlich der Editor von WordPress? Benutzt Ihr ihn eigentlich und wenn ja wie? Ich selbst muss gestehen, dass ich den größten Teil meiner Blogbeiträge in einem ganz normalen Plaintext Editor verfasse, ein wenig mit HTML-Tags vorbereite und erst am Ende nach WordPress wechsle, um die letzten Stylings zu machen, ein bisschen Preview und meist eine etwas unglückliche Fehlerkorrektur vornehme. Nein, ich bin kein großer Freund des WordPress Editors und das ist eigentlich kein gutes Urteil, wenn man bedenkt, dass im Herzen eines Blogsystems eigentlich der Editor schlagen sollte.

Nun scheine ich damit nicht ganz alleine zu sein, zumindest ist der Editor eines der Fokusprojekte für das Projekt WordPress 4.8. Derzeit läuft deshalb eine Umfrage, wie der Editor denn bisher eigentlich genutzt wird.

Was? Eine Umfrage? Ja, denn bisher gibt es noch kein geeignetes Instrument, tatsächliches Userfeedback einzuholen. Vielleicht eine der spannendsten Debatten in der WordPress Entwickler⋅innenszene ist derzeit, wie man eigentlich eine 80:20-Regel grob einhalten möchte (“wenn es 80 Prozent der Leute nützt eignet es sich für den Core”), wenn man nicht über die geringsten Daten verfügt, wie WordPress eigentlich genutzt wird. Man erinnere sich an die Diskussion, den Blocksatz-Button aus dem Editor zu entfernen. Doch, das Thema, wie man Nutzer⋅innen-Daten am besten erhebt und welche Diskussionen dazu laufen, bietet sicher genug Stoff für einen eigenen Beitrag. Eine Umfrage also. Angesichts der letztlich nicht vorhandenen Datenlage ist das sicher der beste Ansatz.

Natürlich erhofft man sich davon interessante Einblicke, welche Features man erhalten sollte, welche stören oder gar weg können. Mich stört beispielsweise ganz enorm, dass ich bei langen Texten Ewigkeiten scrollen muss, bis ich zu den darunterliegenden Metaboxen komme (Man kann das übrigens oben rechts bei Screen Options abstellen). Doch natürlich bleibt es nicht nur dabei, Daten zu erheben, vielmehr wird schon längst an einem neuen Editor gebastelt und erste Prototypen und Mockups liegen vor, die wirklich vielversprechend sind.

Gutenberg. Prototyping since 1440.

Der Prototyp, an welchem gearbeitet wird, heißt “Gutenberg” und zielt darauf umfangreiche und auch designlastige Beiträge so mühelos wie möglich zu erstellen. Statt sich also einen Text als solide Einheit vorzustellen, ist der Ansatz hier, Texte eher in Blöcken zu denken, welche dann schnell durch den Text manövriert werden können. Ein Block muss dabei nicht nur ein Absatz sein, sondern kann auch aus einem Bild, einem Video oder anderen Elementen bestehen. Ein Ansatz, der durchaus nicht unüblich ist, wenn man mal mit dem einen oder der anderen Webdesigner⋅in gesprochen hat.

Ich habe einen kleinen Screencast vorbereitet, der Euch den neuen Editor zeigt, so wie er heute zu finden ist.

Ich muss gestehen, mir gefallen solche Editoren und auf jeden Fall gefällt mir der Weg, der hier eingeschlagen wird. Ob ich am Ende tatsächlich meine Texte darin schreiben werde, weiß ich noch nicht, aber toll sieht es aus. Die Arbeit an dem Editor ist in vollem Gange. Tammie Lister bittet darum, den Prototypen ausführlich zu testen und Fragen zu beantworten wie beispielsweise

  • Kannst Du auf den ersten Blick erklären, wozu jede Sektion gut ist?
  • Kannst Du einen Absatz schreiben und wie fühlt es sich an?
  • Kannst Du ein Bild hinzufügen? Ist das schwierig?

Getestet werden kann Gutenberg hier. Die Entwicklung und auch das Bugreporting finden auf Github statt. Derzeit wird daran gearbeitet Gutenberg zu einem Featured Plugin weiterzuentwickeln, so dass jede⋅r sich selbst ein Bild verschaffen kann und den neuen Editor als Plugin testen kann. Die technischen Schwierigkeiten und die Zukunft von post_content werden unter anderem in diesem Beitrag diskutiert. Wie separiert man die Blöcke, um sie handhabbar zu machen, ohne die post_content-Spalte der Datenbank zuzumüllen? Vorschläge reichen von data--Attributen an HTML-Elementen bis hin zu HTML-Kommentaren wie <!-- wp:image -->.

Wirklich viel kann man natürlich noch nicht sagen, da alles noch ziemlich am Anfang steht, aber der neue Editor, das wird auf den ersten Blick sichtbar, hält einige Überraschungen bereit und auch unzählige Fragen wie Browsersupport für IE8 und ähnliches.

Wenn Du an der derzeitigen Umfrage zum aktuellen Editor noch nicht teilgenommen hast, kannst Du das hier schnell nachholen. Was hältst Du vom aktuellen Editor und wie findest Du den Entwurf für den Neuen?

3 Wege WordPress zu deaktivieren

Gestern habe ich mir mal ein bisschen angeschaut, welche meiner Beiträge eigentlich am beliebtesten sind und festgestellt, das unter den Topbeiträgen meine “Deaktiviere dies”-, “Deaktiviere das”-Beiträge sind.

Daraus entstanden diese Tweetserie


https://twitter.com/websupporter/status/838113060791402498

Ich ging erst mal Schlafen und als ich heute morgen aufwachte, dachte ich mir, vielleicht adressiere ich ja die falsche Crowd und gehe einfach zu destruktiv mit WordPress um. Ich sollte vielleicht einfach mehr über “Wie Du X aktivierst” oder “Wie Du Y anwendest” schreiben und hatte mir sogar schon ein Thema zurecht gelegt, bis ich dann in meine Timeline guckte und sah, dass Robert, Thorsten und Heiko schon Vorschläge hatten, wie WordPress am besten deaktiviert wird. Nie um einen kleinen Clickbait verlegen lege ich also meine guten Vorsätze beiseite und geb der Crowd, was die Crowd verlangt.

“How to deactivate WordPress” – Ein nicht ganz ernst gemeinter Beitrag zur Debatte.


Vorbemerk: Etliche Vorschläge in diesem Beitrag führen dazu, dass Dein WordPress nicht mehr zu erreichen ist. Das ist sozusagen das Ziel. Wenn Du weißt, was Du tust, probiere es gerne aus, aber beschwere Dich später nicht “David hat mein WordPress kaputt gemacht”; das warst Du. Wenn Du willst, dass ich es fixe: Ich berechne 80 Euro + Umsatzsteuer für jede angebrochene Stunde.


Heiko schlägt im Wesentlichen vor, einfach den Linux Server herunterzufahren.

Meiner Meinung nach ist das ganz schön brutal und passt nicht ganz in mein Clickbait-Schema. Aber vielleicht ja mal ein Artikel “Wie ich meinen Linuxserver gegen die Wand fuhr”? Außerdem Heiko: Was passiert denn, wenn auf dem Server noch ne Drupal-Installation läuft. Derartige Kollateralschäden würde ich gerne vermeiden. Die Leut drüben bei Drupal sollten wir da nicht mit rein ziehen.

Bleiben die zwei Vorschläge von Thorsten und Robert. Robert schlägt vor, einfach die globale $wpdb in der init-Aktion auf null zu setzen. Traut sich aber nicht mal im Tweet, das zu aktivieren (Hashtag: Hashtag).

Thorsten geht das nicht weit genug; er radiert einfach gleich sämtliche globalen Variablen aus. Die mag der einfach nicht.

Ich hab mir beide Vorschläge mal angeschaut und bin damit nicht so glücklich. Erstens ist WordPress nicht deaktiviert, sondern läuft ja einfach weiter und Zweitens krieg ich auch noch jede Menge PHP Notices und Errors. Das ist doch keine saubere Enterprise-Lösung für unser kleines, dreckiges Problem.

Das ist doch keine Lösung?!
Das ist doch keine Lösung?!

Evaluieren wir also noch einmal, welche Möglichkeiten uns zur Verfügung stehen:

Ein erster Weg WordPress zu deaktivieren. Der Maintenance mode

WordPress verfügt über einen eingebauten “Maintenance mode”, den wir für unsere Zwecke missbrauchen könnten. Relativ am Anfang der wp-settings.php wird die Funktion wp_maintenance() aufgerufen, welche prüft, ob im Root-Verzeichnis von WordPress eine .maintenance-Datei rumliegt. Setzt diese auch noch die Variable $upgraded auf einen Timestamp der nicht älter als zehn Minuten ist, verabschiedet sich WordPress. Was mir an diesem Ansatz gefällt ist, dass er sehr früh im System ausgeführt wird und also WordPress relativ früh deaktiviert. Was mir weniger gefällt ist, dass wir uns dazu via FTP auf dem Server einloggen müssen, um die Datei hochzuladen. Das ist einfach keine gute UX 😞. Aber trotzdem, eine solche Datei würde ihren Dienst tun:

WordPress deaktivieren mit der .htaccess

Wir könnten argumentieren, dass WordPress gar nicht richtig deaktiviert ist, weil das System ja immer bis zu einem bestimmten Punkt durchläuft, während hingegen ein deaktiviertes Plugin überhaupt nicht mehr ausgeführt wird. Auf der anderen Seite gibt es ja einen Unterschied zwischen Deaktivieren und Löschen. “Logge dich mit FTP ein, lösche alle WP-Dateien aber achte darauf, nicht den wp-content/-Ordner, oder zumindest den uploads/-Ordner zu löschen” ist somit ein anderes Thema. Aber: Wir könnten über die .htaccess gehen. Hier gibt es verschiedene Strategien. Ich habe mich dazu entschieden, statt auf die index.php auf eine index.html umzuleiten. (Ich setze hier einmal voraus, dass in diesem Ordner und den Unterordnern nur WordPress läuft und nicht noch irgendwo Drupal 😂) Das ganze sähe dann in etwa so aus:

WordPress mit Hilfe eines Plugins deaktivieren

Aber auch für diese Lösung müssen wir auf FTP zurückgreifen und irgendwie ist das nicht so richtig WordPressy. Nein, Thorsten und Robert haben Recht, es sollte doch ein Plugin sein, aber dann doch bitte eines, welches so früh wie möglich einsteigt. Das ist das schöne an Thorstens all-Filter. Ich hatte an die plugins_loaded gedacht, doch allem Anschein nach hat sich das Thorsten auch gedacht und dann kurz nachgeschaut und festgestellt, dass all vor dem spezifischen plugins_loaded ausgeführt wird. Für ein Plugin ist all der Hook der Wahl. Man könnte natürlich auch einfach ohne Hooks arbeiten, aber bitte mal: Das ist dreckig.

Was mir nicht in den Kopf geht: Warum schlagen Beide danach vor, globale Variablen zu löschen? Gut, ich verstehe die Antipathie ihnen gegenüber, aber sich dafür solche Notices einzufangen. Nein, lieber nicht. Ich gehe lieber mit wp_die(). Man könnte auch die() oder exit; nehmen, um noch weniger WP-Code auszuführen, aber hey:

Fazit

Mit gefällt die Plugin-Lösung am Besten. Das Plugin könnte noch ein wenig Liebe vertragen, so dass man WordPress auch wieder aktivieren könnte, ohne das Plugin vom Server zu löschen. Aber für einen ersten groben Entwurf denke ich, langt es. Wie würdest Du WordPress am “geschicktesten” deaktivieren? Musstest Du WordPress schon einmal deaktivieren und wenn ja, warum?

Mit antispambot() gegen Emailharvester

Harvest

Emailadressen, welche frei verfügbar auf einer Webseite herum fliegen, werden regelmäßig von Bots gefressen, in Spamdatenbanken gepumpt und schon wird die Adresse zugespammt. Dennoch müssen immer wieder Emailadressen zugänglich auf der Webseite sein. Jede⋅r hat irgendwo seine Kontaktemail hinterlegt. Manchmal wird statt der Adresse ein Bild dargestellt oder das @ durch ein [at] ersetzt, um sich gegen die Harvester zur Wehr zu setzen.

Auch WordPress verfügt über eine Gegenmaßnahme und kommt mit einer kleinen, aber äußerst nützlichen Funktion daher: antispambot(). Diese wandelt etliche der Zeichen einer Emailadresse in Hex-Zeichen um, wie in diesem Beispiel zu sehen ist:

Welche der Zeichen umgewandelt werden ist dabei einem Zufallsgenerator überlassen und ändert sich (sofern man kein Caching nutzt) jedes Mal. Doch warum diese Umwandlung? Die meisten Email-Harvester-Bots sind relativ “dumm”. Sie prüfen den HTML-Code einer Seite, ob sich irgendwelche Emailadressen dort befinden. Meist geschieht dies über einen einfachen regulären Ausdruck, der nach Email-konformen Strings sucht. Hex-codierte Emailadressen sind erst einmal nicht konform mit dem Email-Format und werden deshalb gerne übersehen. Browser hingegen wandeln diese Emailadressen in normal lesbaren Text um.

Auf der Codex-Seite wird diese Funktion auch gleich für einen Shortcode aufbereitet, den man sich schnell in ein kleines Plugin stecken kann:

Gibt man nun [email]max.mustermann@example.com[/email] ein, so wandelt dieser Shortcode die Adresse in einen Email-Link und die Adresse in eine hexformatierte Adresse um.

Und das hilft?

Es wird wohl nicht gegen jeden Adress-Harvester schützen, aber doch gegen die Meisten. So wie auch ein [at] von einigen Bots wohl übersetzt werden kann und Bilder mit OCR-Methoden ausgelesen werden können, so ist es technisch natürlich auch möglich einen Bot zu bauen, der diese Adressen erkennt. Aber neben einem grundsätzlichen Schutz bietet diese Funktion gegenüber anderen Methoden den Vorteil, dass sie im Zusammenhang mit mailto: verwendet werden kann und damit den Besucher⋅innen einer Seite maximalen Komfort bietet.

Möchtest Du also auf Deiner Seite Emailadressen für Besucher⋅innen zugänglich präsentieren, aber vor Bots verbergen lohnt sich ein Blick auf antispambot(). Kanntest Du diese Funktion schon? Setzt Du sie erfolgreich ein oder welche Maßnahmen triffst Du gegen Email-Harvester?

Starter Content für Themes

Kennt Ihr das auch? Ihr sucht nach einem neuen Theme und flaniert durch verschiedene Showcases, schaut Euch Livedemos und Vorschaubilder an, die Euch das Theme auf verschiedenen Auflösungsstufen, für Desktop, Tablet und Mobile zeigen. Dann habt Ihr Euch endlich entschieden, ladet das Theme herunter, haut es auf Eure frische WordPress Installation und irgendwie sieht nichts so aus, wie erwartet?

Jetzt beginnt ein ewiges Herumfrickeln, bis über den Customizer oder gar die Theme Optionen die Einstellungen so getroffen sind, dass alles passt. Neue Seiten müssen angelegt werden, um die entsprechenen Page Templates zu testen und Widgets müssen konfiguriert werden. Je nachdem wie umständlich das Ganze wird verfliegt da schnell das anfängliche Hochgefühl, endlich das Theme gefunden zu haben und Frust stellt sich ein.

Manche Themeentwickler⋅innen legen ihren Meisterwerken deshalb Dummydaten bei, welche über den WordPress Importer auf die nagelneue WordPress Installation geladen werden können und so zumindest ein wenig Arbeit abnehmen. Das war zumindest immer eine nette Geste, aber bis WordPress 4.7 fehlte einfach ein ordentlicher Workflow für dieses Problem. Doch jetzt gibt es ein neues Feature, das zwischen all dem Jubel um PDF-Vorschaubilder, REST-API, Shortcuts und ich weiß nicht was, ein bißchen untergegangen ist: Starter Content. STARTER CONTENT! 🎉

Wenn Ihr mit einer frischen WordPress Installation in den Customizer geht, um Twentyseventeen zu konfigurieren, dann werdet Ihr nicht einfach einen leeren Blog mit einem “Hallo Welt”-Beitrag vorfinden. Vielmehr findet Ihr eine vollständig konfigurierte WordPress Installation vor. Es gibt ein Menü, eine Frontpage, eine About-Seite, einen Blog und eine Kontaktseite. Die Sidebar ist schon komplett konfiguriert und es gibt ein “Find us”-Textwidget, die Suche und ein Widget “About this site”. Sogar das Hauptmenü und das Socialmenü im Footer sind schon konfiguriert.

2017 Starter Content im Customizer
2017 Starter Content im Customizer

Ein⋅e Anwender⋅in kann nun einfach durch den Customizer spazieren gehen, die Widgets anpassen, raushauen, ersetzen, die Menüs abändern und schließlich mit “Speichern” die Einstellungen speichern. Der Theme-Installations-Workflow ist also komplett in den Customizer integriert.

Bisher funktioniert dies allerdings nur mit frischen Installationen, auf denen noch keine Seiten, Beiträge, Widgets oder sonstige Inhalte angelegt wurden. Es gibt allerdings schon Planungen, wie das Konzept am Besten auf alte Seiten übertragen werden kann.

Wie bereite ich “Starter Content” für mein Theme auf?

Der ganze Zaubertrick hängt nun natürlich an den Entwickler⋅innen von WordPress Themes. Sie müssen den Starter Content bereitstellen und die Konfiguration übernehmen. Dieser Beitrag gibt eine Übersicht, wie das zu bewerkstelligen ist.

Alles spielt sich dabei in der Aktion after_setup_theme ab. Hier kann die Unterstützung von starter-content mit Hilfe von add_theme_support() deklariert werden. Das Interessante ist nun der Konfigurationsarray, welcher mit dieser Deklaration übergeben wird.

Wir können Widgets, Posts, Attachments, Navigations-Menüs, Optionen und Theme-Mods in diesem Array übergeben. Wenden wir uns den einzelnen Möglichkeiten nach und nach zu:

Widgets

WordPress liefert schon eine ganze Reihe vorkonfigurierter Widgets mit. Sagen wir, in unserem Theme gibt es eine Sidebar mit der ID sidebar-1 und wir wollen in dieser das Suchwidget und ein Textwidget mit Öffnungszeiten darstellen, so können wir das wie folgt erreichen:

Im widgets-Bereich unseres Konfigurationsarrays sagen wir also: In der sidebar-1 sollen diese beiden Widgets auftauchen. Dies sind die vorformatierten Widgets, welche der WordPress Core bereitstellt:

  • text_business_info
  • text_about
  • archives
  • calendar
  • categories
  • meta
  • recent-comments
  • recent-posts
  • search

Sagen wir aber, Du möchtest einen individuellen Text in ein Textwidget einpflegen, wie würde das gehen? Statt einem einfachen Textstring übergeben wir nun einen Array. Das erste Element des Arrays enthält den Widget-Identifikator (die sogenannte id_base), hier text, der zweite Array enthält alle Informationen, welche das Widget über die $instance zum Rendern des Widgets benötigt:

Dies funktioniert dann natürlich nicht nur mit den schon im WordPress Core vorhandenen Widgets wie dem Archiv oder ähnlichen, sondern auch mit Widgets, welche über Plugins oder (eventuell) über das Theme bereitgestellt werden. Sehen wir uns dazu folgendes Beispiel an:

Wir registrieren hier zunächst unser Widget Mein_Widget() mit der Base ID meine-base-id. Und in der Methode widget() lassen wir uns im Wesentlichen einfach die $instance ausgeben. Schließlich weisen wir in unserer Content-Starter-Deklaration noch die Inhalte diesem Widget zu und schon wird dieses Widget mit den Inhalten angezeigt.

Posts

Um Beiträge, Seiten oder andere Inhalte für die Vorschau zu erstellen, könnt Ihr wie folgt vorgehen:

Wir legen hier eine Seite mit dem Identifikator test an. Wir weisen diesem Inhalt den Posttype page zu, einen Titel und einen Inhalt. Dieser Array wird schließlich als Übergabeparameter an wp_insert_post() genutzt, da diese Starter-Beiträge mit dem Status auto-draft in der Datenbank hinterlegt werden. So können natürlich auch benutzerdefinierte Felder mit übergeben werden, indem der Array um ein meta_input erweitert wird. Wenn Du einer Seite ein bestimmtes Seitentemplate zuweisen möchtest, kannst Du dies so tun:

'template' => 'sample-page-template.php'

Der WordPress Customizer liefert allerdings auch schon vorgefertigte Seiten, wie das folgende Listing darstellt:

Mit diesen sechs vorgefertigten Seiten erspart sich der/die Entwickler⋅in dann einiges an Konfigurationsarbeit.

Attachments

Attachments sind formal gesehen natürlich nichts anderes als ein besonderer Posttype. Allerdings gibt es bei Anhängen noch Dateien, welche mit bedacht werden müssen und diese machen es notwendig, Attachments separat zu konfigurieren. Dann sind sie allerdings eine wirklich interessante Angelegenheit:

Hier registrieren wir zunächst das Attachment featured-image-logo. Dieses steht uns dann zur Verfügung, um es beispielsweise mit Hilfe von {{featured-image-logo}} an einen Beitrag als benutzerdefiniertes Bild anzuhängen.

Unser besonderes Interesse gilt in diesem Listing natürlich dem file-Wert. Verknüpfte Mediendateien müssen im Theme selbst zu finden sein. Der Pfad zur Mediendatei kann entweder absolut oder aber relativ zum Theme-Verzeichnis angegeben werden. Im hier skizzierten Fall läge die Datei also hier:

http://example.com/wp-content/themes/theme-slug/assets/images/featured-logo.jpg

Dem ein oder anderem mag aufgefallen sein, dass wir den “About”-Beitrag, der ja ein WordPress Standard-Eintrag ist, hier mit einem Array registrieren. Wir können sämtliche Standard-Einträge nehmen und die Eigenschaften dieser Beiträge mit Hilfe solcher Arrays erweitern.

Die Navigation

Kommen wir zur Navigation. Sehen wir uns zunächst kurz das Listing an:

Wir erstellen zwei Seiten und machen uns dann daran, unser Menü zu konstruieren. In nav_menus bezeichnen die Array-Keys (hier beispielsweise top) die Menülocation, welche wir zuvor in unserem Theme registriert haben müssen. Mit name übergeben wir den Namen des Menüs und in items schließlich die einzelnen Menüitems. Das erste Item, welches wir übergeben ist page_home, ein WordPress Standard, welcher auf die Standardseite home verweist, welche wir oben registriert haben. Danach haben wir ein Array. Grundsätzlich gibt es zwei Navigationsitem-Typen, welche wir anlegen können: Objekte und Links. Objekte verweisen auf ein registriertes Objekt, in unserem Fall auf die Testseite, welche wir zunächst angelegt haben und dann über object_id mit {{test}} referenzieren. Auch object und type müssen dabei angegeben werden.

Darunter registrieren wir dann einen externen Link als Menüitem. Hierfür muss einfach eine URL in url und ein Titel in title übergeben werden.

Optionen und Theme Mods

Um Optionen oder Theme Mods anzulegen, wird options beziehungsweise theme_mods bereitgestellt. Diese Bereiche sind Schlüssel-Wert-basiert, wie das folgende Listing zeigt:

Hier sagen wir, dass wir auf der Startseite eine einzelne Seite anzeigen lassen wollen, und zwar die von uns angelegte home und dass wir als Blogseite unsere test-Seite verwenden wollen. Außerdem hinterlegen wir in den Theme Mods hinter dem Schlüssel color den (Farb-)Wert #f00.

Die Konfiguration filtern

Der Filter get_theme_starter_content kann diese Konfiguration dann noch einmal filtern. Dies ist vor allem dann nützlich, wenn ein Plugin sich einhaken möchte, um sein eigenes Widget in der einer Sidebar gleich mit zu präsentieren.

Schluss

So, ich hoffe, dieser kleine Überblick über das “Starter-Content”-Feature in WordPress 4.7 konnte Euch ein wenig weiterhelfen. Dieses Feature ist natürlich vor allem für Themeentwickler⋅innen interessant, welche ihre Themes einem größeren Publikum zur Verfügung stellen möchten. Es ermöglicht Euren Benutzer⋅innen einen möglichst schnellen und schmerzlosen Start mit dem von Euch entwickelten Theme.

Was hälst Du vom neuen “Starter-Content”-Feature? Hast Du es schon einmal eingesetzt oder ist es Dir als Anwender⋅in schon einmal aufgefallen?

Schlicht – Das neue WordPress Theme für meinen Blog

Das Schlicht Theme

Beginnen wir erst einmal damit, das Alte zu Grabe zu tragen: Ich glaube, ich hatte jetzt zwei oder drei Jahre hier im Blog immer das gleiche Theme laufen: Gumbo. Ich kann auch überhaupt nichts Schlechtes über das von Themato Soup erstellte Theme sagen; Es ist immer noch ein schickes Blogdesign. Eines der wenigen im Repository, welches hält was es verspricht und tatsächlich etwas verspricht. Zwar heißt es dort mittlerweile, dass es seit über zwei Jahren nicht mehr aktualisiert worden ist, da es aber wirklich ein solide gearbeitetes Theme ist, läuft das nach wie vor und ich glaube, es wird auch noch einige Zeit laufen.

Aber nach so langer Zeit wurde ich einfach etwas müde, auf meinen Blog zu schauen. Nur konnte ich mich nie aufraffen, mal ein anderes Design auszuwählen oder gar selbst aufzusetzen. Meine Fähigkeiten in dies Richtung sind auch eher beschränkt. Ich hatte schon ein bisschen mit Hannover geliebäugelt. Florian Brinkmann hat da einfach ein Händchen für schöne Blogdesigns. Aber so richtig durchringen konnte ich mich nicht.

Dann flog vor einiger Zeit ein Tweet über meine Timeline und ich wusste, wie mein Blog in Zukunft aussehen würde:

https://twitter.com/FloBrinkmann/status/804350472391888896

Schlicht hat eigentlich schon alles im Namen. Es kommt in einem schlichten und zurückhaltenden Design und ist überwiegend in Grautönen gehalten. Ich hätte ja nicht gedacht, dass ich einmal mit einer Serifenschrift im Block enden würde, aber das von Florian gewählte Sorts Mill Goudy hat es mir tatsächlich angetan und mit einer guten Schriftart fängt eigentlich jedes gute Blogdesign an.

Über den Customizer kann man zwischen zwei Grundlayouts wählen. Das erste Layout könnt Ihr in meinem Blog sehen, dass Zweite finde ich aber auch sehr schick. Die Überschrift findet sich dann links mit den ganzen Metadaten wie Autoren, Datum und so weiter und rechts dann der Beitrag. Ich hätte das zweite Layout gewählt, wenn ich nicht meine Sidebar dadurch verlieren würde, mit der ich Euch (jetzt in rot) auf mein Buch aufmerksam machen möchte. Beides zusammen ging leider nicht und so habe ich mich für die erste Variante entschieden.

Darüber hinaus kann man auch Initiale einschalten, wie man es aus Zeitungen oder Büchern kennt. Hier weiß ich noch nicht so recht und habe diese erst einmal nicht aktiviert. Neben der Sidebar gibt es noch einen Widgetbereich im Footer und man kann auch zwei Menüs einrichten. Für diesen Blog habe ich einfach schnell im Footer ein Menü für Impressum und dieses Zeug eingerichtet.

Schlicht ist Florian Brinkmanns erstes kommerzielles Theme und man kann es für 15 Euro direkt auf seiner Seite erwerben. Wenn man es herunterlädt kommt es gleich mit einem Child Theme zusammen, was einem die Mühe erspart, da selbst erst wieder eines zusammenzustöpseln. Das ist auf jeden Fall top. Darüber hinaus gibt es einen Updater, so dass ihr das Theme selbst ganz bequem über das Backend aktualisieren könnt, wie jedes Design, welches ihr über das WordPress Repository beziehen würdet.

Ja, ich habe ein neues Theme 🎉. Gefällt es Euch auch so sehr wie mir?