Leben des wolf-u.li » Blog

Wordpress 3.0 “Thelonious” ist verfügbar

Uli — Fri, 18 Jun 2010 13:19:18 +0000

Wie Matt gestern abend per Mail verschickt hat, ist Wordpress 3.0 fertig zum Download. An dieser Stelle verweise ich für die neuen Features einfach an Wordpress.org bzw. wordpress-deutschland.org und binde nur die Film-Tour durch neue Wordpress hier ein.

Ich persönlich finde die ShortLink-Option (bisher realisiere ich das einfach so, dass ich nur auf die Beitragsnummer, also z.b. http://wolf-u.li/3510/ verlinke) und das neue Menüsystem zum erstellen von Navigationsmenüs am spannendsten.

© 2005-2009 by Uli Wolf – This Content is distributed under the Creative Commons License
This feed is for personal, non-commercial use only.
The use of this feed on other websites without attribution to the author and notification of the author breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint: d2a576b5311479d89eff39b7ca886f6b)

Umleitung bei ausschließlicher Angabe der post_id in der URL auf den vollen Wordpress-Permalink mittels Nginx

Uli — Sat, 27 Mar 2010 16:05:56 +0000

Ich poste mittels Twitpress meine Einträge auf Twitter, wobei ich die URL zum Eintrag mittels der ID des Posts, also im Fall dieses Posts 3385, angebe. Dies sieht dann so aus:

Neuer Blog-Eintrag: Umleitung bei ausschließlicher Angabe der post_id in der URL auf den vollen Wordpress-Permalink mittels Nginx http://wolf-u.li/3385/

Früher wurde dann per Wordpress auf die volle URL umgeleitet, jedoch funktioniert dies in der Version 2.9.2, die ich momentan fahre, nicht mehr so. Das führte dazu, dass unter http://wolf-u.li/3385/ und der langen Url des Beitrags der gleiche Inhalt angezeigt wurde, was zu Problemen mit den Suchmaschinen führen kann. Da ich keinen Bock hatte, mich bei mir auf Fehlersuche zu begeben, habe ich kurz gegoogled und festgestellt, dass dies für Version 3.1 von Wordpress wiedergeplant ist. Ein wenig Recherche brachte an den Tag, dass man auch manuell per .htaccess (bei Nutzung von Apache) auf index.php?p={POST_ID} umleiten kann.

Da ich den Webserver Nginx (siehe Leitartikel) einsetze, habe ich also nun einfach eine Prüfung geschrieben, die nachsieht, ob nach wolf-u.li/ einfach nur eine Zahl folg und in diesem Fall auf die index.php leitet, welche dann auf die korrekte lange URL leitet. Die komplette Location könnte also so aussehen:

PLAIN TEXT

CODE:

location / {
if (-f $request_filename) {
break;
}
rewrite ^/([0-9]+)/$ /index.php?p=$1 last;
rewrite ^(.+)$ /index.php last;
}

Zuerst wird geprüft, ob der angeforderte Dateiname vorhanden ist. Wenn dem der Fall ist, werden keine weiteren Prüfungen durchgeführt und diese Datei zurückgegeben. Wenn nicht, wird zunächst die oben beschriebene Prüfung durchgeführt. Wurde kein Match ermittelt, so wird einfach nur auf index.php umgeleitet.

Das behob bei mir das Problem des doppelten Contents

© 2005-2009 by Uli Wolf - This Content is distributed under the Creative Commons License
This feed is for personal, non-commercial use only.
The use of this feed on other websites without attribution to the author and notification of the author breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint: d2a576b5311479d89eff39b7ca886f6b)

Saubere Entfernung von Sprachen im Wordpress-Plugin Global Translator für Übersetzungen des Webseiteninhalts

Uli — Sat, 27 Mar 2010 15:37:36 +0000

In den vergangenen Wochen habe ich mich ein wenig mit meinem Google Webmasters Panel auseinander gesetzt und den ein oder anderen Fehler ausgemerzt, der dazu führen könnte, dass ich erneut meinen PageRank verliere. Dies war bereits im Juli letzten Jahres geschehen, da ich wohl zuviele nicht erreichbare Seiten hatte. Mittlerweile habe ich wieder meinen damaligen PR3, de ich auch gerne behalten möchte.

