Das Putzlowitsch Test- und SEO-Blog

Das Problem mit WordPress und den ungültigen URL-Parametern

WordPress hat ein Problem mit ungültigen URL-Parametern. Wenn jemand an die Blogadresse einfach einen Parameter mit einem Wert anhängt, wird das von WP klaglos akzeptiert, obwohl es völlig unsinnige Werte sein können.

Ein Beispiel:
http://vierzehnfuffzig.de/?url=http://www.heise.de
oder
http://vierzehnfuffzig.de/?blafasel=trallalla
oder was auch immer.

In allen Fällen gibt WordPress brav die Startseite meines Test- und Probierblogs aus. Das ist aus SEO-Sicht natürlich schlecht, denn es kann dadurch ganz viel DC enstehen.

Die Abhilfe ist recht simpel, die URL-Parameter müssen einfach gegen die in WordPress bekannten Parameter getestet werden. Das sind nur ein paar Zeilen PHP-Code.

Ich habe das mal in eine kleines Plugin verpackt, welches ich hier zum Download anbiete: 123 Check URL Para Version 0.11

Das war’s, mehr wird nicht benötigt. Probleme könnte es nur geben, falls Plugins oder Themes URL-Parameter verwenden, die nicht in WordPress registriert wurden. Das ist dann aber schlecht programmiert. E sgibt jetzt im Plugin-Quelltext weitere erlaubte Parameter einzutragen:

$para = array( 'p1', 'p2', 'p3' );  // zusätzlich erlaubte URL-Parameter

Einfach die erlaubten Parameter im array wie im Beispiel oben eintragen.

5 Kommentare »

Geschwindigkeit und Sichertheit – https geht auch schnell

Sicher ist sicher

Vor gut sechs Wochen habe ich meine putzlowitsch.de-Website auf https umgestellt.
Das SSL-Zertifikat ist schon immer in meinem Webhosting-Paket bei All-Inkl im Preis enthalten. Nun habe ich es endlich aktiviert.

Putzlowitsch mit Comodo-SSL Zertifikat

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von “AddTrust External CA Root” zurückgeht.

Ein technisch bedingter Nebeneffekt ist, daß meine Putzlowitsch-Domain auch eine eigene IP-Adresse bekommen hat, da All-Inkl nicht wie Strato das SNI-Verfahren verwendet. Im Unterschied zu 1&1, wo bei aktivem SSL das gesamte Webhosting-Paket eine gesonderte IP-Adresse erhält, ist es bei All-Inkl aber nur die per SSL gesicherte Domain.

Für Google eine neue Web-Site

Obwohl ich die Nicht-SSL-Version meiner Putzlowitsch-Seiten per 301-Redirect auf die https-Version weiterleite, ist es für Google erstmal eine neue Website. Erwartungsgemäß war der Google-Bot kurz nach der Umstellung auf meinen Seiten sehr aktiv.

Gut zu sehen ist das in den Google-Webmaster-Tools unter „Crawling-Statistiken“:

Pro Tag gecrawlte Seiten
Pro Tag gecrawlte Seiten

Waren es vorher ungefähr 500 bis 1500 Seiten am Tag, gab es kurz nach der Umstellung einen Spitzenwert von fast 7500 Seiten.

Pro Tag heruntergeladene Kilobyte
Pro Tag heruntergeladene Kilobyte

Entsprechend zeigt sich das auch bei der durch den Google-Bot heruntergeladenen Datenmenge.

Die eigentlich spannende Frage ist aber die nach der Gewschwindigkeit

Sicher muß nicht langsamer sein

Nachdem meine Schnurpsel-Seite hier durch die https-Umstellung einen merk- und meßbaren Geschwindigkeitverlust erlitten hat, war ich gespannt, ob sich das bei All-Inkl ähnlich darstellt.

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt auch bei All-Inkl natürlich Rechenzeit. Nach der Umstellung fühlte sich die Seite nicht langsamer an. Und wie schnell werden die Seiten für den Google-Bot ausgeliefert?

