NextGen Gallery ¹ ist meiner Meinung nach eine der sinnvollsten und am besten durchdachten Erweiterungen für WordPress. Das Plugin ermöglicht eine galerie- und albumbasierte Verwaltung von Bilder aller Art und darüber hinaus die Zuordnung von Schlagwörtern / Tags zur zusätzlichen (flachen) Strukturierung. Hierdurch wird es möglich, Bilder in Artikeln mithilfe des nggtags-Shortcodes ² dynamisch einzubinden, d.h. statt einer festen Referenz auf eine Auswahl von Bildern wird nur noch festgelegt, welche Schlagwortkombinationen für eine bestimmte Artikelstelle relevant sind. Beispielsweise würden mit folgendem Shortcode alle Bilder als Thumbnails angezeigt, die mit „Auto“ (Groß- und Kleinschreibung egal) verschlagwortet wurden ³

[ nggtags gallery=Auto ]

Das Ganze hat meiner Meinung nach drei entscheidende Vorteile:

1. Kommen weitere Bilder mit den entsprechenden Tags in irgendeiner Galerie hinzu, werden sie automatisch im Artikel mit angezeigt.
2. In der Galerie angegebene Metadaten, wie Titel und Beschreibung werden automatisch übernommen und müssen so im Vergleich zur Nutzung der WordPress Mediathek nicht redundant gepflegt werden – v.a. dann nicht, wenn sie sich nachträglich ändern.
3. Der Tagging-Mechanismus funktioniert galerieübergreifend, d.h. neben der in NextGEN vorhandenen intuitiven Strukturierung in verschiedene Galerien (z.B. zu einem bestimmten Ereignis wie „Doktorandenseminare“ oder einer bestimmten Bilderkategorie wie „WordPress Screenshots“), lassen sich sehr einfach übergreifende Selektionen vornehmen ⁴.

Problem bei externen Bildquellen

Ein „Problem“ mit dem Plugin ergibt sich dann, wenn man Bilder z.B. im wissenschaftlichen Kontext von anderen Quellen referenzieren und dennoch auf den Komfort des Plugins nicht verzichten möchte. Aktuell bietet NextGEN Gallery keine Möglichkeit, Bildquellen oder Ähnliches direkt anzugeben. Natürlich könnte man dafür das Beschreibungsfeld nutzen bzw. zweckentfremden und die entsprechende Quelle einfach als Text dort mit aufnehmen. Für den Fall, dass man die Anzeige der Quelle allerdings gezielter steuern möchte, ist diese Möglichkeit nicht geeignet. Auch widerspräche das Vorgehen klar dem Atomaritätsprinzip bzw. der semantischen Bedeutung des Beschreibungsfeldes. Prinzipiell bietet NextGEN auch hierfür einen eingebauten Mechanismus zur Angabe weiterer Metadaten, allerdings ist dieser in neueren Versionen des Plugins nur sehr umständlich erreichbar und wird v.a. nicht in den Übersichten angezeigt.

Lösungsschritte

Nachdem bis zu einer sinnvoll nutzbaren Lösung zur Quellangabe einige Schritte erforderlich waren, halte ich das hier kurz fest.

1. Zusätzliches Feld zur Quellenangabe bei jedem Bild

Zur Bereitstellung des benötigten Metadatenfeldes im Backend von NextGEN hilft das Plugin NextGEN Custom Fields, mit dem nach erfolgter Installation über den neuen Menüpunkt „NGG Custom Fields“ sehr einfach ein neues  Image Custom Field mit  Bezeichnung „Source“ für Quellenangaben angelegt werden kann. Die Eingabe erfolgt anschließend wie gewohnt über den Punkt „Galerie verwalten“, wie im folgenden Screenshot auf der rechten Seite zu sehen.

NextGEN Gallery Source Feld

2. Anpassen des Galerie-Templates

