MailPoet, WooCommerce, GDPR and Schrems II

Another earlier post translated because of public demand. And clearly one that wrote itself almost on it’s own. And again a bit of jurisdiction as covered before with the Google fonts blogpost. So what’s about MailPoet, WooCommerce and how do they connect to GDPR and Schrems II? And what is this after all?

Let’s start with some definitions: MailPoet, WooCommerce, GDPR and Schrems II

MailPoet

MailPoet is a newsletter service. Like MailChimp, CleverReach, … you name them. But slightly different in one point. MailPoet is a WordPress plugin which keeps the design, content creation and – with some limits, we’ll come to this in a minute – and the sending process on your own server that also hosts your WordPress.

MailPoet and GDPR

Thus having said the GDPR part is almost completely covered. Because of this on premise approach for creation, dispatch and analysis you’ll still need consent from the receipient, but not an order processing contract with a third-party. Advantage MailPoet!

The limits of MailPoet

Your own server is capable to cover emailings up to 50 reciepients and a managable amount of – let’s say – one sendout a month, even if it’s a big one. I would consider it a perfect solution for a small association or a school class (resp. their parents) to get regularly updated. Reason is: with any bigger volume the latent danger increases to get the server blacklisted as a spam hub. As a result all mail dispatch form this server is disrupted. Not only your newsletter, but all your email. And in case of a shared hosting any other mail trafic from other domains hosted on this server. In short: you don’t exactly endear yourself to your hoster.

The MailPoet solution for this

With an increasing number of receipients you need to look for another outgoing mail services. There are a couple of specialized servers for this. Their inherent job is to just send out bulk emails. As long as those are based in EU – not a big deal. Get yor order processing contract and of you go. And as MailPoet has european roots they do not only offer the a.m. plugin, but a premium plan for sending out emails for 1000+ receipients.

As a matter of fact: with an increasing number of receipients and frequency of sendings the prices of MailPoet become less attractive. There are solutions for this, too. MailPoet basically allows almost any other SMTP-server to be used. Most of the big, really powerful ones – i.e. sendgrid, sendinblue or sendblaster – are based in US. If you want to make sure your mail is dispachted GDPR compliant you might want to look out for Amazon SES (simple email service) which can be configured to use SMTP endpoint Frankfurt e.g. within EU jurisdiction.

The next obstacle: Schrems II

Schrems II is the common name for the latest judgement from ECJ covering the privacy shield agreement between US and EU. In short: I just doesn’t work, as long US intelligence is allowed to spy on any data. With that the nessessity of a „comparable privacy standard“ compared to EU is not fulfilled. Neither was it with it’s predecessor „safe harbour“ and how ever they might name the upcoming agreement they’re working on it will surely face the same fait.

As SCCs – standard contractual clauses – are considered still legit by the ECJ many US providers are opting for this as a substitute. Unfortunately this won’t work in reality either. Instead of relying on a intergovernmental act of review and approval (which turned out to be not fulfilled) now ones own responsibility is required. Be honest: can you judge Googles, Apples, FaceBooks, Microsoft, Amazons, … whoever claims about privacy? And can and will you review them? And if you do: what would be the outcome? Will NSA, CIA, FBI and others withdraw their spying because it’s you now reviewing? Just forget it!

Now what about WooCommerce and MailPoet?

First of all: there are some integrations – almost ever have been which tie WooCommerce and MailPoet together. Why not ask for the sign up to the newsletter with the next offers right in the checkout process? Since 7th December 2020 there’s a new plot twist:

MailPoet von WooCommerce erworben. Was macht das mit DSGVO und Schrems II?

MailPoet has been acquired by WooCommerce and – as far as they say – nothing will change. At the moment.

The elephant in the room about MailPoet, WooCommerce, GDPR and for sure Schrems II

WooCommerce and the company behind Automattic are US companies. Yes, indeed there are subsidiaries in Ireland (sic!) for both. The irish data protection authorities are not really well known for enthusiasm about persuing privacy violations.

To quote MailPoet and WooCommerce: „at the moment“ everything is (still) fine. As long as there’s not a change about the a.m. mailservers run by MailPoet. The minute „synergy“ is called and servers are migrated to US – which I suppose is most likely with WooCommerce and Automattic behind – Schrems II come into the picture. At that very point the MailPoet service for EU jurisdiction is dead.

Both the privacy policy of WooCommerce and Automattic aren’t currently neither satisfying in terms of Schrems II (just relying on a.m. SCC) nor do they cover the recent case of MailPoets servers. Which in my eyes is a fatal mistake as the merger wasn’t done in a day. There could have been more than just refering to the new (old) WooCommerce privacy policy.

Conclusion

At this very moment my judgement would be:

  • MailPoet is still usable and my prefered choice for a small amount of receipients and a low-frequency newletter
  • for the mid-size newsletter coverage which is handled by MailPoets servers one has to thoroughly observe the upcoming steps of MailPoet, WooCommerce and Automattic
  • both – WooCommerce and Automattic – have to address their insufficient privacy policies. Irish Subs, SCC and „do no evil“ statements to conceal or downplay US servers are just not enough.

Google Fonts, GDPR and SIL OFL (Open Font License)

By popular demand: this is the english version of my earlier blog post.

It all started mid November at the WP Meetup Würzburg. Topic for that evening was all about cookie banners. And related to this any other questions around privacy policy and GDPR. One attendee pointed to the issue of google fonts which have to be hosted locally to be GDPR compliant, but on the other hand the SIL OFL (Open Font License) would prohibit the conversion into WOFF and WOFF2. Which would mean the choice between either being GDPR- or license compliant. I got curious … but let me start from the beginning:

Google Fonts und GDPR (SIL OFL yet to come)

Google Fonts included via

    <link rel="stylesheet"
          href="https://fonts.googleapis.com/…">

or via

@import url('https://fonts.googleapis.com/css2?…');

or directly via