Hierzu habe ich wieder einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Dauer des Herunterladens einer Seite (in Millisekunden)
Dauer des Herunterladens einer Seite (in Millisekunden)

Größere Schwankungen bei der Ladezeit gab es seit Anfang Oktober, warum auch immer, bereits vor der HTTPS-Umstellung. Danach ist für mich zumindest keine signifikanter Anstieg zu erkennen. Die Werte schwanken im Bereich von 500 bis 1100 Milliskunden.

„Gefühl“ und Meßwerte zeigen, die Seite ist durch SSL-verschlüsselte Auslieferung nicht wirklich langsamer geworden.

Noch schneller

In der Ladezeit-Grafik ist ab dem 26. November ein interessanter Kurvenverlauf zu sehen. Die Zeiten für die Auslieferung der Seiten an den Google-Bot liegen seitdem fast konstant bei knapp unter 300 ms. Was ist passiert?

Mein Webhostingpaket bei All-Inkl liegt nun schon seit mehreren Jahren auf einem Server, der mittlerweile nicht mehr der schnellst ist. Ein großer Nachteil war aus meiner Sicht, das dort nur die veraltete PHP-Version 5.2 als Standard lief. Man kann zwar per .htaccess die PHP-Version ändern, aber dann läuft PHP nicht mehr als Apache-Modul, sondern als FastCGI im Kontext des FTP-Benutzers. Genau das wollte ich aber nicht.

Die einzige Möglichkeit, eine aktuelle PHP-Version (5.6) als mod_php zu bekommen, ist der Umzug auf einen anderen Server, bei dem das neue PHP als Standard läuft.

Gesagt, getan. Am Abend des 25.11. habe ich meinen Wunsch dem Support vorgetragen und wurde noch direkt in die nächtlichen Updates und Umzüge eingetaktet. Am nächsten morgen war alles erledigt und meine Websites liefen mit PHP 5.6.

Und nicht nur das, sie waren sogar spürbar (und meßbar, siehe oben) schneller.

SSL muß nicht langsam sein

Putzlowitsch Chrome-Timeline

Alles in allem bin ich mit der HTTPS-Umstellung bei All-Inkl für meine „Putzlowitscher Zeitung“ sehr zufrieden. Ob und was es sonst nocht bringt, werde ich sehen. Technisch gesehen und von der Geschwindigleit her war es in jedem Fall ein Erfolg. :-)

3 Kommentare »

Geschwindigkeit vs. Sichertheit – https bremst Seite aus

Sicher ist sicher

Vor gut einem Monat habe ich meine schnurpsel.de-Website auf https umgestellt. Für das Shared-Webhosting bietet Strato zu einem monatlichen Preis von 2,99 Euro ein einfaches Single-Domain-Zertifikat an, welches ich nun hier auch nutze.

Schnurpsel mit Strato-SSL

Schnurpsel mit Strato-SSL

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. So weit, so gut.

Sicher ist langsamer

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt natürlich Rechenzeit. Die ersten Test der auf https umgestellten Domain bestätigten das auch. Die Seiten werden merklich langsamer geladen. Aber wie langsam ist nun dieses Langsam, wenn es sogar merkbar ist?

Hierzu habe ich einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Google-Webmastertools: schnurpsel.de mit https

Google-Webmastertools: schnurpsel.de mit https

Vor der Umstellung lag die Ladezeit zwischen 0,5 und 1 Sekunde. Das ist sicher kein Spitzenwert, aber durchaus akzeptabel. Nach der Umstellung bewegt sich die Zeit im Bereich von 1,5 bis 2 Sekunden, eine merkliche Verschlechterung.

Die Zeitfresser

Die konkreten Ladezeiten habe ich mir in den Entwicklertools von Chrome angesehen. Die Timeline und die „Resource network timing“ gibt Aufschluß darüber, wie lange etwas beim Aufruf einer Seite dauert.

Da ich keine „Meßwerte“ für schnurpsel.de aus der Zeit vor der https-Umstellung besitze, habe ich die Werte für ein Testblog, auch bei Strato gehostet, als Vergleich herangezogen.

