Alle Versand- und Payment-Icons als SVG: Hallo Zukunft!

Ich war das abgelaufene Weihnachtsgeschäft scharf auf Schärfe. Und so wurden matschige Bilder und pixelige Logos im Erzgebirge-Palast im großen Stil ersetzt. Klassische Bilder wurden neu in einer hochauflösenden Version erstellt, alles was irgendwie Logos, Flaggen und Icons wurde hingegen als SVG angelegt.

Und damit wurden auch die Payment-Icons endlich in die Gegenwart der Webtechnologie befördert. Zumindest die, die ich gebraucht habe. Da ich aber eh im Flow war hab ich auch unsere Warenwirtschaft komplett auf SVG umgestellt. Und mir dann überlegt, dass ich das für die Payment-Icons und die Versandunternehmen eigentlich auch machen müsste, denn es wurde schon mehrfach nachgefragt (obwohl die Icons sehr groß angelegt sind ersetzt halt so ein Pixelbildchen doch kein echtes SVG) und sie erfreuen sich noch immer großer Beliebtheit. Das seh ich nicht nur daran, dass noch immer Kommentare dazu kommen. Nein, auch in Onlineshops laufen sie mir immer wieder über den Weg.

Das Original setzt Segel Richtung Zukunft!

Das Original ist jetzt endlich in der Zukunft angekommen. Beide Iconpacks sind ab sofort als SVG verfügbar. Und natürlich als echte SVG, alle Icons sind wirkliche Vektorgrafiken, es kommen genau 0,0% Rastergrafiken zum Einsatz. Und natürlich sind auch alle anderen Features weiterhin vorhanden: Alle Icons sind einheitlich, die Farben aufeinander abgestimmt und wo es sich anbietet gibt es mehrere Varianten.

Im Zuge der Umstellung wurden natürlich auch alle Logos, die sich seit dem letzten Update geändert haben, auf den aktuellen Stand gebracht und gerade bei den Versanddienstleistern stark ausgebaut. Ein paar Icons haben auch eine generelle optische Überarbeitung erfahren wie beispielsweise die Nachnahme-Icons. Und von ein paar mussten wir uns auch trennen.

Nicht mehr enthaltene Versandicons

  • El Correo Guatemala: Derzeit kein gutes Vectoricon verfügbar

Nicht mehr enthaltene Zahlungsicons

  • Briefkuverts für Rechnungszahlung: Zu aufwendig
  • CartaSi: Derzeit kein gutes Vectoricon verfügbar
  • MoneyBookers: Dienst heißt mittlerweile „SKRILL“
  • Natel Pay: Dienst heißt mittlerweile „Swisscom Pay“
  • Postpay: Dienst eingestellt
  • Yapital: Dienst eingestellt

Ergänzt wurden die Icons durch an mich herangetragene Wünsche. Wenn noch was fehlt, schreibt es gerne in die Kommentare. Mit 291 Versand- und 154 Zahlungsicons dürfte das aber jetzt schon eine der größten, einheitlichen, voll vektorisierten Iconsammlungen weltweit sein. Wenn nicht gar die größte.

Änderungen gegenüber den bisherigen PNG-Icons

Schrift

Die Schrift für im Hintergrund sichtbare große Einzelbuchstaben ist weiterhin Aller Display, für Texte wie bei den generischen Rechnungs- oder Vorkasseicons kommt TT Firs Neue zum Einsatz. Alle Schriften sind aber natürlich umgewandelt, damit die Icons wirklich so aussehen wie sie aussehen sollen. Es gibt aber auch jeweils eine Variante mit offener Schrift, in dem Fall Helvetica Neue, diese Dateien haben den Zusatz helvetica im Dateinamen, womit wir bei der zweiten Änderung wären:

Dateinamen

