Das Putzlowitsch Test- und SEO-Blog

Direkte Bild-Aufrufe auf Seite weiterleiten – so gehts

Das Problem

In den letzten Tagen ist die Aufregung ob der neuen Google-Bildersuche recht groß und viele versuchen, einen Ausweg aus den sinkenden Besucherzahlen zu finden.

In der neuen Bildersuche werden die Bilder direkt in Original-Auflösung auf der Ergebnisseite geladen. Der Nutzer hat also wenig Anlaß, die Ursprungsseite zu besuchen.

Google-Bildersuche: Links

Google-Bildersuche: Links zu Seite/Bilder

Immerhin gibt es vier Links (grün), die den Benutzer auf die Ursprungsseite mit dem Bild führen. Dazu kommt ein Link direkt zum Bild [Bild ansehen] und indirekt die Möglichkeit, per Rechtsklick und „Grafik anzeigen“ nur das Bild aufzurufen.

Der direkte Link zum Bild bringt allerdings keine Besucher auf die Seite. Daher gibt es die Idee, den direkten Aufruf eines Bildes aus der Bildersuche auf eine Seite mit dem Bild umzuleiten.

Achtung!
Lest bitte vorher die Hinweise von Google zu „Bilder-Cloaking“ und überlegt Euch, ob Ihr das Riskio eingehen wollt.

So gehts

Um zu erkennen, ob jemand von der Bildersuche kommt, kann man den Referrer auswerten. Vereinfacht gesagt, könnte man folgende Regel formulieren:

„Ist die Referrer-Domain google.* und die angeforderte Datei ein Bild (jpeg,png,…), dann leite den Nutzer auf eine Seite mit dem Bild um.“

In der .htaccess könnte das so aussehen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond	%{REQUEST_FILENAME} -f
RewriteCond	%{HTTP_REFERER}	^http(s)?://(www\.)?google [NC]
RewriteRule	\.(jpg|png|gif)$	/redirect.php	[L]
</IfModule>

Zunächst wird Rewrite eingeschaltet und die Basis festgelgt.
Dann wird geprüft, ob es die angeforderte Datei überhaupt gibt und ob der Referrer Google ist. Falls ja und die Datei ein Bild ist, wird das PHP-Skript zur Weiterleitung aufgerufen.

So weit, so gut, nur gibt es noch einige Probleme zu lösen.

Leider wird der Referrer auch gesendet, wenn das Bild als Bild auf der Google-Seite geladen wird. Da soll natürlich keine Weiterleitung erfolgen, weil das im Kontext eines Bilder zu einem Fehler führt. Kann man also unterscheiden, ob das Bild geladen wird oder ein Link auf das Bild aufgerufen wird? Ja, mann kann. Zumindest meistens.

Außerdem wird ein bereits geladenes Bild vom Browser im Cache vorgehalten, was zu unvorhergesehenen Ergebnissen bei der Weiterleitung führen kann. Kann man das verhindern? Ja, man kann.

Meine Problemlösungen

Als technische Basis setze ich einen Apache-Server mit den aktiven Modulen mod_rewrite, mod_headers und mod_setenvif voraus. Wobei das Modul mod_setenvif nicht zwingend erforderlich ist, es macht die Sache aber übersichtlicher:

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /bilder

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]
</IfModule>

Zur Unterscheidung von Bildaufruf (img src=…) und Link verwende ich den Wert von „Accept“ im HTTP-Request-Header. Nach meiner Beobachtung enthält dieses Header-Feld bei Bild-Aufrufen nicht den Typ „text/html“, beim Aufruf von Links, auch zu Bildern, aber schon. Wenn also „text/html“ im Accept-Header zu finden ist, dürfte es sich um den Link zum Bild und nicht um das Laden des Bildes in der Google-Ansicht handeln.

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

Den Accept-Header werte ich in einer SetEnvIf Anweisung aus und setze eine entsprechende Variable, die ich später in den Rewrite-Regeln auswerten kann. Zudem extrahiere ich in dem Block den Domain-Namen aus dem Referer, da ich diesen auch in anderen Rewrite-Regeln benötige.

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

Mit den Rewrite-Regeln prüfe ich zunächst die Existenz der Datei und über die Datei-Erweiterung, ob ein Bild aufgerufen wird. Falls nicht, wir der zweite Block der Rewrite-Regeln gar nicht erst ausgeführt.

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