Strato ohne https

Strato ohne https

Die Timeline für schnurpsel.de sieht so aus:

Strato mit https

Die Zeiten für „Blocking“ und „DNS Lookup“ haben nichts mit dem Webserver selbst zu tun und liegen im normalen Rahmen.

Interessant wird es dann beim „Connecting„, der Zeit für den Verbindungsaufbau mit dem Server auf der Netzwerkebene (TCP) und eben auch für die erste SSL-Aushandlung. Die Zeit hat sich von etwa 30 ms ohne SSL auf fast 300 ms mit SSL mal eben verzehnfacht.

Die „SSL„-Zeit gibt es ohne https natürlich nicht. Hier wird die verschlüsselte Verbindung mit dem Schlüsselaustausch, Prüfung des Zertifikates usw. abschließend ausgehandelt. Das schlägt noch einmal mit mindestens 250 ms zu Buche.

Die Zeit für das Senden („Sending“) kann man praktisch vernachlässigen, sie liegt immer im Bereich von wenigen Millisekunden.

Die Wartezeit („Waitung“) ist die Zeit die vergeht, bis nach dem Senden der Anforderung (Request) die Antwort (Response) beim Browser eintrifft. Für WordPress ist es die Zeit, die benötigt wird, um die Seite zu erstellen, also Laden von WordPress, der Plugins und des Themes, Datenbankabfragen, Erzeugen der Ausgabe usw. Die Zeit liegt bei der Schnurpsel-Seite höher als bei der Testseite, weil einfach viel mehr Daten zu verarbeiten sind. Die Testinstallation ist praktisch eine leere WP-Seite.

Zu guter Letzt müssen die Daten vom Server zum Browser übertragen werden, was der „Receiving“-Zeit entspricht. Auch hier dauert es bei Schnurpsel Erwartungsgemäß länger, weil mehr Daten zu übertragen sind.

Langsames SSL bei Strato

Die zusätzliche Zeit von 550 ms (300 ms + 250 ms) paßt ganz gut zu dem, was in den Webmastertools von Google angezeigt wird. Wobei das eher die Untergrenze darstellt, die Verlängerung der Ladezeit durch SSL kann auch höher ausfallen.

Srato mit https (700 ms)

Srato mit https (700 ms)

Letztendlich stellt sich mir nun die Frage, was besser oder schlechter ist. Die deutlich merkbar längere Ladezeit spricht gegen https, das mehr an Sicherheit, verbunden mit größerem Vertrauen und „Professionalität“, aber dafür.

Ich werde bei https bleiben und hoffe einfach, daß Strato da irgendwie noch was an der Geschwindigkeit verbesserm kann. Bei anderen Sachen haben sie es ja früher oder stäter auch geschafft. :-)

12 Kommentare »

Strato-AppWizard verhindert WordPress-Update, so geht es trotzdem

WordPress mit wenigen Klicks installieren

Sie sind ja ganz nett, diese Ein-Klick-Installationen bei den großen Webhostern wie 1&1 (Click&Build), Host Europe (Webanwendungen) und Strato (AppWizard). Mit wenigen Klicks kann man im Konfigurationsbereich des Hostingpaketes ein komplettes WordPress installieren. Man muß sich nicht um die Einrichtung von Datenbanken, die Anpassung der wp-config.php-Datei und den Upload per FTP kümmern.

Leider haben diese Installationen auch Nachteile. Bei Strato soll man das WP-Update per AppWizard durchführen. Schlecht ist es nur, wenn gar kein Update oder nur die kleinen Updates angeboten werden.

Strato AppWizard WP-Update

Für die älteren Versionen gibt es nur die kleinen Updates (3.0→3.0.4, 3.5.1→3.5.2) und bei 3.8 sieht es ganz schlecht aus. Vermutlich ist auch gar kein Updated er Hauptversion, also z.B. von 3.8 auf 3.9 oder 4.0 vorgesehen.

Kein Update möglich

