define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8');

und unter der WP-Adminstration > Einstellungen > Lesen stand UTF-8 unter der Option “Zeichensatz für Seiten und Feeds”. Weshalb wird dies jetzt nach dem Upgrade plötzlich zum Problem?

Ein Blick auf die MySQL-Tabellen via phpMyAdmin offenbart es:

Hier sollte normalerweise utf8_general_ci stehen und eben nicht latin1_swedish_ci.

Schritt 1: MySQL-Tabellen auf UTF-8 umstellen

Nun gilt es also, die MySQL-Tabellen auf UTF-8 umzustellen. Ich habe hierzu einen MySQL-Dump erzeugt, d.h. mittels phpMyAdmin die Tabellen als Text-Datei exportiert. Danach habe ich, wie es auch auf Texto.de beschrieben ist, mittels Suchen/Ersetzen im Texteditor alle Vorkommnisse von CHARSET=latin1 durch CHARSET=utf8 ersetzt. Zum Schluss noch die Tabellen via phpMyAdmin leeren oder löschen und dann die bearbeitete Textdatei wieder hochgeladen. Als Ergebnis steht dann überall utf8_general_ci:

Alternativ kann man übrigens auch das WordPress-Plugin UTF-8 Database Converter eingesetzen. Aber aus irgend einem unerfindlichen Grund machte ich das ganze lieber manuell per Suchen/Ersetzen.

Schritt 2: Umlaute und Sonderzeichen konvertieren

Damit war es leider nicht getan, es wurden nach wie vor die Umlaute und Sonderzeichen wirr dargestellt ( “ĂĽ” statt “ü” usw.). Hier habe ich nun das Tool DSB’s Umlaut Korrektur (DUK) vom MySQLDumper-Entwickler eingesetzt (auf das Nils bei Perun aufmerksam machte).

Das ganze gestaltete sich sehr einfach: man muss nur in die mitgelieferte PHP-Datei die Datenbank-Daten eintragen (Server, DB-Name, Passwort) und diese dann auf den Webspace hochladen. Danach ruft man die Windows-exe-Datei duk.exe auf, gibt den Pfad zur PHP-Datei an und kann nun per 3 Mausklicks völlig entspannt das Zeichen-Wirrwarr automatisch korrigieren lassen.

Damit wurden sämtliche Umlaute und Sonderzeichen im Blog wieder korrekt angezeigt.

Frank Bültge hat übrigens eine Übersicht aller Sonderzeichen zusammengestellt.

Vorstellung des SEO-Plugins izioSEO

LazyBrain stellt unter izioSEO – WordPress SEO Plugin für Lau ein weiteres SEO-Plugin für WordPress vor und meint dazu:

Ich werde das SEO-Plugin nun ein paar Tage testen, bin aber eigentlich schon überzeugt davon und als kostenlose Alternative zu dem wirklich sehr guten wpSEO-Plugin für WordPress kann man es nur empfehlen.

WordPress 2.7.1

Gestern wurde die WordPress-Version 2.7.1 veröffentlicht. Es handelt sich dabei um ein reines Wartungsrelease ohne neuer Features, es wurden inssgesamt 68 Fehler behoben. Man muss sich daher keine Sorgen um bestehende Plugins oder Themes machen; alles was unter der Version 2.7 lief soll auch unter 2.7.1 ohne Probleme laufen. Nichtsdestotrotz ist ein Backup der Dateien sowie der Datenbank beim Update anzuraten.
Wenn man WP 2.7 einsetzt, kann man zum Updaten auch das “Automatische Update” verwenden, in dem man in der WP-Adminstration auf den entsprechenden Link klickt.

10 Schritte zum Schutz des Admin-Bereichs

Der schon im Dezember veröffentlichte Artikel 10 Schritte zum Schutz des Admin-Bereichs von Sergej Müller wurde nun auch im Smashing Magazine in Englisch publiziert.

Die WordPress-Administration seit Mai 2003

Unter A Journey Through Five Years of WordPress Interface gibt es jede Menge Screenshots zu den WP-Administrationsbereichen von der Version 0.7.1 bis zur 2.7.

Theme-Optimierungen für Kommentare unter WordPress 2.7.x

Seit WordPress 2.7 wurde einiges für die Kommentare in den Themes getan, Frank Bültge geht auf die Themen Threaded Comments und Zähler für Kommentare, Track- und Pingbacks ein.

