Category Archives: Plugins

Animierte GIFs sind die Hölle

Zumindest im Plugin-Bereich von WordPress oder der eigenen WordPress-Seite!

Man sucht nach einem Plugin, erhält 537 Ergebnisse und muß sich jetzt einen Überblick verschaffen. Das wird aber immer schwieriger, weil die Icons, die bei den Plugins dabeistehen, ganz oft mit GIF-Animationen versehen sind, die die Aufmerksamkeit auf sich ziehen und das Lesen und Verstehen der Plugin-Beschreibungen völlig unmöglich machen.

Wir befinden uns im Zeitalter der ständigen Ablenkung. Digital Fatigue.

Aber man kann auch was degegen tun!

Mein Plugin der Woche ist Toggle Animated GIF für Mozilla.

Und plötzlich hört das nervige Geblinke auf.  Aaaaahhhh 🙂

Ob die „Hersteller“ dieser GIFs wohl wissen, daß viele Leute wegen diesem Nerv das Produkt und die Herstellerfirma ablehnen und die beworbenen Dinge absichtlich ignorieren? Neee…vermutlich nicht…

YITH WooCommerce Custom Order Status funktioniert nicht unter PHP8? Doch!

Ich sollte wieder mehr Beiträge schreiben. Gelegentlich liest das jemand und kann damit sogar was anfangen 🙂

Also gut…was gibt’s heute?

Nach Umstellung auf PHP8 funktioniert das YITH WooCommerce Custom Order Status-Plugin nicht mehr?

Das ist ganz einfach zu beheben. Gut wenn man ein Error-Logfile hat oder Fehler direkt angezeigt bekommt, denn da steht dann etwa das hier:

Deprecated: Array and string offset access syntax with curly braces is deprecated in /wp-content/plugins/yith-woocommerce-custom-order-status/plugin-fw/lib/yit-plugin-gradients.php line 443

Das bedeutet, daß es ab PHP8 verboten ist, ArrayElemente mit geschweiften Klammern anzusprechen, und das ist hier der Fall:

Das hier:

$base[‚R‘] = hexdec( $color{0} . $color{1} );
$base[‚G‘] = hexdec( $color{2} . $color{3} );
$base[‚B‘] = hexdec( $color{4} . $color{5} );

muß ersetzt werden durch das hier:

$base[‚R‘] = hexdec( $color[0] . $color[1] );
$base[‚G‘] = hexdec( $color[2] . $color[3] );
$base[‚B‘] = hexdec( $color[4] . $color[5] );

 

Der GoogleMaps-Geocoder ist auch nicht mehr das was er mal war!

Ein Update zu meinem Artikel von neulich: „The Events Calendar“ mit OpenStreetMaps statt Google Maps.

Es hat quasi alles geklappt mit der im Artikel beschriebenen OpenStreetMap. Nur lagen manche Marker und Adressen extrem daneben, z.B. mitten in den USA, westlich von Sardinien im Meer oder auch in Zentralafrika. Dabei liegen die Orte eindeutig im schönen Rheinhessen. Was stimmt hier also nicht?

Das Problem trat sowohl auf der im ersten Artikel beschriebenen Events-Calendar-Seite als auch bei einer anderen WebSite auf, die die Adressen einfach aus einer selbst erstellten Dartenbank holt. Egal was man tut…es ist immer irgendwas nicht ok.

Offensichtlich ist es so, daß der Geocoder von Google Maps (also der Service, der aus einr Adresse Koordinaten macht) in letzter Zeit unzuverlässig geworden ist. Etwa seit Mai 2018, als dort zwingend Kreditkartendaten und strengere Regeln für die Benutzung eingeführt wurden (wieder ein Grund mehr, auf OpenStreetMaps umzustellen).

Deshalb habe ich folgende Lösung programmiert:

  • Ein neues Custom Field erstellt, und „latlng“ genannt.