@font-face {
  src: url(https://fonts.gstatic.com/s/…) format('…');
}

would mean that the request is send to the Google servers. By this the website visitors IP address is exposed to Google. As we know IP address is a personal data. Submitting this data would only be possible if there would be consent from the visitor. Which would be very cumbersome to achieve in terms of techniques involved. And: any given consent can easily be withdraw later. If you really want to make sure that everything is applied correctly a cookie would be the best solution. Which needs to have consent as well. As we are talking of US servers, which per se are difficult to use after the Schrems II judgement from ECJ and the fall of the privacy shield.

As a rule of thumb: If Google fonts are used, make sure to host them locally to be GDPR compliant.

Hosting Google fonts GDPR compliant locally (still no SIL OFL)

A skilled web developer knows how to

  • download Google fonts
  • convert them (will come to this in a minute)
  • upload them to your own server
  • include them into your stylesheet or directly into your theme
  • and make sure that no plugin uses own routes to the Google server to include fonts on a sidetrack

Sounds too difficult for you? You’re not alone. This is definitely not a task for the average WordPress user.

It’s quite common knowledge that I’m not a big fan of page builders. But in that regard Elementor has to get some appreciation:

Google Fonts DSGVO konform lokal in Elementor einbinden
Elementor offers the possibility to include locally hosted fonts

Anyone else might want to to try the plugin OMGF – Host Google Fonts Locally. It identifies the used Google fonts in your WordPress installation, downloads and includes them and cuts of the connection to the Google font servers.

Thus far, thus (hopefully) known.

Google Font licenses (as GDPR is covered by now, let’s talk SIL OFL)

This is the new aspect for me. To be honest: I didn’t care too much about the license so far. Google fonts was and is one of the big open source projects in the Google universe. Which meant to me: get it, use it, make the fonts available locally! I wasn’t aware under which license the fonts are published and that there’s a different one with SIL Open Font License beside the commonly known ones like GPL, MIT, Apache, etc. Indeed it’s esay to spot – any Google font commes with a tab for the license:

Google Font Roboto unter der Apache Lizenz

Roboto in this very case uses the Apache License 2.0. But quite some of the Google hosted fonts (as per 24.11.2020) make use of the SIL Open Font License.

Google Font Montserrat unter der SIL Open Font License

All have in common that they are open source licenses, that allow the usage for your web project. The SIL OFL quotes in their FAQ:

Question: 2.1 Can I make webpages using these fonts?

Answer: Yes! Go ahead! Using CSS (Cascading Style Sheets) is recommended. Your three best options are:

  • referring directly in your stylesheet to open fonts which may be available on the user’s system
  • providing links to download the full package of the font – either from your own website or from elsewhere – so users can install it themselves
  • using @font-face to distribute the font directly to browsers. This is recommended and explicitly allowed by the licensing model because it is distribution. The font file itself is distributed with other components of the webpage. It is not embedded in the webpage but referenced through a web address which will cause the browser to retrieve and use the corresponding font to render the webpage (see 1.11 and 1.15 for details related to embedding fonts into documents). As you take advantage of the @font-face cross-platform standard, be aware that web fonts are often tuned for a web environment and not intended for installation and use outside a browser. The reasons in favour of using web fonts are to allow design of dynamic text elements instead of static graphics, to make it easier for content to be localized and translated, indexed and searched, and all this with cross-platform open standards without depending on restricted extensions or plugins. You should check the CSS cascade (the order in which fonts are being called or delivered to your users) when testing.

Taking care of GDPR it’s obivous that two out of three suggestions (a and c)don’t really work in that regard. And to ask website visitors to first download the font, install it on their computer to make the site look beautiful is not a very feasible idea.

But – encouraging downloads also means: downloading is permitted. Nothing so far, that prohibits the local hosting of fonts published under SIL Open Font License.

So everything is fine! Or?

Well, … not really. Downloading Google fonts will give you TTF or OTF – TrueType or OpenType fonts. Most modern browsers can handle these and will render them correctly. But as usual: The better is the enemy of good. Because of performace you might want to use the compressed WOFF/WOFF2 fonts and just for older or *ehmm* broken browsers you will use TTF/OTF as a fallback. If you want to to dive deeper in to font formats I recommend https://creativemarket.com/blog/the-missing-guide-to-font-formats.

Well, and exactly with WOFF the license hassle starts. Again a quote from the SIL OFL FAQ:

Question: 2.2 Can I make and use WOFF (Web Open Font Format) versions of OFL fonts?

Answer: Yes, but you need to be careful. A change in font format normally is considered modification, and Reserved Font Names (RFNs) cannot be used. Because of the design of the WOFF format, however, it is possible to create a WOFF version that is not considered modification, and so would not require a name change. You are allowed to create, use and distribute a WOFF version of an OFL font without changing the font name, but only if:

  • the original font data remains unchanged except for WOFF compression, and
  • WOFF-specific metadata is either omitted altogether or present and includes, unaltered, the contents of all equivalent metadata in the original font.

If the original font data or metadata is changed, or the WOFF-specific metadata is incomplete, the font must be considered a Modified Version, the OFL restrictions would apply and the name of the font must be changed: any RFNs cannot be used and copyright notices and licensing information must be included and cannot be deleted or modified. You must come up with a unique name – we recommend one corresponding to your domain or your particular web application. Be aware that only the original author(s) can use RFNs. This is to prevent collisions between a derivative tuned to your audience and the original upstream version and so to reduce confusion.

Please note that most WOFF conversion tools and online services do not meet the two requirements listed above, and so their output must be considered a Modified Version. So be very careful and check to be sure that the tool or service you’re using is compressing unchanged data and completely and accurately reflecting the original font metadata.

Here comes the nutmeg of the SIL Open Font Licence

Converting the font to another format is considered as a modification. Which would only be permitted if the name is changed both internally and externally. Latter one is simple: just rename the font file, include it in your style sheet with that very name and you’re done. But: that’s only half the truth. Within the font-file you’ll find meta-information which refer to the original name. By this the license violation would even be properly documented.

So – just the choice of either GDPR or license violation?

Yes and no. Here are some possible solutions and todos:

  • Only use Google Fonts, that are not published under the SIL Open Font License. You can find a complete list of their attribution at https://fonts.google.com/attribution (thanks „Zwischenwelt“ https://nairobi-notes.de/2020/11/google-fonts-dsgvo-und-sil-ofl-open-font-license/#comment-62)
  • deny yourself and your visitors performance and just use TTF/OTF fonts. Hmm, well … not really as this could mean conflicting goals if your customer asks for performance because of SEO
  • use tools for the conversion that do not only change the font format, but both namings internally and externally. The usual suspects of web services just don’t
  • Do a risk assessment – which one would be more expensive when fined and can it be mitigated by an insurance or by balance sheet provisions

Short research discovered an open source tool named FontForge which claimes to cover the converison in the right way. Anyone having experience with that? It’s available for Mac, Win and Linux. Any lead to other (better) tools in the comments will be appreciated

Or even better: is there a plugin that converts (correctly) on-the-fly TTF/OTF to WOFF/WOFF2? Anyone?

Another open question from the comments: What about the herokuapp? https://nairobi-notes.de/2020/11/google-fonts-dsgvo-und-sil-ofl-open-font-license/#comment-56 Which offers the font download directly in all a.m. formats. Is it ok to use them? Is it enough (even possible) to shift the responsibility for a license violation to the tool authors?

MailPoet, WooCommerce, DSGVO und Schrems II

Der Artikel hier schreibt sich fast von alleine … Ein weiterer nach dem über die Google Fonts, die etwas Juristerei in sich tragen. Aber der Reihe nach. Was hat MailPoet mit WooCommerce und diese wiederum mit DSGVO und Schrems II zu tun. Und was ist das überhaupt?

Zuerst wer ist ist was: MailPoet, WooCommerce, DSGVO und Schrems II

MailPoet

MailPoet ist einer von vielen Newsletter Anbietern. So wie MailChimp, CleverReach, … und doch an einer Stelle ein kleines bisschen und entscheidend anders: MailPoet ist WordPress Plugin, welches die Newsletter Erstellung direkt in WordPress erlaubt und – mit Einschränkungen, dazu gleich mehr – auch direkt den Versand über den eigenen Server.

MailPoet und die DSGVO

Damit ist dann auch gleich der DSGVO Teil schon fast erschöpfend behandelt: Dadurch, das der Newsletterservice – Erstellung, Versand, Auswertung – komplett auf dem eigenen, selbst gehosteten Server unter WordPress läuft braucht es zwar nach wie vor das Einverständnis des Empfängers (Double-Opt In, widerrufbarer Consent, …) aber eben keinen darüberhinaus gehenden Auftragsverarbeitungsvertrag mit einer Dritten Partei. 1:0 für MailPoet an der Stelle!

Die Einschränkungen von MailPoet

Der eigene Server als Versandinstanz funktioniert eigentlich nur bis ca. 50 Empfänger und einem überschaubaren Newsletter Volumen von, sagen wir, 1x monatlich. Damit ist’s eine sehr perfekte Lösung für einen kleinen Verein, eine Schulklasse (oder deren Eltern) um immer wieder mal Neuigkeiten zu verbreiten. Der Hintergrund: steigt das Mailvolumen besteht die latente Gefahr das der aussendende Mailserver als Spammer in Verdacht gerät und entsprechend auf Filterlisten (auch Blacklists geheissen) landet. In der Folge ist jeglicher Mailversand von diesem Server gestört, nicht nur der Newsletter und – bei einem Shared Hosting – ggf. auch andere Domains, die über diesen Mailserver ausliefern. Kurz: man macht sich auch bei seinem Hoster nicht gerade beliebt.

Die Lösung aus dem Hause MailPoet

Spätestens wenn die einstmals überschaubare Empfängerliste anwächst, muss man sich also Gedanken um den Versand über andere Server machen. Es gibt dazu spezielle Server, deren ureigenste Aufgabe es ist sog. Bulk- oder Massenemails zu versenden. So lange die im EU Raum beheimatet sind – kein großes Problem. Auftragsverarbeitungsvertrag abgeschlossen, los geht’s. Und weil MailPoet vom Ursprung her ein zutiefst europäisches Produkt ist, bietet man bei MailPoet einen entsprechenden Server im Rahmen eines Premium-Plans für mehr als 1000 Empfänger gleich an.

Nur nebenbei: ab einer weiter steigenden Zahl von Empfängern und mit steigender Aussendefrequenz wird das Preismodell von MailPoet zunehmend unattraktiv. Aber auch dafür gibt es Lösungen, weil MailPoet es grundsätzlich erlaubt fast beliebige andere SMTP-Server einzubinden. Die großen, wirklich leistungsfähigen sitzen – man ahnt es – in den USA. Als Beispiel sei sendgrid, sendinblue oder sendblaster genannt. Die datenschutzfreundlichste Methode dürfte da noch Amazon SES (simple email service) sein, der sich über den SMPT-Endpoint auf Frankfurt und damit ins EU Gebiet konfigurieren lässt.

Die nächste Hürde: Schrems II

Schrems II ist die gängige Bezeichnung für das jüngst ergangene EUGH Urteil zum Privacy Shield Abkommen zwischen den USA und Europa. In Kurzform: das Ding funktioniert so nicht, weil die US Geheimdienste immer noch in den Daten rumschnüffeln dürfen und damit der „vergleichbare Datenschutzstandard“ nicht erfüllt ist. Das galt schon für das vorangegangene „Safe Harbour“ Abkommen und wie immer der Nachfolger, an dem gerade fleissig gebastelt wird heissen mag – im wird das gleiche Schicksal zu Teil werden.

Was der EUGH explizit zugelassen hat und wo sehr viele Dienste Anbieter in den USA sich nun drauf zurück ziehen, sind die sog. Standardvertragsklauseln. Die in der Praxis aber leider nun auch nicht wirklich funktionieren, weil nun statt einer zwischenstaatlichen Datenschutzprüfung und -zusage (die eben negativ ausfiel) nun die eigene Zuständigkeit gefragt ist. Und ehrlich: wer kann das, was Google, Apple, FaceBook, Microsoft, Amazon, … behaupten schon nachprüfen – sprich: wer kann das und macht das dann auch – und zu welchem Ergebnis mag man dann kommen? Das privat drauf geschaut NSA, CIA, FBI und weiss nicht wer doch nicht abschnorchelt (abschnorcheln darf)? Eben nicht.

Wo kommt nun WooCommerce bei MailPoet ins Spiel?

Zum einen im Rahmen von Integrationen, die es schon „immer“ gab. Wenn jemand bei mir im WooCommerce Shop was bestellt, würde ich eigentlich schon gerne sicherstellen, diesen Kunden auch gleich mit Neuigkeiten versorgen zu können. Entsprechend gibt es Plugins, die den „ich will den (MailPoet) Newsletter“ Haken gleich in den Checkout-Prozess von WooCommerce integrieren. Seit 7.12.2020 gibt es einen neuen Twist:

MailPoet von WooCommerce erworben. Was macht das mit DSGVO und Schrems II?

MailPoet wurde von WooCommerce übernommen und allen Beteuerungen zu Folge ändert sich (zunächst) erstmal nichts.

Das große Aber zu MailPoet, WooCommerce, DSGVO und ganz sicher Schrems II

WooCommerce und das dahinterstehende Automattic sind zu allererst US Unternehmen. Ja, für den Geltungsbereich von Europa gibt es auch irische Niederlassungen. Das entbehrt insoweit nicht einer gewissen Komik, das die Ansiedlung dort gewählt wurde, wo die nachweislich schlafmützigste und wurschtigste Datenschutzaufsichtsbehörde ihren Dienst versieht. Dagegen waren italienische Zöllner im 70er Jahre Bummelstreik regelrecht agil.

Aktuell ist alles im grünen Bereich. Eben genau so lange, wie „zunächst ändert sich nichts“ von MailPoet auch weiterhin gilt. Solange der Versandserver für diesen mittelgroßen Bedarf von größer 1000 bis „kriege-ich-woanders-billiger“ weiterhin in Europa bleibt ist alles gut. In dem Moment, wo aber US Ressourcen von WooCommerce oder Automattic ins Spiel kommen – was im Sinne von „Synergie“ zu befürchten steht – dann schlägt Schrems II mit voller Härte zu. Ab dem Moment wäre MailPoet faktisch oberhalb von dem kleinen Bedarf von 50 Empfängern in Europa nicht mehr (regelgerecht) zu gebrauchen.

Die Privacy Policy sowohl von WooCommerce als auch Automattic sind aktuell weder im Sinne von Schrems II befriedigend (s.o. unter Standardvertragsklauseln) noch decken sie den Fall des SMTP-Versands durch MailPoet im Moment hinreichend ab. Fatal, denn ich denke mal nicht, dass die Idee zum Kauf von MailPoet durch WooCommerce einen Tag vor dem Announcement erfolgte. Da hätte man etwas besser drauf vorbereitet sein können als nur auf die neue (alte) Privacy Policy von WooCommerce zu verweisen.

Fazit

In der aktuellen Situation bleibt für mich zurück:

  • MailPoet ist im kleinen Rahmen nach wie vor meine erste Wahl, wenn es um die Aussendung von Newlettern geht
  • Im mittleren Mengenbereich muss man sehr genau beobachten, was mit den Servern von MailPoet passiert
  • WooCommerce und Automattic müssen die unklaren Verhältnisse in Sachen Datenschutz angehen. Irische Adresse, Standardvertragsklauseln und eine „wir sind alle lieb“ Privacy Policy um die US Server zu verschleiern oder zu verharmlosen sind zu wenig.

Google Fonts, DSGVO und SIL OFL (Open Font License)

Der Aufhänger zu diesem Post entstand jüngst beim WP Meetup Würzburg als es um’s Thema Cookie Banner ging. Und in der Folge natürlich auch alle anderen Datenschutzfragen. Unter anderem kam von einem Teilnehmer der Hinweis, das lokal gehostete Google Fonts zwar die einzige Form einer DSGVO konformen Bereitstellung sei. Die in den meisten Fällen anwendbare SIL OFL (Open Font License) aber der Umwandlung in WOFF und WOFF2 im Wege stände. Ergo: es bliebe die Auswahl zwischen DSGVO- und Lizenzverstoß. Meine Neugier war geweckt. Aber mal kurz der Reihe nach:

Google Fonts und DSGVO (SIL OFL kriegen wir später)

Die Einbindung der Google Fonts per

    <link rel="stylesheet"
          href="https://fonts.googleapis.com/…">

oder per

@import url('https://fonts.googleapis.com/css2?…');

oder auch direkt per

@font-face {
  src: url(https://fonts.gstatic.com/s/…) format('…');
}

bedeutet immer den Zugriff auf die Server von Google. Durch diese externe Einbindung bekommt Google die IP Adresse des Besuchers, der die Seite aufruft zurück geliefert. Die IP Adresse eines Besuchers ist ein personenbezogenes Datum. Damit wäre das nach DSGVO aber nur zulässig, wenn es die Zustimmung des Besuchers gäbe. Was einerseits technisch nur recht aufwändig umzusetzen ist und zum anderen immer unter dem Vorbehalt des Widerrufs stände. Und um das alles passend pro Besucher zu merken, wäre wiederum ein Cookie notwendig, dem selbst auch widersprochen werden könnte. Das darüberhinaus mit Google auch noch US Server betroffen sind, die nach dem Schrems II Urteil und dem Fall des Privacy Shields nicht mehr ohne weiteres verwendbar sind, nur noch als Sahnehäubchen oben drauf.

Kurz und knapp als Faustregel: Wenn Google Fonts genutzt werden sollen, dann geht das DSGVO konform eigentlich nur, wenn dieses lokal auf dem eigenen Server gehostet werden.

Google Fonts DSGVO konform lokal hosten (immer noch kein SIL OFL)

Wer sich auskennt, weiss wie er die Fonts bei Google

  • runterlädt
  • umwandelt (dazu gleich mehr)
  • auf dem eigenen Server ablegt
  • ins Stylesheet oder gleich ins Theme einbindet
  • und darüberhinaus sicherstellt, das kein Plugin das umfährt und wieder direkt bei Google anklopft um Schriften geliefert zu bekommen

Schon an der Aufzählung der verschiedenen Schritte wird die Komplexität des Vorgangs deutlich. Nichts für den normalsterblichen WordPress User.

Auch wenn ich PageBuilder gerne bashe, Elementor darf man hierfür durchaus mal loben:

Google Fonts DSGVO konform lokal in Elementor einbinden
Elementor bietet die Möglichkeit Schriften lokal einzubinden

Für alle anderen sei das Plugin OMGF – Host Google Fonts Locally empfohlen. Damit wird zum einen ermittelt, welche Google Fonts auf der betreffenden WordPress Installation verwendet werden, diese werden dann heruntergeladen, eingebunden und die Verbindung zum Google Server gekapt.

Soweit, so (hoffentlich) bekannt.

Google Font Lizenzen (DSGVO geklärt, jetzt kommt SIL OFL dran)

Hier kommt der für mich neue Aspekt. Ehrlich gesagt galt für mich die oben postulierte Faustregel einigermassen unhinterfragt in Sachen Lizenz: Google Fonts ist eines der großen OpenSource Projekte von Google. Ergo kann (und darf und sollte) man die Schriften runterladen dürfen. Unter welcher exakten Lizenz die stehen und das es mit der SIL Open Font License auch gleich noch etwas ganz anderes als die üblichen Verdächtigen GPL, Apache, etc. gibt war mir nicht wirklich bewußt. Dabei ist’s wirklich einfach – bei jeder Schrift auf dem Google Server ist auch der Reiter „License“ gleich mit dabei:

Google Font Roboto unter der Apache Lizenz

Roboto steht in diesem Fall unter der bekannten Apache License 2.0. Aber es geht eben auch anders und nicht wenige Schriften der 1020 (Stand 24.11.2020) Schriften im Google Font Repo sollen mit der SIL Open Font License ausgestattet sein.

Google Font Montserrat unter der SIL Open Font License

Grundsätzlich sind beides OpenSource Lizenzen, die die Verwendung auch auf Webseiten erlauben. Die SIL OFL um die es nachfolgend im speziellen gehen soll sagt in der FAQ dazu:

Question: 2.1 Can I make webpages using these fonts?

Answer: Yes! Go ahead! Using CSS (Cascading Style Sheets) is recommended. Your three best options are:

  • referring directly in your stylesheet to open fonts which may be available on the user’s system
  • providing links to download the full package of the font – either from your own website or from elsewhere – so users can install it themselves
  • using @font-face to distribute the font directly to browsers. This is recommended and explicitly allowed by the licensing model because it is distribution. The font file itself is distributed with other components of the webpage. It is not embedded in the webpage but referenced through a web address which will cause the browser to retrieve and use the corresponding font to render the webpage (see 1.11 and 1.15 for details related to embedding fonts into documents). As you take advantage of the @font-face cross-platform standard, be aware that web fonts are often tuned for a web environment and not intended for installation and use outside a browser. The reasons in favour of using web fonts are to allow design of dynamic text elements instead of static graphics, to make it easier for content to be localized and translated, indexed and searched, and all this with cross-platform open standards without depending on restricted extensions or plugins. You should check the CSS cascade (the order in which fonts are being called or delivered to your users) when testing.

Also: entweder direkt im Stylesheet auf den Font verweisen, den Font dem Besucher per Link zum Download anbieten oder per @font-face einbinden. Zwei der drei Optionen (a und c) sind – s.o. – wegen Datenschutz nicht wirklich eine Empfehlung. Und Webseiten Besucher erstmal zu bitten (nötigen) die Schrift lokal zu installieren, damit die Seite hübsch aussieht ist wenig praktikabel.

Immerhin: die Option zwei beinhaltet damit auch ganz klar „runterladen ist erlaubt“. Nichts spricht bis hier hin gegen das lokale hosten der Schriften unter der SIL Open Font License.

Dann ist doch alles gut! Oder?

Na, ja … fast. Die Google Schriften werden beim Runterladen als TTF oder OTF – TrueType oder OpenType Schriften bereitgestellt. Die meisten modernen Browser stellen TTF/OTF-Schriften auch problemlos dar. Aber wie so oft: das Bessere ist des Guten Feind. Aus Performance-Gründen mag man heute eigentlich lieber das komprimierte Format WOFF/WOFF2 für Schriften verwenden und andere bestenfalls als Fallback für ältere oder *hüstel* kaputte Browser bereitstellen. Wer tiefer in die verschiedenen Schriftformate eintauchen mag: https://creativemarket.com/blog/the-missing-guide-to-font-formats.

Und mit WOFF fangen die lizenzrechtlichen Spitzfindigkeiten an. Nochmal aus der SIL OFL FAQ:

Question: 2.2 Can I make and use WOFF (Web Open Font Format) versions of OFL fonts?

Answer: Yes, but you need to be careful. A change in font format normally is considered modification, and Reserved Font Names (RFNs) cannot be used. Because of the design of the WOFF format, however, it is possible to create a WOFF version that is not considered modification, and so would not require a name change. You are allowed to create, use and distribute a WOFF version of an OFL font without changing the font name, but only if:

  • the original font data remains unchanged except for WOFF compression, and
  • WOFF-specific metadata is either omitted altogether or present and includes, unaltered, the contents of all equivalent metadata in the original font.

If the original font data or metadata is changed, or the WOFF-specific metadata is incomplete, the font must be considered a Modified Version, the OFL restrictions would apply and the name of the font must be changed: any RFNs cannot be used and copyright notices and licensing information must be included and cannot be deleted or modified. You must come up with a unique name – we recommend one corresponding to your domain or your particular web application. Be aware that only the original author(s) can use RFNs. This is to prevent collisions between a derivative tuned to your audience and the original upstream version and so to reduce confusion.

Please note that most WOFF conversion tools and online services do not meet the two requirements listed above, and so their output must be considered a Modified Version. So be very careful and check to be sure that the tool or service you’re using is compressing unchanged data and completely and accurately reflecting the original font metadata.

Hier kommt die Fußangel der SIL Open Font Licence

Auf gut deutsch: die Umwandlung der Schrift in ein anderes Format wird als Modifikation gewertet. Diese wiederum ist nur zulässig wenn nicht der gleiche Name intern wie extern verwendet wird. Extern ist simpel: Datei umbenennen, entsprechend im Stylesheet einbinden, fertig. Aber das ist eben nur die halbe Wahrheit, weil in der Schrift selbst eben noch Meta-Informationen verbleiben, die den ursprünglichen Namen referenzieren. Und damit wäre der Lizenzverstoß auch noch sauber dokumentiert.

Also die Auswahl zwischen DSGVO- und Lizenzverstoß?

Ja, aber nicht nur. Hier ein paar mögliche Lösungen und anstehende Aufgaben

  • Die ausschliessliche Verwendung von Google Fonts, die nicht unter die SIL Open Font License fallen.
  • Verzicht auf Perfomance durch die Verwendung von TTF/OTF Schriften. Was ggf. einen Zielkonflikt bedeutet wenn es dem Kunden um Performance auch im Sinne von SEO gehen sollte.
  • Passende Font-Umwandlungstools, die nicht nur das Format, den Dateinamen, sondern auch die internen Metas anfassen und entsprechend bearbeiten. Die üblichen Webdienste, die es zur Font-Format Umwandlung gibt können das soweit ich recherchiert habe nicht.
  • Risikoabwägung DSGVO Verstoß vs. Lizenzverstoß – was wird im Zweifel teurer und kann es über entsprechende Versicherungen oder Rückstellungen mitigiert werden.

Der sauberste Weg wäre sicher die Einhaltung der Lizenz unter Erfüllung der dort gemachten Anforderungen. Kurze Recherche lieferte FontForge als mögliches OpenSource Tool, das diese Umwandlung beherrschen soll. Frage in die Runde: arbeitet wer damit und kann entsprechende Rückmeldungen dazu bereitstellen? Das Programm wird als Mac, Windows und Linux Version bereitgestellt. Oder gibt’s andere (bessere) Tools dafür – ab in die Kommentare damit!

Oder gleich ein Plugin, dass sich on-the-fly um die (korrekte) Umwandlung von TTF/OTF zu WOFF/WOFF2 kümmert? Anyone?

Was ich auch gerne sehen würde: weiss jemand einen schlauen Weg um überhaupt mal eine Liste der Google Fonts ausgeworfen zu bekommen, die die entsprechenden Lizenzen der jeweiligen Schrift wieder gibt? Im Sinne von: welche kann man bedenkenlos einsetzen, wo ist mehr Aufwand erforderlich.

To replace or not to replace …

After dismantling the Monkey we can now dive deeper into what is needed, which parts are missing, which are faulty, which ones need to be replaced. Or as Shakespear would say: „To replace or not to replace, whether ‚tis nobler in the mind to suffer and keep the original or to take arms against a sea of troubles and invest a lot of money into new parts …“ I might have mixed up some things though.

Parts to always replace … no or given

What ever parts have a normal wear and tear over time will always be replace when refurbishing what ever bike or car. Having everything already easily accessible there’s no hesitation to do an extented service rather than starter over again after a few weeks or months in usage. The parts to include:

  • Engine/gearbox oil and filters
  • spark plug(s)
    as I’m thinking of replacing the engine as such, this will automatically include these items. Only oil as such has to be added, which is not even a full liter and shouldn’t cost more than 10 €
  • air filter
    as always: the question of staying with the original filter housing and replace the filter or going for an open aftermarket part – I guess it will depend on the choice for the engine. Anyway, cost’s will be about 10 € for either of which.
  • break pads, discs – or as for the Monkey – drums
    again the question: just replace the wear and tear or upgrade to disc brakes – at least for the front. Just the pads will be about 30 € for both front and rear in total. May be I should even add the cable for the front brake as it is less than 20 €. Better safe than sorry.
  • fork oil where applicable
    the Monkey only has a simple spring fork, so no need here. But … there are even upside down forks available on the aftermarket … hmm … Let’s see if budget is left over. A complete fork with disc brakes goes for about 170 €
  • chain and sprockets
  • ball bearings for swing arm, steering and wheels
  • tires and tubes

Let’s have a closer look at the last 3 items:

Chain and sprockets

As far as I could research the original ratio is 12 / 37 with a 420 chain of 78 links. Any tooth more in front (or less on the rear) will result in a higher speed, any tooth less in front (or more on the rear) will give a better acceleration.

To my surprise I found 14 on the front and the given 37 on the rear. The 107cc engine was clearly put in to place for speed. As I consider the full automatic gearbox to bit too sluggish I would have opted for the 12 and may be even 40 or 41 in the back. If you do the maths: 1 tooth in front has about the same effect on the ratio as 3 on the rear sprocket (37 divided by 12 = 3,0833). And as the bend for the chain get’s to narrow with any smaller front sprocket 12 should be the least to go for. So any measure to improve acceleration should be done on the rear sprocket from that point on. To replace or not to replace is no question if you look at the picture:

replace or not to replace … no question for the rear sprocket
heavily worn out teeth on the rear sprocket

And once you replace one part of the drive chain, better replace them all. About 35 to 50 €, mainly depending on the brand of the chain, have to be added to the budget.

Ball bearings

Bearings for the wheels and the swing arms are standard parts, therefore very easy to source and quite cheap. Not to replace them would be really a missed opportunity as the most cumbersome part is the work on it. Lot’s of stuff has to be dismantled and sometimes axles – esp. the swing arm one, Honda seems to be specialized on this – can be seized up. Or the bushes a such refuse to get out of the frame. Have every thing in handy pieces knocked down already is half the work done.

Both the upper and lower bearing shell of the steering still look good. They just have to be properly protected for the paint job on the frame. The ball bearing as such will come new.

All bearings for steering, swing arm and wheels will sum up to approx. 40 €.

Tires and tubes

Same as for the sprockets: there’s no doubt about the replacement of the tires. I’m not too sure about the DOT number as it is only a two-digit one (normally it should be at least 3 or 4 digits for the production week and year). The best I could think of would be week 2 of 1999 (because of only one digit for production years pre 2000). But what ever – the brittle look of the tire sidewall says loud enough: „Just dump it!“

The replacement will be the original pair of Bridgestone TW2 in 3.50-8″, which come for about 40 – 50 €/pc. Also the tube is a bit special. Not only in size, but to reach the valve properly it has to be in 90°. Just another 10 €/pc.

Things to replace or not to replace in total

Just the spare parts to replace wear and tear sum up to about 250 €, which is a quarter of my estimated budget. All prices stated above are based on sources in Germany, mainly monkey-racing.com and monkeypower.de. If anyone has sources to recommend in Nairobi I’ld be happy to hear about them in the comments below.

Undressing the Monkey

After the very first assessment I undressing of the monkey has started. Let’s take of the fur to see how the bones are.

Undressing the monkey on my new workspace
Undressing the monkey on my new workspace

One of the things I already noted is the usage of whatever screws, bolts, nuts and whatever other fixtures no matter of length, head-size. Means, I have to get some more tools to access all of it.

The tools I used for undressing the monkey so far

Til now I was fine with my toolset I already used back in Germany on my Honda XLV 600 Transalp. The provided stuff by Hondy is mostly of very low quality so I pimped it a bit. And as it was much more than the original Honda tools I also decided to carry them in a bumbag.

Sadly I lost the pair of pliers (No. 1 on the picture above) at the Munich airport as they didn’t allow me to have it in the cabin luggage. Anyway – that’s the easiest to replace. The spanners cover the mostly used 8 – 10 – 12 – 13 -14 and 17 size (No. 2). Plus the 24 (No. 9) for the Transalp rear axle, which I suppose isn’t of much help with the Monkey. No. 3 to 7 feature a very clever system of a ratched (6) which can be combined with the sockets (3), with the nuckle (4) and the extension (5) which also can be used as a screwdriver using the bits (7). Very space and weight saving. The spark plug puller (8) completes the set of tools.

The heart of the Monkey

This round of diving deeper into the assessment shed some light on the engine.

The heart of the Monkey - a 107 cc full automatic engine
The heart of the undressed monkey: a 107 cc engine

Surely. A bold 107 cc engine – remember the original one is 50 cc only – but with an automatic gearbox and no kick-starter. That’s too much of a lazy life. Automatic gear boxes are fine for kids starting their biking career. Or on scooters. Or with cars. But on a motorbike, even a small one like this … no way!

But at least this carving gave enough evidence to figure out which engine might have been used. And indeed this one looks quite similar:

A similar one I found on the internet
A similiar engine … cost’s about 250 € (about the money I spend on the complete bike)

Picture taken from: Happy Motorparts online store. The most interesting part of it is in their description:

… für ATV / Kinderquad / fahrende Bierkiste …

the last one, which translates into „beer crate mobile“, caught my attention.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://www.youtube.com/watch?v=FsuQfJtb0Vs

But as I haven’t seen such plastic beer crates in Kenya so far, I wonder which might be a proper kenyan equivalent to make use of this engine. Because once taken apart from the bike it will surely not make it’s way back into it. Maybe a wheelbarrow :-D? That would be real monkey business.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://www.youtube.com/watch?v=wkq8CEqUvNA

But let’s first figure out which engine will find it’s way into the Honda Monkey. I’m still undecided between the original 50 cc, semi-automatic with kicker or going for a bit of more convienence having both kicker and electric starter? Or all the way up to this 190cc, 5 speed manual beast?

Daytona Anima 190 cc engine
Daytona Anima 190 cc: aircooled 4-Stroke SOHC 4 valve single cylinder 187.2cc, kick (primary) V2 decomp system and electric starter, wet sump, multi-plate 6-disc wet clutch, 5-speed manual transmission

I’m sure just the price tag of 1.300 € (about 165.000 KES!) will prohibit this madness of owning a pocket rocket, though I’m very tempted.

Again: any ideas which way to go are appreciated. Just hit the comments below.

First assessment

This step of having a first assessment should normally be taken before buying a car or a motorbike. But we’re talking of monkey business, right? So: as I wasn’t even in Nairobi when my girlfriend bought the bike on my behalf, it has to happen now. After some general history about the Monkey and me, this time we’ll have a first assessment of our new aquisition.

Vehicle Identification

Normally you should find various stickers ans bagdes on the frame of a bike or in the enginebay of a car with a VIN. A vehicle identification number. This Honda Monkey didn’t have any, but just a stamped in number in the frame.

First assessment VIN: Frame No Z50J - 1173131
Frame No Z50J – 1173131

Given the fact that it has a rear suspension we can conclude that it is a model after 1974. Any model before 1974 are the hardtails. By the decals on the tank one can conclude it’s a 1976 model. Here’s an overview of all models. But any literature I could access speaks of yellow as the one and only color of 1976. Which turned out is true for US. On the European and Japanese market two other colors where sold. White and – the one we have – G20 papaw green. Which also seems to be quite rare. Did we find a true gem?

First assessment of the engine

Now for the first time it get’s really tricky on this bike:

If you take a closer look there a two important parts missing: the gear lever on the left and the kickstarter on the right. Clearly this is not the original engine. Anyway – whoever did the swap did a fairly good job. killswitch and start button work, a complete wiring harness for this engine was installed and even a bigger battery.

As much as it works it doesn’t look good and it’s far from original. Worst to see at the side cover which might not be even from a motorbike. It also might explain, why the brake pedal gets in touch with the engine cover

brake pedal hit's the engine cover when released
brake pedal hit’s the engine cover when released

First assessment of the paper work

This was fast and easy: there isn’t just any. Normally you would check the logbook or any comparable documents like a CoC for newly imported vehicles if you get what you’re promised. This bike doesn’t have a registration which already brings me to my first question. Does it need to have one? The seller claimed it doesn’t … but hey, it’s the one who will care the least once sold. Which regulations from NTSA apply? And if it needs a registration how to get one for an almost 50 year old bike? Maybe someone can shed some light on those legal issues in the comments below.

First assessment of the condition

To be honest: though it runs I would rate it „poor, but not hopeless“. Lot’s of parts like the fenders, the headlamp and indicators are missing. Quite unusual BTW the indicators. The front fork has the mountpoints though indicators were uncommon on this model.

First assessment: The front fork has mountpoints for indicators, though those were not common on this model year
The front fork has mountpoints for indicators, though those were not common on this model year

Other parts are poor like the exhaust or the badly repaired seat. Brakes, chain and tires need to be serviced and most certainly replaced. If it is a gem, it’s at least a very unpolished one.

And the polishing that has to be done raises a very cruial question:

Which type of restauration to choose?

  1. The sheer minimum would be to service the bike, replace missing parts and keep all the patina it acquired over the last decades. Keeping it in an „as-is“ condition, just with proper maintenance is one of the latest trends when it comes to car and bike restorations. It had a life, it was used, it shall look used. As much as it would save money my feeling is that it deserves more. Maybe any vehicle deserves more than this.
  2. The next level would be to come to an „as new“ condition. Let it look like a shiny new bike, right out of the 1976 show room. Everything that is faulty or broken has to be refurbished or replaced with original new parts to get it back to it’s old glory.
  3. A „better as new“ condition. Basically the same as variation before but with some enhancements, esp. when it comes to new manufacturing techniques or materials. E.g. replacing some heavy weight cast iron parts with lighter aluminium. But overall it will be the same bike at the end.
  4. Even one step further would be a „contemporary rebuild“. Let’s say: drum brakes will be replaced by disc braces. Or old light bulbs will be substituted by LED lights. This would be the bike Honda would build today using the same basis. Borders are quite blured between 3) and 4) and sometimes even with the next level. Which would be
  5. A „custom restauration“. Just take the bike as a basis to create something completely new. I’ve seen Superbike handlebars on Honda Monkeys with some addtional motor tuning all the way from big bore kits up to 200 cc to even superchargers. Or some relaxed Bobber? You’ll find so many inspiration on the internet and YouTube especially.

