Als wäre es gestern gewesen. Im Mai 2018 ging es um die Reduktion der Bildgröße beim direkten Upload von Bildern z. B. von einer Digitalkamera.
Mein Favorit war ja das Urgestein Resize images before upload, das aber mit Stand Jänner 2021 seit 7 Jahren nicht mehr upgedatet wurde. Das wäre ja nicht das Problem, weil es ja immerhin Bilder mit einer Kantenlänge von 8.000 Pixel verarbeiten konnte. Mit Einführung des Gutenberg Editors funktioniert das aber nicht mehr. Ein Workaround wäre die Verwendung des Classic Editor Plugins, was aber wieder ein Rückschritt wäre.
reSmushit.it funktioniert zwar sehr gut mit dem Gutenberg Editor und ist zudem gratis, verkleinert aber nicht die Kantenlänge der upgeloadeten Bilder.
Das kann Resize Image After Upload. Im Gegensatz zu reSmushit.it können Bilder aber nicht nachträglich auf Größe optimiert werden. Wobei reSmushit.it nur komprimiert, aber nicht die Anzahl der Pixel reduziert. Nutzt man beide Plugins parallel, sollte bei reSmush.it aber in den Einstellungen der Haken bei Optimiere bei Upload rausgenommen werden.
Es können Bilder mit einer Kantenlänge vo 6.500 x 6.500 Pixel verarbeitet werden. Bei 7.000 Pixel Kantenlänge versagt das Plugin mit der Fehlermeldung:
Die Antwort ist keine gültige JSON-Antwort.
Imsanity konnte beim letzten Test 2018 keine Bilder mit 3.500 Pixel Kantenlänge verarbeiten. Mittlerweile können Bilder mit zumindest 6.500 Pixel Kantenlänge verarbeitet werden. Die Größenreduktion erfolgt hier wie bei Resize Image After Upload über maximale Pixel in Höhe und Breite.
Imsanity bietet auch mehr Einstellmöglichkeiten und kann zudem alle Bilder nachträglich optimieren.
Man kann bei der Gelegenheit auch versuchen den Speicher für die PHP-Skripte zu erhöhen.
php_value memory_limit 512M
In meinem Fall funktioniert das aber nicht, weil das Limit vom Server vorgegeben wird.
Lässt sich das Limit (durch Sicherheitseinstellungen des Servers) nicht über die .htaccess ändern bleibt nur mehr die Möglichkeit die php.ini (sofern erlaubt) am Server zu ändern.
Gelegentlich wird auch vorgeschlagen die wp-config.php um den Eintrag WP_MEMORY_LIMIT zu erweitern. Das kann, muss aber nicht funktionieren.
Wer sich in WordPress die Optionen anzeigen lassen will, die normalerweise nur über die Datenbank (wp_options Tabelle über phphMyAdmin) oder die Oberflächen im Adminbereich ersichtlich sind, kann das über:
http://ihre_domain.xxx/wp-admin/options.php
tun.
Das funktioniert, wenn man eingeloggt ist. Die Optionen können auch geändert werden inklusive der Möglichkeit die Seite damit zum Absturz zu bringen.
Kaum ein Website-Betreiber, der nicht wissen will, was sich auf seiner Homepage so tut. Wer kommt, wer geht und wie lange er auf welcher Seite der Website verweilt.
Seit geraumer Zeit ist Google Analytics ein Werkzeug, dass diese Einblicke gewährt. Ist mal ein Analytics-Konto eingerichtet und der Tracking-Code auf den Seiten vorhanden, werden anonym Daten gesammelt welche IP-Adresse (also der Webbesucher) welche Seiten der Website aufruft.
Es gab schon länger WordPress-Plugins, die diese Informationen im WordPress-Dashboard bereitstellten. Da die (Weiter-)Entwicklung solcher Plugins von jeher zeitintensiv war, ist es auch verständlich, dass es Programmierer und Firmen gibt, die auf ein Geschäftsmodell setzen, das ein abgespecktes gratis Grundpaket anbietet, erweiterte Informationen aber nur über ein kostenpflichtiges Pro-Modul.
Wer sich jedoch nicht für „jedes“ Plugin die Kosten leisten kann oder will, greift im Falle von Google Analytics vielleicht auf das Google Site Kit direkt von Google zurück.
Ist das Plugin installiert, startet man zunächst die Einrichtung während der man sich mit der Gmail-Adresse einloggt, die auch im vorhandenen Google-Analytics-Konto verwendet wird.
Ist die Eigentümerschaft der Website verifiziert, muss noch der Website-Zugriff auf die Google-Konto-Daten erlaubt werden.
Und zum Schluss wird noch der Zugriff auf die Google Search Console eingerichtet und zum WordPress Dashboard zurückgekehrt (Go to my Dashboard). Hier ist zu beachten, dass die Search Console nicht mit Google Analytics identisch ist.
Zurück im WordPress Dashboard verbindet man sich mit dem Analytics Dienst (Analytics Dienst verbinden). Nach der Abfrage des zu verwendenden Google Kontos kann man Site Kit erlauben auf das Google-Analytics-Konto zuzugreifen.
Hat man ein Konto, aber Google Site Kit kann darauf nicht zugreifen, hilft Re-fetch My Account. Hat man jedoch kein Konto, kann man es an dieser Stelle anlegen.
Sind Search Console und Analytics Dienst verbunden, dauert es noch eine Zeitlang, bis Daten gesammelt wurden und im Dashboard angezeigt werden können. In der Zwischenzeit sieht es nämlich so aus:
Nach einiger Zeit füllen sich die Anzeigen im Dashboard nach und nach. Details findet man, wenn man dem Link zum entsprechenden Dienst bei der Quellenangabe folgt.
Bei der Gelegenheit kann man sich auch gleich für den PageSpeed Insights Dienst anmelden, der die Website für Mobilgeräte und Desktops evaluiert und bewertet. Das sieht dann so aus:
… alt aber gut. Zunächst erschreckt es, dass das Plugin deutlich in die Jahre gekommen ist. Im April 2018 behauptet WordPress.org, das Plugin wäre seit 5 Jahren nicht mehr aktualisiert worden und wurde nicht mit der aktuellen WordPress Version getestet.
Andererseits kann es (noch immer) sehr große JPG Dateien verarbeiten.
Ohne zusätzliche Plugins kann man je nach Template verschiedene Größen für Bilder festlegen, die von WordPress dann automatisch erstellt werden.
So kann z. B. ein Bild mit 1.000 x 1.000 Pixel hochgeladen werden und WordPress erstellt daraus zusätzlich ein Vorschaubild, ein mittelgroßes Bild und ein großes Bild.
Das funktioniert z. B. mit einem quadratischen Bild mit 3.000 Pixel aber nicht mehr mit 3.500 Pixel. Letzteres bringt einen HTTP-Fehler, wenn man versucht solch ein Bild rauf zu laden. Das hängt damit zusammen, dass letzteres Bild am Server quasi als RAW-Bild mit 12,25 Millionen Pixel und praktisch ebenso vielen Bytes erstellt wird. Und das ist für PHP bzw. je nach Servereinstellungen zuviel.
Plugins wie Smush Image Compression and Optimization oder reSmush.it Image Optimizer reduzieren zwar die Dateigröße durch Komprimierung aber nicht die Anzahl der Pixel.
Das macht z. B. Imsanity.
Hier zusätzlich wird die maximale Größe für das raufgeladene „Originalbild“ festgelegt. Aber auch Imsanity gelingt es nicht ein quadratisches 3.500 Pixel Bild zu verarbeiten.
Nun kommt der Veteran Resize images before upload und zeigt wie es geht.
Auch hier werden die maximalen Abmessungen eingegeben, ABER das ganze funktioniert auch noch mit Bildgrößen von 8.000 Pixel im Quadrat. Lediglich bei 8.500 Pixel gibt das Plugin auf, was aber für die meisten Anwender und ihre Kameras kein Problem darstellen sollte.
Resize images before upload kann über die wp-config.php auch konfiguriert werden:
define( ‚RIBU_RESIZE_WIDTH‘, 1000 ); //1000 px wide
define( ‚RIBU_RESIZE_HEIGHT‘, 900 ); //900 px high
define( ‚RIBU_RESIZE_QUALITY‘, 75 ); //0-100, 100 being high quality
defined( ‚RIBU_MAX_UPLOAD_SIZE‘ ‚2097152b‘ ) ); //size in bytes
Das Solaz Them von Arrowpress ist ein Hotel Theme, das u. a. durch seine Schlichtheit auffällt.
Einen Vorgeschmack bekommt man auf der Demoseite des Herstellers wo man sich gleich mal für eine von 4 Homepages entscheiden kann – im konkreten Fall haben wir uns für Home 2 entschieden.
Nachdem das komplette Theme käuflich erworben und heruntergeladen ist, finden sich der Ordner Dokumentation, Import, Licensing, Plugins und Theme files.
Die Dokumentation besteht aus einem Textfile, dass auf eine Internetseite verweist, die nicht existiert … das ist enttäuschend (aber zumindest ist die Dokumentation noch im Google Cache und kann von dort gesichert werden – Stand Ende September 2017)
Theme Installation
Über die WordPress Theme-Installation können das Solaz und das Solaz-child Theme auf den Server geladen werden.
Plugin Installation
Die Ansage von Solaz überrascht zunächst ein wenig:
This theme requires the following plugins: ArrowPress Importer, ArrowPress Shortcodes, Contact Form 7, Redux Framework, Revolution Slider, Ultimate Addons for Visual Composer, WP Hotel Booking, WPBakery Visual Composer, Woocommerce and Yith Woocommerce Wishlist.
This theme recommends the following plugins: ArrowPress Social, MailChimp for WordPress, WP Store Locator and WP User Avatar.
ArrowPress Importer
ArrowPress Shortcodes,
Revolution Slider
WPBakery Visual Composer
Ultimate Addons for Visual Composer
und ArrowPress Social
… sind zumindest schon mal im Downloadpaket enthalten und können als ZIP-Datei auf den Server geladen werden.
WPBakery Visual Composer will mir bei der Gelegenheit gleich eine Premium Lizenz aufs Auge drücken und verbindet sich dazu gleich frech mit der Verkaufsplattform, über die das Theme bezogen wurde, um dann festzustellen, dass darin keine Premium Lizenz enthalten ist … no na ned ;-)
Ebenso biedert sich Slider Revolution mit Premium Benefits (für Premium Geld) an.
Im Dashboard muss bei Ultimate Addons for Visual Composer => Google Maps ein API-Key eingetragen werden
Contact Form 7, Redux Framework, WP Hotel Booking,Woocommerce und Yith Woocommerce Wishlist
Woocommerce schlägt gleich mal vor den Einrichtungsassistenten auszuführen … das kann erst mal warten. Was aber eingestellt gehört ist unter Einstellungen => Kundenkonten => Kundenregistrierung => Aktiviere Kunden-Registrierung auf der „Mein Konto“-Seite.
Demo Content Import
Das ist zunächst etwas verwirrend, weil die Importfunktion NICHT die in Solaz => Import/Export ist sondern die unter in Design => Import Demos …. dort ist entsprechend unserer Vorlage Home 2 zu wählen.
Als nächstes muss noch der Slider importiert werden. Slider Revolution => Slider importieren => Datei auswählen … die entsprechende Datei ist in unserem Fall die home2.zip im Import/home_2 Verzeichnis des heruntergeladenen Themes.
Es fällt allerdings auf, dass das Theme (noch?) keine Sprachauswahl aufweist.
Viele Stunden später … Conclusio
Es stellt sich die Frage, wie viele Stunden die Theme-Ersteller benötigten, um die Vorlage so aussehen zu lassen, wie sie auf deren Homepage abgebildet ist.
Und dann stellt sich die Frage wie steil die Lernkurve bei der Vielzahl an zusätzlichen Plugins subjektiv empfunden wird.
Kommt dann noch hinzu, dass Sprachauswahl und Schnellanfrage nicht funktionieren, ist der Aufwand plötzlich im Bereich der Nichtabschätzbarkeit – und damit auch die Kosten für den Kunden.
Man könnte daraus lernen, dass nicht alles Gold ist, das (auf den ersten Blick) glänzt und dass eine 90%-Lösung mitunter eher einem pragmatischen Ansatz entspricht im Vergleich zur 100% Lösung die mit den budgetierten Mitteln nicht zu erreichen ist.
Somit empfiehlt es sich das KISS-Prinzip anzuwenden … keep it simple and stupid … oder „Weniger ist mehr“. Einfache Vorlagen verwenden und diese wenn es (unbedingt) sein muss mit der Funktionalität von Plugins erweitern.
UpdraftCentral ist ein vorzügliches Tool, um ein WordPress-Backup zu erstellen.
Es gibt die Möglichkeit Backups für fremde (verbundene) Seiten mit dem UpdraftCentral Dashboard Plugin durchzuführen. Ebenso können Backups auf Dropbox, Google Drive u. a. ausgelagert werden, was besonders bei beschränktem eigenen Speicherplatz oder auch im Sinne der Redundanz von Vorteil ist. Ein WordPress-Backup kann sogar per E-Mail versendet werden, wobei typische E-Mailgrößenbeschränkungen (meist zwischen 10 und 20 MB) zu beachten sind.
Wozu also ein neues Plugin um ein Backup der WordPress Dateien durchzuführen?
Ganz einfach … UpdraftCentral sichert NICHT die Verzeichnisse wp-includes und wp-admin. Das ist in der Regel auch nicht notwendig, weil diese Dateien ganz leicht im Original wieder hergestellt werden können – und dann auch noch in der aktuellsten Version. Zudem sollten Dateien in diesen Verzeichnissen von Nutzer auch nicht geändert werden. Geänderte (im Vergleich zu den Originaldateien) und hinzugekommene Dateien werden unter anderem vom Sicherheits-Plugin Sucuri Security entdeckt.
Wurden die Dateien dennoch geändert, stellt sich die Frage, ob legitim oder durch einen Hacker-Angriff. Hat man keinen FTP-Zugriff, kann man den Inhalt „verdächtiger“ Dateien nicht prüfen … und mit UpdraftCentral auch nicht herunterladen.
Somit kommt BackWPup für ein WordPress-Backup wieder ins Spiel. Auf der Plugin-Seite auf WordPress.org gibt es das Plugin zum Download.
Für das praktische WordPress-Wartungs-Tool MainWP gibt es (so wie für UpdraftCentral) eine Extension wodurch ein WordPress-Backup auch für ferngewartete Seiten einfach wird.
Welches Tool mittel- oder auch langfristig das Bessere ist, kann zur Zeit nicht eindeutig beantwortet werden. Wie so oft scheint es Geschmacksache zu sein.
Alternativen?
Das Duplicator-Plugin mit dem man ebenfalls ein WordPress-Backup durchführen kann, ist in der kostenfreien Version aber hinsichtlich des Speicherorts eingeschränkt. Hier kann nur auf der eigenen Seite (dem eigenen Webspace) gesichert werden. Duplicator wurde in der Vergangenheit eingesetzt um Seiten zu migrieren – d.h. von einem Server zum anderen oder von einem Verzeichnis in ein anderes zu transferieren.
Allerdings ist Letzteres eine Funktion, die auch mit UpdraftCentral und BackWPup möglich ist – obgleich ich es selbst noch nicht verwendet habe.
