Das Putzlowitsch Test- und SEO-Blog
Thema: WP (Wordpress)

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 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.

13 Kommentare »

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 »

XoviLichter Shortcode im WordPress-Widget – so gehts

Vorvorgestern habe ich das XoviLichter-Ranking-Plugin für WordPress vorgestellt. Mit dem vom Plugin implementierten sogenannten Shortcode kann man die Top-Liste und weitere Informationen an beliebigen Stellen in Artikeln oder Seiten einbinden.

Man kann den Shortcode aber auch prima in einem einfachen Text-Widget verwenden, um z.B. ein XoviLichter-Top-20 in der Sidebar oder im Fußbereich der Seite anzuzeigen. Ein Beispiel habe ich mal auf meiner Bla-Fasel-Testseite im Footer in der Mitte eingefügt. Die Sache ist auch ganz einfach.

Xovilichter-Shortcode im Widget

Man zieht ein Text-Widget in den gewünschten Seitenbereich und befüllt Titel und Inhalt mit den entsprechenden Daten. Ins Textfeld kommt natürlich der Shortcode, eingerahmt z.B. von einer Ordered List (OL) und mit ein paar Parametern versehen:

<ol>[agn_top100 max='20' cut='27' lit='lst' typ='txt']</ol>

Der Paramater max legt die maximale Anzahl der auszugebenden Listeneinträge fest, hier also 20.

Durch cut=‘27‚ werden die Einträge nach 27 Zeichen mit … verkürzt. Das ist ein brauchbarer Wert für ein Footer-Widget im Theme „Twenty Eleven“. In der Sidebar muß der Wert kleiner sein (z.B. 19), weil die Widgets dort schmaler sind.

Mit dem Wert ‚lst‚ für lit (Listentyp) erfolgt die Ausgabe nicht als Tabelle, sondern als HTML-Liste.

Mit dem typ txt werden nur normale Suchtreffer (Text) ausgegeben, also keine Bildern, News oder Videos, die beim XoviLichter-Wettbewerb eh nicht gewertet werden.

Dem ol-Tag kann man noch eine Klasse mitgeben und so die Ausgabe einfach per CSS anpassen. Für die Darstellung der Symbole unter Windows sollte die passende Font-Familie angegeben werden. Ansonsten werden je nach Browser nur Kästchen angezeigt.

ol.top-20 .sym { font-family: "Segoe UI Symbol"; }

Bis hierhin ist alles kein Problem, aber jetzt kommt der kleine Haken an der Sache. Normalerweise interessiert sich die Shortcode-Funktionalität von WordPress nicht für die Texte in Widgets. Glücklicherweise kann man dem mit einer Zeile PHP-Code in der functions.php des Themes Abhilfe schaffen:

add_filter('widget_text', 'do_shortcode');

Damit wird WordPress veranlaßt, auch den Widget-Text durch die Shortcode-Verarbeitung zu schicken und alles ist prima.

Wie man den Zeitpunkt der letzten Aktualisierung in den Widget-Titel bekommt, findet Ihr bestimmt selbst raus.

Na dann, frohes Ranking! :-)

Xovilichter

0 Kommentare »

Ich will den alten Datei-Hochlader in WordPress zurück haben!

Bis zur Version 3.4 war die WordPress-Welt für mich noch in Ordnung.

Doch mit Version 3.5 wurde ein neuer Dialog zum Hochladen von Dateien installiert, der mir überhaupt nicht zusagt.

Das linke Bild zeigt den alten Dialog, das rechte den neuen.

Gut, es gibt nun eine hübsche Thumbnail-Übersicht, aber darunter leiden die Beschreibungs- und Beschriftungsfelder zum Bild. Sie sind einfach zu schmal.

Außerdem ist mir die Handhabung der neuen Galerie-Funktion zu umständlich. In der alten Version konnte ich einfach alle zum Artikel hochgeladenen Bilder als Galerie einfügen. Jetzt muß ich erst eine Galerie erstellen.

Ich weiß nicht, wie es Euch geht, mir zumindest hat der alte Medien-Dialog besser gefallen.

Kurz und gut, ich habe mich durch die WordPress-Dateien gewühlt und den alten Upload-Dialog wieder hervor geholt. Es war letztendlich einfacher, als ich dachte. Mit ein paar Zeilen PHP-Code kann man den guten alten Datei-Hochlader wieder ans Licht holen.

