Die Wahl des richtigen Slider-Plugins

Ende 2016 begann ich mit der Neugestaltung einer Firmen-Website. Beim CMS fiel die Wahl auf WordPress, einerseits, weil es alles bietet, was ich brauche, andererseits zugegebenermaßen der Einfachheit halber, denn mit WordPress, den Core-Funktionen, den Plugins und dem Template-System kenne ich mich recht gut aus und kann damit ohne viel Nachforschungen in der Dokumentation oder dem Codex schnell zum Ziel kommen.

Auf der Startseite sollte ein Slider angezeigt werden, der hübsch animiert diverse Bilder durchblättert, die das Tätigkeitsgebiet der Firma zeigen. Soweit so gut. Tatsächlich war das das erste Projekt, in dem ich einen solchen Slider verwenden musste, ich probierte diverse aus und war generell eher unzufrieden. Zum Schluss blieb ich an Master Slider hängen, das Plugin ist kostenlos im Plugin-Repo von WordPress zu finden, kann aber (wie so viele Plugins) durch den Erwerb einer Lizenz erweitert werden. Das tat ich allerdings nicht, da die recht einfachen Anforderungen schon erfüllt waren.

Als Bilder wurden recht hoch auflösende Fotos genutzt, die wiederum in Ausschnitten angezeigt wurden und über die gesamte Breite der Startseite gingen.

Dieses Projekt ging Anfang des letzten Jahres online, war aber nie so richtig fertig, da ich es nebenbei, neben meiner eigentlichen (vollen) Arbeitszeit bearbeitete. Vor kurzem erledigte ich ein paar offene Punkte und sah mir auch noch einmal die Performance der Seite genauer an. Tatsächlich war diese sehr schlecht. Pagespeed Insights strafte mich mit wenigen Punkten, die Ladezeit war sehr hoch (und wir reden von teilweise zweistelligen Sekundenzahlen) und die Datenmenge hoch. Nach sehr kurzer Recherche fiel der Blick wieder auf das Slider-Plugin. Die Dateigröße der über das Plugin hochgeladenen Bilder war enorm, in den Einstellungen war ausgewählt, dass die Bilder passend zugeschnitten werden, was ich in der Realität aber nicht feststellen konnte und aus irgendeinem Grund, lud mein Browser (und damit vermutlich auch jeder andere) die Seite deutlich länger, als er es auch bei der hohen Datenmenge gemusst hätte. Ich habe das nicht sehr genau analysiert, aber es fiel auf, dass die Ladezeit mit einem kompletten Durchlauf des Silders zusammenhing.

Also machte ich mich wieder auf die Suche und war wieder generell eher unzufrieden, fand dann aber MetaSlider, ebenfalls im offiziellen Plugin-Repo kostenlos erhältlich und gegen Geld erweiterbar. Der Funktionsumfang hier ist allerdings noch etwas größer und einige Funktionen, die bei Master Slider Geld kosten, sind hier schon mit drin.
Ich lud hier die Bilder erneut über das Plugin hoch und spielte etwas mit den Einstellungen und tada: Die Funktion ist quasi die selbe, die Seite lädt nun aber deutlich schneller und Pagespeed Insights hat nur noch wenig auszusetzen (aus dem Stand von ca. 60 Punkten auf nun 93, ohne weitere Optimierungsarbeit).

Bis auf etwas grübeln hat mich das ganze quasi keine Arbeit gekostet, mir jedoch gezeigt, dass man sich nicht darauf verlassen kann, dass ein Plugin mit über 100.000 Installationen und einer ziemlich guten Bewertung auch wirklich ohne Probleme einsetzbar ist. Der Aufwand, hier etwas gründlicher auszuwählen, lohnt sich.

WordPress-Plugin veröffentlicht: Simple Terms And Conditions for BuddyPress

Ich habe mir quasi als Vorsatz für 2016 vorgenommen, Speziallösungen für WordPress, die eventuell auch anderen helfen könnten, im WordPress Repository in Pluginform zu veröffentlichen.