Damit das neu erstellte Feld auch in Thumbnail-Übersichten oder bei Einzelbildern im Frontend angezeigt wird, muss es entsprechend eingebunden werden. Mein erster Ansatz war, ein eigenes NextGEN Gallery Template für die Ausgabe zu nutzen, allerdings funktioniert der folgende Shortcode leider nicht, da NextGEN seltsamerweise bei tagbasierten Galerien bisher keine Tamplates unterstützt.

[ nggtags gallery=Auto template=source]

Dieser Missstand ließe sich zwar entsprechend http://wordpress.org/support/topic/plugin-nextgen-gallery-nggtags-caption beseitigen, allerdings müssten hierzu die Funktion nggShowGalleryTags in der nggfunctions.php und die Funktion show_tags in der shortcode.php von NextGEN entsprechend angepasst werden, was logischerweise nicht update-sicher und damit wenig sinnvoll ist. Hier heißt es also abwarten, ob diese durchaus sinnvollen Erweiterungen für nggtags irgendwann durch den Autor Alex Rabe ihren Weg in das Plugin finden, wovon ich fest ausgehe.

Somit blieb nichts anderes, als direkt das gallery.php Template entsprechend anzupassen. Nachdem wir hier im Blog allerdings sowieso ein einheitliches Galerieformat verwenden, ist dem auch nichts entgegenzusetzen – insbesondere da es so (ohne den zusätzlichen template-Parameter im Shortcode) noch einfacher ist, später Galerien in Blogartikeln einzufügen.

Um sicherzustellen, das die Templates nicht bei einem Plugin-Update direkt wieder überschrieben werden, sollten die folgenden Anpassungen ausschließlich (!) in einem zu erstellenden Unterordner „nggallery“ des verwendeten Themes durchgeführt werden:

1. Kopieren der gallery.php und der singlepic.php aus /wp-content/plugins/nextgen-gallery/view/ nach wp-content/themes/AKTUELLES-THEME/nggallery/.
2. Einfügen von $image->ngg_custom_fields[„Source“] an der gewünschten Stelle, z.B. hinter echo $image->caption.

Problem hierbei ist, dass die Quellangaben (zumindest in unserem Fall) meist URLs sind, die i.d.R. eine Länge haben, durch welche die schön gefloateten Thumbnail-Übersichten unruhig würden oder falscch umbrechen, sicher aber schlecht lesbar wären (s. Screenshot):

Fehlerhafte Darstellung bei Thumbnails mit Quellen

3. Fußnoten für Quellenangaben

Da wir hier im Blog ein Plugin zur Erzeugung von Fußnoten für zusätzliche Anmerkungen oder wissenschaftliche Quellenangaben verwenden, war es naheliegend, dieses Plugin auch für die Galeriebilder zu nutzen. In unserem Fall handelt es sich um das Plugin Simple Footnotes, das sich durch eine sehr einfache Handhabung sowie Multisite- und WP 3.1-Kompatibilität auszeichnet. Im Prinzip sollten die folgenden Schritte aber auch auf andere Plugins übertragbar sein.

Statt der Einbindung der Quellangabe direkt in der Caption, muss hierzu das Source-Field von oben lediglich mit der entsprechenden Shortcode-Funktion das Simple Footnotes Plugins „gewrappt“ werden. Da das Gallery-Template das Plugin allerdings nicht kennt, ist es erforderlich, zunächst eine entsprechende lokale Instanz zu erzeugen:

n
$footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));

Damit die Fußnoten nur dann erzeugt werden, wenn auch tatsächlich eine Quellenangabe vorhanden ist, sollte zusätzlich noch folgende Abfrage integriert werden:

if ($image->ngg_custom_fields["Source"]){
	echo ($footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));
}