Dazu muß man rechts oben im WP-Admin auf Optionen gehen und „Benutzerdefinierte Felder“ anwählen. Beim ersten Mal muß man „neues Feld“ auswählen und ihm den Namen „latlng“ geben. Beim nächsten Mal existiert latlng dann schon, das muß man dann in der Liste auswählen.

Links oben den Ort suchen. In der dann erscheindenden Karte die richtige Adresse lokalisieren, dann mit der rechten Maustaste dahin klicken und „Adresse anzeigen“ wählen. Jetzt erscheinen links die Koordinaten. Toll, gell?

  • Die Koordinaten komplett kopieren (etwa „49.7427,8.2378“), mitsamt dem Komma, und in das Feld latlng eintragen. Seite / Beitrag dann speichern.

Adresse stimmt jetzt, jetzt nur noch die Anzeige von Adresse auf Koordinaten umstellen, wenn dieses Feld gefüllt ist.

  • Die in der functions.php vorhandene Funktion, die den [leaflet-map]-Shortcode erzeugt, etwas erweitern.

Ich gehe mal davon aus, daß die Adresse bekannt ist, etwa in der Art oder so ähnlich:

$address .= $strasse." ".$hausnummer.", ".$plz." ".$ort;

dann wäre die Version mit funktionierendem Geocoder z.B. folgende:

$sc  = "[leaflet-map address='".$address."' tileurl='https://{s}.tile.opentopomap.org/{z}/{x}/{y}.png' zoom=14]";
$sc .= ' [leaflet-marker address="'.$address.', DE" '.$icon.']';
$sc .= $address.'[/leaflet-marker]';

muß jetzt geändert werden zu

$latlng = get_post_meta($post->ID, 'latlng');
if ($latlng) {
$latlng = explode(",", $latlng[0]);
$sc = '[leaflet-map lat='.$latlng[0].' lng='.$latlng[1].' tileurl="https://{s}.tile.opentopomap.org/{z}/{x}/{y}.png" zoom=14]';
$sc .= ' [leaflet-marker lat="'.$latlng[0].'" lng="'.$latlng[1].'" '.$icon.']';
$sc .= esc_html($address);
$sc .= '[/leaflet-marker]';
}
else {
$sc = "[leaflet-map address='".$address."' tileurl='https://{s}.tile.opentopomap.org/{z}/{x}/{y}.png' zoom=14]";
$sc .= ' [leaflet-marker address="'.$address.', DE" '.$icon.']';
$sc .= $address.'[/leaflet-marker]';
}

Jetzt stimmts 🙂

„The Events Calendar“ mit OpenStreetMaps statt Google Maps

Ein sehr beliebtes Kalender-Plugin ist The Events Calendar…auch schon in der kostenlosen Basisversion wunderbar und meistens ausreichend.

Man kann auch automatisch Google Maps einbinden. Das kann aber datenschutzrechtlich problematisch sein, denn eingebundene GoogleMaps benutzen viele viele Cookies und viele Tracker, um den Besucher der WebSite zu identifizieren und nachzuverfolgen. Das sollte man abschalten!

Eine Möglichkeit, OpenStreetMaps statt Google Maps einzubinden sucht man vergeblich. Auch der Support vom Events Calendar ist da eher lustlos: „Danke für deine Anfrage. Im Moment machen wir ganz viele Sachen, und evtl. ist dieses Feature auch schon dabei. Ansonsten schreib das doch einfach auf die Wishlist. Wir melden uns bei dir wann wir uns dransetzen.“ Tja…das Thema ist seit 4 Jahren in der Wishlist, und niemand hat sich je drangesetzt.