Im zweiten Block wird eine Liste von Referrer-Domains abgearbeitet, für die die Weiterleitung erfolgen soll. In dem Fall sind es die drei Google-Domains, von denen die meisten meiner Besucher kommen (exemple.com ist nur ein Platzhalter). Die Abfrage nach dem Referer kann man natürlich auch anders gestalten. Das hängt halt davon ab, was man damit erreichen will. Hier setze ich mir wieder ein Flag (DO_RDR), das ich später für die Weiterleitung auswerte.

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

Außerdem setze ich einen Wert (NO_CACHE), mit dem am Ende geprüft wird, ob das Caching deaktiviert werden soll. Der Block mod_headers steht zwar am Anfang, der Webserver führt diese Anweisungen aber erst ganz zum Schluß aus, kurz bevor die Antwort an den Client gesendet wir. Damit wird das Caching des von Google direkt geladenen Bildes verhinert.

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]

Im dritten Rewrite-Block erfolgt dann die Weiterleitung, falls es sich um einen Link-Request (REQ_HTML) handelt und eine Weiterleitung überhaupt ausgeführt werden soll (DO_RDR).

Wohin weiterleiten?

Ein weiteres Problem kann die eigentliche Weiterleitung sein. Wohin soll die Reise gehen?

Im Beispiel ist das relativ einfach. Die Bilder liegen in einem Unterverzeichnis /bilder/ und der Dateinamen besteht aus Bezeichnung und laufender Nummer. Die Zielseiten mit den Bildern bestehen auch aus Bezeichnung und laufender Nummer. Damit läßt sich schon in der .htaccess Datei die Weiterleitungsregel unmittelbar formulieren.

/bilder/tomaten-7.jpg -> /bild-tomaten-7.html
/bilder/banane-23.jpg -> /bild-banane-23.html
...

Schön, wenn man so eine klare Struktur für seine Bilder hat. Ich habe die leider nicht. :-)

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	.*	/rdr.php	[L]

Also muß die Weiterleitung z.B. von einem PHP-Skript erledigt werden, in dem man dann praktisch beliebige Weiterleitunsziele adressieren kann.

In WordPress gibt es für die über die Mediathek hochgeladenen Bilder jeweils eine Attachment-Seite. Nun könnte man sich die Informationen zum Weiterleitungsziel aus der WP-Datenbank holen. Aus Performance-Gründen habe ich da einen etwas anderen Weg gewählt.

Für WordPress, wie z.B. hier bei schnurpsel.de, sieht das rdr.php-Skript so aus:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
@include( THISPATH.'redir.php' );

function set_404() {
	header( "HTTP/1.0 404 Not Found", true, 404 );
	echo <<<EOT
<!DOCTYPE html>
<html>
<head><title>404 Not Found</title></head>
<body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
EOT;
	exit;
}

function set_header( $ctype ) {
	@header( "Content-type: $ctype" );
	@header( 'Cache-Control: no-cache' );
	@header( 'Cache-Control: max-age=0', false ); 
	@header( 'Expires:'.gmdate('D, d M Y H:i:s', 0 ).' GMT' );
}

function redirect( $url, $status = 302 ) {
	@header( 'Cache-Control: no-cache, no-store, must-revalidate' );
	@header( "Location: $url", true, $status );
	exit();
}

$img_uri = urldecode( $_SERVER['REQUEST_URI'] );
$redir_url = $redir_b[$img_uri];

if( !$redir_url && @preg_match( '~(.+?)-(1600|1200)\.(jpg|png|gif)$~', $img_uri, $treffer ) ) {
	$redir_url = $redir_b[$treffer[1].'.'.$treffer[3]];
}

if( $redir_url )
	redirect( $redir_url );
else {
	$img_file = THISPATH.$img_uri;
	$img_size = @getimagesize( $img_file );
	if( $img_size ) {
		set_header( $img_size['mime'] );
		@readfile( $img_file );
		exit;
	}
}
set_404();
?>

Download: rdr.zip

In meinem rdr-Skript includiere ich eine weitere PHP-Datei (redir.php), die nur ein Array mit den Weiterleitungszielen für die Bilder enthält. Falls kein Weiterleitungsziel gefunden wird, gebe ich einfach das Bild selbst aus.

Die redir.php PHP-Datei lasse ich mir von einem Skript durch WordPress erstellen:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
define( 'WP_USE_THEMES', false );
define( 'USE_ATTACHMENT_URL', true );

@include( THISPATH.'redir.php' );