Die ersten zwei Buchstaben sind der ISO-Code des Landes, in dem der Dienst (meiner Meinung nach) primär tätig ist. Dabei haben euorpaweit tätige Unternehmen EU erhalten, weltweit tätige das im ISO nicht vergebene Kürzel WW (für worldwide). Außerdem gibt es ein paar Zusätze:

  • alt: Kurz für Alternative. Beispielsweise ein andersfarbiger Hintergrund.
  • text: Ist eine Version des eigentlichen Logos mit zusätzlichem Text.
  • helvetica: Enthält offene Schriften.
  • heritage: Ein früher von diesem Dienst verwendetes Logo, das ich aus sentimentalen Gründen nicht rausgenommen habe.
  • historic: Ein wahrhaft historisches Logo dieses Dienstes, das ich aus sentimentalen Gründen nicht rausgenommen habe.

alt kann mit allen Zusätzen kombiniert auftreten, Bei mehreren Alternativen wird dann einfach durchgezählt. Bis auf die DPD- und GLS-Alternativen müsste ich das auch konsequent durchgezogen haben.

Alle Dateien wurden darüber hinaus mit SVGO optimiert, um die Dateigrößen möglichst klein zu halten. Allerdings hab ich darauf verzichtet, das Markup zu minifizieren, weil es die Lesbarkeit doch stark beeinträchtigt, möchte man beispielsweise nur schnell über den Texteditor eine Farbe ändern. Und es ist ja vor dem Deploy schnell mit erledigt.

Genug der Worte. Viel Spaß mit den Icons und wem noch was fehlt, gerne in die Kommentare schreiben.

Objekte und Arrays: Alle gegen Smarty

Shopware pflügt manchmal mit einer komischen Mischung aus Objekten und Arrays durch das Template, beispielweise auf den Herstellerseiten:

Shopware\Bundle\StoreFrontBundle\Struct\Product\Manufacturer Object
(
    [id:protected] => 1
    [name:protected] => Anton Schneider
    [description:protected] => 
    [metaTitle:protected] => 
    [metaDescription:protected] => 
    [metaKeywords:protected] => 
    [link:protected] => https://dev.wibros.eu/anton-schneider/
    [coverFile:protected] => https://cdn.cuckoopalace.com/media/vector/4c/76/c3/schneider.svg
    [attributes:protected] => Array
        (
            [core] => Shopware\Bundle\StoreFrontBundle\Struct\Attribute Object
                (
                    [storage:protected] => Array
                        (
                            [id] => 1
                            [supplierID] => 1
                            [wan] => AS
                            [wib_class] => schneider
                        )
 
                )
 
        )
 
)

Leider unterstützt Smarty die in php mittlerweile gültige Syntax get()['arraykey'] nicht.

{$manufacturer.getAttributes()['core']->get("wib_class")}

führt also zu einem Parse Error. Um jetzt doch an wib_class zu kommen muss man einen komischen Spagat machen:

{assign var="attr" value=$manufacturer->getAttributes()}
{assign var="class" value=$attr.core->get("wib_class")}

Bleibt die Frage: Warum?

Rate mal mit Shopware

Die älteren werden sich erinnern: Rate mal mit Rosenthal war eine Quizsendung im ZDF. Ich würde das gerne wieder aufleben lassen.

Wo findet man in Shopware die Einstellmöglichkeit, dass Filter sich automatisch aktualisieren (Live reload, AJAX reload oder wie auch immer man das nennen will)?

  • Einstellungen – Grundeinstellungen – Storefront – Filter / Sortierung
  • Artikel – Kategorien
  • Einstellungen – Caches / Performance – Einstellungen – Allgemein – Filter

„Einstellungen – Caches / Performance – Einstellungen – Allgemein – Filter“ ist so richtig wie nicht intuitiv.
Und während sich in „Einstellungen – Caches / Performance – Einstellungen – Allgemein – Kategorien“ Sachen finden, die sich auch in „Einstellungen – Grundeinstellungen – Storefront – Kategorien / Listen“ hat man diese nicht ganz unwichtige Option nicht doppelt und dreifach untergebracht.

Templatevererbung und Namespaces in Shopware