Mit diesem Code wurden die Fußnoten auch erzeugt, allerdings leider für jedes Bild wieder bei 1 beginnend, da bei jedem Aufruf innerhalb der Bilderschleife des Gallery-Templates eine neue Instanz des Footnote-Plugins erstellt wurde. Abhilfe schafft hier das Auslagern der Instanzerzeugung außerhalb der Schleife und verwenden von $footnotes als globale Variable. Wichtig: Ähnlich wie bei einem Singleton ⁵ sollte die globale Plugin-Referenz nur initialisiert werden, sofern sie noch null ist:

global $footnotes;
if (!$footnotes){
	$footnotes = new nacin_footnotes();
}

Resultat sind wie gewünscht in Fußnoten ausgelagerte Quellenangaben der Bildergalerie. Allerdings tritt das Problem doppelter Fußnoten weiterhin auf, sofern auf einer Seite, wie in diesem Beitrag, normale (textbasierte) Fußnoten und Bildergalerien gleichzeitig verwendet werden. Das liegt daran, dass das Plugin Simple Footnotes seinen Content Filter so angelegt hat, dass es sich selbst bzw. besser gesagt eine Instanz von sich selbst dem Filter übergibt:

add_filter( 'the_content', array( &$this, 'the_content' ), 12 );

Durch den WordPress-Filter-Registrierumgsmechanismus ⁶ wird bei jeder neuen Instanz von nacin_footnotes() auch jeweils ein entsprechender Content-Filter eingehängt, was a) inperformant ist und b) dazu führt, dass der Fußnotenblock in seiner Gesamtheit mehrfach am Ende eines Posts angezeigt werden kann. Leider habe ich für dieses Problem keine Optimallösung parat, so dass nur die Anpassung des der Datei simple-footnotes.php des Plugins bleibt. Hier muss ganz am Ende der Datei folgende Änderung durchgeführt werden:

//new nacin_footnotes();
global $footnotes;
$footnotes = new nacin_footnotes();

Hierdurch wird sichergestellt, dass das Plugin nur einmal erzeugt wird, egal ob direkt oder über das Gallery-Template. Zusätzlich ist es ggf. noch erforderlich, die folgende Änderung an der shortcode-Funktion des Plugins vorzunehmen. Hierdurch wird sichergestellt, dass die Fußnoten immer korrekt durchgezählt werden und bei 1 beginnen:

//FO we have to check if the footnote text is already present, otherwise the gallery plugin mechanism will not work (don't know why)
/*
if ( ! isset( $this->footnotes[$id] ) )
	$this->footnotes[$id] = array( 0 => false );
$this->footnotes[$id][] = $content;
$note = count( $this->footnotes[$id] ) - 1;
*/
if (!in_array($content,$this->footnotes[$id])){
	$this->footnotes[$id][] = $content;
	$note = count( $this->footnotes[$id] ) - 1;
}
else{
	$note =  array_search($content,$this->footnotes[$id]);
}

Ersetzt man nun noch den von NextGEN für die Bildunterschriften verwendeten span-Tag im Gallery-Template nun noch durch den von WordPress standardmäßig genutzten p-Tag der Klasse wp-caption-text und fügt dem ngg-gallery-thumbnail-Container die Klasse wp-caption hinzu, erhält man das folgende „fertige“ Gallery-Tempalte:

<?php
/**
Template Page for the gallery overview

Follow variables are useable :

	$gallery     : Contain all about the gallery
	$images      : Contain all images, path, title
	$pagination  : Contain the pagination content

 You can check the content when you insert the tag <?php var_dump($variable) ?>
 If you would like to show the timestamp of the image ,you can use <?php echo $exif['created_timestamp'] ?>
**/

// FO: muss global erzeugt werden, da sonst die Nummerierung für jede Galerie neu beginnt
global $footnotes;
if (!$footnotes){
	$footnotes = new nacin_footnotes();
}
if (!function_exists('imagesourcelink')) {
	function imagesourcelink($text){
		// text starts with http://
		if (strpos($text, "http://") === 0){
			return '<a href="' . $text . '" title="Go to external Source" >' .$text . '</a>';
		}
		else{
			return $text;
		}
	}
}