require('./wp-blog-header.php');

echo '<pre>';

$args = array( 'post_type' => 'attachment', 'posts_per_page' => -1, 'post_mime_type' => 'image', 'post_parent' => null ); 
$attachments = get_posts( $args );
if ( $attachments ) {
	foreach ( $attachments as $post ) {
		$attachment_url = wp_get_attachment_url( $post->ID );
		$attachment_uri = @parse_url( $attachment_url, PHP_URL_PATH );
		if( USE_ATTACHMENT_URL )
			$page = get_attachment_link( $post->ID );
		else
			$page = get_permalink( $post->post_parent );
		if( $page && $attachment_uri && !$redir_b[$attachment_uri] ) {
			if( strpos( $page, 'attachment_id' ) === false ) {
				$redir_b[$attachment_uri] = $page;
				echo "+ $attachment_uri -> $page\r\n";
			}
			else
				echo "- $attachment_uri -> $page\r\n";
		}
		else
			echo "* $attachment_uri -> $page\r\n";
	}
}

$export_data = "<?php\r\n\$redir_b = ";
$export_data .= var_export( $redir_b, true );
$export_data .= ";\r\n\r\n?>";
file_put_contents( THISPATH.'new_redir.php', $export_data );
echo '</pre>';
?>

Download: get-redir.zip

Mit der Konstante ‚USE_ATTACHMENT_URL‘ wird festgelegt, ob die Weiterleitung auf die Attachment-Seite (true) oder zur Artikel-Seite mit dem Bild (false) erfolgen soll.

Zum Anfang wird die bestehende ‚redir.php‘ geladen. Es werden dann nur Einträge hinzugefügt, die es noch nicht gibt.

Außerdem prüfe ich, ob es die Attachment-Seite wirklich gibt, denn für Bilder ohne Eltern-Seite bzw. Bilder in nicht veröffentlichten Artikeln wird kein Permalink zurückgeliefert, sonder nur die URL mit dem ‚attachment_id‘-Parameter.

Am Ende wird eine neue Datei ’new_redir.php‘ geschrieben, mit der man dann die alte ‚redir.php‘ ersetzen kann.

Folgende Dateien sind an der Methode beteiligt:
/rdr.php
/redir.php
/wp-content/uploads/.htaccess

In der .htaccess-Datei muß die RewriteBase entsprechend angepaßt werden:

RewriteBase /wp-content/upload

Für meine Putzlowitscher Zeitung enthält das Array etwas mehr als 2000 Einträge. Das ergibt eine Dateigröße von ca. 350k. Wer deutlich mehr Bilder in WP verwaltet, muß sich ggf. etwas anderes einfallen lasse.

So ein Array hat aber den Vorteil, daß ich darin auch beliebige, andere Weiterleitungsziele definieren kann.

Noch ein paar Tips und Hinweise

Falls sich alle Eure Bilder in einem Unterverzechnis befinden, bei WordPress z.B. /wp-content/uploads/, dann packt die .htaccess-Datei genau dort rein. Für alle anderen, normalen Seitenaufrufe wird sie dann gar nicht erst abgearbeitet.

Was irgendwie möglich ist, sollte schon in der .htaccess-Datei erledigt werden. Der Aufruf eines Skriptes, eventuell sogar mit Datenbankabfragen, kostet mehr Server-Leistung und verschlechtert die Performance.

Ihr könnt sogar unterscheiden, ob jemand den Button [Bild ansehen] angeklickt oder per Rechtsklick das Bild aufgerufen hat. Beim Rechtsklick wird ggf. vom Browser als Referer die komplette Google-Such-URL übermittelt. Das kann man zur Unterscheidung auswerten, z.B. ob der Parameter tbm=isch im Referer enthalten ist.

Das Speichern mit Rechtsklick auf das Original-Bild in der Bildersuche funktioniert nicht. Es wird die HTML-Seite des Weiterleitungs-Ziels gespeichert. :-)

Ich habe bisher nur mit wenigen Browsern getestet. Bei denen hat es aber funktionert, wie es soll.

Ich übernehme keine Haftung für Schäden, die möglicherweise durch die Umsetzung der hier vorgestellten Methoden entstehen.

14 Kommentare »

Für bestimmte Domains ein Ersatzbild anzeigen – meine Lösung

Die „neue“ Google-Bildersuche

Google-Bildersuche: Neues Layout in DE

Google-Bildersuche: Neues Layout in DE