Diese paar Zeilen PHP habe ich in ein kleines Plugin verpackt, welches Ihr hier findet:
123 Old Uploader

Nun will ich mal hoffen, daß der Code für den alten Uploader von WordPress nicht entfernt wird, dann sähe es nämlich schlecht aus. Aber solange die Möglichkeit besteht, werde ich den alten Uploader nutzen.

1 Kommentar »

Bilder in der WordPress-Mediathek neu verknüpfen

Bilder und Artikel

Lädt man in WordPress Bilder direkt im Editor hoch, werden sie automatisch mit dem aktuell bearbeiteten Artikel bzw. der Seite verknüpft. Diese Bilder werden dann z.B. in der Worpdress-Galerie zu diesem Artikel angezeigt. Die Zuordnung eines Bildes zu einem Artikel ist normalerweise nicht änderbar. Auch wenn man ein Bild in einem oder mehreren anderen Artikeln verwendet bleibt die Eltern (Artikel) – Kind (Bild) – Beziehung bestehen.

Elternlose Bilder

Wird ein Bild in der Mediathek hochgeladen, ist es zunächst elternlos. In der Bilderliste steht dann in der Spalte „Verwendet in“ wie bei den Aprikosen nur „(Nirgendwo verwendet)“.

Wordpress-Mediathek: Funktionen für Bilder

Mit einem Klick auf „Verknüpfen“ kann man das Bild dann einem Artikel oder einer Seite zuweisen. Das Bild bekommt seine Eltern auch zugeteilt, wenn es erstmalig in einem Artikel oder einer Seite verwendet wird.

Bilder-Adoption

Manchmal kann es wünschenswert sein, ein Bild einem anderen Artikel zuzuordnen. Ein Weg ist, dieses direkt in der Datenbank zu erledigen. Dazu muß im Feld post_parent des Bildes die ID des gewünschten Artikels eintragen.

Einfacher ist es natürlich, wenn man die Zuweisung in der WordPress-Mediathek durchführen kann. Eine entsprechende Funtkion kann mit ein paar Zeilen PHP-Code nachgerüstet werden:

function plw123_add_attach( $actions, $post, $detached )
{
  if ( current_user_can( 'edit_post', $post->ID ) )
    $actions['attach'] = '<a href="#the-list" onclick="findPosts.open( \'media[]\',\''.$post->ID.'\' );return false;" class="hide-if-no-js">'.__( 'Attach' ).'</a>';
  return $actions;	
}
add_filter( 'media_row_actions', 'plw123_add_attach', 10, 3 );

Der PHP-Code kann z.B. in die Datei functions.php des Themes eingetragen werden.

Der Link „Verknüpfen“ wird dann für jedes Bild bei den Funktionen angezeigt, die beim Überfahren einer Mediathekzeile mit der Maus eingeblendet werden (Beispiel Kamera):

Wordpress-Mediathek: Funktion "Verknüpfen" bei jedem Bild

Die vorgestellte Lösung habe ich mit WordPress 3.2.x und 3.3.x getestet.

25 Kommentare »

Frohes neues Jahr mit Google Top-100

Frohes neues JahrSchnurpsel wünscht allen Lesern
ein frohes neues Jahr.

Die Putzlowitscher Zeitung hat ja schon vorhin ihren Lesern ein frohes neues Jahr 2012 gewünscht, nun will ich das hier auch bei Schnurpsel tun, da vermutlich nicht alle Leser meine beiden Blogs lesen.

Für das aktuelle Google-Doodle funktioniert meine Frohes neues Jahr Top-100 schon recht gut. Als Zusatz habe ich kürzlich noch die automatische Anpassung vom Titel der Seite und der URL hinzugefügt. Das geht ganz gut mit der WordPress-Funktion wp_update_post. Im Seiten-Template prüfe ich ganz am Anfang, ob Titel und Seitenname bereits dem aktuellen Doodle-Titel entsprechen. Falls nicht, werden die Felder post_title und post_name entsprechend angepaßt.

Somit läuft die Top-100 nun praktisch ohne mein Zutun für alle neuen Google-Doodles. Naja, zumindest will ich das mal hoffen.

