In der Entwicklung, Kompatibilitätsprüfung und Anpassung von WordPress-Plugins für aktuelle WordPress-Versionen steckt eine Menge Arbeit, die in Deutschland sehr gerne genutzt aber nur selten honoriert wird.

Obwohl ich der WordPress Community selbst bisher nur 5 (relativ kleine) aber nützliche Eigenentwicklungen (und ein paar darüber hinaus gehende Tipps) zur Verfügung gestellt habe, kann ich gut nachvollziehen, worüber Frank sich beschwert, wenn er meint, seine Open-Source-Arbeit würde nicht angemessen honoriert werden. Allein die SVN-Plugin-Uploads und -Anpassungen können mitunter ganz schön an den Nerven zehren… Daneben spart der Nutzer oft eine Menge Entwicklungsaufwand…

Was wäre, wenn die Plugin-Entwickler ihre Spenden an die WordPress Community einstellen würden?

Für WordPress stehen inzwischen über 4.000 kostenlose Features/Erweiterungen (WordPress-Plugins) zur Verfügung, die regelmäßig zur freien Verwendung aktualisiert werden. Die Auswahl und Kombination der Komponenten macht das eigene System leistungsfähiger, individueller, interessanter – mitunter werden auch Tools zur vereinfachten Systempflege angeboten.

Manche Entwickler erwarten für Ihre Entwicklung eine kleine Spende, andere freuen sich bereits über eine kurze Erwähnung in der Blogosphäre…

Vielleicht schaut der eine oder andere ja trotz “Auto-Aktualisierung” mal beim Plugin-Entwickler vorbei und stellt dort nicht nur Support-Anfragen, sondern klickt auch einmal auf den “Donation-Button”, um sich bei diesem zu bedanken und die Weiterentwicklung des lieb gewonnenen Plugins sicher zu stellen?

Ich habe jüngst selbst Plugins erneuert und war schon etwas erstaunt über die verschwindend geringe Resonanz: Hunderte von Downloads, (fast) keine Rückmeldung, kein Voting auf wordpress.org, … Es ist schon eigenartig, wie still es in der Blogosphäre geworden ist.

Ich sehe in der Open-Source-Plugin-Entwicklung persönlich kein Geschäftsmodell, habe aber das Gefühl, dass sich die fortschreitende Automatisierung der Entwicklungsprozesse außerhalb der Individuallösungen (SEO, Theme-Entwicklung, etc.) gerade als contraproduktiv erweist. Falls es so ist, wäre dies für alle Beteiligten, für Entwickler, Verteiler und Nutzer von WordPress sehr, sehr schade.

Wenn Sie einen Wartungsvertrag haben, wurde das heute veröffentlichte WordPress-Upgrade 2.7 -> 2.7.1 (68 Tickets) soeben für Sie eingespielt.

Das Plugin generiert eine suchmaschinenfreundliche XML-Sitemap (Artikelliste) und kann die führenden Suchmaschinen bei Neueinträgen und Änderungen automatisch und kurzfristig anpingen/benachrichtigen.

In der aktuellen Version (3.1.2) des Sitemap-Plugins entdeckte ich heute einen kleinen Bug, der mit WordPress 2,7 unter bestimmten Bedingungen eine unliebsame Double-Content-Produktion bzw. überflüssige Weiterleitungen zur Folge hat. Der Bug betrifft Artikel, die auf mehrere Seiten verteilt werden. Wer Artikel-Unterseiten in seiner Sitemap einblendet, wird einerseits feststellen, dass die jeweils letzte Unterseite eines auf mehrere Seiten verteilten WordPress-Artikels nicht gelistet wird (halb so wild), andererseits aber auch bemerken, dass Seite 1 solcher Artikel in der Sitemap doppelt erscheint, nämlich 1x mit dem normalen Seitennamen und 1x als …/seitenname/1/. Für solche Artikel wird also eine falsche und eine richtige Seite an die Suchmaschinen gemeldet.

Wer ebenfalls das Sitemap-Plugin nutzt, die Paging-Funktion für Artikel verwendet (Seite 1, 2, X) und die Anzeige von Unterseiten in der Sitemap aktiviert hat, kann sich der nachstehenden Lösung bedienen, um das Google-Sitemap-Problem bis zur entwicklerseitigen Plugin-Korrektur zu überbrücken:

SEO-Quick-Fix, um Seite-1-Artikel mit der Endung …/1/ abzufangen:

Datei sitemap-core.php in /wp-content/plugins/google-sitemap-generator aufrufen, nach der Funktion “function Render()” suchen (Zeile 1023ff.) und hinter “if($this->_url == "/" || empty($this->_url)) return '';” eine kleine Erweiterung wie diese einfügen:

// Bei Nutzung von Standard-Seitennamen (Endung “…/”)
// diese Zeile einfügen:
if (ereg('([a-zA-Z0-9-]+)(\/1\/)', $this->_url, $regs)) return '';

// Die Permalinks im fob marketing Blog enden auf .html
// und wurden kurzfristig so abgefangen:
if (ereg('([a-zA-Z0-9-]+)(.html)(\/1\/)', $this->_url, $regs)) return '';

Suchmaschinen werden sensibler – und eigentlich ist das auch gut so. Im Internet und auch bei der WordPress-Optimierung ist mehr denn je Qualitätsarbeit gefragt.

Vor gar nicht all zu langer Zeit hieß es noch “Content is King“, dicht gefolgt von der Gewährleistung einer optimalen Vernetzung im Internet. Das gilt natürlich nach wie vor, von “wüster Produktion” sei jedoch abgeraten, denn es mehren sich dieser Tage die Fälle, in denen “unsaubere Programmierung” den Anlass für Störfälle gibt. Die Herausforderung für Webdesigner, Suchmaschinen- und WordPress-Optimierer scheint mehr denn je in der Gewährleistung eines sauberen Codes zu liegen – ziemlich aufwendig aber glücklicherweise mein Spezialgebiet.

Im Dezember mehrten sich die Störfälle, bei denen permanente Umleitungen, allen voran Trackback-Links Anlass zur Besorgnis gaben. Wie sich in meiner WordPress-Website-Klinik herausstellte, liefert das Blog-System WordPress, mit welchem auch die Website von fob marketing gebaut wurde, nicht nur für Trackback-Links, sondern auch für viele andere, teils automatisierte Domain-Umleitungen, die unbemerkt im Hintergrund ablaufen, einen falschen Error-Code (302). Error 302 signalisiert der Suchmaschine, dass eine Seite vorübergehend verzogen ist. Eindeutig das falsche Signal, vor allem dann, wenn es massenweise in Erscheinung tritt!

Trackback-Links kann man bei der WordPress-Optimierung auf verschiedene Weise unschädlich machen, durch “Nofollow-Abschwächung”, durch “robots.txt-Ausschluss”, durch Error-Code-Korrektur oder auch durch simple Entfernung der störenden Links. Was aber kann man tun, um fehlerhafte Weiterleitungen zu verhindern, von denen man normalerweise gar nichts mitbekommt?

Wer WordPress-Artikel löscht, seine Permalinks verändert, seine Tag-URLs ändert, … muss davon ausgehen, dass ein Teil der alten Verlinkungen nicht etwa auf Error-404-Seiten landet (falls eingerichtet), sondern unbemerkt mit Error-302-Signal (sofern nicht dediziert und selektiv mit 301 umgeleitet) auf ein mehr oder weniger zufälliges Ziel umgeleitet wird. Nicht auf allen Webservern lässt sich das Problem direkt im “Core Code” von WordPress beheben. So landet man relativ schnell und ahnungslos im Spam-Filter empfindlicher Suchmaschinen.

Schuld an der Misere ist die WordPress-Funktion wp_redirect (und auch wp_safe_redirect) in der Datei /wp-includes/pluggable.php, bei WordPress 2.7 in Zeile 822ff. zu finden. Sowohl WordPress eigene Funktionen als auch verschiedene WordPress-Plugins nutzen diese Funktion um das 302-Chaos beliebig zu vervielfältigen.

Was tun, wenn der eigene Server Sicherheitspatches nutzt, die 302-Änderungen im WordPress Core ignorieren?