Ihr wollt einen Block in einem Shopware-Template ändern und erweitert daher das Eltern-Template:

{extends file="parent:frontend/listing/text.tpl"}

So weit so bekannt. Wollt ihr jetzt aber in diesem Template Snippets aus dem Elterntemplate ohne Namespace verwenden führt das dazu, dass ein neues Snippet im Namespace eurer neuen Datei (hier also „frontend/listing/text”) angelegt wird.

{s name='ListingActionsCloseOffCanvas'}{/s}

Um das zu verindern müsst ihr einen evtl. gesetzten globalen Namespace nach dem vererben erneut setzen oder den gewünschten Namespace bei jedem Snippet mit angeben.
Also entweder so:

{extends file="parent:frontend/listing/text.tpl"}
{namespace name="frontend/listing/listing"}

Oder so:

{s namespace='frontend/listing/listing' name='ListingActionsCloseOffCanvas'}{/s}

Dynamische Snippets in Smarty

Für den Fall, dass man aus einer Smarty-Variable ein Snippet zaubern will:

{$namespace = "frontend/language"}
{$name = $lang.locale}
{""|snippet:$name:$namespace}

Konkretes Beispiel:
Man hat den locale einer Sprache (z.B. de_DE), möchte aber ganz gerne „Deutsch“ im Frontend ausgeben. Mit dem Code oben geht genau das, Smarty gibt jetzt den Inhalt des Snippets „de_DE“ aus dem Namespace „frontend/language“ aus. Der Namespace ist dabei wichtig, sonst funktioniert es nicht!

Man kann über den cat-Modifier außerdem noch den Namen erweitern, damit man als Snippet-Name nicht nur „de_DE“ in der Datenbank stehen hat:

{$name = "lang_"|cat:$lang.locale}

und bekommt damit lang_de_DE als Name.

Schon vor Amazon kapituliert, deutsche Verleger?

Ich hab jetzt ne eigene Kategorie für die kleine Serie angelegt: „Alle kaufen bei Amazon“. Da findet ihr meine Rants zu deutschen Onlinehändlern.

Ich bin die Tage auf ein interessantes Buch aufmerksam geworden: „Das Natur-Talent“ von Marcel Ackle, erschienen im Klartext-Verlag. Beim Verlag mit 1-3 Tagen Lieferzeit zu bekommen oder bei Amazon. Da ich letztere ja so total liebe und „Prime“ dort derzeit alles heißt zwischen „kommt gar nicht“, „kommt mit mehreren Tagen Verspätung“, „legen wir beim Nachbarn vor die Tür, sagen es aber niemandem“ oder „Flash from the past: Wir halten tatsächlich mal wieder unser 1-Tag-Prime-Versprechen!“ habe ich beim Verlag bestellt.

Heute dann eine Mail von der „Germinal Medienhandlung GmbH“. Komisch. Die Datenschutzerklärung von Klartext erwähnt mit keinem Wort, dass meine Daten an Germinal weitergegeben werden, Germinal hingegen sagt:

Die Germinal GmbH ist vom Verlag beauftragt Ihre Bestellung auszuführen.

Außerdem sagen sie noch:

Ihr Auftrag wurde heute bearbeitet. Leider ist die Ware zur Zeit nicht verfügbar.

Heute heißt übrigens mehr als 24 Stunden nach Bestelleingang. Und beim Klartext-Verlag steht weiterhin

Sofort versandfertig, Lieferzeit ca. 1-3 Werktage

Aber eigentlich braucht einen das alles nicht zu wundern. Germinal betreibt seinen Webauftritt unter https://www2.germinal.de/. Für ein gültiges Zertifikat für https://www.germinal.de/ hat leider das Geld gefehlt, auch für einen DNS-Eintrag für https://germinal.de/ war leider nicht mehr genug Bares vorhanden (wer den Sarkasmus hier nicht erkennt: Kostet beides nichts!). Wenig überraschend ist dann bei deaktiviertem Javascript auf der Germinal-Homepage nur das zu lesen:

<#! -- hier stand piwik-code -- >

Ich meine, die kommentieren Kommentare mit dem falschen Kommentarzeichen (der Text steht foglich auch so am Ende der Seite wenn Javascript aktiv ist). Warum also sollten die so komplexe Themen wie einen Lagerbestandsabgleich, den man problemlos gegen die API fahren könnte, den die vom Klartext-Verlag eingesetzt Shopware-Installation von Haus bietet, im Griff haben? Da sind also echte Profis am Werk, mit denen dieser Klartext-Verlag zusammenarbeit, der übrigens zur ominösen Funke-Mediengruppe gehört, die keiner kennt, denen aber laufend irgendwelche Interviews gegeben werden.

Und ja, ich hab grad bei Amazon bestellt. Selber schuld, Germinal. Und bitte nicht rumheulen wenn ihr demnächst zuschließen müsst. Denn das böse Internet ist nicht schuld. Eure Unfähigkeit ist schuld.

$discardedLessThemes vs. Shopware: Es könnte so einfach sein

Ich mag das Theme-Konzept von Shopware ja eigentlich. Es gibt ein Bare-Theme, das außer HTML nichts enthält. Kein Styling, kein Javascript, einfach nur reines HTML.
Darauf aufbauend gibt es ein Responsive-Theme das, wie der Name schon sagt, responsive ist und über Variablen im Backend farblich auch ein bisschen angepasst werden kann. Das ist für den Wohnzimmerhändler sicherlich toll und man sieht auch mittlerweile unzählige Shops, die das Responsive-Theme nutzen und außer Logo und Farbe nichts geändert haben. Kann man machen, ist dann halt kacke.

Für unsere Ansprüche ist das natürlich nichts. Wir haben ein komplett selbst gestaltetes Theme, das auch nach allen Regeln der Kunst umgesetzt werden soll. Und da es so ganz anders ist als das Default-Theme wäre es natürlich gut, wenn man nicht den ganzen CSS-Ballast, den das Responsive-Theme mitbringt, rumschleppen müsste.

Weil sind wir doch mal ehrlich: Shopware 5 und damit die Grundlage des Responsive-Themes ist von 2015, der letzte Commit auf das Repo von pocketgrid, welches das Responsive-Theme nutzt, ist sogar noch ein Jahr länger her. Mittlerweile haben wir echtes CSS Grid und es wäre fahrlässig, das nicht zu nutzen.

Nur: Der Weg von

zu

ist ganz schön steinig und unnötig beschwerlich.

Vom Bare-Theme erben

Funktioniert total gut. Also bestimmt. Wenn man einen frisch installierten Shop hat ohne ein einziges Plugin. Das dürfte aber eher die Ausnahme sein. Schon bei einem Shop, der lediglich das PayPal-Modul installiert hat, scheitert das Kompilieren des Themes:

Während der Bearbeitung von Shop "Demoshop" ist ein Fehler aufgetreten: variable @tabletViewportWidth is undefined in file custom/plugins/SwagPaymentPayPalUnified/Resources/views/frontend/_public/src/less/_modules/index/sidebar.less in sidebar.less on line 11, column 30 09| } 10| 11| @media screen and(min-width: @tabletViewportWidth) { 12| .paypal--sidebar { 13| .unitize(margin-bottom, 20); 14|

Öh ja, das ist so semi-gut. Kann man prinzipiell nachrüsten, sobald man aber noch ein paar komplexere Plugins am Start hat wie beispielsweise die Advanced Promotion Suite knallt es auch bei den Farbwerten, die man eigentlich über das Backend konfigurieren kann (aber eben nicht beim Bare-Theme).

$discardedLessThemes beim Responsive-Theme

Also vom Responsive-Theme erben. Seit Shopware 5.4 gibt es da die Möglichkeit, sowohl in den Vererbungspfad des CSS/LESS als auch das Javascripts einzugreifen. Für LESS/CSS mittels discardedLessThemes, für das Javascript mittels discardedJavascriptThemes.

Da also das Responsive-Theme eintragen und kompilieren und alles ist super. Natürlich nicht. Auch hier hat man die Rechnung ohne die Plugin-Autoren gemacht. Direkt als erstes fliegt einem wieder der Tablet-Viewport um die Ohren. Hat man sich dafür ein eigenes LESS-File angelegt knallt zumindest in unserem Fall das Amazon-Pay-Plugin. Und zwar mehrfach aufgrund des Zugriffs auf jetzt nicht mehr vorhandene Definitonen aus dem Bereich der Buttons. Also auch hier eigene LESS-Files anlegen und leere Definitionen dort eintragen.
So geht das Spielchen, das einem Marathon gleicht, munter weiter, bis alle Plugins, die noch nichts davon gehört haben, dass die Vererbung mittlerweile abschaltbar ist, zufrieden gestellt sind. Erst dann hat man für einen Shop mit diversen Plugins auch endlich eine wirklich CSS-freie Darstellung. Also quasi Bare-Theme ohne die Probleme mit den fehlenden Farbdefinitionen.

Nur: CSS-frei ist das ganze deswegen noch lange nicht, da sorgt schon jedes Plugin dafür, dass da wieder ein bisschen was zusammen kommt, aber zumindest lässt sich so der Umfang des CSS schon mal auf ca. 2500 Zeilen reduzieren, während der gleiche Shop mit Responsive-Theme auf 25.000 Zeilen kommt. Es ist noch ein weiter Weg…

Wie Vollpfosten-Versender die Kunden in die Arme von Amazon treiben…

Das ist quasi ne Fortsetzung zu Der deutsche E-Commerce versagt schon bei den Basics. Wird wohl ein Mehrteiler.

Braucht mal wieder jemand Futter, warum Amazon so beliebt beim Kunden ist? Weil viele andere Versender einfach Vollpfosten sind. Hier gleich zwei Vollpfosten des Monats August.

Ich hatte Bedarf nach mehr Ventilatoren. War ja auch mal heiß dieses Jahr. Erste Bestellung über zwei Stück des gleichen Typs am 26. Juli aufgegeben bei nem großen Elektroladen in Karlsruhe, Ware angeblich sofort lieferbar. In der Bestellbestätigung steht dann plötzlich 1. August als Liefertermin. OK, die bringen den wohl persönlich, aber egal, ist ja die nächste Woche auch noch heiß.
Meine Zahlung über PayPal wurde dann am nächsten Tag per Mail bestätigt. Kann man bei ner sofortigen Zahlungsmethode natürlich machen, ist mit einem Tag Verzug aber halt lächerlich und zeigt wie schlecht das Warenwirtschaftssystem hinten dran sein muss.
Sollte man daran noch Zweifel haben: Vier Tage nach Bestelleingang kommt ne E-Mail, dass man auch den Termin am 1. August leider reißen wird, neuer Liefertermin wäre der 13. August, man offeriert aber eine Teillieferung. Ich antworte sofort und frage wie die Teillieferung denn aussehen wird. Man braucht zwei Arbeitstage um mir zu antworten, dass das eine Standardmail vom System sei und eine Teillieferung anders als offeriert doch nicht möglich wäre. Wie schlecht bitte kann ein Warenwirtschaftssystem eigentlich sein, das vor Mailversand nicht erkennt, dass auch eine Teilmengenlieferung nicht möglich ist? Ich antworte erneut direkt, bekomme aber keine Antwort, sondern eine Rechnung. Am nächsten Tag steht ohne Versandmitteilung die Ware plötzlich auf dem Hof.
Noch einen Tag später hat sich dann sogar der Twitter-Account des Händlers, den ich zwischenzeitlich angeschrieben hatte, gemeldet. Auch mit einer Reaktionszeit von zwei Tagen. Der Händler verkauft auch über Amazon, es ist mir ein Rätsel, wie er dort die Antwortzeiten einhält während er auf allen anderen Kanälen 48 oder mehr Stunden benötigt.

Neuer Händler, gleiche Ware

Ich bin aber noch nicht fertig. Mit dem neu avisierten Liefertermin für den 13. August habe ich direkt eine Ersatzbeschaffung vorgenommen. Am 31. Juli habe ich also bei einem eBay-Händler, der mit 17.000 Bewertungen auch eher nicht aus dem Wohnzimmer versendet, eine weitere Bestellung aufgegeben, Liefertermin zwischen dem 2. und 3. August. Nachdem am 2. August dann ja aber überaschenderweise die Ware vom ersten Händler eingetroffen ist und die vom eBay-Händler noch nicht versendet gemeldet war, habe ich dort versucht den Kauf abzubrechen:

Hiermit widerrufe ich den Kauf. Der Artikel wird nicht mehr benötigt. Da er auch noch nicht versendet ist bitte Zahlung wieder auf mein PayPal-Konto gutschreiben.

Die Antwort irritierte mich dann aber:

Bitte lehnen Sie die Lieferung ab, wenn Sie bei Ihnen eintrifft, zurückhalten können wir sie leider nicht mehr.

Aha, also doch schon versendet? Einen Tag haben sie ja noch um den versprochenen Liefertermin einzuhalten. Und natürlich kam am 3. August keine Ware. Und auch die nächsten Tage nicht, weshalb ich am 6. August erneut schrieb:

Bislang ist kein Paket hier eingetroffen, obwohl das schon bis spätestens Freitag der Fall hätte sein sollen und es ja angeblich auch schon versendet ist. Bitte lassen Sie mir die Sendungsnummer zukommen, es ist etwas müßig, jeden Tag den DHL-Fahrer abpassen zu müssen, damit er das Paket ja nicht irgendwo in der Nachbarschaft abgibt, wo niemand was von der Annahmeverweigerung weiß.

Die Antwort einen Tag später ist ein Musterbeispiel für extrem schlechte Kundenkommunikation:

Leider können wir momentan aufgrund der Hitzewelle nicht alle Tickets / Anfragen zeitnah beantworten. Wir versichern Ihnen, dass wir mit Hochdruck daran arbeiten Ware zu versenden und Ihre Anfragen schnellstens zu beantworten.

Bitte geben Sie uns daher ein, zwei Tage Zeit. Es wird nichts vergessen und wir sind uns sicher alle Ihre Anfragen nach dieser Zeit zu Ihren Zufriedenheit beantworten zu können.

Wie jetzt? Die Hitzewelle ist schuld, dass auf eBay offensichtlich falsche Lagerbestände standen, E-Mails nicht zeitnah beantwortet werden und der Verpackungsbereich gleich hitzefrei hat? Also bei uns wurde durchgearbeitet in allen Abteilungen und ja, wir hatten auch warm.

Wir schreiben mittlerweile übrigens den 7. August. Und es geht nach wie vor um die Ware, deren Stornierung ich am 1. August angefragt hatte, die aber zu dem Zeitpunkt angeblich schon nicht mehr zurückgehalten werden konnte. Am 9. August habe ich dann sowohl von eBay als auch vom Händler eine Versandbestätigung erhalten. Was in beiden Fällen fehlt: Eine Trackingnummer. Richtig krotesk wird es bei der Mail des Händlers:

Die Stellen, an die das Warenwirtschaftssystem eigentlich die Trackingnummer einfügen sollte sind einfach leer. Und ich habe den Screenshot absichtlich etwas größer gemacht, damit man sieht, dass der Link zum Adobe Reader ein Link ist, man das aber beim Trackinglink nicht hinbekommen hat.

Die Ware ist übrigens immer noch nicht da. Es scheint als hätte da ein Dropshipper seine Lagerbestände nicht im Griff. Das auf dem Rücken des Kunden auszutragen ist aber halt auch ein Unding. Eine Verschärfung des Tons beim Händler schien mir daher angebracht:

Ich werde hier seit 14 Tagen verarscht und hingehalten, die Ware ist bis heute nicht angekommen. Ich verlange umgehend das Geld zurück!

Das hat dann dazu geführt, dass binnen zwei Tagen das Geld da war. Kommentarlos. Ware ist nie gekommen. Ich wurde also nicht nur verarscht, ich wurde nachweisliche angelogen was den Versendet-Status der Ware angeht.

Umziehen Part 5: Die Schmerzen mit dem SSL

Das Webseiten nur noch über HTTPS erreichbar sind ist mittlerweile eher die Regel denn die Ausnahme. Zeit, die alte Serie aus 2012 noch mal aufzugreifen, denn durch die Omnipräsenz von HTTPS kommen plötzlich neue Probleme ins Spiel die es vorher so noch nicht gab.

Das Szenario dürfte der Standard sein:
Man hat einen Webshop und betreibt diesen auf www.example.com. Für genau diese Domain besitzt man auch ein Zertifikat, evtl. sogar mit Extended Validation. Außerdem hat man noch, um Trittbrettfahrer abzuhalten, example.org und example.net registriert.
Und alles was nicht www.example.com ist leitet man entsprechend um. Das ist bei HTTP auch kein wirkliches Problem und über zwei Zeilen in der .htaccess zu lösen:

1
2
3
4
5
6

<IfModule mod_rewrite.c>
RewriteEngine On
 
RewriteCond %{HTTP_HOST} !^www.example.com$
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
</IfModule>

Kommt jetzt HTTPS ins Spiel ist es vorbei mit der Einfachheit. Denn https://example.com/ und https://www.example.com/ sind technisch nun mal zwei verschiedene URLs, können völlig unterschiedliche Inhalte zeigen und brauchen für eine fehlerfreie Funktionsweise entsprechend für jede URL ein Zertifikat.
Safari und Firefox quittieren den Umleitungsversuch von https://example.com/ nach https://www.example.com/ mit dem Zertifikat von https://www.example.com/ korrekterweise mit einer Fehlermeldung – Chrome erstaunlicherweise nicht (IE und Edge wurden nicht getestet).

Die Kosten für das eigentlich unnötige Zertifikat können sich schnell aufsummieren, neben dem Zertifikat selbst (evtl. mit EV) braucht man unter Umständen nämlich auch noch eine weitere IP-Adresse, weil der Provider aus nicht nachvollziehbaren Gründen noch immer kein SNI unterstüzt.

Will man also allen Traffic ohne www-Prefix unabhängig von HTTP und HTTPS fehlerfrei umleitung brauch man eine Lösung und die Rettung kommt, mal wieder, von Uberspace. Denn dort gibt es SNI, IPv6 und Zertifikate von Let’s Encrypt. Man muss also nur einen Uberspace klicken, mit uberspace-add-domain die gewünschten Domains hinzufügen und dann für diese nach dieser Anleitung Zertifikate erzeugen. Dann stellt man nur noch die DNS-Einträge für die umzuleitenden URLs auf Uberspace um und leitet alles ohne Zertifikatsfehler richtig um. Die .htaccess ist quasi identisch zu der oben, nur dass das Umleitungsziel jetzt natürlich die HTTPS-URL ist.

1
2
3
4
5
6

<IfModule mod_rewrite.c>
RewriteEngine On
 
RewriteCond %{HTTP_HOST} !^www.example.com$
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
</IfModule>

Bleibt noch die Frage: Braucht man das? Niemand dürfte das händisch falsch eingeben und dann an einer Fehlermeldung hängenbleiben. Nun, selbst der Fall dürfte hin und wieder vorkommen, aber es braucht nur jemand einen falschen Link zu setzen damit Besucher mit entsprechenden Fehlermeldungen konfrontiert werden. Und auch die Search Console von Google meckert das falsche Zertifikat an (man muss ja beide Properties anlegen um die bevorzugte Domain in den SERPs einstellen zu können). Um so unverständlicher, dass Chrome da einfach drüber „hinwegsieht“.