/*	FO: Da $gallery->ID als Group-ID für jQuery Colorbox / Slimbox nur dann funktioniert,
	wenn echte Gallerien verwendet werden, nicht aber bei nggtags (Tag-basierter Auswahl)
	muss hier noch einmal gesondert mitgezählt werden
*/
global $lightboxgroup;
if (!$lightboxgroup){
	$lightboxgroup = 0;
}

?>
<?php if (!defined ('ABSPATH')) die ('No direct access allowed'); ?><?php if (!empty ($gallery)) : ?>

<div id="<?php echo $gallery->anchor . $lightboxgroup ?>">

<?php if ($gallery->show_slideshow) { ?>
	<!-- Slideshow link -->
	<div>
		<a href="<?php echo $gallery->slideshow_link ?>">
			<?php echo $gallery->slideshow_link_text ?>
		</a>
	</div>
<?php } ?>

<?php if ($gallery->show_piclens) { ?>
	<!-- Piclense link -->
	<div>
		<a href="<?php echo $gallery->piclens_link ?>">
			<?php _e('[View with PicLens]','nggallery'); ?>
		</a>
	</div>
<?php } ?>

	<!-- Thumbnails -->
	<?php foreach ( $images as $image ) : ?>

	<div id="ngg-image-<?php echo $image->pid ?>" <?php echo $image->style ?> >
		<div >
			<a rel="lightbox-<?php echo $lightboxgroup ?>" href="<?php echo $image->imageURL ?>" title="
			<?php
			echo $image->description;
			if ($image->ngg_custom_fields["Source"]){
				echo ', Quelle: ' . $image->ngg_custom_fields["Source"] . ".";
			}
			?>
			" <?php echo $image->thumbcode ?> >
				<?php if ( !$image->hidden ) { ?>
				<img alt="<?php echo $image->description ?>" src="<?php echo $image->thumbnailURL ?>" <?php echo $image->size ?> />
				<?php } ?>
			</a>
			<p-caption-text><?php 

			echo $image->alttext;

			if ($image->ngg_custom_fields["Source"]){
				echo ($footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));
			}

			?></p>
		</div>
	</div>
	<?php if ( $image->hidden ) continue; ?>
	<?php if ( $gallery->columns > 0 && ++$i % $gallery->columns == 0 ) { ?>
	<br style="clear: both" />
	<?php }
	endforeach;
	$lightboxgroup++;
	?>

	<!-- Pagination -->
 	<?php echo $pagination ?>

</div>

<?php endif; ?>

Zusätzlich zu den hier beschriebenen Punkten ist in diesem Template von Zeile 32-39 auch eine Zählervariable für Bildergruppen in Lightboxen, wie beispielsweise Slimbox oder Colorbox enthalten, die es auch bei tagbasierten Galerien ermöglicht, Bilder einer Galerie nacheinander durchzuklicken. Außerdem enthält das Template die Funktion imagesourcelink (Zeile 20-30), die im Source-Feld eingetragene URLs in den Fußnoten automatisch verlinkt.

Endergebnis

Das Ergebnis der Bemühungen sieht anschließend wie folgt aus:

Thumbnails mit Fußnoten

Für den Fall, dass noch kein CSS für die Galerie-Darstellung existiert, sind ggf. noch folgende ergänzenden CSS-Angaben erforderlich, um die Darstellung der Thumbnails gleichmäßig über die Seite zu verteilen. Die Größenangaben basieren hierbei auf einer in NextGEN eingestellten Thumbnail-Größe von 126x100px. Die Pixeldifferenz zu 146px Breite rührt von den CSS-Einstellungen des hier verwendeten Twentyten Child-Themes bzw. den dort vorgegebenen Paddings:

.ngg-gallery-thumbnail{
	width: 146px;
	height: 160px;
	overflow: hidden;
}