Man überlege sich ein Konzept aus .htaccess und robots.txt -Auschlüssen und -Umleitungen und übergebe die Feinjustierung einem nützlichen WordPress-Plugin namens Redirection. Dieses WordPress-Plugin habe ich in jüngster Zeit lieb gewonnen, weil es (Angaben des Plugin-Autors zu Folge leider erst ab WordPress 2.7) einen wesentlichen Beitrag dazu leisten kann, auch “automatische WordPress-Umleitungen” zumindest auf Error-Code-Basis zu kontrollieren. Nicht nur Error-Codes lassen sich managen, auch zur Double-Content-Kontrolle ist das Plugin sehr gut geeignet, da es über ein Monitoring für konfigurierte WordPress-Umleitungen verfügt. Man kann die Umleitung verhindern, dediziert Error-Codes festlegen, alte Schreibweisen auf neue umleiten (zum Beispiel Großschreibung gegen Kleinschreibung ersetzen), Regex-Befehle nutzen, WordPress-Umleitungen direkt umschreiben… und schließlich in der Google-Suche dabei zusehen, wie der eigene WordPress-Blog sich vom Schaden erholt.

Sollte jemand unsicher sein, welche Umleitungen für die WordPress-Optimierung geeignet sind, sei ihm der vorangegangene Artikel zur Website-Klinik emfohlen (zu dem es hiermit doch noch einen Folgeartikel gibt) – und ggf. auch der Besuch eines Google-Artikels zum Thema “Umleitung für Dummies” bzw. “Unser Date mit Googlebot, Teil II: HTTP-Statuscodes und der If-Modified-Since-Header”.

Ich wünsche Euch und Ihnen allen “Happy Blogging und Blog heilende Zauberkräfte” – auch und vor allem für das Jahr 2009!

Die einen tippten auf “Überoptimierung”, ich selbst tippte primär auf ein “Problem nach Änderung der internen Verlinkungsstruktur”, … Wenn es ein Google-Problem gibt, kommen oft mehrere Dinge zusammen, die es zu analysieren und zu reparieren gilt. Hier also meine “SEO-Tipps”, wie man den Blog im Zweifel durchprüfen und wieder flott bekommen kann. In meinem Fall dauerte es etwa 10-14 Tage, bis Google die Reparaturmaßnahmen verarbeitet und die Website in der Google-Suche wieder “normal” gelistet hat, wobei die Korrekturen und Optimierungen “nach und nach” erfolgten, denn wie sich herausstellte, war mein WordPress-System trotz allerlei Updates ein bisschen in die Jahre gekommen und bedurfte einiger Zuwendung:

SEO-Tools zum Aufspüren von Website-Problemen:

1. Google-Webmaster-Tools: Dort finden sich erste Hinweise auf “Double-Content-Probleme”, Seiten, die der Bot nicht wirklich mag.

In meinem Fall wurden in den Webmaster-Tools auf einmal Seiten reklamiert, die es eigentlich längst nicht mehr geben sollte: Seiten aus 2002-2005, die mit der neuen Website im Jahre 2006 gelöscht wurden, Blogartikel aus der Vergangenheit, die nach der Permalinkänderung vor vielen Monaten umgeleitet worden waren (neue Linkziele mit 301 Redirect für alte URLs), hinzu kamen RSS-Feeds, Trackback-URLs und fehlerhafte “Tags” mit Klein- und Großschreibung, auch paginierte Seiten (Artikel mit Folgeseiten), die Google mir als “problematisch” servierte. Nanu. Eine Menge “Spider-Futter” dabei, das längst nicht mehr gebraucht wird und größtenteils sogar schon sehr lange “deaktiviert” war.

Die schnelle Lösung: Ausschluss der veralteten Seiten per robots.txt. Aber VORSICHT: In meinem Fall habe ich dies riskiert, weil die 301-Umleitungen schon sehr lange gesetzt waren und alle “neuen” Seiten längst indiziert sind. Außerdem stelle ich Google die korrekten URLs dauerhaft per Google-Sitemap zur Verfügung, so dass mir der Robots-Ausschluss in meinem speziellen Fall angebracht und sinnvoll erschien. Zusätzlich sind im “Marketing- und SEO-Blog” RSS-Feed- und Trackback-URLs fast überall mit rel=”nofollow” entschärft worden.