Wie bei Oceparx zu lesen ist, gibt es wohl ab 0 Uhr noch ein extra Neujahrs-Doodle. Mal sehen, ob das hier dann mit der Top-100 auch so gut klappt.

1 Kommentar »

Die WordPress-Gallery (Galerie) ohne Links, so gehts

Erklärungen überspringen – direkt zur Lösung :-)

Die WordPress-Bildergalerie

Seit WordPress Version 2.5 gibt es eine eingebaute Bilder-Galerie, die mit dem Shortcode [gallery] in einen Beitrag integriert werden kann.

Der ersten Version fehlten ein paar sinnvolle Optionen wie Include und Exclude und auch die Art des Links, mit dem ein Galerie-Bild unterlegt ist, konnte nicht beeinflußt werden. Das Bild verlinkte immer auf die Anhang-Seite.

Da ich aber lieber direkt auf die Bilddatei verlinke, habe ich das Plugin „123 Extended Gallery“ geschrieben, welches die WordPress-eigene Gallery-Funktion ersetzt und erweitert.

Mittlerweile kennt WordPress für die Galerie auch die Parameter exclude und include, um Bilder von der Anzeige auszuschließen oder beliebige Bilder hinzuzzfügen. Mit dem Parameter [gallery link=“file“] kann nun auch auf das Bild direkt verlinkt werden.

Was aber immer noch fehlt ist die Möglichkeit, überhaupt keine Links zu verwenden. Das scheint für den einen oder anderen aber durchaus eine erwünschte Option zu sein.

Mein Plugin hat gewissermaßen ausgedient, denn WordPress kann nun praktisch alles selber, was meine „Extended Gallery“ bisher umgesetzt hat, außer eben keine Links zu verwenden.

Deshalb stelle ich im Folgenden eine eigenständige Lösung dafür vor, die z.B. in die Datei functions.php des Themes intergriert werden kann.

In den Tiefen der WordPress Action- und Filter-Hooks

Erweiterungen und Änderungen für WordPress sollten immer über die definierte Plugin-Schnittstelle erfolgen, direktes Manipulieren der WP-Dateien ist unsauber, fehleranfällig und daher zu vermeiden.

In der Gallery

Die Implementierung der Shortcode-Funktion gallery_shortcode in der Datei media.php hat am Anfang einen Filter-Einstiegspunkt (Hook), mehr aber nicht:

// Allow plugins/themes to override the default gallery template.
$output = apply_filters('post_gallery', '', $attr);
if ( $output != '' )
  return $output;

An der Stelle kann man die gesamte Funktion ersetzen, indem man den selbst erzeugten Gallery-HTML-Code zurück gibt. Genau an der Stelle setzt auch mein altes Gallery-Plugin an, aber ich will ja jetzt nur die Links entfernen.

Die Bilder mit den Links werden weiter unten erzeugt:

foreach ( $attachments as $id => $attachment ) {
  $link = ... ? wp_get_attachment_link($id, $size, false, false) ...

Die Funktion wp_get_attachment_link bietet auch einen Filter-Hook, aber ein dort eingehängtes Filter soll ja nur innerhalb der Galerie-Erzeugung aktiv sein.

Nun kann man zwar mit einer Filterfunktion für ‚post_gallery‘ am Anfang eine passende Funktion bei wp_get_attachment_link einklinken, bekommt sie aber am Ende nicht mehr weg. Dann wirkt sie aber auf alle noch folgenden Attachment-Links auch außerhalb der Galerie, was natürlich nicht erwünscht ist.

Wenn man die Anzahl der Bilder kennen würde, könnte man diese in einer globalen Variable vermerken und im eigenen Attachment-Link-Filter runterzählen. Wenn der letzte Link bearbeitet ist, kann man die Filterfunktion wieder ausklinken.

Die anzuzeigenden Bilder werden in der WP-Gallery mit den WordPress-Funktionen get_posts bzw. get_children ermittelt. Diese Funktionen bieten leider keine Filter- oder Action-Hooks. Sie erzeugen ein neues WP_Query-Objekt und holen sich das Ergebnis mit der Objekt-Funktion query ab.

Im WP_Query-Objekt

In der Funktion query gibt es erfreulicherweise mehrere Action- und Filterhooks. Am besten geeignet erscheint der Filteraufruf für ‚the_posts‘ fast am Ende, da hier alle Daten vorliegen und damit die Anzahl der gefundenen Bilder bekannt ist. Leider wird dieser Hook nur bedingt aufgerufen:

if ( !$q['suppress_filters'] )
  $this->posts = apply_filters_ref_array('the_posts', array( $this->posts, &$this ) );

Man ahnt es schon, genau die Variable suppress_filters wird von get_posts und damit auch get_children gesetzt, um die Ausführugn der meisten Filter zu unterdrücken. Das ist auch wichtig und richtig, denn diese Filter sind oft nur in der WordPress-Loop sinnvoll einsetzbar und würden bei der Abfrage einer kompletten Liste der Bilder möglicherweise unerwünschte Ergebnisse liefern.

Und nun? Der Rettungsanker ist der Action-Hook ganz am Anfang der Funktion query:

do_action_ref_array('pre_get_posts', array(&$this));

Meine erste Idee war es nun, die Variable suppress_filters einfach zu löschen, so daß die Filter aufgerufen werden. Das führt aber wie schon gesagt möglicherweise zu unerwarteten Ergbnissen, weil die Filter für die WordPress-Loop gedacht sind. Keine Gute Idee!

Mein nächster Ansatz war nun, daß ich mir zunächst in der Action-Funktion für pre_get_posts das WP_Query-Objekt global speichere um später wieder darauf zugreifen zu können.

Wenn es eine Funktion nach der eigentlichen Abfrage der Datenbank gibt, die ihrerseits einen Filter- oder Action-Hook enthält, könnte ich diese „mißbrauchen“, um über das gespeicherte Objekt schließlich die Anzahl der Bilder zu ermitteln.

Seit WordPress 2.7 gibt es die Sticky-Posts, also Beiträge, die ganz oben auf der Artikelseite fest getackert werden können. Um diese Sticky-Posts vor allen anderen in die Liste einzufügen, wird in der Funktion query die Option ’sticky_posts‘ abgefragt:

$sticky_posts = get_option('sticky_posts');

Die Funktion get_option enthält netterweise ganz am Anfang den Filterhook für ‚pre_option_‘ . $option. Damit kann ich nun meine Abfrage der Anzahl über das zuvor gespeicherte WP_Query-Objekt „triggern“, die Anzahl der Bilder global speichern und letztendlich das eigentliche Filter für wp_get_attachment_link installieren.

Die Filter- und Action-Kette zusammengefaßt

Ist doch eigentlich alles ganz einfach, oder? :-)
Hier nochmal eine kurze, grafische Zusammenfassung aller Schritte:
Gallery-No-Link PAP
Erstellt mit yEd

Nachtrag 13.02.2012: Es geht auch viel einfacher, wie man hier sehen kann: Gallery with No Image Links-Plugin :-)

Die Zip-Datei gallery_no_link.zip runter laden und auf dem heimischen Rechner entpacken.

Download: 123 Gallery No Link

In der enthaltenen Datei plw123_gallery_no_link.php kann eine Option konfiguriert werden.

define( 'PLW123GOL_NO_LINK', false );

Mögliche Werte:
false: die Links werden durch den Link-Parameter ’none‘ im gallery-shorcode unterdrückt:

[gallery link="none"]

true: die Links werden immer in allen Galerien unterdrückt

Das Modul 123 Gallery No Link kann auf drei unterschiedlichen Arten in WordPress installiert werden.

1. in der functions.php des Themes

Dazu ist die Datei plw123_gallery_no_link.php in das WordPress-Theme-Verzeichnis des aktiven Themes zu kopieren und in der functions.php am Ende folgendes einzufügen:

@include( 'plw123_gallery_no_link.php'

2. als Plugin

Dazu ist die Datei plw123_gallery_no_link.php in das WordPress-Plugin-Verzeichnis (/wp-content/plugins/) zu kopieren und im Backend bei den Plugins zu aktivieren.

3. als MU-Plugin (ab WordPress 2.8)

Dazu ist die Datei plw123_gallery_no_link.php in das MU-Plugin-Verzeichnis (/wp-content/mu-plugins/) zu kopieren. Falls dieses Verzeichnis nicht existiert, muß es neu angelegt werden. Eine Aktivierung des Plugins ist nicht erforderlich, PHP-Dateien in diesem speziellen Verzeichnis werden immer geladen.

0 Kommentare »