Die Macher von WordPress.de bieten seit dem 11. Oktober 2005 nun auch einen Ping-Service an. Die Pings können auf ping.wordblog.de gesendet werden und die Liste der aktualisierten Blogs erscheint sowohl auf WordPress.de als auch auf WordBlog.de.
Mehr Informationen dazu gibts direkt bei Worldblog.de unter Pingservice.
Nun bin auch ich an einen Account bei wordpress.com gekommen und konnte mich auf dem neuen kostenlosen Blog-Hostingservice des „WordPress-Erfinders“ Matt Mullenweg etwas umsehen. Der Service läuft unter WordPress MU und bietet bereits einige Features der kommenden 1.6-Version von WordPress wie den WYSIWYG-Editor und eine Anzeige der Referrer.
Die Themes sind vorgegeben und nicht editierbar und stehen derzeit nur in Englisch zur Verfügung.
Wer das nun selbst ausprobieren und eine Einladung für wordpress.com haben möchte, hinterlässt einfach einen Kommentar hier und schon gehen Träume in Erfüllung 😉
Aber Achtung: Ich habe derzeit nur einen einzigen Invite zu vergeben. Ob ich danach die Möglichkeit habe weitere Invites zu vergeben, habe ich noch nicht herausgefunden.
Wer lieber eingedeutschte Templates nutzen will, findet bei wordblog.de eine entsprechende Anmeldung. Auch dort ist der Service noch nicht öffentlich, aber einmal angemeldet, kommt man sicher früher oder später zu einem Invite.
Und zum Schluss noch dies: Geld lässt sich mit einem solchen Invite offenbar nicht machen…
Nachdem ich in den letzten Wochen Pingbacks aus anderen Blogs vermisste, obwohl dort auf Posts hier verwiesen wurde, wurde ich misstrauisch. Und siehe da, Robert Basic berichtete mir via eMail vom gleichen Phänomen.
MacManX ging der Sache auf den Grund und nun ist zumindest klar, wo das Problem liegt: Bad Behavior 1.2.1 und 1.2.2 blocken als neues Feature alle Requests, welche einen leeren user-agent string enthalten. Und Pingbacks von WordPress Blogs enthalten tatsächlich einen leeren user-agent string. Somit verwehrte Bad Behavior in den letzten Wochen allen hier eingehenden Pingbacks den Zugriff.
Der grundsätzliche Ansatz von Bad Behavior ist zwar durchaus gut gemeint, aber im Nachhinein betrachtet doch etwas zu rigoros. Immer wieder mussten Updates des Plugins durchgeführt werden, da dieses einmal den MSN-Bot und dann wieder irgend jemand anders aussperrte. Das macht die Verwaltung des Plugins aber äusserst aufwendig und lässt einem immer wieder zweifeln, ob man vielleicht gerade wieder jemanden aussperrt.
Ich habe mich darum nach den ersten positiven Erfahrungen von Robert mit Spam Karma 2 entschlossen, diesem Plugin eine Chance zu geben. Immerhin werden mit Spam Karma 2 die Requests nicht von vorneherein verweigert und False-Positives lassen sich ohne Probleme zurückholen.
Für alle, die sich eine Installation von SpamKarma 2 überlegen, sei an dieser Stelle noch auf den Post von Thomas Schewe, „Bad Behavior blockt Spamkarma 2„, hingewiesen, welcher erklärt, wieso in den Optionen von Spam Karma 2 die Option TrackBack Referrer Check ausgeschaltet werden sollte.
So, und nun hoffe ich auf erfolgreiche Testwochen mit Spam Karma 2.
… war das Erste, was mir heute beim Abruf meiner Seiten aufgefallen ist. Ein kurzer Blick auf den Server zeigte denn auch eine Prozessorauslastung von 100%, welche der Apache– und MySQL-Dienst unter sich aufteilten. Das Error-Log des Apache zeigte denn auch seitenweise
PHP Warning: mysql_affected_rows(): A link to the server could not be established in wp-db.php on line 155
an, was an sich ja wirklich auf einen Fehler oder zumindest ein Problem hinwies. Da ich in den letzten Tagen nichts an den Konfigurationen gebastelt habe, fiel die Fehlersuche um so schwerer. Nach Rumpröbeln an den Apache- und MySQL-Konfigurationen dann endlich doch mal ein erleuchtender Einfall: Wieso nicht mal die WordPress-Plugins der Reihe nach deaktivieren?
Und siehe da, mit ausgeschaltetem Bad Behavior lief der Server auf einmal wieder rund. Aber um die Ehre von Bad Behavior zu retten: Schuld war nicht das Plugin selbst, sondern die dazugehörigen Datenbanktabellen. Wieso ist mir bis jetzt allerdings noch immer nicht klar, denn die Tabellen waren weder korrupt noch sonstwie beschädigt.
Lange Rede, kurzer Sinn: Bad Behavior-Tabellen gelöscht und schon läuft das Serverchen wieder auf Hochtouren 🙂
Ein neuer WordPress-Exploit geistert derzeit durch das Internet. Betroffen sind alle WordPress-Versionen bis und mit 1.5.1.3 bei welchen die PHP-Variable register_globals=on gesetzt ist.
Ist register_globals auf off gesetzt (was heutzutage ja meist der Fall sein sollte), besteht keine Gefahr, wie Florian Holzhauser berichtet.
(via BasicThinking)
WordPress ist ab sofort in der Version 1.5.1.3 erhältlich. Das Update soll ein Sicherheitsproblem beheben, wie im WordPress Blog zu lesen ist:
The problem is not yet public but you should update your blog as soon as possible to 1.5.1.3. If you are unable to do upgrade in the short-term you may protect yourself by deleting the xmlrpc.php file from your WordPress directory.
Und wenn wir grade bei Updates sind: Auch das Plugin Bad Behavior erfuhr ein Update und ist nun in der Version 1.1.2 erhältlich. Auch hier ist ein Update zu empfehlen, da die vorherige Version offenbar den MSNBot aussperrt.
[ Update ] 15:00 Uhr
Evil.Bert schreibt in seinem Blog dimension2k:
Mehr Details über die Schwachstelle wurden bislang noch nicht veröffentlicht, allerdings scheint das Problem weitreichender zu sein. In einem heute auf Heise.de veröffentlichten Artikel über eine Schwachstelle im CMS-Postnuke wird den Usern ebenfalls geraten die Datei xmlrpc.php zu löschen.
Das Changelog zur Version 1.5.1.3 befindet sich übrigens hier.
Habe soeben dieses Blog auf die neueste WordPress-Version 1.5.1.2 aktualisiert und hatte kurzfristig einen kleinen Schock, da danach keine Blogseiten mehr angezeigt wurden.
Zum Glück nach 10 Minuten Entwarnung: Schuld ist das Plugin „Entity2NCR„, welches nicht mit mit der WordPress-Version 1.5.1.2 kompatibel ist. Zum Glück hatte ich noch im Hinterkopf, mal etwas über die Inkompatibilität des Plugins mit WP 1.5.1.2 gelesen zu haben.
Tatsächlich steht dies auch auf der Homepage des Plugins:
If you are running 1.5.1 or above, do NOT install Entity2NCR. You don’t need it, and will run into problems due to the plugin’s function having the same name in the WordPress core.
Solltet ihr auf andere Probleme stossen, wäre ich für eine kurze Mitteilung (bruehwiler @ gmail punkt com) dankbar.
Owen hat ein neues Tool zum Testen der Track- und Pingback-Funktionen von Blogs online gestellt. Pingomation zeigt die Zeit, wann das Blog das letzte Mal Ping-o-Matic angepingt hat und bietet gleichzeitig die Möglichkeit, ein- und ausgehende Trackbacks und Pingbacks zu testen.
Da das gerade erschienene WordPress 1.5.1 offenbar Probleme mit Trackbacks hat, kommt Pingomation gerade richtig um die Funktionen nach erfolgtem Upgrade zu testen.
(via Asymptomatic)
Im Januar 2005 kündigte Google an, zusammen mit MSN und Yahoo ein neues Attribut für die Kennzeichnung von Links einzuführen. Das neue „nofollow“-Attribut soll bewirken dass
Die Suchmaschinenbetreiber argumentieren, dass das neue Attribut helfe mit, Spam in Kommentaren von Blogs zu minimieren, da die Suchmaschinen die gekennzeichneten Links nicht indizieren würden. Wie viele Blogger bin auch ich der Meinung, dass dies der falsche Weg ist.
Leider fügt WordPress das „nofollow“-Attribut standardmässig den Kommentatoren-Links zu und es gibt keine Möglichkeit, dieses Verhalten in der Administration ein- oder auszuschalten. Tom Raftery beschreibt in einem Artikel nun aber, welche Dateien einer WordPress-Installation geändert werden müssen, damit das „nofollow“-Attribut nicht mehr angezeigt wird.
Für alle, die sich lieber mit einer deutschen Anleitung auseinandersetzen, liefere ich hier eine Übersetzung:
In der Datei wp-includes/comment-functions.php ist Zeile 173 wie folgt zu ändern:
Ändere
rel='external nofollow'
zu
rel='external'
In der Datei wp-includes/default-filters.php lösche Zeile 173
add_filter('pre_comment_content', 'wp_rel_nofollow', 15);
und in der Datei wp-includes/functions-formatting.php lösche die Zeilen 490-494:
function wp_rel_nofollow( $text ) {
$text = preg_replace('||i', '', $text);
return $text;
}
Und zum Schluss sind, ebenfalls in der Datei wp-includes/functions-formatting.php, in den Zeilen 482-489 alle Vorkommnisse von rel='nofollow' zu löschen. Achtung: Lösche nur den Code rel='nofollow' und nicht die gesamte Zeile.
Das wars auch schon! Euer WordPress-Blog ist nun nofollow-frei!
[Update] 15.05.2005
Obige Anleitung bezieht sich auf WordPress 1.5. Wie Karsten in den Kommentaren berichtet, funktioniert die Anleitung bei WordPress 1.5.1 nicht mehr.