Any recommendations?

So guys, what are your ideas when it comes to rebuild this bike? Preserving, restoring, enhancing, tuning? What would you do having this mini trail in your garage? Give me some comments below. And again: if anyone has some information how to get this 1976 Honda Monkey fully legal onto kenyan roads I’ld be more than happy to hear about this.

Honda Monkey Business

Alright. My apologies for being quiet lately. And as you might notice – for the change in focus that will happen with this blog starting with this very post. And for covering the upcoming topics in english henceforth. We start talking about Monkeys. Honda Monkeys to be precise. And the buisness of refurbishing them … aehm at least one. Mine. I’m sure there will be some monkey business along the way.

How the Honda Monkey business all started

Honda Monkey Z50A K2 from 1970/71 Example picture, not my particular bike of these days
Not the particular bike I owned, but the same model, same color.
And mine wasn’t in this perfect condition, still in a very good shape.

My very first motobike was a Honda Monkey Z50A K2 from 1970/71. I was fifthteen and eager to hit the road. At that time in Germany the only motorisied vehicle you could drive with 15 (besides tractors) where mofas. Pedals like a bike, engine like a motorbike and it could be ridden without any driving licence. We are talking of the 1980s – things changed meanwhile, just in case you wonder). When an auctioning in our village was publicly announced and two mofas were amongst the listed items, I knew I had to get one of those! Auctions are always a good chance for a bargain and this one was even round the corner.