Normalerweise ist es ja kein Problem, das Update direkt im Adminbereich von WordPress durchzuführen. Nur leider wird diese Möglichkeit von den 1-Klick-Paketen schlicht und ergreifend ausgeknipst, ist nicht vorhanden.

Strato-AppWizard - kein WP-Update

Nun habe ich mich auf die Suche begeben, an welcher Stelle denn das Update wegkonfiguriert wird. Fündig wurde ich in der Datei wp-includes/capabilities.php. Dort gibt es Funktionen mit denen Abgefragt werden kann, welche Rechte ein angemeldeter Nutzer hat, also was er alles im Adminbereich tun darf.

So sieht dort eine Funktion im StratoAppWizard-Paket aus:

function current_user_can( $capability ) {
	$current_user = wp_get_current_user();

	if ( empty( $current_user ) )
		return false;

	$args = array_slice( func_get_args(), 1 );
	$args = array_merge( array( $capability ), $args );

	if ( $capability == 'update_core' ) { return false;	} else { return call_user_func_array( array( $current_user, 'has_cap' ), $args ); }
}

Die Frage, ob der aktuelle Nutzer WordPress updaten darf (‚update_core‘), wird in der letzten Zeile immer mit false beantwortet. Es darf als niemand, es wird gar nicht erst geprüft, ab man als Admin dieses Recht hat. Nö, die Funktion sagt immer nein.

WP-Update wieder hervorzaubern

Entsprechend simpel ist die Lösung des Update-Problems. Man muß einfach die originale Funktion wieder herstellen. Das geht einfach mit einem FTP-Programme oder auch mit dem Strato Web-FTP.

Wir wechseln in das Verzeichnis /WordPress_01/wp-includes/, wobei die Nummer am Ende die laufende Nummer der AppWizard-Installation ist.

Strato Web-FTP capabilities.php

Dort finden wir die Datei capabilities.php und direkt darunter eine capabilities.php.bak.1387242074, ggf. mit einer anderen Zahl am Ende. Das ist die nicht manipulierte, originale WordPress-Datei. Genau die brauchen wir.

Nun können wir einfach zuerst die capabilities.php in capabilities.php.strato umbenennen und anschließen die capabilities.php.bak.1387242074 in capabilities.php.

Das Umbenennen geht im Strato-WebFTP mit der rechten Maustaste auf der Datei.

Strato Web-FTP - Datzei umbenennen

Das wars auch schon, im Adminbereich sollte nun das Update auf die neue WP-Version angeboten werden.

Getestet habe ich das nur mit der Version 3.8, bei den älteren Versionen könntes aber prinzipiell genauso funktionieren.

WP Version 3.2.x und 3.4.x

Bei WordPress Version 3.2.x und 3.4.x hat Strato das Core-Update an einer anderen Stelle ausgeschaltet (Veränderung in der Datei /wp-include/update.php). Es wäre aber zu aufwändig, diese Änderungen rückgängig zu machen.

Strato AppWizard WP-Update 3.5.1

Als Ausweg bleibt hier das schrittweise Update im Strato-AppWizard bis zur WordPress-Version 3.5.1-4. Bei dieser Version ist das Update nicht gesperrt und damit dann direkt im WP-Backend möglich.

Strato auf die Sprünge helfen

Es ist ja nun nicht das erste Mal, daß ich eine Strato-Problem bzw. -Fehler ausbügeln muß. Wenn ich da so an das www/ohne-www Problem oder die Sache mit der Remote-Adresse denke. Das früher fehlende mod_rewrite will ich gar nicht erst an die große Glocke hängen.

Wie auch immer, ich hoffe, daß ich dem einen oder anderen leidgeplagten Strato-User ein bißchen helfen konnte. Dann hat es sich doch schon gelohnt. :-)

39 Kommentare »

Das RaketenSEO-Ranking im Blog mit meinem Plugin einbinden

Gestern hatte ich ja bereits die maschinenlesbaren Daten von aus.gerech.net vorgestellt. Ihr könnt diese Daten selbst nutzen und auswerten (wenn Ihr es könnt :-). Oder Ihr benutzt einfach mein WordPress-Plugin, das ich hier kurz vorstellen will.