Die ggf. erforderlichen Änderungen an der singlepic.php zur Darstellung von Einzelbildern erfolgen analog.

Auch wenn in letzter Zeit wieder häufiger davon zu lesen ist, Google Analytics bzw. das von Google bereitgestellte Browser-Plugin zum „opt-out“ aus Google Analytics sei immer noch nicht mit deutschem Datenschutzrecht vereinbar ¹, existieren Möglichkeiten, um das Analytics-Tracking zumindest nach bisher vorherrschender Rechtspraxis ² durch serverseitige Maßnahmen datenschutzkonform zu machen.

Rechtsgrundlage

Grundsätzlich ist in Deutschland die Erhebung von Nutzungsdaten digitaler Medien, wie beispielsweise Webseiten, im Telemediengesetz (TMG) geregelt. Hiernach ist die Erhebung von pseudonymisierten Nutzungsdaten nach §15 (3) zunächst zulässig ³:

Der Diensteanbieter darf für Zwecke der Werbung, der Marktforschung oder zur bedarfsgerechten Gestaltung der Telemedien Nutzungsprofile bei Verwendung von Pseudonymen erstellen, sofern der Nutzer dem nicht widerspricht.

Nachdem sehr viele Internetseitenbetreiber Google Analytics oder vergleichbare Werkzeuge zur Auswertung des Besucherverkehrs einsetzen, ohne sich explizit an die geforderte Pseudonymisierung zu halten, hat der Düsseldorfer Kreis im November 2009 (hauptsächlich für öffentliche Einrichtungen) die Verwendung von IP-Adressen als Pseudonym für explizit unzulässig erklärt, da die Anonymisierung hier nicht in ausreichendem Maße gewährleistet sei ⁴.

Serverseitige IP-Anonymisierung

Google hatte daraufhin reagiert und im Mai vergangenen Jahres eine Möglichkeit bereitgestellt, um die IP-Adressen der Webseitenbesucher nur noch (teil-)anonymisiert abzuspeichern ⁵. Außerdem zeigt sich Google neueren Berichten zufolge auch sehr bemüht, weitere Unstimmigkeiten bzgl. eventuell vorhandener Datenschutzbeeinträchtigungen beizulegen ⁶. Die Voraussetzung für die Zulässigkeit der Google-Analytics-Nutzung ist damit allerdings immer noch, dass das eingesetzte Tracking-Verfahren den Parameter zur Anonymisierung der IP-Adressen (bzw. besser gesagt des letzten Oktetts der IP-Adressen) nutzt, um die u.a. vom Düsseldorfer Kreis geforderte Pseudonym-Eigenschaft zu gewährleisten ⁷.

Technische Umsetzung

Webseitenbetreiber, die den Tracking-Code händisch einfügen, konnten entsprechend der Google API die Anonymisierung relativ einfach einsetzen, in dem sie den entsprechenden Parameter (synchron / asynchron) direkt in den Tracking-Code einbinden.

Anpassung des synchronen Tracking-Codes

<script type="text/javascript">
	var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
	document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
	var pageTracker = _gat._getTracker("UA-XXXXXX-XX");
	_gat._anonymizeIp();
	pageTracker._initData();
	pageTracker._trackPageview();
</script>

Geändert hat sich hier lediglich die Zeile 7. Ähnlich verhält es sich bei Nutzung des performanteren und die Ladezeit der Website weniger beeinträchtigenden asynchronen Trackings.

Anpassung des asynchronen Tracking-Codes

<script type="text/javascript">
	var _gaq = _gaq || [];
	_gaq.push(['_setAccount', 'UA-XXXXXX-XX']);
	_gaq.push(['_gat._anonymizeIp']);
	_gaq.push(['_trackPageview']);

	(function() {
		var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
		ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
		var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
	})();
</script>