Turned out the mofas were two of the a.m. hardtail Honda Monkeys. One in red without any keys and papers and one in blue. At least with keys, still no papers. Unexperienced as I was I would go for the one with at least one item of hassle less. I won the bid for it for the pocket money friendly amount of 150 or 160 DM (Deutsche Mark). I can’t even remember the exact figure – but it was extremely cheap. Which would translate into about the same amount in Euro in todays money (or approx. 20.000 KES for my Kenyan audience).

The monkey business of miscalculation

What I had to learn was: those weren’t mofas at all, but mokicks (because of the kick starter). Meant I had to get me a driving licence at the age of 16. Which was the minimum age to be allowed driving such. First Honda Monkey business. Good news though: it would allow me to travel at 40 km/h instead of just 25 km/h which was the max. for mofas. I used the year in between to get the paperwork done (a story in itself). And to practice (illegally) my riding skills in the woods behind my parents house.

Of course I needed some upgrades for the bike. My bicycle of that time which I used for my school commute already had all bells and whistles. My motorbike shouldn’t stand back. The two things I needed desperately included flashers and a luggage rack. As I said: I had to carry a school back and only primary school kids had backbacks. And indicating with handsignals was up to bicycle riders, not to motor people.

First steps into a biker career

Still I had no real clue what I bought. I learned all the basics about braking, shifting, handle the clutch in the driving school. I tried to apply my new knowledge to my Monkey, but it refused. A closer look discovered my mistake. The „clutch“ lever wasn’t such, but another way to engage the rear brake besides the normal foot pedal on the right. So where was the clutch? With no internet for research I could figure out that the Monkey was semi-automatic. Other than that the 3 gears where shifted as usual. First down, two and three upwards and a centrifugal clutch would do the magic of seamless shifting. Which I was happy to have – I wasn’t to precise with clutch on the driving school bike.

