Quellenangaben und Fußnoten für NextGEN Gallery

[toc]

NextGen Gallery[ref]Downloaddes Plugins im WordPress-Repository unter http://wordpress.org/extend/plugins/nextgen-gallery/[/ref] 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[ref]Dokumentation unter http://nextgen-gallery.com/gallery-tags/.[/ref] 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[ref]Achtung: Die Leerzeichen innerhalb der eckigen Klammern müssen nach einem Copy & Paste entfernt werden, damit der Shortcode von WordPress ausgeführt wird.[/ref]

[ 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[ref]Beispielsweise würden mithilfe des Shortcodes [ nggtags gallery=Referenzverwaltung ] alle Bilder angezeigt werden, die mit „Referenzverwaltung“ verschalgwortet wurden, sowohl aus der Galerie „Doktorandenseminare“ als auch aus der Galerie „WordPress Screenshots“ (sowie allen ggf. vorhandenen weiteren Galerien).[/ref].

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.

[singlepic id=245 w=614 h= float=]

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):

[singlepic id=246 w=614 h= float=]

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[ref]Informatiker mögen mir die unsaubere Verwendung an dieser Stelle verzeihen.[/ref] 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[ref] Siehe dazu auch Diskussion auf http://stackoverflow.com/questions/1524925/howto-use-the-has-filter-wordpress-function-with-an-object-based-callback.[/ref] 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:

[singlepic id=247 w=614 h= float=]

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.

Nicht lesbare Thumbnails bei WordPress / Buddypress mit suPHP

Auf unserer Multiblogging-Plattform setzen wir aus Sicherheitsgründen suPHP statt mod_php ein. Einer der großen Vorteile ist, dass Skripte so unter dem Benutzer des jeweiligen vHosts ausgeführt werden und so weder schreibbar noch ausführbar für andere Benutzer sein müssen. Da die Dateien dem vHost-Besitzer „gehören“ genügt für normale Dateien, wie z.B. Bilder, eine Linux-Dateisystem-Berechtigung von umask 644 bzw. -rwxr–r– oder auf Deutsch:  Besitzer (vHost owner) darf lesen und schreiben, der Rest – insbesondere der Apache-User www-data darf nur lesen.

Das Problem …

In der Debian / Ubuntu Default-Konfiguration für von Skripten erstellte Dateien, also z.B. für von WordPress / Buddypress erzeugte Profilbilder oder vom Plugin NextGEN Gallery erstellte Thumbnails, setzt suPHP die Berechtigung 600 bzw. -rw——-, wodurch die Dateien nicht durch den Apache-User gelesen werden können. Das führt i.d.R. zu klassischen 404-Fehlermeldungen beim Zugriff auf die URLs oder dazu, dass Bilder einfach nicht dargestellt werden, sondern lediglich deren Alternativtext (sofern überhaupt verfügbar).

Die Lösung …

… ist prinzipiell relativ einfach. Allerdings ist zur Änderung Zugriff auf die Webserverkonfiguration erforderlich, was jedoch inzwischen aufgrund der immer häufiger genutzten eigenen vServer mit Root-Zugriff vielfach gegeben ist. In diesem Fall muss lediglich der umask-Eintrag der Datei /etc/suphp/suphp.conf von 0077 (entspricht 600 in Oktalnotation) auf 0022 (entspricht 644 in Oktalnotation) geändert werden:

;Umask to set, specify in octal notation
;umask=0077

Sicherheitshalber ggf. noch den Apache-Prozess neu starten, so dass die Änderungen auch auf jeden Fall übernommen werden und ab sofort sollten von PHP-Prozessen erzeugte Dateien mit den korrekten und v.a. von Apache lesbaren Berechtigungen 644 erzeugt werden:

/etc/init.d/apache2 restart

„jQuery is not defined“-Fehler im WordPress Backend

Mehr oder weniger zufällig haben wir gestern nach einem Update auf Version 3.0.4 einen „Bug“ im WordPress-Backend gefunden, durch den kein Umschalten des WYSIWYG-Editors zwischen „Visuell“ und „HTML“ mehr möglich war. Da die Eingrenzung des Fehlers doch etwas gedauert hat, poste ich das hier, für den Fall, dass es sonst noch jemandem weiterhilft.

Interessant daran: Scheinbar hatte sich WordPress per Cookie / Einstellung zuvor gemerkt, welchen Modus ein Benutzer beim Schreiben / Editieren zuletzt aktiviert hatte, denn entdeckt wurde der Fehler dadurch, dass bei einem Benutzer scheinbar der Editor nicht mehr funktionierte, bei anderen alledings erschien der Editor (TinyMCE) problemlos. Genau lässt sich auch nicht sagen, seit wann das Problem wirklich existiert, vermutlich schon seit einer der früheren 3.0.X-Versionen.

Das Problem

Die Identifikation des genauen Symptoms war per Firefox-Fehlerkonsole relativ schnell erledigt. jQuery wurde scheinbar nicht korrekt geladen, wodurch darauf aufbauende Javascripts Fehler wie z.B. „jquery is not defined“ oder „edButtons is undefined“ auswurfen.

[singlepic id=1 w=614 h=420]

Die Herkunft des Problems lag allerdings etwas tiefer….

Vorgeschlagene Lösungen

Erste Amtshandlung nach Identifikation der Fehlerquelle war (wie vermutlich bei den meisten) Googlen nach der Meldung aus der Fehlerkonsole. Resultat: http://lmgtfy.com/?q=wordpress+jquery+is+not+defined.

Unter den Support-Forum-Posts der Google-Ergebnisse wurde das Deaktivieren von Plugins zur Eingrenzung der Ursache (z.B. http://wordpress.org/support/topic/javascript-error-jquery-is-not-defined) oder noch häufiger ein erneuter Upload der entsprechenden Javascript-Dateien per FTP-Binärmodus (z.B. http://wordpress.org/support/topic/jquery-is-not-defined) vorgeschlagen.

Lösen ließ sich das Problem in unserem Fall damit allerdings nicht, denn die JS-Dateien kommen bei uns über ein Shell-Update-Skript direkt aus dem WordPress-SVN und auch nachdem alle Plugins deaktiviert waren, bestand der Fehler weiter, obwohl wir z.B. auch das (wie ich persönlich finde) sehr gute, im ersten Link erwähnte Admin Dropdown Menü verwenden.

Die tatsächliche Lösung

Bei der weiteren Suche bin ich dann schnell an der Javascript-Quelle hängen geblieben, die – wie man im Screenshot oben gut erkennen kann – das PHP-Skript „load-scripts.php“ nutzt, um verschiedene Einzeldateien zur Verkürzung der Ladezeit zu konkatenieren. Dieser Mechnismus hat wohl auch schon in anderen Konstellationen Fehler verursacht, siehe z.B. http://wordpress.org/support/topic/wp-28-jquery-error. Durch einfaches Abschalten der Skriptverkettung sowie (sicherheitshalber) auch der gleichzeitig von WP durchgeführten Kompression mittels gzip, konnte der Fehler schließlich relativ einfach beseitigt werden. Hierzu müssen lediglich die beiden folgenden Zeilen in die Datei wp-config.php eingefügt werden, die sich im Root-Verzeichnis der WordPress-Installation befindet:

define('CONCATENATE_SCRIPTS', false);
define('COMPRESS_SCRIPTS', false);

WordPress XML Sitemap für Multisite-Installationen

[toc]

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]