2. XENUs Link Sleuth: Dieses Tool liefert eine umfangreiche Übersicht zu technisch problematischen Verlinkungen und Redirects. Jeder Trackback-URL-Link liefert beispielsweise eine 302-Umleitung zum Artikel selbst, die im Grunde weder stimmig ist (die Seite ist nicht “vorübergehend verzogen”), noch notwendig. Xenu listet diese Probleme sehr schön auf. Ob man die Trackback-URL jedoch komplett ausbaut, muss jeder für sich selbst entscheiden. WordPress-Blogs können auch ohne Trackback miteinander kommunizieren und im Ernstfall wissen die meisten Blogger wohl bereits, wie eine WordPress-Trackback-URL aussieht und wie man sie verwendet. Dennoch finde ich es persönlich momentan noch “netter”, den Besuchern meine Trackback-URLs für den Fall der Fälle irgendwo auszuweisen.

3. Broken Link Checker: Mit diesem WordPress-Plugin lassen sich “kaputt gegangene” externe URLs ausfindig machen, defekte Links zu Seiten, die inzwischen umgezogen sind oder zu ganzen Websites, die mittlerweile nicht mehr existieren.

Der Marketing & SEO Blog wurde “Mitte 2006″ aufgesetzt, damals mit WordPress 2.0.4 und auf einer Testdomain (www.marketingcontrolling.eu). Seitdem wurde die Blog-URL 2-3x geändert, diverse Plugins und WordPress-Versionen ausgetauscht, er hat schon einiges mitgemacht.

Gründe genug, auch den eigenen Blog einmal in die hauseigene “Website-Klinik” zu schicken und die Datenbank nach möglichen Fehlern und Problemen zu durchforsten. Wie sich herausstellte, hat sich an mancher Stelle unbemerkt die damalige Testdomain festgesetzt. An vielen Stellen wurden natürlich die damals gültigen URLs (intern) verlinkt (und mittlerweile umgeleitet). Auch externe Verlinkungen zeigten und zeigen noch zu Hauf auf alte (falsche) URLs, was es Google trotz Sitemap wohl schwer machte, beim Spidern zwischen “veraltet” und “aktuell” zu unterscheiden.

Des Rätsels Lösung lag also in der kompletten Überarbeitung all jener internen Verlinkungen, die bei WordPress-Updates und Permalinkumstellungen via WordPress-Admin in der Datenbank nicht berücksichtigt werden und folglich diverse (zusätzliche) Redirects (bei fehlender Weiterleitung Error-Seiten) aufrufen.

Zu kontrollieren sind in der Standard-Auslieferung von WordPress die Datenbank-Tabellen wp_options, wp_posts (“post_content” und “guid”) und natürlich sämtliche internen Trackbacks (Kommentarlinks) der Tabelle wp_comments.

Wenn es zusätzlich gelingt, den einen oder anderen externen Link anpassen zu lassen, scheint Google die Korrekturmaßnahmen sehr schnell entsprechend zu würdigen.

Zusammenfassung:

Die Faustregel bei Permalinkveränderungen heißt offiziell:
“Schreibe guten Content und sorge für neue Verlinkungen”

Etwas schneller geht es möglicherweise so:

• Überprüfung der kompletten Website (Datenbank) auf fehlerhafte und veraltete Verlinkungen.
• Korrektur/Anpassung von internen, falls möglich auch von einigen externen Verlinkungen.
• Vereinheitlichung der Tag-Strukturen, die sich im Laufe der Zeit geändert haben können, so dass veraltete Weiterleitungen heute unter Umständen “Double Content” produzieren, durch Groß- und Kleinschreibung, UTF8-Umstellung und obsolet gewordene Permalink-Strukturen.
• Kontrolle des Systems auf mögliche “Überoptimierung” in Standard-Seitenbeschreibungen.
• Gegebenenfalls “Ausschluss überflüssiger und nicht mehr existierender Seiten” durch robots.txt-Datei und “Abschwächung dazu gehöriger Verlinkungen” (mit rel=”nofollow”).
• Kontrolle in die Jahre gekommener Templates, ggf. mit Linkkorrektur. (“Wurde hier etwas übersehen?”)
• Beseitigung übersehener Bad Neighbourhood und Spam-Links aus (Follow-) Kommentaren.
• Bei Einsatz von Artikeln mit Folgeseiten: “Abfangprogrammierung”, um diese im Meta-Title vom Einleitungstext unterscheidbar zu machen. (Gleiches gilt für Blog-Archive mit Unterseiten.)
• In der Website-Klinik wurden zudem dubiose Zeitstempel für in WordPress 2.5 zwischengespeicherte Artikel festgestellt, welche in meinem Fall zur Anlage real nicht existierender Sitemap-Archive für das weit zurück liegende Jahr 1999 führten. Sehr dubios, dieser Bug. Um fehlerhafte Sitemap-Pings zu vermeiden, wurden in der Tabelle “wp_post” (post_date_gmt) hier die Speicherdaten entsprechend angepasst.
• Falls nicht ohnehin regelmäßig auf sauberen Code geachtet wird, kann bei dem einen oder anderen schließlich noch eine Validitäts-/W3-Kontrolle von Nutzen sein.