Once I got familiar with all quirks of the bike and was officially allowed to hit the road. Not a day later than my 16th birthday I could eventually start my bikers career. Besides my daily commutes I also started using the Monkey for errands and short stints to the local public pool. At one point I went for a „big“ journey of 200, 250 km all around the hills of Westerwald. A real adventure for a 16 year old!

Supply and demand regulate the price

When my cousin offered me his Yamaha DT 50 – still a mokick, but a full-sized enduro – I got tempted. I started announcing the Honda for 500 DM and shortly after it was sold for 400 DM to some guys who seemed to be familiar with that very model. I concluded of their response to my changes and the uncommon full fledged papers I got for it. Man, was I happy to make that money! Still I can admit I had no clue. That very model at that time was already worth at least twice of what I got paid. Those guys buying must have taken me for a complete idiot selling this cheap.

With todays knowledge I would have bought both the red and the blue one and just kept them. Today vintage Honda Monkeys are traded (depending on model year and condition) in a range of 3.000 to 6.000 €. This is the most Honda Monkey business I encountered so far.

There for it was a rather easy decision to buy the one that was lately offered on jiji.co.ke, though it already looked very poor on the pictures of the advert. Nevertheless I saw some potential in it.

I am still sure that a bit of love (and of course money) could turn this in to it’s old glory:

What we are talking of is a 1976 softtail Honda Monkey in „papaw green“. Quite an unusual color which for example wasn’t sold in US at all. Other colors of that model year are a clear white (also rare) and a bright yellow (the major color you’ll find on the market).

Next episode will be about an assessment for the bike to get an idea about the upcoming work.

Flugangst

Es gibt Neues aus Nairobi zu vermelden. Eigentlich Neues aus Deutschland, denn nach über einem Jahr geht es zurück aus der Wahlheimat. Ich sitze hier noch 2 Stunden am Flughafen rum, damit meine Freundin pünktlich vor dem Ende der Ausgangssperre wieder zu Hause ist und mir ist gar nicht wohl.

Nein, es ist nicht schon einsetzendes Heimweh und der Wunsch bald wieder zurück in Kenya zu sein. Oder besser: nicht nur. Seit ewigen Zeiten habe ich einfach nur Angst vor dem Flug.

Meine erste Flugreise liegt fast 30 Jahre zurück. Mit der Familie (ich der Sohn, Papa pays) über’n großen Teich und dann per Wohnmobil quer durch die USA von Küste zu Küste. Damals war alles neu, aufregend und dennoch habe ich mich in dieser fliegenden Dose alles andere als wohlgefühlt.

Beim Busfahren schaut man immerhin vorne durch die Windschutzscheibe und weiß was der Mann oder die Frau an der Kurbel gerade treibt. Fliegen war für mich der totale Kontrollverlust. Der nächste Flug nach Gran Canaria fast 10 Jahre später war – obwohl wesentlich kürzer – dann der Horror mit Ansage. Nicht das irgendwas schief gelaufen wäre. Aber wenn der Kopf nicht mitspielt … .