Hier hat sich entsprechend Zeile 4 geändert. Insbesondere in der Übergangszeit nach Einführung des Zusatzparameters fand man häufig auch folgende falsche Verwendungsform, die nicht zum gewünschten Ergebnis führt ⁸. Hier ist also Vorsicht geboten:

_gaq.push(['_anonymizeIP']);

Verwendung in WordPress

Nachdem von den verfügbaren WordPress-Plugins nicht alle eine benutzerfreundliche („dazuklickbare“) Option zur Einbindung des Parameters mitbringen, ist man bei der Plugin-Auswahl schon etwas eingeschränkt. Nach einem kurzen Funktionsvergleich der aktuell populärsten WordPress Plugins für Google Analytics

• Google Analyticator,
• Web Ninja Google Analytics,
• Google Analytics for WordPress und
• Ultimate Google Analytics

fiel meine Auswahl in diesem Fall schnell auf Google Analytics for WordPress, nicht zuletzt da es neben der expliziten Option zur Konfiguration der IP-Maskierung im Vergleich zu den anderen Plugins auch sonst den robustesten und flexibelsten Eindruck machte. Wichtig ist nur, unter „Einstellungen > Google Analytics > Advanced Settings > anonymize IP“ das entsprechende Häkchen zu setzen.

Wer zusätzlich gerne eine Dashboard-Übersicht hätte, wie sie die anderen Plugins z.T. mitbringen, kann als Ergänzung das Plugin Google Analytics Dashboard einsetzen, das trotz aktuell nicht ausgewiesener WordPress 3.0 Kompatibilität zumindest bei ersten Tests auch in dieser Version einwandfrei funktionierte.

Hinweispflicht im Impressum

Unabhängig von der IP-Maskierung besteht natürlich weiterhin die Verpflichtung im Impressum einer Website auf die Nutzung von Google Analytics hinzuweisen. Hierzu bietet Google eine verwendbare Vorlage, die nach eigener Aussage die wesentlichen Bestandteile enthält ⁹:

Diese Website benutzt Google Analytics, einen Webanalysedienst der Google Inc. („Google“). Google Analytics verwendet sog. „Cookies“, Textdateien, die auf Ihrem Computer gespeichert werden und die eine Analyse der Benutzung der Website durch Sie ermöglichen. Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website (einschließlich Ihrer IP-Adresse) wird an einen Server von Google in den USA übertragen und dort gespeichert. Google wird diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten für die Websitebetreiber zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen zu erbringen. Auch wird Google diese Informationen gegebenenfalls an Dritte übertragen, sofern dies gesetzlich vorgeschrieben oder soweit Dritte diese Daten im Auftrag von Google verarbeiten. Google wird in keinem Fall Ihre IP-Adresse mit anderen Daten von Google in Verbindung bringen. Sie können die Installation der Cookies durch eine entsprechende Einstellung Ihrer Browser Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich nutzen können. Durch die Nutzung dieser Website erklären Sie sich mit der Bearbeitung der über Sie erhobenen Daten durch Google in der zuvor beschriebenen Art und Weise und zu dem zuvor benannten Zweck einverstanden.

Natürlich kann ich als Nicht-Jurist keine Nutzungsempfehlungen aussprechen (das sollte jeder eigenverantwortliche entscheiden), aber in dieser Form scheint Google Analytics zumindest den aktuell geltenden Datenschutzbestimmungen (auch für öffentliche Einrichtungen) zu genügen.

Inzwischen dürfte die Möglichkeit eigene Seiten sowie deren Aktualisierungen (z.B. Blogposts) per sitemap.xml an Google zu übermitteln wohl den meisten Webseitenbetreibern geläufig sein. Für den Fall der Fälle finden sich in den Webmaster Tools bei Google weitere Informationen dazu.

Klassische WordPress-Plugin-Lösung