WordPress Permalinks und die Performance

Im Artikel Permalinks und die Performance gehe ich auf neue Informationen über den Aufbau von Permalinks im Zusammenhang mit der Blogperformance ein, bitte auch die Kommentare lesen.

Benutzergruppen in WordPress – Wer darf was

Perun hat in einem Artikel die Benutzergruppen von WordPress (Admin, Autor, etc.) ausführlich erklärt, außerdem gibt es eine PDF-Datei als tabellarische Übersicht.
Achtung: Perun verwendet zur offiziellen deutschen Übersetzung abweichende Begriffe (z.B. “Abonnent” statt “Registrierter Leser”), seine Begriffe stammen wohl aus der inoffiziellen Übersetzung.

WordCamp 2009 am 14.02. in Jena

Zum Schluss möchte ich noch mal an das WordCamp 2009 in Jena erinnern, das an diesem Wochenende stattfindet. Es wird u.a. auch Matt Mullenweg teilnehmen, wer sonst noch kommen wird könnt Ihr in der Teilnehmerliste sehen.

http://www.beispiel.de/?p=1234

schönere URLs wie etwa

http://www.beispiel.de/kochrezepte/Apfelstrudel

generieren zu lassen. Das dient u.a. der Benutzerfreundlichkeit und bietet Vorteile im Bereich der Suchmaschinenoptimierung. Den Aufbau (auch “Struktur” genannt, übersetzt vom engl. “structure”) der Permalinks kann man dabei fast beliebig festlegen, z.B.

• www.beispiel.de/[Jahr]/[Monat]/[Tag]/[Artikel-Titel]
• www.beispiel.de/[Kategorie]/[Artikel-Titel]
• www.beispiel.de/[Autor]/[Artikel-Titel].

Wie Dougal Campbell nun darstellt, können manche Permalink-Kombinationen zu massiven Performance-Problemen im Blog führen.
Werden nämlich Permalinks mit den Bestandteilen Kategorie (%category%), Tag (%tag%), Autor (%author%) oder Artikel-Titel (%postname%) eingeleitet, so speichert WordPress in der Optionen-Tabelle im Feld “rewrite_rules” umfangreiche Informationen für jede im Blog vorkommende Seite (“Page”, nicht aber “Post” bzw. Blog-Artikel) ab. Lt. Dougal ist nur dadurch WordPress einigermaßen performant in der Lage, anhand der URL auf die tatsächliche interne ID des Artikels bzw. der Seite zu schließen.

Betreibt man nun ein Blog mit vielen angelegten Seiten (“Pages”), so kann sich dieses Datenbankfeld “rewrite_rules” ins fast unermessliche füllen, was zu entsprechenden Performanceproblemen führen kann. So berichtet matthijs auf der [wp-testers] Mailingliste, dass er in einem seiner Blogs dieses Datenbankfeld nicht mehr per Browser oder Texteditor öffnen kann, weil beides dann aufgrund der großen Datenmenge einfach abstürzt.

On one of my sites I can’t even open the database field to take a look because my browser and text editor crash because of its size.

Im Folgenden mal als Beispiel, welche Information genau WordPress in dem Datenbankfeld ablegt, wenn wir eine der o.g. Permalinkstruktur verwenden und eine neue Seite “testseite-1″ anlegen:

[testseite-1/attachment/([^/]+)/?$] => index.php?attachment=$matches[1]
[testseite-1/attachment/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[testseite-1/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[testseite-1/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[testseite-1/attachment/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]
[(testseite-1)/trackback/?$] => index.php?pagename=$matches[1]&tb=1
[(testseite-1)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(testseite-1)/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(testseite-1)/page/?([0-9]{1,})/?$] => index.php?pagename=$matches[1]&paged=$matches[2]
[(testseite-1)/comment-page-([0-9]{1,})/?$] => index.php?pagename=$matches[1]&cpage=$matches[2]
[(testseite-1)(/[0-9]+)?/?$] => index.php?pagename=$matches[1]&page=$matches[2]

Diese Information wird für jede Blog-Seite angelegt; daher ist wohl leicht vorstellbar, wie viele Daten sich bei einem Blog mit mehr als 1000 Seiten in dem einzigen Datenbankfeld ansammeln.

wordpress.org hat inzwischen reagiert und in der Permalinks-Dokumentation den folgenden Hinweis aufgenommen:

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to start your permalink structure with a numeric field, such as the year or post ID.

Fazit

Nach meiner Einschätzung kann man auch weiterhin einen Nicht-Zahlenwert, also z.B. die Kategorie (%category%), als ersten Permalink-Bestandteil verwenden, solange man nicht vorhat, viele Seiten (“Pages”) im Blog anzulegen. Klassische Blogs sind damit also wohl nicht wirklich betroffen, da diese im Gegensatz zu vielen Posts meist nur eine Hand voll Pages aufweisen (z.B. “Über das Blog”, “Impressum”, “Kontakt”, …). Ganz anders kann es allerdings bei Webauftritten aussehen, bei denen WordPress als CMS eingesetzt wird. Beispielsweise sind in diesem Fall folgende Permalink-Strukturen anzuraten und führen nicht zum Aufblähen des Datenbankfeldes:

/%year%/%month%/%day%/%postname%/
/%year%/%month%/%postname%/
/%year%-%month%-%day%/%postname%/
/%year%-%month%/%postname%/
/%year%/%postname%/
/%post_id%/%postname%/
/%post_id%-%postname%/
/%post_id%/%category%/%postname%/
/%year%/%category%/%postname%/
/%year%-%postname%/

WordPress passt übrigens das Datenbankfeld automatisch an, sobald man die Permalink-Struktur aktualisiert und speichert.

• Lokalisierung eingeführt
• Links zu bestimmten Websites können automatisch mit rel="nofollow" ausgezeichnet werden.
• Es können nun mehrere Suchbegriffe gleichzeitig eingetragen werden
• Auf Wunsch wird die CSS-Datei des Plugin-Verzeichnisses verwendet, Beispiel-Icons liegen ebenfalls bei.
• websnapr.com Thumbnail-Vorschau optional zuschaltbar; diese Bildchen erscheinen dann, wenn man mit der Maus über einen Link fährt. Wer’s halt braucht…
• Kleinere Fehlerbehebungen und Anpassung für WordPress 2.7

In diesem Zuge habe ich vor ein paar Tagen auch das vom mir geschriebene Plugin Maintenance Mode eine Version 4.0 herausgebracht, die neben mehrereren behobenen Fehlern nun auch eine Lokalisierung ermöglicht und jetzt im Admin-Bereich auch in Deutsch ist. Weitere Updates meiner Plugins folgen die nächsten Tage.

Neben Software Guide betreibe ich zusammen mit den Moderatoren Metty und Andreas noch die Website Blog-Parade.de, auf der Blog-Paraden bzw. Blog-Karnevals zentral angekündigt werden.

Für Blog-Parade.de habe ich im Zuge des Updates auf WordPress 2007 ein von mir geschriebenes internes Plugin sowie das Role-Manager-Plugin entfernt und setze stattdessen nun Adminimize und Peter’s Collaboration E-mails ein. Beide Plugins ergänzen sich perfekt und bieten die Möglichkeit, die Rechte selbständig anmeldender Gäste ausreichend einzuschränken (Adminimize) sowie die Moderatoren per E-Mail zu benachrichtigen, sobald ein angemeldeter Besucher einen Beitrag zur Freigabe eingereicht hat (P.C. E-mails). Diese Kombination kann ich jedem empfehlen, der auf einer mit WordPress betriebenen Website Besuchern die Möglichkeit geben will, Artikel vorzuschlagen bzw. selbständig zu schreiben und von einem oder mehreren Moderatoren freigeben zu lassen.

Obwohl seitdem mehrere Tage vergangen sind, möchte ich dennoch meine Meinung hierzu äußern, auch weil mich Frank danach fragte:

Üblicherweise haben bislang WordPress-interessierte die Feeds der einschlägigen deutschsprachigen Blogs abonniert, darunter u.a. bueltge.de, perun.net, blog.wordpress-deutschland.org, sw-guide.de, etc. Dadurch ist man dann einigermaßen auf dem Laufenden, bekommt Sicherheitsupdates mit, usw. Wer dann noch Englisch versteht, hat vielleicht zusätzlich noch wordpress.org/development und ggf. ein paar weitere englischsprachige Blogs abonniert und ist damit dann eigentlich sehr gut über WordPress informiert.

Würde man nun ein klassisches Blog mit mehreren Autoren aus dem Boden stampfen, das ganze mit “WordPress-Magazin” titeln und erwarten, dass (Gast-)autoren Beiträge in dieses Blog klopfen, so wäre dies m.E. zum scheitern verurteilt. Warum sollte ein Autor schließlich auf einem fremden Blog bloggen, wenn dies auf eigenen Blog genau so gut klappt?

Was meines Erachtens aber klappen würde, wäre folgendes Konstrukt:

Mehrere WordPress-Autoren, die jeweils schon in der Vergangenheit einige WordPress-Beiträge veröffentlicht haben und entsprechendes Know-how mitbringen, schließen sich zu einem Moderations-Team zusammen. Es gibt dann eine zentrale Webseite wordpress-magazin.irgendwas und nur diese Moderatoren können dort Artikel veröffentlichen.

Jetzt gehen wir mal davon aus, dass z.B. Frank Bültge unter diesen Moderatoren ist: Frank schreibt nun auf seinem eigenen Blog (bueltge.de) einen Beitrag, den er für veröffentlichungswert auf der Magazin-Webseite hält, also taggt er seinen Beitrag mit wp-magazin:publish. Sein im Hintergrund laufendes Magazin-Wordpress-Plugin registriert das und veröffentlicht diesen Artikel dann auch auf der Magazin-Webseite.

Nehmen wir weiter an, ich bin nicht in diesem Moderations-Team, wäre aber der Meinung, eben einen tollen WP-Artikel geschrieben zu haben, der auch auf der Magazin-Seite erscheinen soll, so kann ich z.B. ein Magazin-Plugin bei mir im Blog installieren und den Artikel mit wp-magazin:publish taggen. Daraufhin wird mein Artikel zur Prüfung beim Magazin eingereicht und die Moderatoren dort bekommen eine E-Mail. Alternativ (wenn ich das Plugin nicht installiert habe) kann ich auch per Webformular oder Login auf meinen Beitrag aufmerksam machen und die Moderatoren prüfen diesen. Schreibe ich nun mehrere gute Artikel als Gastautor, bekomme ich vielleicht auch das Recht, selbständig Artikel ohne Review zu veröffentlichen.

Um dann auch eine gewünschte Themenvielfalt zu erreichen, müsste das Moderations-Team natürlich entsprechend regelmäßige Reviews durchführen und als Ergebnis manche Themen pushen, versuchen Schwerpunkte zu verlagern, etc.

Bezüglich Ansässigkeit eines solchen Magazins, also ob bei wordpress-deutschland.org, de.wordpress.org oder unter einer eigenen Domain, wäre ich völlig leidenschaftslos.

Leider hat es MustLive nicht für nötig empfunden, mich als Autor über seine Entdeckung zu informieren, so dass ich davon nichts mitbekommen habe. Glücklicherweise hat mich aber Robert Basic heute per E-Mail auf den Artikel aufmerksam gemacht.

Ich habe daraufhin nun die Sicherheitslücke geschlossen und die Version 2.2 veröffentlicht, die zum Download zur Verfügung steht.

Die Sicherheitslücke war in allen bisherigen Plugin-Versionen enthalten und es war zumindest theoretisch möglich, über die Plugin-Optionen für die Ausgabe der Fehlermeldungen bei Eingabe einer falschen Lösung einen schadhaften Code auszuführen. Grundsätzlich empfehle ich jedem, das Update durchzuführen. Ich werde dies auch zum Anlass nehmen, meine anderen Plugins die nächsten Tage auf Sicherheitslücken zu prüfen.

Was ist neu in WordPress 2.3?

Die wichtigsten Neuerungen in WordPress 2.3 sind:

• Eingebautes Tagging, weiteres hierzu siehe weiter unten.
• Unter «WP-Administration > Plugins» wird nun angezeigt, von welchen installierten Plugins es Updates gibt:
  
  Dabei telefoniert allerdings WordPress in Microsoft-Manier nach Hause, weiteres hierzu siehe weiter unten.
• Aufgeräumte URLs: ist ein Blog z.B. unter www.irgend.wo und irgend.wo erreichbar (also mit und ohne www) und steht in der WordPress-Konfiguration z.B. die Blog-URL mit www.irgend.wo, so wird ein Aufruf von irgend.wo automatisch auf www.irgend.wo umgeleitet. Unter WordPress 2.3: Canonical URLs werden Details und weitere Features erläutert.
• Neuer Artikel-Freigabe-Status “Prüfung zur Freigabe” (pending preview): dies war m.E. dringend notwendig, da es bisher neu erstellte Artikel nur im “Entwurf” gab; bei Blogs mit mehreren Autoren war so nicht klar, wann der Artikel fertig geschrieben ist und freigegeben werden kann.

Das nun fest eingebaute Tagging

WordPress hat nun eine Möglichkeit in WordPress eingebaut, Artikel zu taggen ohne dass man dazu separate Plugins installieren muss. Unter WP-Admin > Verwalten > Import lassen sich die Tags von bestehenden Plugins (UTW, Simple Tagging, Jerome’s Keywords) per Mausklick in WordPress 2.3 übernehmen.

Allerdings ist das eingebaute Tagging nicht zufriedenstellend, darauf bin ich bereits im Rückschritt-Artikel eingegangen. Es werden beim Artikel nicht mal die zur Verfügung gestellten Tags angezeigt, sondern man sieht lediglich folgendes Eingabefeld:

Anzeige aller im Blog vorkommender Tags bzw. Tag-Vorschläge und eine Autovervollständigung beim Tippen: Fehlanzeige. Genau so wenig wurde an eine Tag-Verwaltung gedacht. Für die Ausgabe der Tagcloud gibt es keine CSS-Unterstützung, stattdessen wird der Style direkt im HTML ausgegeben.

Wer also ein Plugin wie etwa Simple Tagging bisher einsetzte, wird bitter enttäuscht werden. Dennoch gibt es mittlerweile teilweise eine Abhilfe. Amaury, der mein Plugin Simple Tagging übernahm und weiterentwickelte arbeitet derzeit an einem weiteren Plugin mit dem ähnlichen Namen Simple Tags: dieses soll im Prinzip das in WP 2.3 bestehende Tagging so erweitern, dass das Tagging so komfortabel wird wie vormals unter Simple Tagging.
Ganz ist es dem Autor allerdings noch nicht gelungen: Die Auto-Vervollständigung klappte nicht immer, eine Ausgabe von Related Tags gibt es (noch) nicht, und die Definition der Parameter über die Plugin-Optionen ist auch noch nicht möglich. Dafür gibt es aber bereits eine Tag-Verwaltung und etwa die Anzeige ähnlicher Beiträge.

Letztendlich macht das Plugin Simple Tags das Tagging in WordPress 2.3 wieder annähernd so, wie dies zuvor schon mit Plugins möglich war, die noch fehlenden Features werden wohl auch noch von Amaury nachgereicht.

Lorelle on WordPress hatte sich übrigens auch mit WordPress-2.3-Tagging beschäftigt und verweist auf ein paar weitere Tagging-Plugins für WP 2.3.

WordPress 2.3 telefoniert nach Hause

Heiße Diskussionen gab es um das neue Feature, das in der WP-Administration unter ‘Plugins’ einen Hinweis anzeigt, sobald es von einem Plugin eine neuere Version gibt. Es werden hierzu nämlich Daten an WordPress übermittelt (Blog-URL, PHP-Version, vorhandene Plugins inkl. Version). WordPress-Chef Matt Mullenweg sagt hierzu:

Your blog URL and version has been sent by default for 4+ years to every ping service in the world, including Ping-O-Matic, every time you make a post. Of course you can turn that off, just like you can turn update notification off, but statistically no one does.
The only new information being sent by the update checker is PHP version and a list of plugins. If you don’t like that feature, please install a
plugin to disable it:

http://wordpress.org/extend/plugins/disable-wordpress-core-update/

http://wordpress.org/extend/plugins/disable-wordpress-plugin-updates/

Meine Meinung nach sollte solcher Datenaustausch stets per Default deaktiviert und nur über die Optionen zugeschaltet werden können (inkl. genauer Auflistung, welche Daten hier übertragen werden). Matt Mullenwegs Hinweis “installier’ Dir doch einfach ein Plugin, wenn Du das abstellen willst” halte ich für unprofessionell und dumm.

WordPress 2.3 installieren oder ignorieren?

Die WordPress-Entwicklung läuft derzeit auf zwei Zweigen: (1) WordPress 2.0.x und (2) WordPress in der jeweils aktuellsten Version. Das bedeutet, dass für alle anderen WordPress-Versionen keine Sicherheitslücken geschlossen werden. Setzt man also nicht die neueste Version vom Zweig 2.0.x (derzeit: 2.0.11) oder das neueste WordPress (derzeit eben Version 2.3) ein, so begibt man sich in die durchaus reelle Gefahr, dass jemand das Blog übernimmt. Das geht schnell, und Beispiele für Blog-Übernahmen (Hijacking) gab es in der Vergangenheit einige.

Der sicherheitsbewusste WordPress-Anwender bleibt also am Ball und geht jeweils mit den Aktualisierungen mit, oder wechselt vielleicht gleich das Blog-System; ob sich allerdings die Situation mit anderen Blog-Systemen bessert, ist fraglich. Zumindest ist WordPress aber das am weitesten verbreitete Blogsystem, d.h. es wird der Wahrscheinlichkeit nach am ehesten von bösen Buben (oder auch Mädchen) angegriffen.

Wie von älterer Version upgraden?

Als erstes sollte man mal die Plugins prüfen und aktualisieren. Hilfreich ist hierzu die Liste der unter WP 2.3 kompatiblen Plugins.

Dann das Upgrade durchführen; ich empfehle dabei, stets die Original-Version von wordpress.org herunterzuladen und nicht die von WordPress-Deutschland (WPD) zu nehmen: so wurde zuletzt in der WPD-Version ein Zusatz-Werbe-Plugin eingebaut, ohne die User darüber zu informieren. Zudem besteht die Gefahr, dass sich durch die Modifikationen des WPD-Team Fehler einschleichen, die sich nicht ohne weiteres eingrenzen lassen: eine Klärung über das internationale WP-Team wäre in diesem Fall sehr schwierig.
Einen Vorteil sehe ich durch die WPD-Versionen übrigens nicht: das deutsche Sprachfile gibt es auch hier, und alles weitere (z.B. übersetztes Kubrick-Theme, Links auf gesponserte Blogs, etc.) braucht man meines Erachtens eigentlich nicht.

Kritische SQL-Injektion-Verwundbarkeit seit 22.08.2007 bekannt

Wie Blogsecurity am 22.08. berichtete, wurde eine kritische Sicherheitslücke in WordPress entdeckt, die wohl alle Versionen bis WordPress 2.2 betrifft. Das WordPress-Entwicklerteam wurde entsprechend informiert; ein inoffizieller Patch wurde nicht veröffentlicht, da dadurch Details über die Lücke bekannt würden und dies Hacker entsprechend ausnutzen könnten.
Erstaunlich ist hier, dass es auch 13 Tage nach der Entdeckung weder eine Info/Stellungnahme noch ein Sicherheitsupdate von WordPress gibt. Das ist aber leider so üblich: man möchte zu häufige Sicherheitsupdates vermeiden, um die Community nicht zu verärgern wegen zu vieler notwendiger Updates, so konnte ich dies zumindest über Monate hinweg anhand der Entwickler-Mailingliste mitverfolgen. Dies ist meines Erachtens aber der falsche Weg.

WordPress-Theme-Vorstellungen

1. Sandbox (ein Theme-Gerüst) hatte dazu aufgerufen, minimalistische und standardkonforme WordPress-Themes zu erstellen. Unter And the winners are… werden die besten 20 Themes daraus vorgestellt (es gibt auch eine Live-Preview – oben rechts sind die Themes auswählbar). (via Dr. Web)
2. Mashable listet 30 dreispaltige WordPress-Themes. (via Basic Thinking)
3. Valentin Tomaschek hat die Blog-Parade Die persönlichen Top-Wordpress Templates gestartet, die noch bis zum 15. September läuft. Hier stellen Blogger die jeweils liebsten 5 WordPress-Themes vor. (via Blog-Parade.de)

WordPress automatisch aktualisieren

Cedric Weber stellt unter WordPress automatisch aktualisieren die Möglichkeit vor, gleichzeitig mehrere WordPress-Installationen per Shell-Skript upzugraden.
Eine bei mir seit Monaten bewährte Alternative habe ich übrigens unter Multi-(Sub-)Domain-Blog, CMS oder Wiki vorgestellt.

Firefox-Eweiterung und WP-Plugin, um Themes und Plugins per Mausklick zu installieren

OneClick for WordPress bietet eine Firefox-Eweiterung und ein WP-Plugin, mit dessen Kombination es dann möglich sein soll, Themes oder Plugins per Mausklick automatisch zu installieren: einfach den Download-Link mit der rechten Maustaste anklicken und die entsprechende Auswahl im Kontextmenü tätigen:

Könnte interessant sein und viel Zeit sparen, wenn man ein neues Blog einrichtet und verschiedenes auf die schnelle ausprobieren möchte. (via Blogging Pro)

Vergleich: MovableType 4 und WordPress 2.2

Mashable geht im Artikel MovableType 4 vs. WordPress 2.2 auf die jeweiligen Vorteile und Unterschiede von beiden Blog-Systemen ein. (via Frank Bültge)

WordPress-Update auf 2.3: Rückschritt?

Dies ist ein Artikel von mir zum geplanten Update auf die Version 2.3.

Ein XHTML-Design für 10 US$ in ein WordPress-Theme umwandeln

Das verspricht ThemesPress.com, ich kann mir allerdings nicht vorstellen, dass da was vernünftiges rauskommt. Hat wer Mut und wagt es?

Dokumentation zur Lokalisierung von Themes und Plugins

Auf 49 Suns gibt es mit eine ausführliche Einführung zur Lokalisierung von Themes und Plugins, um Themes und Plugins einzudeutschen.

Kontaktformular-Plugins

Robert Basic hat die Leser nach einem Kontaktformular-Plugin für WordPress gefragt und in den Kommentaren kamen hierzu einige Tipps. Ich persönlich verwende allerdings ein selbst geschriebenes PHP-Script, das zudem Mathe-Fragen als Captcha-Schutz verwendet (selbe PHP-Klasse wie mein Math-Comment-Spam-Protection-Plugin). Generell ist das Thema Kontaktformular sehr heikel: gleich mehrere WP-Plugins hatten in der Vergangenheit Sicherheitslücken, die Angreifer entsprechend ausnutzten um Blogs zu übernehmen.

Heute hat nun WordPress offiziell die Beta 1 herausgebracht. Soweit ich das blicke, werden bis zur Ende September erscheinenden endgültigen Version keine Features mehr eingebaut, sondern nur noch Bugs ausgebessert.

Mit jedem WordPress-Update dasselbe Problem: Funktionieren die eingesetzten Plugins noch? Es gibt wie gewohnt im offiziellen WordPress-Wiki eine Seite, auf der die bereits unter 2.3 getesteten Plugins aufgelistet werden: Plugin Compatibility 2.3. Am besten beteiligt Ihr Euch aktiv, testet also selbst die eingesetzten Plugins und tragt diese dann im Wiki ein: damit erhält die Community auch bald eine möglichst vollständige Übersicht ;)

Ich habe dort auch meine aktiv betreuten Plugins eingetragen, bis auf Edit Comments XT funktionieren bereits alle noch aktiv supporteten Plugins unter 2.3.

Haupt-Problem wird mit WordPress 2.3 das Tagging: Wer das Simple-Tagging-Plugin einsetzt (ursprünglich von mir entwickelt und von Amaury fortgeführt) wird schwer enttäuscht werden:

• Type Ahead / Autovervollständigen der Tags ist nicht implementiert, dabei wäre es so einfach:
  
• Keine CSS-Unterstützung für die Tag-Cloud, stattdessen wird der Style direkt im HTML ausgegeben (Kopfschüttel, jetzt fehlen nur noch table-Tags)
• Die beliebten Ausgabe der “Related Posts” (Ähnliche Beiträge) gibt es auch nicht
• Die “Related Tags” gibt es ebenso wenig und es wird nicht programmatisch unterstützt: Bei Simple Tagging konnte man halt via Sidebar-Menü bzw. URL sagen “gib mir alle Beiträge, die gleichzeitig die Tags ‘Urlaub’, ‘Frankreich’ und ‘Meer’ enthalten”, also so wie man dies z.B. von del.icio.us kennt. Das in WP 2.3 eingebaute Tagging unterstützt das URL-seitig erst gar nicht, so dass hier auch eine Plugin-Lösung wohl schwierig umzusetzen ist, ohne dass man die Core-Dateien modifiziert.

Als vor einigen Monaten bekannt wurde, dass WordPress Tagging in die Core-Funktionen aufnimmt, haben bereits einige die WP-Entwickler darauf hingewiesen, auch das Simple-Tagging-Plugin hier zu berücksichtigen. Leider ohne Erfolg.

Generell wird in letzter Zeit vielfach die Vorgehensweise von WordPress m.E. wirklich zurecht kritisiert, siehe hierzu auch das Interview mit einigen WordPress-Ex-Entwicklern vom Juli 2007.