Resize images 2.0

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.

Google Site Kit Plugin in WordPress einrichten

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:

Das prima-general Plugin

[goback]

[pactiveplugins]

Liste der aktiven Plugins

[pano]

file => wp-content/upload/pano/...
width => 100%
height => 320

[pcookies]

Liste der gesetzten Cookies aus $_COOKIE

[pdiv]...[/pdiv]

Parameter (Defaults in fett)

pdiv_class => pdiv
pdiv_id => pdiv
style => style=""

[pdsgvo]

zeigt die Datenschutzerklärung, die mit dem Plugin hinterlegt wird

[pfindshortcode]

Parameter (Defaults in fett)

find =>

[pgaoptout]

Parameter (Defaults in fett)

pgaoptout_class => pgaoptout
pgaoptout_id => pgaoptout
content => Google Analytics deaktivieren
alert => Google Analytics wurde deaktiviert
content_in => Google Analytics aktivieren
alert_in => Google Analytics wurde aktiviert
html_tag =>a
delimiter =>  

[pprivate]...[/pprivate]

Parameter (Defaults in fett)

force_show => 0, 1, true, false
private_class =>

[ptel] oder [insertTel]

Parameter (Defaults in fett)

tel =>
add_name =>
button_show => 0, 1, true, false
button_class => phoneBtn

[pwppaths]

WordPress Pfade und Konstanten anzeigen wenn ein User eingeloggt ist.

Resize images before upload

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

Einstellungen > Medien

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.

Imsanity - Einstellungen

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.

Resize images before upload - Einstellungen

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

Captcha Code

Adds Captcha Code anti-spam methods to User front-end WordPress forms.

Mal sehen, ob dieses Plugin verhindern kann, dass Brute-Force-Attacken zum knacken des Login-Passworts geritten werden.

Das Plugin "Rename wp-login.php" konnte nicht verhindern, dass auf die Login-Seite zugegriffen wird.

 

Das prima-show-posts-by Plugin

Aus einer Notwendigkeit ist das Prima-Show-Posts-By-Plugin entstanden.

Es stellt zwei Shortcodes zur Verfügung

[ insertPostByCat] oder [ psp]

Parameter (Defaults in fett)

Query String

  • category_name => category slug
  • post_type => post|page|custom post
  • post_status => publish|pending|draft|auto-draft|future|private|inherit|any
  • p => post id
  • name => post slug
  • page_id => page id
  • pagename => page slug
  • posts_per_page => -1 = all
  • order => desc|asc
  • orderby => title, date, name, meta_value (meta_key setzen)
  • meta_key =>

Formatierung

  • post_class => psp_post_class z. B. sideBySide
  • show_title => true
  • title_tag => h2
  • title_class => psp_title_class

Features

  • separator => true|false
  • separator_last' => true|false ... setzt Separator nach dem letzten Beitrag
  • show_article_link => true|false
  • featured_image_link => true|false
  • title_link => true|false
  • show_excerpt => true|false

  • toggle_content => true|false
  • toggle_open_id => 1|n|0 = keines aufmachen
  • thumbnail_size => thumbnail|small-feature|post-thumbnail ... für Excerpt
  • startDay => 
  • endDay =>
  • startMonth =>
  • endMonth =>
  • meta_min => #für bereich bei order_by=meta & meta_key YYYY-MM-DD
  • meta_max =>

[ schedCont] oder [ ppscp]

Parameter (Defaults in fett)

  • post_class => scheduleContent
  • start => 1.1.
  • end => 31.12.

 

BackWPup - für das WordPress-Backup?

UpdraftCentral ist ein vorzügliches Tool, um ein WordPress-Backup zu erstellen.

Wordpress-Backup

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.

Awesome Responsive Menu

Dieses Plugin zum Einfügen eines mobilen Menüs ist eindeutig die bessere Wahl im Vergleich zum WPTouch-Plugin. Vor allem wenn es lediglich darum geht ein mobiles Menü in ein WordPress-Theme einzubauen, dass dieses selbst nicht vorsieht (z. B. das WordPress Twenty Eleven Theme).

Awsome Responsive Menu

Während Awesome Responsive Menu im Grunde macht was es soll (ein mobiles Menü einfügen), drängt einem WPTouch ein komplett neues Theme auf, dass in der nicht-Pro-Version auch nicht wirklich anzupassen ist. D.h. man muss unter anderem die Schriftfarben für Überschriften von WPTouch übernehmen. Die eigenen Farbeinstellungen gehen verloren.

Aber auch Awesome Responsive Menu hat so seine Schwächen ... oder sagen wir mal Schönheitsfehler.

Der Menu Breakpoint muss in den Einstellungen manuell eingegeben werden. Also die Breite in Pixel, ab der das Menü erscheint. Ich habe mich da für die Breite 800 entschieden, weil ab dieser Breite auch der Sidebar von Twenty Eleven ans Seitenende verschoben wird.

Die Verwendung der WordPressfunktion wp_is_mobile () wäre an dieser Stelle praktisch, weil größere Pads zwar die Breite im Browser erreichen, aber die Navigation dennoch eine andere ist (die Maus kann über einem Menüpunkt hovern, der Finger am Tablet nicht).

Und das man bei den Advanced Settings die ID des Menü-Containers zuerst suchen und dann eingeben muss, erschließt sich mir auch nicht auf den ersten Blick.

Awasome-Responsive-Menu-Settings