DSGVO#2 – Emojis und Gravatare entfernen

In WordPress 4.x (ich glaube 4.2) sind Emojis hinzugekommen. Die befinden sich auf einem zentralen Server.
Sind schnell ausgebaut: In die functions.php folgendes eintragen:

/* Entfernt die Emojis/Scripte/Styles im Frontend */
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

/* Entfernt die Emojis/Scripte/Styles im Backend */
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );

Gravatare werden zentral über einen Server von Automattic zusammengeführt. Datenschutzrechtlich auch sehr bedenklich.
Sind aber auch schnell deaktiviert:

Einstellungen -> Diskussion: unten den Haken bei „Avatare benutzen“ wegmachen und speichern.

DSGVO#1 – Cookies, Quellen und Tracker

OK, denn mal los mit der DSGVO-Konformitäts-Orgie.

Zuerst würde ich mal rausfinden, welche Cookies,  Quellen und Tracker eigentlich derzeit auf meiner Seite unterwegs sind. Wie geht das?

1.) Cookies in Mozilla:

  • in die Developer Tools gehen: Rechte Maustaste irgendwohin und dann auf Q drücken. Jetzt sollte etwas raus- oder aufklappen.
  • Cookies müssen erst aktiviert werden. Dazu auf das kleine Zahnrad klicken (in dem, was gerade geklappt ist) und bei „Standard-Entwicklerwerkzeuge den Haken bei „Speicher“ setzen. Jetzt taucht in der oberen Leiste der Punkt „Speicher“ auf.
  • Jetzt links „Cookies“ wählen, dann tauchen sie auf. Seite evtl. neu laden.

Jetzt kann man schön sehen, woher die Cookies und andere kommen. In der Spalte „Domain“ steht’s drin. Eigene Kekse, mit meiner eigenen Domain drin, kommen direkt aus meiner Küche, sind also ok…die brauche ich vermutlich alle, damit WordPress richtig läuft. Meistens unverzichtbar.

Cookies von anderen Domains sollten so wenige wie möglich auftauchen.

2.) Quellen in Chrome:

  • Seite öffnen, rechte Maustaste, unterster Punkt „Prüfen“
  • Klappt was raus. Oben 3. Punkt von links „Sources“.
  • Wie bei den Cookies…alles was links auftaucht und nicht „meinedomain.de“ ist sollte uns zum Handeln und Entfernen veranlassen.

3.) Tracker mit Ghostery (Plugin für Mozilla und Chrome):

  • Fast selbsterklärend. Aktivieren, und dann sieht man oben rechts entweder einen kleinen sympathischen Geist mit Nummer drin oder rechts unten eine violette Box oder Kreis mit Nummer drin. Draufklicken, dann sieht man Details.

Aller Wahrscheinlichkeit nach sind es bei Cookies, Sources und Trackern dieselben Kandidaten, die da auftauchen.

Viele davon sollte man rausschmeißen, wenn man mit den Folgen leben kann. Google-Schriftarten…kann ich darauf verzichten? Ja? Dann raus damit.

Was gäbe es noch?

  • fonts.googleapis.com: Google-Schriftarten. Die kann man ausbauen und lokal speichern…siehe hier
  • maps.googleapis.com: Google Maps. Sollten auch ausgebaut werden,und evtl. durch OpenStreetMaps ersetzt. Artikel folgt.
  • facebook.com oder ähnliches: Dito. Muß (sollte) raus. Mit großer Wahrscheinlichkeit ist es die Facebook-Sharebox oder -Likebox.
  • twitter, googleplus, etc…das hat sicher mit nicht konformen Sharebuttons zu tun. Durch Entfernung einer tpypischen Sharebutton-Leiste (Facebook, Twitter, Google+ und Xing) und ersetzen durch den gesetzestreuen Shariff kann man auf einen Schlag die meisten Fremdcookies loswerden.

So…jetzt aber…was sollte man nicht entfernen?

ad.irgendeinwerbenetzwerk.com, googleaddingsbums etc.: Wenn man das entfernt kriegt man keine Werbeeinnahmen mehr. Und daß Werbevermarkter auf ihr Geschäftsmodell (inkl.Tracking) verzichten ist nicht zu erwarten.

Also was tun?

Ich könnte mir vorstellen, daß es ein „berechtigtes Interesse“ im Sinne der DSGVO ist, nicht pleite zu gehen, wenn man von Werbeeinnahmen abhängig ist.

Ich habe keine Ahnung, ob das richtig oder falsch ist und kann deshalb auch keine Beratung bieten (schon gar keine Rechtsberatung).

Aber ich denke es ist das Beste, wenn man diese Tracker, Cookies etc. nicht entfernt und, in der Datenschutzerklärung darauf hinweist, erklärt was sie tun, und den Vermerk „berechtigtes Interesse“ dazuschreibt.

 

DSGVO#3 – Google-Fonts lokal speichern