Damals war das Plugin Global Translator dafür verantwortlich, welches bei einer nicht vorhandenen Übersetzung ein 404 ausgespuckt hatte, was Google nicht so sehr gefallen hatte. Mittlerweile siehts in meinen Google Webmaster Tools schon wieder nicht so rosig aus. Da der Anteil ausländischer Besucher aus Ländern, deren Sprache nicht Englisch oder Chinesisch ist, täglich nur bei ~2% liegt, habe ich mich nun entschlossen, alle überflüssigen Sprachen zu entfernen, um mehr Anfragen für die Übersetzungen der Sprachen Englisch und Deutsch verfügbar zu haben. Natürlich ist das nicht so leicht, da ja doch mittlerweile knapp 12k Seiten im Google Index gelandet sind und ich für Unerreichbarkeit keine Schelte bekommen möchte

Der mehrstufige Actionplan sieht nun folgendes vor:

Erstellung von Rewrite-Rules für nginx zur 301-Umleitung (Moved Permanentely) auf Webserverebene
Beantragung der Entfernung der Übersetzungen aus dem Google Suchindex
Anpassen der Einstellungen in Global Translator
Entfernung der überflüssigen Übersetzungsverzeichnisse
Aktualisierung des Page-Cache

Erstellung von Rewrite-Rules für nginx zur 301-Umleitung
Die Übersetzungslinks sollen für eventuelle, schon vorhandene Verlinkungen, auf den Originalartikel umgeleitet werden. Da ich, wie vielleicht einige wissen, als Webserver Nginx einsetze (Siehe Leitartikel), benötige ich hierfür die entsprechenden Rewrite-Rules. Leider bin ich ein Experte in Regex, jedoch funzt der folgende Code:

PLAIN TEXT

CODE:

location ~* ^/(ar|be|ca|cs|da|el|es|et|fa|fi|fr|ga|gl|hu|is|ko|mk|ms|mt|nl|bg|hr|id|it|hi|iw|ja|no|lv|lt|pl|pt|ru|sk|sl|sq|sr|sv|ro|th|tl|tr|uk|vi)/ {
rewrite ^/(ar|be|ca|cs|da|el|es|et|fa|fi|fr|ga|gl|hu|is|ko|mk|ms|mt|nl|bg|hr|id|it|hi|iw|ja|no|lv|lt|pl|pt|ru|sk|sl|sq|sr|sv|ro|th|tl|tr|uk|vi)/(.*)$ /$2 permanent;
}

Er muss mit in den Server-Teil der betreffenden Blog-Domain eingebaut werden. Vermutlich könnte man von der Location her direkt die Sprache capturen, so wie oben funzt es aber auf jeden Fall Die Sprachen "en", "zh-CN" und "zh-TW" habe ich weggelassen, da ich diese vorerst weiter behalte.