In der „neuen“ Google-Bildersuche wird beim Klick auf ein Ergebnis das Bild direkt in der Bildersuche in voller Auflösung geladen und angezeigt. Das dürfte viele Nutzer davon abhalten, die Ursprungsseite zu besuchen.

Die Idee ist es, dem Nutzer innerhalb der Google-Bildersuche eine Bild in schlechter Qualität (unscharf/verpixel) mit einem zusätzlichen Hinweistext anzuzeigen.

Achtung!
Lest bitte vorher die Hinweise von Google zu „Bilder-Cloaking“ und überlegt Euch, ob Ihr das Riskio eingehen wollt.

Technische Basis

Um zu erkennen, ob das Bilder in der Google-Bildersuche angezeigt wird, muß der HTTP_REFERER ausgewertet werden. Das funktioniert aber nur, wenn die eigene Seite mit https läuf. Von einer Seite mit SSL (Google-Suche) wird kein Referrer zu einer Seite ohne SSL übermittelt.

Das Erstellen der veränderten Bilder erfolgt On-The-Fly per PHP-Skript. Die so erstellten Bilder werden zwischengespeichert und beim nächsten Aufruf dann ggf. direkt ausgeliefert. Damit fällt die nicht gerade ressourcenschonende Bildbearbeitung nur beim ersten Aufruf des Bildes an.

Die Umsetzung

In der .htaccess-Datei habe ich folgende Verzweigung eingebaut:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond	%{HTTP_REFERER}	^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/ [NC]
RewriteRule	.* - [E=DOM_REFERER:%1]

# Für bestimmte Ref-Domains verändertes Bild ausliefern
RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|png)$	-	[NC,C]
RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.	/geb/index.php	[L]
</IfModule>

Im ersten Block wird Rewrite eingeschaltet und die Basis festgelgt.

Im zweiten Block extrahiere ich den den Domainnamen aus dem Referrer und speichere ihn in einer Umgebungs-Variablen ab. Das vereinfacht die Bedingungen im nächsten Block.

Die eigentliche Verzweigung erfolgt im nächsten Block. Hier prüfe ich zunächst, ob es die angforderte Datei überhaupt gibt und ob es sich um ein Bild handelt. Falls nicht, werden die nachfolgenden Bedingungen gar nicht erst abgearbeitet.
In der folgenden Liste (Black-List) wird geprüft, ob für die Referrer-Domain ein verändertes Bild ausgeliefert werden soll. Falls ja, wird das PHP-Skript aufgerufen.

Das PHP-Skript befindet sich im Unterverzeichnis /geb/ als Index-Datei. Außerdem ist hier das Cache-Verzeichnis und der True-Type-Font für die Textausgabe mit GD enthalten:

/geb/
/geb/index.php
/geb/font.ttf
/geb/cache/
/geb/cache/.htaccess

Das Cache-Verzeichnis muß vom Webserver/PHP beschreibbar sein. Es wird mit einer .htaccess-Datei vor dirketen Zugriffen geschütz:

<Files *>
order deny,allow
deny from all
</Files>

Das PHP-Skript

Index.php

Im PHP-Skript habe ich z.Z. zwei Funktionen implementiert, die die Bilder verändern.

Eine Funktion (proc_gd) benutzt die GD-Erweiterung und erzeugt ein verpixeltes Bild. Für die Textausgabe wird unbedingt eine Font-Datei (font.ttf) benötigt.

Die andere Funktion (proc_imagick) benutzt die Imagick-Erweiterung, die bei vielen Webhostern aber nicht zum Standard gehört. Hier wird das Bild unscharf gemacht. Für die Textausgabe wird ein interner Font benutzt.

Keine 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 »

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 »

XoviLichter-Ranking für alle – Das WordPress-Plugin

Vor einigen Tagen hatte ich ja bereits die maschinenlesbaren Daten von aus.gerech.net vorgestellt. Dort hatte ich auch ein paar Zeilen PHP-Code für die Nutzung der Daten angekündigt. Nun sind aus den paar Zeilen doch eine WordPress-Plugin geworden, welches ich hier kurz vorstellen will.

Xovilichter 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 XoviLichter Top-100:
<table class='chart-list'>[agn_top100]</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‚, bei zukünftigen SEO-Wettbewerben etwas anderes :-)
  • 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 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 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. :-)

Weitere Artikel mit Bezug zu diesem:
7 Kommentare »