Also…setze ich mich halt mal dran 🙂

  1. Zuerst braucht man natürlich einen installierten  The Events Calendar mit mindestens einer Veranstaltung, die eine Adresse hat („Schnitzelbacher Straße 77a, 66321 Schmutzweiler“ z.B.). Jetzt im Admin-Bereich beiVeranstaltungen -> Einstellungen -> Allgemein -> Karteneinstellungen -> Google Karte aktivieren -> ankreuzen.Klar, dann kommt jetzt eine GoogleMap, aber die ist auch gleich wieder weg.
  2. Jetzt das Plugin Leaflet Map installieren. Das bindet wunderschöne OpenStreetMaps ein, mit wählbarem Stil (Wasserfarben etc.) und ist ganz leicht mit [shortcode] steuerbar.
  3. Jetzt muß man dem Events Calender nur noch sagen, daß er einen anderen Atlas nehmen soll:
    1. Die Datei the-events-calendar\src\views\modules\map.php finden
    2. und so wie oben in der Datei beschrieben  ins Theeme-Verzeichnis kopieren
      [your-theme]/tribe-events/modules/map.php
    3. Jetzt nur noch im Code ein paar Zeilen ändern. Das hier:

      $style = apply_filters( 'tribe_events_embedded_map_style', "height: $height; width: $width", $index );
      ?>
      <div id="tribe-events-gmap-<?php echo esc_attr( $index ) ?>" style="<?php echo esc_attr( $style ) ?>" aria-hidden="true"></div><!-- #tribe-events-gmap-<?php esc_attr( $index ) ?>

      ändern in

      $address = tribe_get_address( $venue_id ).", ".tribe_get_zip( $venue_id )." ".tribe_get_city( $venue_id ).", ".tribe_get_country( $venue_id );
      $shortcode  = '[leaflet-map address="'.$address.'" zoom="15" fit_markers="1"]';
      echo do_shortcode($shortcode);
      ?>

Fertig 🙂 Wer will kann bei der Karte jetzt noch mit diversen Shortcodes Aussehen und Verhalten ändern…

DSGVO#4 – Nützliche Plugins

Hier noch ein paar sinnvolle Plugins zur DSGVO:

  1. WP GDPR Compliance
    Erstellt Checkboxen und Infotexte neben Kontaktformularen
  2. Disable Comments
    Überall die Kommentarfunktion entfernen
  3. Ginger – EU Cookie Law
    Erstellt eine Cookie-Nervbox und blockiert auch tatsächlich viele Cookies, wenn der Benutzer auf „Nein“ klickt
  4. Antispam Bee
    Perfekter Ersatz für das datenschutzkatastrophale Akismet.
    Es müssen bei der Biene nur die 3 Optionen links unten abgewählt werden.
    Ich habe zusätzlich noch (links mitte) „“ deaktiviert…man weiß ja nie…

WordPress schneller machen #2: Performance-Bremsen ermitteln

Guten Tach!

Im ersten Teil habe ich ein paar Tools vorgestellt, mit denen man eine WordPress-Seite schneller machen kann…man würde ihr sozusagen um 10:30h einen Kaffee bringen. Was aber wenn sie vor Trägheit noch nicht einmal aus dem Bett kommt? Ist sie vielleicht zu schwerfällig? Haben wir zuviele Plugins an Bord? (Aber ich brauche doch alle 47 davon!). Müssen wir mal nachsehen…

Eine Spurensuche mit Sherlock McWoyng.

P3 in Action

P3 in Action…früher mal…

P3 (Plugin Performance Profiler)

Eigentlich war dieses Plugin immer mein Favorit…man konnte genau sehen, welches Plugin wieviel Performance an sich reißt.

Nur leider funktioniert das ganze nicht mehr, zumindest nicht be mir…P3 scannt sich ausschließlich selbst, und mittlerweile erhalte ich nur noch PHP-Fehler. Im Support-Forum scheint niemand zu antworten. Schade.

Muß also eine Alternative her!

Alternative List

Ich suche eine Alternative zu P3 mit der Seite

Alternativen zu P3

Simple Debug

Nein, bringt mir leider nichts…ich sehe alle möglichen Informationen, aber kann nicht feststellen, welches Plugin die Site ausbremst. Also weitersuchen…