Bei eingebetteten Google Fonts sollte das meiner Meinung nach in der Datenschutzerklärung erwähnt werden („Berechtigtes Interesse“), denn Google trackt ganz bestimmt IP-Adresse und Referrer (und wer weiß was nicht noch alles).

Man kann die Google Fonts aber auch lokal kopieren und damit das Tracking verhindern. Das geht so:

    1.  Nachsehen, um welche Fonts es sich handelt.Ich kann das ganz gut im Quelltext sehen, indem ich nach fonts.googleapis.com suche. Dann finde ich einen oder mehrere Links, die etwa so aussehen:
      http://fonts.googleapis.com/css?family=Architects+Daughter:400|Patua+One:400&subset=latin.
      Hier handelt es sich um die beiden Schriftart Architects Daughter und Patua One je mit einer „Dicke“ von 400 und dem Zeichensatz latin.

      Die müssen wir uns jetzt holen und lokal speichern. Dazu gibt es eine schöne Anleitung, es wird sogar ein Plugin erstellt, das wir dann bei uns hochladen können: https://www.news47ell.com/how-to/host-google-fonts-locally-wordpress/
    2. Jetzt müssen wir nur noch den früheren Aufruf der Fonts bei fonts.googleapis.com entfernen. Aber wo ist der versteckt?Hier stehen ein paar Möglichkeiten dazu:
      https://stackoverflow.com/questions/29134113/how-to-remove-or-dequeue-google-fonts-in-wordpress-twentyfifteen

      Bei Standard-Themes (Twentyfifteen etc.) scheint es auszureichen, den Font-Aufruf mit z.B.
      wp_dequeue_style ('twentyfifteen-fonts');
      auszubauen. (der 2. Link oben zu Stackoverflow, 1. Antwort)Wenn das nicht klappt: Es gibt ein Plugin, das genau das tun soll. Es heißt Remove Google Fonts ReferencesWenn das auch nicht klappt, würde ich den gesamten PHP-Code meines Themes (Child und Parent) nach „googleapis“ oder „fonts“ durchsuchen. Irgendwo ist da eine Funktion. Raus damit und // davorgesetzt.
    3. Nachsehen, ob der Aufruf zu fonts.googleapis.com im Quelltext verschwunden ist
    4. Wenn  nicht…ist vielleicht ein Caching-Plugin aktiv?
    5. Nachtrag zum Theme AVADA:
      Hier ist es etwas komplizierter. Die Fonts können wie oben beschrieben ausgebaut und lokal installiert werden, dann sind sie aber immer noch im Quelltext mit einer Google-Verlinkung sichtbar Was auch immer AVADA da tut, es ist (wie immer) kompliziert, umständlich und langsam. Meine Lösung ist, daß in den Avada-Schriftarten-Einstellungen die entsprechende Schriftart ausgewählt sein muß, die dann auch benutzt wird (und lokal gespeichert sein sollte).

DSGVO-Tips und Tricks

Hier erscheinen jetzt demnächst ein paar Dinge und ToDos und Fundstücke im Bezug auf die DSGVO, die für mich Sinn machen, und die ich so oder so ähnlich auch umgesetzt habe.

Das kann man keinesfalls als Rechtsberatung bezeichnen, denn ich weiß manchmal selbst nicht so genau, ob die Dinge, die ich umsetze, jetzt richtig oder falsch sind.

Im Bereich DSGVO und Datenschutz kann man derzeit eine große Verunsicherung und ein gefährliches Halbwissen feststellen, gepaart mit einer massiven Panik, je näher der 25.05.2018 rückt.

OK, ich fang dann gleich mal an.

  1. Google Fonts lokal speichern

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-Theme übersetzen

Eine leichtverständliche Anleitung zum Übersetzen eines Themes.

  1. Das Programm Poedit downloaden und installieren: http://www.poedit.net/download.php
  2. Im Ordner des zu übersetzenden Themes /wp-content/themes/meintheme einen Unterordner languages suchen und die Datei default.po mit Poedit öffnen. Jetzt sieht man alle englischen Texte, die im theme verwendet werden.
  3. Die Texte übersetzen und danach speichern. Jetzt wird eine Datei default.mo erstellt. Diese Datei entsprechend den Sprachcodes umbenennen  Für Deutsch wäre das dann de_DE.mo. Man kann die Codes hier finden (unter WP LOCALE).
  4. Die Datei de_DE.mo in den Ordner /languages unseres Themes hochladen., also (vermutlich) nach  /wp-content/themes/meintheme.
  5. In der wp-config.php nachsehen, ob der WPLANG-Parameter gesetzt ist: define (‚WPLANG‘, ‚de_DE‘);
  6. Jetzt sollte das Theme eure Sprache sprechen.

Wenn bei Punkt 2 die Datei default.po nicht da ist, sondern eine default.pot-Datei…dann wirds etwas komplizierter. ..das erkläre ich dann später 🙂

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!