7 Tips, wie man seinen Webmaster verliert

(Inspiriert von hier, übersetzt und erweitert)

  1. Geben Sie verwirrende, unklare und knappe Anweisungen und lassen Sie den Webmaster rätseln, was das zu bedeuten hat. Nachfragen lassen Sie aus Zeitmangel nicht zu. Wenn er alles richtig gemacht hat, sagen Sie gar nichts. Wenn er etwas falsch gemacht hat, machen Sie ihn zur Sau, schieben Sie ihm die gesamte Schuld in die Schuhe und drohen mit Ihrem Anwalt.
  2. Obwohl Sie keine Ahnung vom Internet haben, sollten Sie immer darauf bestehen, daß Ihr Webmaster die Dinge genauso umsetzt, wie Sie das wünschen, anstatt so, wie er das für Ihre Website für richtig hält.
  3. Handeln Sie zu Anfang stark um den Preis und deuten Folgeaufträge an. Feilschen Sie danach aber auch um jede Viertelstunde der Folgeaufträge.
  4. Verlangen Sie regelmäßig Extra-Arbeiten…mal eben schnell hier was machen…und dann noch hier…und seien Sie stinksauer, wenn Sie die Zeit dafür auf der Rechnung wiederfinden.
  5. Wenn der Webmaster fragt, was Sie auf Ihrer neuen WebSite gerne selbst ändern möchten, sagen Sie „alles!“. Wenn das stark modifizierte Content-Management-System fertig ist schicken Sie ihm aber trotzdem alle Änderungen als mehrseitiges DOC oder PDF zu und verlangen, daß er das für Sie ändert.
  6. Lassen Sie ihn viel Zeit mit der Beantwortung Ihrer Anfragen verbringen (z.B. für Geschwindigkeits-Optimierung, SEO, AdWords, das richtige Plugin unter 67 verschiedenen Möglichkeiten etc.), sagen Sie „Danke“, wenn er das Ergebnis ausführlich präsentiert, aber sonst auch nichts.
  7. Lassen Sie sich für jeden kleinen geplanten Vorgang eine genaue Zeitschätzung geben. Dann gehen Sie zu Ihrem Ex-Programmierer oder jemandem aus Ihrer Verwandschaft („der 14-jährige Sohn vom Schwager kann auch Internet“), fragen Ihn was er dafür nehmen würde, und danach präsentieren Sie diese Zahl Ihrem Webmaster.

 

…Fortsetzung folgt…

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 zu

      $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#5 – Cookie-Nervbox online erstellen

Wer ein modernes System wie WordPress hat, kann ja ganz einfach mit einem entsprechenden Plugin eine Cookiebox erstellen. Aber was ist mit Besitzern selbstprogrammierter Seiten, oder z.b. älteren CMS- oder Shopsystemen wie OScommerce?

Dafür gibt es jetzt eine einfache Lösung: https://cookieconsent.insites.com

Das Online-Tool generiert ein paar Zeilen Code, die dann einfach vor den schließenden </ head > eingeklebt werden, mit vielen vielen Möglichkeiten und Farben. Sehr empfehlenswert!

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…

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