Performance Profiler

Bringt mir leider auch nichts. Schade.

Also gut…there is obviously no easy solution…also müssen wir tiefer graben. Fragen wir doch das Insekt unseres Vertauens:

Firebug

Firebug öffnen, Rechtsklick auf die Seite und „Element untersuchen“, dann „Netzwerk“, Seite neu laden und mal nachsehen.

Aha!

Ach nee!

Wow!

Man sieht, daß sich die Startseite mit Google Maps verbinden möchte…was sie aber gar nicht bräuchte, weil es auf der Startseite gar keine Karte gibt! und das kostet wertvolle (Milli-)Sekunden.

Muß ich in dem Karten-Plugin abschalten! Die Stelle finden, an der der Google-Maps-JavaScript-Code eingebunden wird, und dann eine Abfrage machen, damit auf der Startseite keine sinnlose Map-Abfrage stattfindet. Etwa in der Art von:

Vorher:
$binde_kartenlink_ein;

Nachher:
if ($seite_auf_der_ich_bin != "Startseite")
   {
   $binde_kartenlink_ein;
   }

Gut…das mache ich jetzt mal.

*ärmelhochkrempel*

Fortsetzung folgt…

Vintage-Fotogalerie

Guten Tach mal wieder!

WordPress Polaroid Gallery

Ich suche gerade ein kostenloses Foto-Galerie-Plugin, bei dem die Bilder so ein bißchen schräg und abgenutzt aussehen, gern auch mit diesem gewellten Rand, den Fotos früher noch hatten…noch früher als „damals, als man Fotos noch entwickeln lassen mußte“.

Die Suche ist gar nicht so einfach…Millionen von geradlinigen, Flickr-artigen Kachel-Optiken…aber eine Vintage-Optik, die an ein altes verstaubtes Fotoalbum erinnert…Fehlanzeige 🙁

Das beste Plugin, das ich bislang gefunden habe, ist die Polaroid Gallery.

Jetzt nur noch schnell dem weißen Hintergrund eine schöne, alte Stuktur geben, das sollte dann schon mal gut aussehen.

Wäre toll, wenn ich den Rand der Fotos wellig machen könnte. Mal nachsehen, was mit CSS3 möglich ist 🙂

 

WordPress schneller machen #1: JavaScripts in den Footer

Ich schreibe jetzt in unregelmäßigen Abständen über meine Erfahrungen bei der Geschwindigkeitsoptimierung von WordPress.

Heute: JavaScripts vom Header in den Footer verschieben.

Zu viele JavaScripte können das Laden der Seite verzögern. Das liegt offenbar daran, daß Browser nicht mehr als 2 Dateien gleichzeitig von der gleichen Adresse downloaden können (sollten). Das kann man sehen, wenn man mehrere größere Downloads vom gleichen Server durchführt…mehr als 2 gehen nicht. Wenn wir uns den HTML-Quelltext unserer WordPress-Seite ansehen, bemerken wir darin fast immer recht viele Links zu JavaScript-Dateien. (bei mir sind es 19!) Mehr als 2. Jedes Plugin scheint sein eigenes JavaScript mitzubringen…das muß dann natürlich auch immer geladen werden. Alle diese JS-Dateien liegen auf demselben Server (nämlich meinem), also sagt die obige Regel „Haaaaalt…mehr als 2 sind verboten“. Das macht die Seite dann doch etwas langsamer. Verschärfend kommt hinzu, daß die Aufrufe immer im Header zu passieren scheinen…unser wertvoller, wohlformulierter INHALT muß warten, bis alles da ist!

Abhilfe: Alle JavaScript-Links vom Header in den Footer verschieben…dann kann man schon mal die ersten paar Zeilen des Inhalts lesen, während im Hintergrund unbemerkt noch JavaScript lädt.

Dazu gibt es, wie immer natürlich, Plugins.

Bei der Suche habe ich zuerst dies hier gefunden:

JavaScript to Footer