Wenn diverse WordPress-Updates am Ende in einem bereinigten System zusammenfließen, steigt nicht nur die Performance, auch der Google-Bot scheint diese Änderungen sehr schnell und dankbar anzunehmen. Suchmaschinenoptimierung ist keine Hexerei, sondern leider mit recht viel Arbeit verbunden. Wer sich davor nicht scheut, möchte vielleicht die Gunst der friedlichen Stunde nutzen und sein Blog mal wieder richtig auf Vordermann bringen. Diesen und natürlich auch allen anderen Lesern wünsche ich frohe (noch verbleibende Rest-) Weihnachten und wo vorhanden auch einen herrlichen Anschlussurlaub. In diesem Sinne: Viel Spaß in der Website-Klinik – oder auch im wohl verdienten Urlaub – ansonsten: “Happy Blogging”!

Hat jemand eine aktuelle Empfehlung, um solchen Räubern und Problemen vorzubeugen? (Technorati darf das. Die Jungs darüber aber nicht. Ich selbst bin mit dem Originaltext zur Zeit nur über den Link zu “ähnlichen Beiträgen” im Double Content zu finden. Ist nur ein Beispiel.Geklaut und umgemodelt wurde der Permalink-301-Blogeintrag.)

Bisher hatte ich keinen besonderen Stress mit “Versenkungsspielchen seitens Dritter”. Mein Blog ist auch inzwischen repariert und möglicherweise bald wieder bei Kräften. Dennoch möchte ich es den Content-Dieben künftig nicht mehr unbedingt so einfach machen, wie bisher. Da gab`s doch mal taugliche Plugins für sowas?

Hat jemand eine aktuelle Empfehlung, bereits “gute” oder “schlechte Erfahrungen” mit einem dieser Copyright-Plugins gemacht?

Es wird zur Zeit viel über “dubiose Google-Schwankungen” gesprochen. Ich vermute mal, die Schwankungen sind ab und zu ein bisschen berechtigt. Wer beispielsweise seine Blog-URLs / Permalinks verändert, dabei aber nicht sauber gearbeitet hat, braucht sich dieser Tage über “Schwankungen” nicht zu wundern. Was Permalinks angeht, scheint Google ausgesprochen empfindlich geworden zu sein.

Ein Permalink Migration Plugin allein könnte sich zum Beispiel rasch zum Boomerang entwickeln, da es “das eigentliche Permalink-Problem” wohl nur vorübergehend lösen kann. Umleitungen sind dazu gedacht, Bots und Besucher vorübergehend aufzufangen und zum neuen Ziel zu führen. Was aber macht der Google-Bot dieser Tage mit jenen, die 301 zu lange nutzen?

In den letzten Tagen habe ich mich natürlich gefragt, warum der Marketing und SEO Blog wohl abgeschmiert sein könnte. In dubiose Linkgeschichten bin ich nicht verwickelt, äußere Auffälligkeiten konnte ich auch nicht feststellen, bleibt also nur die Fehleranalyse im eigenen Haus. Und siehe da, ich habe “damals” eine Kleinigkeit vergessen:

Ich meine, vor etwa 5 Monaten, im Juli diesen Jahres, habe ich im Zuge eines WordPress-Updates meine Blog-URLs vollständig umgestellt. Dabei wurde der Ordner /marketing-seo-blog/ eingeführt und die URL-Verlängerung “marketing-blog-ID” aus dem Seitennamen “Name.html” entfernt. Dies hatte eigentlich eher kosmetische Gründe. Die alten URLs funktionierten eigentlich bestens und hätten wohl lieber nicht geändert werden sollen. Ich wollte den Blog, wenn ich ohnehin schon WordPress-Änderungen einbauen musste, jedoch gerne auch gleich optisch von der übrigen Homepage trennen.(Fehler 1: Never touch a running system.)

Fix wurden diverse permantente 301-Weiterleitungen mit mod_rewrite angelegt – und ab zur nächsten Baustelle, denn für den eigenen Blog hat man ja in der Regel nur sehr wenig Zeit. “Schwupps” war die Sache also vergessen. (Fehler 2)

Kurz darauf verlor der Blog zum ersten Mal an PageRank. Von PageRank 6 ging es abwärts auf 5. Ich schrieb es dem allgemeinen Trend zu (und natürlich den frischen Änderungen) und machte mir keine weiteren Gedanken, da mein Blog ja nach wie vor bestens bei Google zu finden war. (Fehler 3)

Angesichts des vor knapp einer Woche aufgetretenen Ranking-Problems machte ich mich also auf die Suche nach potenziellen Fehlerquellen. Besser spät als nie:

1. Sämtliche früher einmal erhaltene Verlinkungen führen heute natürlich auf veraltete Permalinks und somit auf 301-Weiterleitungen. Das Verhältnis von alt zu neu (Verlinkungen auf alte und neue Permalinks) ist mangels Schreibfrequenz eher schlecht. Sehr schlecht…

2. Leute, die früher einmal so nett waren, meinen Blog zu verlinken, linken meist heute noch auf den falschen Blog, die Adresse www.fob-marketing.de/marketing-blog/, statt /marketing-seo-blog/. Hmmm…

3. Diverse Content-Grabber und -Verteiler verlinken ebenfalls auf alte URLs. Ziemlich übel…

4. In den Google-Webmaster-Tools finden sich lustige Geschichten, die mich nun stutzig machten:

Bereits Im September auf Nofollow gesetzte Trackback-URLs, werden ebenso wie Permalink-Feeds mit aktuellem Datum indiziert und als fehlerhaft (Error 404) ausgewiesen. Besonders unangenehmerweise spidert Google dabei nicht etwa (nur) die neuen Nofollow-Permalinks, sondern scheinbar auch sehr gerne jene mit der veralteten URL-Struktur! Ooops? Ignoriert Google auf einmal nicht nur den 301-Redirect, sondern auch rel=”nofollow”?

Well. Betroffen sind vor allem Artikel, die von außen “falsch” verlinkt werden. Das eigentliche Problem scheint in der Eile allerdings selbst verursacht worden zu sein. Bei der Änderung der URL-Strukturen in diesem Blog wurde seinerzeit leider versäumt, die internen Verlinkungen vollständig anzupassen. Es ist schon enorm, was in einem Blog an Verlinkungen zusammenkommt, in Blog-Beiträgen, Querverlinkungen und Kommentaren, von innen heraus und auch von außen… lauter “faule Links” auf alte Posts(Permalinks), Trackback-URLs, Feeds, Tags, Kategorien – reichlich 301 Redirects.

In meinem Fall kann man Google also wirklich keine Schuld für den Aussetzer geben. Das 301-Karussel ist sicherlich heftig für den Bot. Schon erstaunlich, dass er es so lange mitgemacht hat.

Die fälschlich als “doppelter Title Tag” ausgewiesenen Seiten der Webmaster Tools nehme ich nun auch ein bisschen ernster als zuvor, werde also zusätzliche Abfang-Programmierungen für Artikel mit eigener Seitennavigation nachrüsten. Für die Sitemap, paged articles usw. – was ich bislang nur direkt in der Blog-Navigation gemacht habe. Hier geht es übrigens nicht wirklich um “doppelte Title Tags”, sondern um die Vermeidung von Double Content, durch Einsatz unterschiedlicher Seitentitel – “Unterscheidungsmerkmale”.

So schnell werde ich das Problem in diesem Blog wahrscheinlich nicht lösen können. Kommentare sind inzwischen schon permalinkbereinigt (was die internen Permalinks angeht), 1-2 fehlerhafte Links wurden geändert, ein paar kaputte rausgeschmissen, 1-2 übersehene Spammer gelöscht, zahlreiche Blogbeiträge aktualisiert… aber wie die noch übrigen etwa 600 alten Verlinkungen aus vergangenen Tagen “mal eben” bereinigt werden können, darüber muss ich erst einmal nachdenken…

Wer diesen Blog gerne weiterlesen möchte, sollte lieber das RSS-Feed abonieren. Bis der Blog wieder gefunden wird, geht sicher noch ein bisschen Zeit ins Land.

Und wer seine Permalinks NACHTRÄGLICH ändern möchte, dem kann ich nur raten, sich vorher einen genauen Überblick über das Ausmaß des Vorhabens zu verschaffen. Mit Template-Umbau und 301-Rederect ist es noch lange nicht getan. Die Datenbank bietet ausreichend Platz für reichlich Permalinks und will berücksichtigt werden.

Ich für meinen Teil werde mit WP 2.7 hier erst dann an den Start gehen, wenn sichergestellt ist, dass die aktuellen URLs diesmal vernünftig übernommen werden können.

Wie sage ich immer? “Erst planen, dann starten!”
Nachträgliche Änderungen können bei Internetentwicklungen ungeahnte Konsequenzen nach sich ziehen.

Nun ja. Shit happens… nicht nur bei “mach mal schnell”, sondern auch bei “och was soll`s, ich mach` einfach mal schnell. Das Update muss rauf!”

Aber eine “echte Problemlösung” für WordPress-Permalink-Updates ist schon in Reichweite. Update folgt…

Da manche Projekte aber nicht warten können, habe ich mich ein bisschen an der Bug-Eliminierung beteiligt. Beim Testen der neuen Website meiner Schwester Tonja Bockelmann, deren Domain sich gerade mitten im Serverumzug befindet, hatte sich zuvor herausgestellt, dass nach dem Update auf WordPress 2.7 RC1 keine WordPress Pages mehr editiert werden konnten:

“Seite aufrufen -> Text editieren -> “Update Pages” anklicken… und zack, weg war der Text!”

Meine Analyse brachte eine fehlerhafte Doctype-Deklaration ans Tageslicht, welche den Browser bei Aufruf von Pages (nicht so bei Blog-Artikeln) zum Wechsel in das jeweilige Standard-Zeichensatzformat (in meinem Fall ISO-8859-1 für “westlichen” bzw. deutschen Zeichensatz) zwang. Dies hatte zur Folge, dass Texte mit deutschen Umlauten nicht mehr korrekt gespeichert werden konnten. Stattdessen wurden sie abgeschnitten und entsprechend zerhackt in der Datenbank archiviert. Schuld daran war eine einfache Leerzeile im neuen WordPress-Code, die allerdings ziemlich schwer zu finden war.

Update Pages in WP 2.7 RC1 reparieren

Wer seine WP-2.7-Website mit der Vorab-Version RC1 fertigstellen möchte, kann den Doctype-Fehler in der Datei wp-admin/edit-page-form.php rund um Zeile 50 herum korrigieren. Die tückische Code-Lücke, welche bei Browsern den Standard-Zeichensatz zum Vorschein bringt und das Page-Update folglich unmöglich macht, wird durch die Lücke zwischen PHP-Start und -Ende verursacht. Mehr Infos und Code-Beispiele finden sich im WordPress-Track-Ticket Nr. 8335, wo Vladimir Kolesnikow so freundlich war, bei der Problemlösung zu unterstützen und den Bug-Fix auch gleich in den Core-Code zukünftiger Versionen zu integrieren.

Wer die Code-Zeilen von bis:

?>
<?php

entfernt oder die aktuellste Entwicklerversion nutzt, bleibt künftig im UTF-8-Zeichensatz und kann weiterarbeiten.

5 Dateien wurden angepasst, um eine kritische Sicherheitslücke in WordPress 2.6.3 zu schließen. Da sich zwischenzeitlich offenbar viele Leute an einem WordPress-Fake mit vorgegaukelter WordPress-Version 2.6.4 bedient haben, gibt es auch einen Versionssprung. Das Update ist daher ein Update auf die WordPress-Version 2.6.5.

Achtung: Dem Update liegen neue Übersetzungen (Sprachdateien) bei. Wer seine Übersetzungen angepasst hat, sollte sich die Sprachdateien vor dem Update lieber etwas genauer ansehen. Weitere Infos und Update-Pakete können bei WordPress Deutschland abgerufen werden.

Das WordPress-Update gibt es übrigens auch für die .mu-Version. Dann mal ran…

Ich meine, mich zu erinnern, dass der WordPress-Trac schon einmal voller Software-Bugs gewesen ist, als plötzlich eine neue WP-Version erschien. Aber:

Meine Hoffnung schwindet leider gerade dahin, dass WordPress 2.7 in diesem Monat noch fehlerfrei und einsatzbereit ausgeliefert werden kann. Statt der für den 10. November anvisierten “lauffähigen Vorabversion” wurde am 15. November die unglücklicherweise noch relativ stark mit Fehlern behaftete WordPress 2.7 BETA 3 (en) -Version vorgestellt. Eben eine Beta-Version…

Leider scheint sich das WP-2.7-Bug-Barometer zwischenzeitlich ein bisschen der Börse angepasst zu haben und ebenfalls nicht richtig zu “erholen”. Sah es gerade noch so aus, als wäre ein Boden gefunden, kommen plötzlich und unerwartet neue Probleme im Entwickler-Trac zum Vorschein. Dies kann man natürlich niemandem übel nehmen. Entwickler und Tester arbeiten sehr fleißig an der neuen WP-Version und größere Software-Updates können schon mal einen Rattenschwanz ungeahnter Probleme nach sich ziehen. Viele davon scheinen Browser-Probleme zu sein. Wurden WordPress-Releases eigentlich jemals zuvor so intensiv mit IE, Safari und Firefox zugleich getestet? Hätte man das eine oder andere neue WordPress-Feature vielleicht lieber für eine spätere WordPress-Version vormerken sollen?

Das Ergebnis wird sicher großartig werden. Fraglich ist nur, wie lange es noch dauert, bis man es downloaden, testen, anpassen, optimieren und nutzen kann. Eine Frage, die sich vor allem jene Unternehmen stellen, die noch nie zuvor mit WordPress gearbeitet haben – nun aber endlich starten wollen.

Gegenwärtig schlummern noch 8 dicke, 2 kleine und 35 als “mittelschwer” ausgewiesene Fehler im WordPress-Trac. Ein Fehler mehr als gestern. Nicht alle Bugs sind für jeden kriegsentscheidend, einige aber sind durchaus problematisch, teils für Design und Validierung, teils für Bedienung und Navigation, teilweise aber auch für Suchmaschinen. Zudem scheint auch die Performance-Optimierung, zumindest im Backend von WordPress 2.7, einen Rückschlag erlitten zu haben.

Was nun? Warten oder mit alter WordPress-Version starten?

So ärgerlich dies auch ist – wer es eilig hat, sollte vielleicht doch lieber noch auf die aktuelle WordPress-Version (2.6.3) setzen und die begehrten Features der 2.7-Version im Reifestadium nachrüsten oder nachrüsten lassen. In diesem Fall dann eventuell erst bei Erscheinen von WordPress 2.7.1? Ein kurzfristiger Erscheinungstermin für WordPress 2.7 würde mich persönlich, sofern nicht hier und dort ein Auge zugedrückt wird, aus heutiger Sicht zumindest ziemlich überraschen.

Und falls sich jemand nur an der Versions-Angabe stören sollte – hey, ein bisschen Code in den PHP-Abschnitt der functions.php des verwendeten WordPress-Themes einfügen, und keiner weiß mehr was gespielt wird:

remove_action('wp_head', 'rsd_link'); // "Really Simple Discovery"
remove_action('wp_head', 'wlwmanifest_link'); // "Windows Live Writer"
remove_action('wp_head', 'wp_generator'); // "WP-Versionsnummer"

Diese Einträge entfernen zumeist überflüssige Einträge im WordPress-Header. Wer den Windows Live Writer verwenden und lediglich die WordPress-Versionsangabe entfernen möchte, braucht nur die Dritte Zeile des Codes zu verwenden.