Raketenseo Top-100 Liste

123 Top-100 Plugin

Das Plugin besteht im wesentlichen aus zwei Funktionen.

Die erste Funktion agn_top100_read_data ist für das Abholen der Daten im JSON-Format zuständig. Hier habe ich etwas mehr Aufwand betrieben, um unnötige Requests und Datenübertragungen zu vermeiden. Die Daten werden lokal auf dem Server der WordPress-Installation im Verzeichnis wp-content/uploads gespeichert. Dieses muß daher von WordPress beschreibbar sein, damit das Caching funktioniert.

Die zweite Funktion agn_top100_shortcode implementiert einen WordPress-Shortcode, mit dem man sich die gewünschten Daten im Artikel oder auf der Seite ausgeben lassen kann.

Im einfachsten Fall sieht das dann so aus:
...
Hier findet ihr die aktuelle RaketenSEO Top-100:
<table class='chart-list'>[agn_top100 nam='raketenseo']</table>
...

Per Voreinstellung wird die Liste als Tabelle ausgegeben, allerdings ohne Table-Tags. Die müßt Ihr selbst drumrum packen. Das hat den Vorteil, daß Ihr der Tabelle einfach eine CSS-Klasse oder sonstige Formatierungen mitgeben könnt.

In der Voreinstellung ergibt sich damit eine Tabelle wie auf dieser Beispielseite (ohne Grafik). Die Platzierung wird einfach durchnummeriert, vor der URL steht ggf. ein Symbol für den Ergebnistyp, hinter der URL folgt ein Link-Symbol mit einem (nofollow!) Link zur Seite. URLs, die Länger als 70 Zeichen sind, werden am Ende mit … verkürzt.

Über Shortcode-Parameter kann die Ausgabe angepaßt werden. Folgende Einstellungen sind möglich:

  • nam – Name der Daten
    Vorgabe: ‚xovilichter‚, hier also raketenseo eintragen :-)
  • ret – Was soll der Shortcode zurückgeben?
    Vorgabe: ‚rnk‚, mögliche Werte

    • rnk – Ranking Tabelle/Liste (siehe lit)
    • upd – Datum und Zeit des letzten Updates (siehe dtf)
    • cnt – Anzahl der gefundenen Treffer insgesamt
  • max – Maximal Anzahl auszugebender Treffer
    Vorgabe: ‚100‚, eine Zahl zwischen 1 und 123
  • dtf – Ausgabeformat des letzten Updates (siehe ret:upd)
    Vorgabe: ‚‚d.m.Y H:i‘‚, Format entsprechend PHP-Date-Funktion
  • lit – Listentyp: Tabelle oder Liste?
    Vorgabe: ‚tab‚, mögliche Werte

    • tab – Tabelle (table)
    • lst – Liste (ol)
  • cut – Anzahl Zeichen, ab der eine URL verkürzt wird
    Vorgabe: ‚70‚, eine Zahl zwischen 0 (keine Verkürzung) und größer
  • sym – Typ-Symbol vor der URL anzeigen
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden
  • lnk – Link am Ende der URL ausgeben
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden

Hier ein paar Beispiele:
...
<ol>[agn_top100 nam='raketenseo' max='33' lit='lst' sym='0']</ol>
...

Gibt maximal 33 Einträge als HTML-Liste (OL) ohne vorangestelltem Typ-Symbol aus.

...
Top-100 vom [agn_top100 nam='raketenseo' ret='upd' dtf='l, d.m.Y H:i'] Uhr
...

Gibt den Zeitpunkt des letzten Updates formatiert aus.

Technische Voraussetzungen und Download

Technische Voraussetzungen:

  • WordPress 3.8 oder höher
  • PHP 5.2 oder höher mit curl-Funktion
  • Verzeichnis wp-content/uploads muß von WordPress beschreibbar sein

Download Version 0.14: 123 Top-100 Plugin

Falls es Unklarheiten oder Fragen gibt, einfach fragen. :-)

Keine Kommentare »