Super-einfach gebaut mit 6 Zeilen PHP. 3x remove_action(‚wp_head‘) und 3x add_action(‚wp_footer‘). Funktioniert. Aber…ääähhhh…Momentn…wo ist jetzt mein schöner Header-Slider mit Ken-Burns-Effekt abgeblieben? Der ist WEG!

Das liegt daran, daß der Slider JavaScript braucht, um zu funktionieren…nämlich unseren beliebten Multi-Werkzeugkasten jQuery! Wenn jQuery im Footer geladen wird, kann der Header, der davon abhängig ist, nicht funktionieren! Wir brauchen also ein anderes Plugin mit der Möglichkeit, jQuery im Header zu belassen und alles andere nach unten zu schieben. Und siehe da, das gibt es wirklich 🙂

Scripts to Footer

Nach Installation dieses Plugins geht man dann auf Einstellungen -> Scripts to Footer und kreuzt unten noch „Keep jQuery in Header“ an.

Fertig! Die Seite ist jetzt schneller 🙂

Demnächst mache ich sowas ähnliches mit den CSS-Dateien…

 

WordPress-Plugins: Update verhindern

Immer wieder gibt es Updates, die immer auch schnell installiert werden wollen: WordPress selbst, Themes und auch Plugins.

Blöd ist nur: Nach einem solchen Update sind eigene Anpassungen weg!

Bei WordPress selbst, in den Core-Dateien, ist das weniger problematisch…darin sollte man sowieso nicht selbst rumwurschteln, sonden auf Hooks und Filter zurückgreifen.

Bei Themes kann man mit Hilfe eines Child-Themes die selbstprogrammierten Anpassungen vor dem Update retten.

Und bei Plugins? Es gibt ja (noch?) keine Child-Plugin-Technik. Also muß man den Ordner des jeweiligen Plugins vor dem Update sichern, und die eigenen Anpassungen und Änderungen mit einem „Diff-Tool“ wie z.B. WinMerge wieder in die neue Version einkleben.

Oft klappt das auch, weil sich von Version 1.802 zu 1.803 vielleicht außer einem Bugfix und der hinzugekommenen mongolischen Sprachunterstützung nichts geändert hat.

Es gibt aber auch Plugins, bei denen in der neuen Version wirklich sehr viel geändert wurde und kein Stein auf dem anderen blieb. Da macht das Quellcode-Mergen mit WinMerge o.ä. bestenfalls nur keinen Spaß. Schlimmstenfalls geht es gar nicht.

Also was tun?

Die Antwort kommt aus der Schweiz, von Walter!

Einfach durch Änderung der Versionsnummer Plugin-Updates verhindern!

Das geht so:

1.) Plugins – Editor – und rechts oben das gewünschte Plugin wählen. Ich habe mal „Hello Dolly“ genommen.

2.) In der jetzt erscheinenden Liste der PHP-Dateien die richtige suchen. Sie heißt meistens genauso wie das Plugin und ist odftmals auch die einzige PHP-Datei. In unserem Fall ist es „hello.php“.

3.) Diese Datei öffnet sich jetzt im Editor. Oben stehen ein paar wichtige Kommentare im Header, wie z.B. diese hier:

/*
Plugin Name: Hello Dolly
Plugin URI: http://wordpress.org/plugins/hello-dolly/
Description: This is not just a plugin, it symbolizes the hope and enthusiasm of an entire generation summed up in two words sung most famously by Louis Armstrong: Hello, Dolly. When activated you will randomly see a lyric from <cite>Hello, Dolly</cite> in the upper right of your admin screen on every page.
Author: Matt Mullenweg
Version: 1.6
Author URI: http://ma.tt/
*/

4.) In der Versions-Zeile, wo jetzt „Version: 1.6“ steht, einfach eine riesige Zahl eintragen, so daß es z.B. später „Version: 100006000“ heißt.

5.) Speichern und fertig.

Danke Walter!