Google Analytics Code in WordPress Preview deaktivieren

Kurz, knackig und unheimlich praktisch, wenn man während des Schreibens eines Blog-Posts öfter mal den Preview Button in WordPress bemüht. Die Vorschau fließt üblicherweise – wie alle anderen Seiten auch – in die Webstatistik ein und verfälscht somit etwas euer Zahlenwerk. Wer es also genau nehmen möchte, kann mit diesem kleinen Snippet die Ausgabe des Google Analytics Codes im Preview von WordPress unterbinden:

<!--?php 
    if( !is_preview()) { ?-->
    <!-- Google Analytics Code -->
<!--?php } ?-->

Dieses und weitere brauchbare WordPress-Snippets findet ihr übrigens auf WP-Snippets.

Wunderwaffe SET NAMES, SET CHARACTER SET

Nur zwei eine Zeilen Code genügt, um Herr über das Chaos der Zeichencodierung eines PHP-MySQL-Projektes zu werden. Falls jemand von euch auch mal vor dem Problem stehen sollte, dass Umlaute trotz aller Experimente die „Datenbank-Kollation“ und „charset“ auf UTF-8 umzustellen nicht wie gewünscht dargestellt bzw. abgelegt werden, dann spart euch erstmal den Versuch durch wildes Ersetzen der „krummen“ Zeichen das Problem in den Griff zu bekommen. Versucht erst einmal folgende zwei Zeilen Code in eure Datenbank-Verbindung einzutragen:

mysql_query("SET NAMES 'utf8'");

UPDATE: Im Gesamtzusammenhang könnte die Datenbankverbindung dann so aussehen:

$con = mysql_connect("localhost","user","password");
 
if (!$con) {
  die('Could not connect: ' . mysql_error());
}
 
mysql_select_db("database", $con);
mysql_query("SET NAMES 'utf8'");
// mysql_query("SET CHARACTER SET 'utf8'");

Bei meinem Problem hat es Wunder gewirkt. Warum bin ich nicht schon viel früher darauf gestoßen? Hier noch der Link zur offiziellen Doku  SET NAMES, SET CHARACTER SET P.S. Danke an Oliver, damit hat sich der Aufwand nochmals um eine Zeile reduziert 🙂

301 redirects für URLs mit Parameter

Über htaccess und speziell über 301 Redirects ist vor allem im Zusammenhang mit Suchmaschinenoptimierung bereits viel geschrieben worden. In der Regel findet man für die meisten alltäglichen Problemstellungen auch eine passende Lösung.

Das Problem mit den Parametern in den URLs

Im Verlauf einer Suchmaschinenoptimierung für ein Seite die auf Typo3 Basis erstellt wurde, stieß ich auf ein Problem, das im Zusammenhang mit Typo3 in vielen Fällen zu beobachten ist. Den URLs wurde beim Aufsetzen des Projektes keine Beachtung geschenkt und Extensions wie das sehr verbreitete RealURL oder CoolURI waren nicht im Einsatz. Die URLs sahen beispielsweise so aus: http://www.domain.de/index.php?id=66 Seiten wurden nicht anhand des Seitennamens (index.php oder produkte.php) aufgerufen und eindeutig gekennzeichnet, sondern über den Parameter (z.B. ?id=66 -> Startseite, ?id=produkte -> Produktübersicht). Nach Installation und Konfiguration der RealURL Extension wurden zwar die URLs in „sprechende URLs“ umgewandelt, jedoch waren die Seiten über die alten Adressen direkt oder über die Suchergebnisse in Google weiterhin aufrufbar. Um die so entstandene Duplicate-Content-Problematik zu beheben, mussten Weiterleitungen geschaffen werden, die Rücksicht auf die Parameter nehmen und die passende neue Seite aufrufen. Die Standard Weiterleitung in den meisten Erklärungen zum Thema 301 Redirects sieht vor, die Seiten z.B. wie folgt weiterzuleiten:
RewriteEngine on
Redirect 301 /index.php http://www.domain.de/produkte.php
oder das passendere Beispiel mit Parameter
RewriteRule ^index.php?id=(.*)$ /produkte.php [L,R=301]
In unserem Falle hätte dies jedoch lediglich dazu geführt, dass ALLE Seiten die gleiche Zieladresse nämlich http://www.domain.de/produkte.php aufgerufen hätten, unbeeindruck von dem für uns wichtigen ID-Parameter, der eine Zuordnung zu einer dezidierten Unterseite ermöglicht.

Die Lösung

Die Lösung für das Problem einen 301 Redirect für URLs mit Parameter zu schaffen, kann so aussehen:
RewriteCond %{query_STRING} ^id=166(.*)$
RewriteRule ^index\.php$ http://www.domain.de/produkte.php? [R=301,L]
  • RewriteCond definiert zunächst die Bedingung für eine Umleitung.
  • Die Variable $query_STRING enthält den Parameter, also den gesamten Teil nach dem ?-Zeichen, der definiert wird durch den Inhalt zwischen dem Start-String ^ und dem Ende-String, der durch $ markiert wird. In unserem Beispiel demnach id=166 und andere willkürliche Parameter oder Zeichenketten die noch folgen könnten mit Hilfe von (.*). Im Falle von Typo3 z.B. der Parameter „no_cache=1“. http://www.domain.de/index.php?id=66&no_cache=1
  • RewriteRule definiert die Umleitung, wenn die o.g. Bedingung erfüllt ist, nämlich eine URL mit dem Parameter id=66.
  • Start und Ende werden wieder über ^ und $ definiert und leiten dann die index.php an die gewünschte Adresse http://www.domain.de/produkte.php mit einem 301 Redirect weiter.
Sollte es wie in unserem Fall nicht nur Duplicate Content Probleme aufgrund von kryptischen URLs und sprechenden URLs geben, sondern auch der Fall auftreten, dass mehrer IDs auf die gleiche Seite führen, kann die Bedingung mit dem „|“ als „Oder“ erweitert werden. Im nachfolgenden Beispiel gilt also: Wenn die Bedingung id=lorem ODER id=165 usw. in der URL erfüllt ist, wende die RewriteRule an.
RewriteCond %{query_STRING} ^(id=lorem)|(id=165)|(id=219)|(id=ipsum)(.*)$
RewriteRule ^index\.php$ http://www.domain.de/lorem.html? [R=301,L]
Eine Adresse wie http://www.domain.de/?id=66 kann wie folgt redirected werden:
RewriteCond %{query_STRING} ^(id=66)(.*)$
RewriteRule ^$ http://www.domain.de/ipsum.html? [R=301,L]
Dass man sich viel Arbeit ersparen kann wenn man zum GoLive eine anständige URL-Struktur vorweisen kann wird spätestens hier klar. Soweit fürs Erste. Viel Spass beim Aufräumen…