Beantragung der Entfernung der Übersetzungen aus dem Google Suchindex
Bis dato hatte ich von den angebotenen Sprachen des Global Translator nur jene aktiviert, die seitens Google Adsense erlaubt sind. Diese müssen nun über die Google Webmaster Tools entfernt werden.
Dazu loggt man sich zunächst dort ein. Man wählt die betreffende Webseite und geht zu "Website-Konfiguration" -> "Crawler-Zugriff". Dort klickt man auf den Tab "URL entfernen". Im folgenden Auswahlfenster wählt man dann als Option "Ein Verzeichnis sowie alle Unterverzeichnisse auf der Website", da wir beispielsweise /ar/* entfernen möchten. Im nächsten Eingabefeld muss dann ar/ eingegeben werden.

Laut Google sollte man ausserdem nun die robots.txt anpassen, da ein 301 Redirect nicht als "nicht mehr erreichbar" gilt. Hierzu legt man für jede entfernte Sprache ein

Disallow: /{SPRACHCODE}/

an, sodass dies dann beispielsweise so aussieht:

User-agent: * Allow: / Disallow: /ar/

Anpassen der Einstellungen in Global Translator
Nun rate ich dazu, die Sprachen im Plugin zu entfernen. Bei mir bleiben derzeit nur "en", "zh-CN" und "zh-TW" übrig, den Rest habe ich deaktiviert. Nach dem Speichern sollte die Sitemap neu erzeugt werden, da nun die überflüssigen Sprachen wegfallen.

Entfernung der überflüssigen Übersetzungsverzeichnisse
Hat man die obigen Schritte erfolgreich durchgeführt, so können die überflüssigen Übersetzungsverzeichnisse gelöscht werden. Glücklich ist, wer Shellzugriff hat, da gehts etwas schneller als per FTP . Die Übersetzungen finden sich in {WORDPRESS_HOME}/wp-content/gt-cache/. Ich würde das Verzeichnis "stale" nicht mitlöschen, auch dort würde ich nur die nicht mehr benötigten Sprachen entfernen.

Aktualisierung des Page-Cache
Ich setze für das Cachen meiner Seiten das Plugin WP-Super-Cache ein, welches nun auch aktualisiert werden sollte. Ein Klick auf "Delete Cache" auf der Einstellungsseite des Plugins würde dies durchführen. Ich persönlich verwende aber zusätzlich das Plugin "Askapache Crazy Cache", welches mir erlaubt, schnell alle Seiten neu zu cachen. Auf einem shared Webspace macht dies jedoch nur begrenzt Sinn, da die CPU-zeit häufig begrenzt ist.

Fazit: So bin ich nun relativ sauber die überflüssigen Sprachen losgeworden und hoffe so die nicht erreichten Seiteninhalte reduzieren zu können.

Häufung von Fehler “Unerreichbar” in Google Webmaster Tools aufgrund von Global Translator und Parameter replytocom

Uli — Wed, 10 Mar 2010 21:25:03 +0000

In den letzten Tagen haben sich bei mir in den Google Webmaster-Tools sehr viele "Unerreichbar"-Fehler aufgrund des dynamischen "replytocom"-Parameters angehäuft. Dieser wird bei, von Global Translator übersetzten, Seiten an verlinkungen der Kommentare angehängt, was Google wohl nicht so gut verpackt.

Die Lösung ist sehr einfach: Man gehe in die betroffene Seite, klicke links auf "Website-Konfiguration" und anschließend "Einstellungen". Dort trägt man am Ende der Seite unter "Parameterbehandlung" den Parameter "replytocom" mit der Aktion "Ignorieren" ein.

Sieht dann so aus:

Bildercache für den Webserver nginx am Beispiel von Gravatar-Icons

Uli — Mon, 22 Feb 2010 18:57:57 +0000

Dieser Artikel ist Teil einer Reihe zum Webserver nginx.
Schau dir auch die anderen Artikel an: Zum Leitartikel

Vor einigen Tagen schrieb ich bereits über eine Möglichkeit, die Gravatar-Icons lokal zwischen zu speichern. Leider wurde dabei bei jedem Aufruf eines Bildes immer einen php-call gemacht, was mir bei manchen Beiträgen das Blog in die Knie zwingen würde und dem eigentlich gewünschten Effekt (Beschleunigung) entgegenstehen würde. Daher habe ich mir mal die Funktionen meines Webservers nginx angesehen und dabei festgestellt, dass dieser die folgende Prüfung erlaubt:

Ist das Bild vorhanden?
- Wenn ja: Direkte Auslieferung
- Wenn nein: Aufruf einer PHP-Datei zum Download des Bildes

Die Umsetzung war dann einfach:

Das ist die Konfigurationsdatei für den vHost in nginx:

PLAIN TEXT

CODE:

server {
listen 80;
server_name img.yourdomain.tld;
error_log /path/to/your/logs/error/img.yourdomain.tld.log warn;
root /path/to/your/document/root/;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:1234;
include /etc/nginx/fastcgi_params;
}
location / {
index cdn.php;
# if the requested file exists, return it immediately
if (-f $request_filename) {
break;
}
# all other requests go to CDN-PHP-File
if (!-e $request_filename) {
rewrite ^(.+)$ /cdn.php last;
}
}
}

Nun speichert man in /path/to/your/document/root/ die Datei cdn.php mit folgendem Inhalt:

PLAIN TEXT

CODE:

// Script by Uli Wolf - http://wolf-u.li
// Modify the settings below according to your needs:
// Size of the gravatar-images:
$gimagesize = 32;
// If the mailadress was not found, you can get various images:
// - identicon
// - monsterid
// - wavatar
$mailnotfound = "identicon";
$removefromurl = array("/g/","/",".png",".jpg",".gif");
$gravatar_hash = str_replace(strtolower($removefromurl),"",$_SERVER["REQUEST_URI"]);
$gravatar_hash = preg_replace("/[^a-z0-9\s]/", "", $gravatar_hash);
if(strlen($gravatar_hash)!=32) {exit;}
$grav_img = "http://www.gravatar.com/avatar/" . $gravatar_hash . "?s=" . $gimagesize . "&d=" . $mailnotfound . "&r=G";
if(extension_loaded('curl')) {
$gch = curl_init();
$gcurl_options = array(
CURLOPT_URL => $grav_img,
CURLOPT_HEADER => false,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 20,
CURLOPT_BINARYTRANSFER => true,
CURLOPT_MAXREDIRS => 2
);
curl_setopt_array($gch, $gcurl_options);
$gdata = curl_exec($gch);
curl_close ($gch);
unset($gch);
} else {
ob_start();
$gfilehandle_url = fopen($grav_img, "rb");
fpassthru($gfilehandle_url);
fclose($gfilehandle_url);
$gdata = ob_get_contents();
ob_end_clean();
unset($gfilehandle_url);
}
$gfilehandle_img = fopen("g/" . $gravatar_hash . ".png", "wb+");
fwrite($gfilehandle_img, $gdata);
fclose($gfilehandle_img);
unset($gfilehandle_img);
header('content-type: image/png');
echo $gdata;
?>

Was macht diese Datei?

Oben kann man zunächst einstellen, wie groß die Bilder sein sollen und welches Bild angezeigt werden soll, wenn nix hinterlegt ist. Anschließend wird eine Prüfung der URL durchgeführt, die einige mögliche Angriffsvektoren ausfiltern soll. Dabei bleiben dann nur Strings mit 32 Zeichen in Groß- und Kleinbuchstaben übrig, andernfalls wird das Script beendet. Im Anschluss wird dann das Bild geholt (per curl, wenn möglich), gespeichert und ausgegeben. Das verzeichnis /path/to/your/document/root/g/ sollte hierzu vorhanden sein.

Warum der Unterordner /g/? Ich wollte mir damit offen halten, verschiedene Bildertypen zu cachen. Das habe ich gelöst, indem ich meinen Bilderhashes ein "/g/" vorstelle, welches diese als Gravatar-Bilder markiert. Fällt mir also irgendwann mal ein, dass ich beispielsweise gerne noch Pavatar (wie auch immer geartet) cachen möchte, dann kann ich dies hier einbauen.

Meine Url sieht also am Ende so aus:

http://img.yourdomain.tld/g/a9ec4695d424a6dcb6f896afb0ee22bc.png

und wird bei ersten Aufruf gecached mittels php und anschließend in den weiteren Aufrufen immer statisch durch den Webserver ausgegeben. Möchte man nun regelmäßig die Bilder aktualisieren, empfiehlt es sich, das hier bereits vorgestellte Script in regelmäßigen Abständen laufen zu lassen.

Für den Einbau in Wordpress ist das ganze auch recht einfach. Man öffnet die comments.php und sucht darin den Aufruf:

PLAIN TEXT

CODE:

( $comment, 32); ?>

Diesen ersetzt man dann durch:

PLAIN TEXT

CODE:

" . md5(strtolower(get_comment_author_email())) . ".png' height='32' width='32'>"; ?>

Wobei die Domain und die Größe natürlich austauschbar sind.

Zu guter letzt noch ein Hinweis für Apache-Nutzer: Das PHP-Script lässt sich natürlich auch mit diesem Webserver nutzen.

Auslieferung von Gravatar-Icons aus einem lokalen Cache – Download per curl

Uli — Fri, 19 Feb 2010 10:25:17 +0000

Vor einigen Tagen bin ich über Crazytoast auf einem Blog auf die Idee der Auslieferung der Gravatar-Bilder aus einem lokalen Cache gestoßen. Prinzipiell fand ich das keine schlechte Idee, da auch bei mir einige Ladezeit von Gravatar verursacht wird. Auch der regelmäßige Refresh erschien mir als durchaus sinnvoll. Lediglich die Art der Einbindung wollte mir noch nicht so recht gefallen. Auch programmiertechnisch fehlten mir einige Dinge.

So wurde beispielsweise als einzige Möglichkeit des Herunterladen der Bilder die Funktion fopen() angeboten, welche jedoch bei den meisten Hostern deaktiviert (allow_url_fopen=0) wird, da es durchaus genügend Beispiele für Sicherheitslücken welche durch die unkluge Nutzung dieser Funktion gibt. Aus meinem Patch für Piwik habe ich daher einen Teil des Codes extrahiert, welcher es mir erlaubt, curl zu benutzen.

Wie bei Plerzelwupp beschrieben muss man zunächst die comments.php öffnen und die folgende Zeile suchen:

PLAIN TEXT

CODE:

( $comment, 60); ?>

Das zweite Argument der Größe könnte bei euch auch durchaus anders aussehen!

Wie auch immer, man löscht jedenfalls diese Zeile und setzt dafür den folgenden Code ein:

PLAIN TEXT

CODE:

// Script originally from:
// http://www.plerzelwupp.de/wordpress-gravatare-cachen/
//
// Modified by Uli from http://wolf-u.li:
// - Translation
// - Cleanup
// - Added curl
// Modify the settings below according to your needs:
// Path to the cache-directory of the gravatar images:
$gimagecachedir = "upload/g/";
// Path of the directory of the gravatar-images:
$gimageurldomain = "http://wolf-u.li/upload/g/";
// Size of the gravatar-images:
$gimagesize = 64;
// If the mailadress was not found, you can get various images:
// - identicon
// - monsterid
// - wavatar
$mailnotfound = "identicon";
// Do not modify the code below:
$gravatar_hash = md5(strtolower(get_comment_author_email()));
$gcachetime = 40320 * 60; // 40320 = 4 Weeks
$gimage = $gimagecachedir . "/" . $gravatar_hash . ".png";
if (!file_exists($gimage) || (time() - $gcachetime> filemtime($gimage))) {
ob_start();
$grav_img = "http://www.gravatar.com/avatar/" . $gravatar_hash . "?s=" . $gimagesize . "&d=" . $mailnotfound . "&r=G";
if(extension_loaded('curl')) {
$gch = @curl_init();
$gcurl_options = array(
CURLOPT_URL => $grav_img,
CURLOPT_HEADER => false,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 20,
CURLOPT_BINARYTRANSFER => is_resource($file),
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_MAXREDIRS => 2
);
@curl_setopt_array($gch, $gcurl_options);
$gdata = @curl_exec($gch);
@curl_close ($gch);
unset($gch);
} else {
ob_start();
$gfilehandle_url = fopen($grav_img, "rb");
fpassthru($gfilehandle_url);
fclose($gfilehandle_url);
$gdata = ob_get_contents();
ob_end_clean();
unset($gfilehandle_url);
}
$gfilehandle_img = fopen($gimage, "wb+");
fwrite($gfilehandle_img, $gdata);
fclose($gfilehandle_img);
unset($gfilehandle_img);
unset($gdata);
}
echo " . $gimageurldomain . $gravatar_hash . ".png' height='" . $gimagesize . "' width='" . $gimagesize . "'>";
?>

Über die Einstellungen im Kopf des Codes kann man nun das Cacheverzeichnis festlegen. Die darauffolgende URL ist die URL, so wie sie zum Bild zeigen würde. Darunter befindet sich die Größe.

Die konkreten Änderungen gegenüber der Version des Blogs:

Übersetzung des Codes auf Englisch (sorry, ich steh da drauf)
Cleanup, Entfernung überflüssiger Codestücke
Einbau von Curl als präferierte Downloadoption
Entfernung der Erstellung von HTML-Dateien, da dies nicht benötigt wird

Soweit so gut. Nun habe ich noch das CronJob-Script von diesem Blogeintrag auf infoblog.li kurz aufgeräumt:

PLAIN TEXT

CODE:

// Script originally from:
// http://infoblog.li/wordpress-gravatar-cache-mit-automatischer-aktualisierung/
//
// Modified by Uli from http://wolf-u.li:
// - Translation
// - Cleanup
// - Added curl
// Modify the settings below according to your needs:
// Path to the cache-directory of the gravatar images:
$imagecachedir = "blog/cdn-g/";
// Size of the gravatar-images:
$imagesize = 64;
// Update files older than this time:
$maxcacheage = 604800; // 7 * 24 * 3600 = 7 Days
// If the mailadress was not found, you can get various images:
// - identicon
// - monsterid
// - wavatar
$mailnotfound = "identicon";
// Do not modify the code below:
$handle= opendir($imagecachedir);
while ($file = readdir ($handle))
{
// Einzelne Pfade und Dateinamen auslesen
$gravatar_hash = substr($file, 0, 32);
$gravatarimg = $imagecachedir . $file ;
if ($gravatar_hash != ".." && $gravatar_hash != ".")
{
// Update only if timestamp of the file is older than $maxcacheage
$cachedtime = filemtime($gravatarimg) - time();
if ($cachedtime> $maxcacheage)
{
$grav_img = "http://www.gravatar.com/avatar/".$gravatar_hash."?s=" . $imagesize . "&d=" . $mailnotfound . "&r=G";
if(extension_loaded('curl')) {
$ch = @curl_init();
$curl_options = array(
CURLOPT_URL => $grav_img,
CURLOPT_HEADER => false,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 20,
CURLOPT_BINARYTRANSFER => true,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_MAXREDIRS => 2
);
@curl_setopt_array($ch, $curl_options);
$data = @curl_exec($ch);
@curl_close ($ch);
unset($ch);
} else {
ob_start();
$filehandle_url = fopen($grav_img, "rb");
fpassthru($filehandle_url);
fclose($filehandle_url);
$data = ob_get_contents();
ob_end_clean();
unset($filehandle_url);
}
$filehandle_img = fopen($gravatarimg, "wb+");
fwrite($filehandle_img, $data);
fclose($filehandle_img);
unset($filehandle_img);
unset($data);
}
}
}
closedir($handle);

Was macht dieses Script? Es aktualisiert alle 7 Tage die Gravatars, die bereits im Cache liegen. Auch dieses Script wurde auf curl umgestellt und ein bisschen aufgeräumt. Ich rate dazu, das Script wenigstens alle Stunde einmal ausführen zu lassen, um die Anzahl der gleichzeitig zu aktualisierenden Gravatare so gering wie möglich zu halten. Dies kann entweder per lokalem CronJob, oder einem CronJob-Dienst aus dem Internet wie beispielsweise cronjob.de ausgeführt werden (HowTo für letzteren Fall).

Meine letzten Hinweise zur Performance: Man sollte sich im klaren sein, dass bei größeren Kommentaranzahlen (sagen wir mal 300) auch bei jedem Kommentar geprüft wird, ob die Datei vorhanden ist (d.h. 300 Dateisystemaufrufe). Das kann definitiv bremsen.

Daher habe ich mir eine andere Methode der Auslieferung überlegt, welche ich in einem weiteren Artikel beschreiben werde.

wolf-u.li hat Pagerank 3 bekommen

Uli — Wed, 08 Apr 2009 21:27:46 +0000

Wie ich gerade gesehen habe, hat mir das Pagerank-Update von diesem Monat einen Pluspunkt beschert. So hat sich also diese Seite 1111 Tage nach dem ersten Beitrag auf PR3 gesteigert Bringt zwar erstmal nicht sooo arg viel, aber freut mich, dass Google mich mag

Umstieg von Disclose-Secret und Role-Manager auf Role-Scoper

Uli — Wed, 18 Mar 2009 17:07:56 +0000

Seit Ewigkeiten habe ich auf meiner Seite Disclose-Secret und Role-Manager zum Schutz privater Beiträge in Betrieb gehabt. Leider funktioniert dieser nach Umstieg auf Wordpress 2.7 nur noch sehr eingeschränkt, bei Bearbeitungen und neuen Beiträgen gar nicht mehr.
Auf der Suche nach einer Alternative stieß ich auf das Plugin Role-Scoper, welches nach einigen Feature-Requests meinerseits nun problemlos eine Authentifizierung im RSS-Feed und eine Zuordnung von Beiträgen zu Gruppen unterstützt.
Neben meinem regulären RSS-Feed ist nun für registrierte Leser mit den entsprechenden Gruppenzuweisungen auch ein gesonderter Feed verfügbar, in welchem ein paar Beiträge zusätzlich verfügbar sind.
Im Gegensatz zu Disclose Secret arbeitet das Plugin einwandfrei unter Wordpress 2.7 und integriert sich problemlos in die Oberfläche.

Der Autor ist an einer Weiterentwicklung interessiert und veröffentlicht beispielsweise nach einem Bugreport auch schnell neue Versionen.

Sollen RSS-Feeds gekürzt oder ungekürzt erscheinen?

Uli — Thu, 26 Feb 2009 17:05:44 +0000

Inspiriert durch mehrere Beiträge, zuletzt durch And reas, aber auch durch Frank Bueltges und ein paar andere möchte ich mal erfahren, wie meine Leser den RSS-Feed gerne hätten.

Ungekürzt: Kompletter Beitrag im Feed
Gekürzt: So wie bisher nur ein Auszug im Feed

~~Der Poll bleibt eine Woche offen, mal schauen, was die Leser so meinen.~~
Die Leser haben entschieden, dass der Feed ungekürzt erscheint.

Wordpress 2.7.1 ist erschienen

Uli — Tue, 10 Feb 2009 21:20:40 +0000

Soeben ist Wordpress 2.7.1 erschienen und bringt einige Fixes mit sich. Das Updatepaket für die DE-Version ~~wird sicher auch bald kommen.~~ ist auch erschienen.