Es dauerte wieder fast 10 Jahre. Flughafen Manching. Eigentlich der Busbahnhof zwischen VW Wolfsburg und Audi Ingolstadt. Einer unserer Lieferanten hatte zur „Road“Show (sic!) geladen. Und im Rahmen der Veranstaltung auch Rundflugtickets verlost. Es kam wie’s kommen musste: eines war für mich bestimmt. Erfreulicherweise war ich der Größte aus der Runde, die in den kleinen Kuckuck kletterte, so dass ich das Recht des „Beifahrer“sitz‘ für mich reklamieren konnte. Das was sich das in Sachen Instrumente und Platzangebot vor mir ausbreitete erinnerte mich verdammt an den alten VW Käfer meines Patenonkels. Aber: Mehr Blick durch die Frontscheibe und auf das was der Pilot so trieb ging nicht. Die Angst war überwunden.

Angst, heißt es, haben wir vor unbekannten Dingen, Situationen. Die beste Therapie ist Information und die Entdeckung des Unbekannten.

Entsprechend waren der nächste Urlaubsflug in die Türkei, zum WordCamp Europe in Belgrad oder der Wochenendtrip nach Malinda ein Klacks. Und auch die Langstrecke nach Nairobi, die ich zwischenzeitlich schon mehr als ein halbes Dutzend mal geflogen bin ist Normalität geworden.

Und nun? Es ist nicht die Angst vor dem Flug selbst. Das ist wie immer. Auch wenn ich dieses Mal nicht mitten drin in Kairo einen Zwischenstopp habe, der die Strecke in zwei schöne gleiche Teile teilt. Heute geht es gleich auf einen Rutsch bis Amsterdam und dann weiter auf Frankfurt. Das unbekannte ist dieses Mal dieser Sch…virus der mitfliegt. Oder hoffentlich besser nicht. Es ist die Angst vor der Enge. Das zusammen gesperrt sein mit Leuten, die man nicht kennt und von denen man nicht weiß, ob und wie ordentlich sie sich in den letzten Tagen und Wochen verhalten haben.

Bis lang kann ich für mich sagen: alles richtig gemacht. Selbstisoliert seit einem halben Jahr. Nur raus, wenn Besorgungen anstanden oder der Lagerkoller drohte. Und dann Maske auf und Abstand halten. Und die verbal in die Seite boxen, die die beiden letztgenannten Maßnahmen nicht oder nur halbherzig umsetzen wollten. Kenya hat eine andere, kürze Distanz, die als Eintritt in die physische Privatsphäre gewertet wird als wir Nordeuropäer. Und dennoch war bei den meisten der Wille zu mindestens 1,5 m erkennbar. Der Rest durfte erinnert werden.

Die Angst wird sich fortsetzen, wenn ich gelandet bin. Es geht weiter mit der Bahn und was ich auf Twitter über die Covidioten mitlese, beruhigt mich kein bisschen.

Wahrscheinlich lache ich morgen Abend drüber.

Update 7.9.2020

Das Lachen ist mir zumindest auf dem Flug Amsterdam – Frankfurt etwas im Halse stecken geblieben. So prima Kenya Airways mit der Situation umgeht – nur ca. 1/3 des Fluges konnte überhaupt bebucht werden – so elend empfinde ich die Situation in Europa. Flieger rappel voll und rundum wird Corona und die damit einhergehenden Maßnahmen ignoriert oder mindestens drüber gescherzt und ad absurdum geführt. Man fühlte sich in eine Runde alter weißer Männer versetzt, die ihre billigen Witzchen reissen. Nur die Männer waren vornehmlich jung oder weiblich. Man fragt sich, wer das 3. Welt-Land ist.

Ich war froh gestern abend noch mit N95 Masken – die ich bislang nie getragen hatte – nachgerüstet zu haben.

Immerhin: ich weiß wo meine Angst hingehört. Es nicht mal der Virus selbst, sondern die Art wie manche Leute damit umgeht, die mir die Angst macht. Seit heute früh ist es eher Wut.

Warum ein Starter Theme beim PageSpeed hilft

Ok, hier in Nairobi ist „business as usual“. Also zumindest „Corona usual“. Spricht alles dafür nochmal ein WordPress Thema anzupacken. Machen wir doch da weiter, wo ich zuletzt bei der Auswahl eines Starter Themes aufgehört hatte. Nämlich, wie es sich ausgezahlt hat, genau auf dieses Pferd zu setzen. Vor allem wenn es um PageSpeed geht, hilft ein Starter Theme.

Die Kundenanforderungen

Wir brauchen eine mehrsprachige Seite, super gestyled, weil wir im künstlerischen Bereich publizieren. Das ganze muss responsive und ultraschnell sein, weil die Seite auch in langsamen, afrikanischen Mobilfunknetzen funktionieren muss. Wir sind öffentliche Hand, also bitte auch Barrierefreiheit und DSGVO beachten! Ach ja: wir gehen online am 10. Juli 2020

Sinngemässes erstes Briefing Ende Mai 2020

Aber das sind ja gleich 3 4 5 6 Wünsche auf einmal:

  • multilingual
  • barrierefrei
  • responsive
  • schnell
  • gestalterisch hochwertig
  • DSGVO konform

