Also fange ich besser ganz vorn an.
Blog-Adresse relativieren
Wenn man das eigene WordPress-Blog sowohl mittels https:// als auch per http:// sauber ausliefern möchte, gerät man schnell in eine „Zwickmühle“. Gerade im Head-Bereich gibt es viele Nachlade-URLs die Voll-Qualifizierte Web-Adressen sind und die den Inhalt des Eintrags der WordPress-Adresse aus den Einstellungen benutzen. Dieser Eintrag kann aber nun mal nur eine der beiden Möglichkeiten enthalten. Ist die BaseURL auf http:// gesetzt werden alle StyleSheet- und JavaScript-URLs als http:// ausgezeichnet. Ruft der Besucher das Blog per https:// auf, gelten für den Browser diese URLs aus Links zu „Drittanbietern“ und die Inhalte werden nicht nachladen.
Beispiel des Lightbox2-Plugins:
... <link rel='stylesheet' id='wp-lightbox-2.min.css-css' href='http://www.perl--online.com/blog/wp-content/plugins/wp-lightbox-2/styles/lightbox.min.css?ver=1.3.4' type='text/css' media='all' /> ... |
Schöner wäre es, wenn es im html-Quelltext meiner Webseite nur relative URLs gäbe. Irgendwann hatte ich ja mal angefangen, in den Plugins alle entsprechenden Einträge zu suchen und anzupassen, aber das hält leider jeweils nur bis zum nächsten Update.
Also suchte ich nach Alternativen. Erst fand ich Tipps die nur den Inhalt der Text-Bereiche abändern. Das hilft zwar gegen die absoluten Bilder-URLs die die Mediathek beim Einbinden generiert, aber sonst nichts.
Was ich brauchte war etwas, dass den gesamten Output kurz vor dem Ausliefern noch mal durch die Mangel nimmt.
Erst nach langem Suchen fand ich eine unscheinbare Hook-Aktion ‚template_redirect‘ die genau das tut.:
add_action( 'template_redirect', 'up_template_redirect' );
Und wie das immer so ist, wenn man weiß wonach man suchen muss, findet man auch jede Menge Tipps.
Kurzer Einschub
Die hier beschriebene Lösung benutze ich schon einige Jahre und wo ich jetzt dabei bin, alle Fakten zusammen zu suchen, stelle ich fest, dass WordPress scheinbar das bis hierhin beschriebene Problem inzwischen selber lösen kann. Die URLs werden offensichtlich selbständig angepasst, je nachdem wie das Blog aufgerufen wird. Meine Lösung dazu ist also offensichtlich gar nicht unbedingt nötig. Allerdings war sie das, als ich mir darum Gedanken machte und so bespreche ich meine Lösung weiter.
Canonical-Adresse korrigieren
Nun konnte ich also aus jedem Link das Protokoll und den Servernamen aus den URLs entfernen. Ab sofort beginnen alle URLs in meinem Quelltext nur noch mit „/blog…“ (statt „http://…“) und funktionieren dadurch immer, egal unter welcher Adresse mein Blog aufgerufen wird. Sogar alternative Domainnamen werden nun gültig.
Was erst mal ein Vorteil ist, wird dann aber schnell zum Nachteil. Google testet und indiziert diese alternativen Domains leider auch. Dadurch gibt es dann die selbe Seite schnell in mehreren Versionen im Google-Index, mit bekannten Folgen. Dafür ist ja eigentlich der canonical – Meta-Eintrag im html-Head zuständig. Wenn der aber nun nach dem ersten Komplett-Ersetzen auch nur eine relative URL enthält, ist jede Domain gültig.
Die Lösung ist ganz einfach. Mein Replace muss hinterher den canonical-Eintrag wieder „absolut“ machen. Um sich bei Google etwas einzukratzen, kann man sich dabei ja gleich auf https:// festlegen. Nun sollten die ganzen Geister-Domains im Google-Index wieder verschwinden.:
<link rel="canonical" href="https://www.perl--online.com/blog/archives/133080" /> |
POST-Requests
Kaum ist das alles schick, kommt der nächste Hinweis. In der Mail hieß es, wir sollen es so einrichten, dass die Kontaktformulare auf der Webseite verschlüsselt übertragen werden. Erst mal ging es zwar nur um das Kontaktformular. Weil das Problem aber auch alle anderen Formulare betrifft, die auch nur entfernt personenbezogene Daten senden könnten, kann man sich natürlich spätestens jetzt auch überlegen, das gesamte Blog ausschließlich per SSL bereitzustellen. Ich bin mir aber nicht sicher, ob wirklich alle Besucher darauf eingehen würden.
Also erweitere ich den Replace-Teil noch mal um eine weitere Ersetzung, die nun auch noch die Formular-URL abändert.
TextReplace-Snippet
Nun habe ich also ein Snippet, dass erst alle absoluten URLs in relative verkürzt und dann im „zweiten Schritt“ die Adressen für die canonical-URL und für die Formular-Action-URLs wieder in absolute Adressen zurück umwandelt. – Diese dann aber gleich in https-URLs.
... function up_replace_content ($content) { $replace = array ( //'<alt>' => '<neu>', 'https://www.perl--online.com/blog/' => '/blog/', 'https://www.uweprl.de/blog/' => '/blog/', 'http://www.perl--online.com/blog/' => '/blog/', 'http://www.uweprl.de/blog/' => '/blog/', 'rel="canonical" href="/blog/' => 'rel="canonical" href="https://www.perl--online.com/blog/', ' action="/blog' => ' action="https://www.perl--online.com/blog' ); $content = str_replace(array_keys($replace), $replace, $content); return $content; } //add_filter('the_content','up_replace_content'); //add_filter('the_excerpt','up_replace_content'); function up_template_redirect() { ob_start(); ob_start('up_replace_content'); } add_action( 'template_redirect', 'up_template_redirect' ); |
Um dieses Snippet zu nutzen, muss man die Zeilen in die function.php des benutzten Themes einfügen – oder man bastelt sich ein eigenes, kleines Plugin. Eine einfache Vorlage dafür findet man hier.
Der Vorteil letzterer Lösung ist, dass sie unabhängig vom Theme funktioniert und relativ simpel inaktiv und wieder aktiv „geschaltet“ werden kann.
Alternative als Plugin
Wer es etwas Web-Interface-iger mag, sollte sich mal ansehen, ob das Plugin WordPress-Plugin Realtime-Find-and-Replace für ihn in frage kommt.
In der freien Plugin-Variante kann man allerdings nur noch fünf Regeln erstellen – oder man erwirbt die Pro-Version für 10 Dollar – (Der Preis von 5 Dollar ist scheinbar verjährt). In der Pro-Version kann man dann nicht nur beliebig viele Regeln erstellen, es gibt auch noch einige andere interessante Featurs – für den der es braucht. Ich würde die 10 Dollar ja zur Not einsehen, wenn ich herausfinden würde, was genau ich dann für welchen Zeitraum dafür bekomme. Weil ich aber nicht heraus bekam, was das Plugin auf längere Sicht wirklich kostet, nutzte ich lieber die oben beschriebene Alternative.
Hinterlasse einen Kommentar