Für WordPress gibt es schon seit einiger Zeit ein sehr einfaches und gutes Plugin von Arne Brachhold, das die automatische Erzeugung und Aktualisierung dieser sitemap.xml sowie deren komprimiertem Pendants „sitemap.xml.gz“ übernimmt. Wir haben dieses Plugin u.a. auf dem offiziellen Internetauftritt der Forschungsgruppe München www.kooperationssysteme.de im Einsatz. Nachdem diese aktuell extern gehostete Seite allerdings in unsere inzwischen stetig gewachsene und weiterentwickelte WordPress Multiblogging-Plattform umziehen sollte und die aktuelle „stable“ des Plugins nicht Multisite-fähig war, ging die Alternativensuche los.

Multisite-fähige Plugins

Sucht man in den WordPress Plugins nach „google sitemaps multisite“ findet man als ersten Treffer zunächst das vielversprechend klingende Plugin Google XML Sitemaps with Multisite support von Mario Kostelac, das nach näherer Begutachtung auf der oben erwähnten Erweiterung aufbaut und nach eigenen Angaben einen Großteil des Codes von Arne Brachhold verwendet:

99% percent of work is done by Arne so, thank you Arne. I hope that our projects will merge into the one in the near future.

Haupteinschränkung des Plugins: Es verwendet immer noch von Zeit zu Zeit (statisch) erzeugte Sitemap-Dateien und legt diese in einem Unterordner „sitemaps“ im Webroot bzw. WordPress-Installationsverzeichnis ab. Diese müssen dann bei einer Multisite-Installation für die einzelnen Blogs per manuellem Rewrite oder über Anpassungen der robots.txt integriert werden, was mit Zusatzaufwand verbunden ist.

Bei der weiteren Recherche nach brauchbaren Plugins bin ich anschließend sehr schnell über eine Weiterentwicklung der ursprünglichen Erweiterung gestolpert, die sich zwar aktuell noch in der Beta-Phase befindet, Ihren Dienst aber mit ein paar minimalistischen Einschränkungen schon sehr gut macht. Details auf der entsprechenden Website von Arne Brachhold. Wie man dem Changelog entnehmen kann, unterstützt die Beta nicht nur Multisite-Installationen, sondern erzeugt die sitemap.xml für die einzelnen Blogs „on the fly“, wodurch keine umständlichen Rewrites oder Eintragungen in der robots.txt mehr erforderlich sind:

• No static files anymore, sitemap is created on the fly!
• Sitemap is split up into sub-sitemaps by month, allowing up to 50.000 posts per month!
• Reduced server resource usage due to less content per request.
• 100% Multisite compatible, including by-blog and network activation.
• New API allows other plugins to add their own, separate sitemaps.

Nachdem ich das Plugin im Root-Blog einer WordPress-Installation (3.0.4) getestet habe, die u.a. auch Buddypress (1.2.7) nutzt, scheint es wohl aus diesem oder einem mir unerfindlichen anderen Grund ein Problem mit dem Rewrite der url blog.de/sitemap.xml zu geben, das mich erst zu dem Glauben veranlasst hat, das Plugin würde überhaupt nicht funktionieren. Nach etwas Recherche und Testen in anderen (nicht-root) Blogs der Multisite-Installation wurde dann aber schnell klar, dass die Sitemaps jeweils korrekt erzeugt wurden. Lediglich im Root-Blog konnte die Sitemap nicht über blog.de/sitemap.xml, sondern ausschließlich über die Non-Permalink-Variante blog.de/index.php?xml_sitemap=index aufgefrufen werden.

Anpassung der .htaccess-Datei

Durch einen Blogpost von Jan Dembowski zu einer Anpassung des verwendeten Plugins (der zwar in dieser Form inzwischen aufgrund der aktuellen Beta veraltet ist, jedoch für den vorliegenden Fall sehr hilfreich war), ließ sich auch das Problem mit dem Root-Blog durch Einfügen einer weiteren Rewrite-Rule in der .htaccess-Datei von WordPress lösen:

RewriteRule ^sitemap.xml index.php?xml_sitemap=index [L]