Das erste Plugin wurde vorgestern gesichtet und freigegeben und ist seit eben im Repository verfügbar, es handelt sich um „Simple Terms And Conditions for BuddyPress“ und fügt, wie der Name vielleicht schon vermuten lässt, der BuddyPress-Registrierungsseite eine Checkbox zum Bestätigen der Nutzungsbedingungen hinzu.
Alle angezeigten Texte, sowie die Style-Parameter des umschließenden div lassen sich über das Backend ändern, es muss also nirgendwo in den Code eingegriffen werden.
Aktuell arbeite ich an Version 1.1 mit übersetzbaren Strings und deutscher Sprachdatei.

Ich habe, da höchstwahrscheinlich demnächst mindestens ein weiteres Plugin folgt, eine Unterseite angelegt, die als Verzeichnis der Plugins dienen soll. Das Plugin selbst hat eine eigene Seite mit einer etwas ausführlicheren Beschreibung und Anleitung erhalten.

Ab sofort nur noch HTTPS

Wer das hier liest, tut dies über eine mit einem von Let’s Encrypt ausgestellten Zertifikat verschlüsselte Verbindung.

Komischer Satz, ist aber so, ich habe die Seite komplett auf HTTPS umgestellt, alle internen Links geändert und alle eingebundenen Medien aktualisiert, es sollte nun also alles verschlüsselt sein.

Danke an natenom für den dezenten Hinweis, sich mal wieder mit dem Thema SSL/TLS zu beschäftigen. Tatsächlich ist jetzt, wo Let’s Encrypt produktiv nutzbar ist, der Aufwand kein Grund mehr, Internetseiten nicht verschlüsselt zu übertragen. Schon StartSSL war ja eine deutliche Hilfe, nun muss man aber noch nicht einmal mehr lange warten, bis Zertifikate ausgestellt werden.

Hier habe ich aufgeschrieben, wie man das Hostingpanel ISPConfig so patcht, dass es automatisiert Zertifikate von Let’s Encrypt anfordert.

Fix: WordPress Multisite Core Bug in WordPress 4.2.2

Nach längerer Zeit bin ich derzeit mal wieder damit beschäftigt, eine Website mit WordPress aufzuziehen. Sie benötigt die Multisite-Fähigkeiten (bekannt als „Netzwerk“) von WordPress.

In WordPress 4.2.2 jedoch gibt es einen Core-Bug, der besonders diese Funktion betrifft. Es ist nicht möglich, eine neue Seite zu erstellen, da die entsprechenden Tabellen in der Datenbank nicht angelegt werden können, beim Anlegen der neuen Seite gibt es einen Haufen Fehlermeldungen (sofern man die Debug-Ausgabe aktiv hat) oder eine weiße Seite (wenn nicht).
Die neue Seite erscheint zwar nachher im Dashboard, jedoch fehlen die Tabellen und so gibt es natürlich auch einen Datenbank-Fehler wenn die Seite aufgerufen wird.

Zu diesem Problem gibt es eine Lösung, die allerdings erst beim nächsten WordPress-Update in den Core einfließen wird. Wer nicht so lange warten will, kann mehrere Patches anwenden und die betroffenen Dateien selbst fixen. Da diese Patches nicht ganz einfach zu finden sind, hier die Zusammenfassung:

  • Ticket 32308 betrifft die Datei /wp-includes/formatting.php und hat den Patch 32308.1.patch hervorgebracht.
  • Ticket 32127 betrifft die Dateien /wp-includes/wp-db.php und /wp-admin/includes/upgrade.php, hierzu gehört der Patch 32127.3.patch, welcher jedoch nicht direkt auf WordPress 4.2.2 anzuwenden ist (der erste Fix ist nicht gültig).

Der Einfachheit halber nun hier noch die drei Dateien in der gepatchten Version zum Download (Achtung! Das wird nur mit WordPress 4.2.2 funktionieren und ich übernehme keinerlei Garantie dafür!):

Patch WordPress Multisite in WordPress 4.2.2