Ok, beschränktes Budget und kurzer Entwicklungszeitraum kommen nochmal oben drauf, passten aber bei uns durch die Tür. Aber schon im Rest ist klar erkennbar: da stecken ein paar Zielkonflikte drin. Wenn Bilder ins Spiel kommen, kann das mit „schnell“ schon mal schiefgehen. Multilingual heisst bei mir so gut wie immer Multilingual Press (MLP3) – also Multisite. Multisite kann bekanntermassen auch eher mal zum unzähmbaren und langsamen Monster geraten. BTW: die allererste Idee an der Stelle seitens des Kunden hiess: können wir ausgehend von einer rein deutschen Version die englischen und französische automatisiert aus einem Translator Plugin ausspielen? Kann man grundsätzlich, allerdings kosten auch die API-Anbindungen an Google Translate oder Deepl Geld und der Mehrwert einer echten fremdsprachigen Version ist natürlich das ordentliche SEO. Selbst wenn die Übersetzungen z.T. auf der Basis von Maschinenversionen gemacht wurden, die dann nur noch redigiert wurden. Die Qualität der Texte ist damit aber auf jeden Fall eine Stufe besser.

Die gute und die schlechte Nachricht: Agentur hilft mit

Das ist insoweit eine wirklich gute Nachricht, als das wir hier keine Gestalter sind (noch nicht). Aufbauend auf dem Hauptprojekt bekamen wir daher die Vorgaben, wie die Seiten denn auszusehen hätten übermittelt. Die schlechte Nachricht dabei: Grafikagenturen haben nur begrenzt eine Ahnung von Programmierung. Ihnen ist schlicht nicht bewusst, welche Limits einem ein Konstrukt von Header, Content, Sidebar, Footer auferlegt. Und welchen Aufwand es bedeutet, ein paar locker flockig gezogene Striche, die aus diesem Konstrukt ausbrechen, zu programmieren. Oder auch einfach nur wegzudiskutieren. Erfreulicherweise gab es jemanden am anderen (Kunden)Ende, der das Projektmanagement in der Hand hatte und als sachverständiger Filter einiges von sich aus relativierte oder Einwände unsererseits verstand. Egal wie: bis wir die ersten Zeilen Code aus einem allseits abgestimmten Entwurf ableiten konnten, war es KW26. Das Releasedatum 10.7. wo ein virtual Event stattfinden sollte war immer noch gesetzt.

Barrierefreiheit

Das Thema Barrierefreiheit war mit dem Agentur Entwurf zumindest schon mal relativiert. Versalien an fast allen Ecken und Enden, softe Farben auf denen die Schriften sicher nicht immer den passenden Kontrast finden. Dazu ein paar Sachen, die unter Usabilitygesichtspunkten nicht gerade glücklich gewählt waren. Da helfen auch keine Labels an Elementen, die man dort schlicht nicht vermutet oder denen man auf den ersten Blick eine andere Funktion unterstellt. Immerhin: das Gutenberg Starter Theme bringt auf den ersten Blick schon mal ein paar Sachen mit, die bei der Barrierefreiheit helfen, hat aber auch da noch deutlich Luft nach oben. Es wird Zeit für die erste Ableitung davon!

PageSpeed und StarterTheme schliessen Barrierefreiheit und Multilingual nicht aus. Hier hilft Juiz Lang Attribute

Ein weiteres, das ich dabei unterwegs lernen durfte: Auszeichnungen von fremdsprachigen Texten innerhalb des Contents. Klar, MLP3 setzt die korrekten Language Tags für die Website und damit für alle darin befindlichen Posts und Pages. Was aber wenn innerhalb des deutschen Contents französische Originalzitate auftauchen? Juiz Lang Attribute heisst die Lösung, mit der entsprechende hreflang Attribute entweder für einen kompletten Post oder auch inline für einzelne Elemente im Content gesetzt werden können. Inklusive entsprechendem Menüpunkt – anders als die Pluginbeschreibung nahelegt – innerhalb von Gutenberg.

Keine Pagebuilder

Ok, mal ganz abgesehen von der zunehmenden persönlichen Aversion: das Thema PageSpeed steht dem für mich klar entgegen. Immer noch eine gefühlte Wahrnehmung, aber ich arbeite am Nachweis ;-). Gutenberg sollte im vorliegenden Fall dem Kunden genügend Gestaltungsmöglichkeiten für den Content liefern und tat dies, bis auf eine Ausnahme auch. So sehr es mir wiederstrebte, aber für ein Element „IconList“ kam dann doch der komplette Kadenz Blocks da rein. Immerhin kann die ungenutzten Blocks bei Kadenz weg schalten um Benutzer nicht unnötig auf dumme Ideen zu bringen.

Schnell und responsive

Zum Glück mal eine Zielkongruenz. An der Stelle hilft es dem PageSpeed schon ungemein, ein Starter Theme einzusetzen und nicht über Child Theme Verrenkungen rein zu kommen. Alle Anpassungen laufen direkt in den Code, es müssen nicht erst Funktionen wieder aus der dequeue oder unloaded oder überfahren werden. CSS und Funktionen werden direkt in die Ausgangsbasis geschrieben. An der Stelle ein großes Dankeschön an Kirsten Schelper, die mich in SASS genötigt hat. Die Verteilung auf einzelne kleine Datei-Häppchen macht das CSS sehr gut pflegbar und logisch im Aufbau. Ein paar einfache Regeln legen den Farbraum fest (auch wenn wir unterwegs lernen mussten, dass die Prozentangaben der Agentur die Farbdichte nicht die Transparenz meinte) und der Preprozessor übersetzt alles in eine einzige CSS-Datei. Womit wir wieder beim Speed wären: so etwas lässt sich zum einen prima minifizieren und zum anderen sinkt die Zahl der Request.

Kann nur noch der Content zum Killer werden

In der Tat braucht es ein bisschen Fingerspitzengefühl um Kunden da mit ins Boot zu bekommen. Bilder müssen zumindest mal auf ein halbwegs passendes Format gestutzt werden um bei der Suche nach Geschwindigkeit nicht das Konstrukt aus der Kurve zu werfen. Texte müssen richtig strukturiert werden und Überschriften nicht nach Gestaltung sondern nach HTML-Semantik gewählt werden. Die Möglichkeiten der Fehlbedienung die Gutenberg an der Stelle bietet sind auf einer Stufe mit jedem Pagebuilder. Wenn der Kunde entscheidet H5 als erste Überschrift zusätzlich noch kursiv zu machen, dann erlaubt auch Gutenberg das. Gut das man ihn dann auf den ⓘ-Button aufmerksam machen kann, der die Gliederung aufzeigt und auf semantische Fehler hinweist.

Das Ergebnis

Die Seite ging – noch nicht in allen Belangen vollständig – am 10. Juli online. Immerhin die Desktopversion war komplett fertig gestellt, Mobil ist seit gestern vollständig und ein paar Kleinigkeiten in Sachen Barrierefreiheit kommen im Laufe dieser Woche noch dazu.

Was wir auf jeden Fall beimThema PageSpeed hilft ist das Starter Theme. Google zeigt 100 für die mobile Version, 99 für den Desktop. Auch GTmetrix liefert einen 100er PageSpeed Wert und 92 für YSlow, was wohl entweder nur mit einem anderen Server oder einem CDN zu verbessern sein dürfte. Die Zahl der Request lässt sich mit einem eigenen Theme jederzeit unter Kontrolle halten. Die Seitengröße lag am Ende bei etwas rund um 750 kB (abhängig von den Bildern, die gerade auf der Eingangsseite präsentiert werden).

Die Bilder wurden mit Imagify optimiert und in WebP Versionen übersetzt. Aus dem gleichen Haus kommt noch WP-Rocket für’s Caching dazu. Für mich das absolute Dreamteam. Cacheaufbau anhand der sitemap.xml? Oh, ich sehe Du nutzt Yoast SEO – lass uns das doch gleich mitverwenden. Ah, Du hast schon Imagify am Start – dann ist das Thema WebP dort besser aufgehoben. Solche intelligenten Dinge sind es, die mir WP-Rocket sympatisch machen.

Und nur nebenbei: mein „langsames, afrikanisches Mobilfunknetz“ kommt meistens auf stabile 50 Mbit/s Up- und Download.