Skip to content

...endlich mal wieder eine neue WordPress-Version ;-)

Na gut, das ist ein bisschen ironisch, denn grad dachte ich, die eigenen und betreuten Blogs seien soweit aktuell, da steht doch im Adminbereich schon wieder:

"eine neue Version 2.6.2 ist verfügbar"

Ja, ich finde es sinnvoll, wenn Fehler und Lücken so schnell wie möglich behoben werden, dieses Mal hat auch alles problemlos geklappt ***mal vorsichtshalber auf Holz klopfend*** Klasse finde ich die Geschwindigkeit der deutschen Entwickler, die die angepasste Version 2.6.2, wie gewohnt, innerhalb eines Tages zur Verfügung stellten. Ein bisschen strukturierter und nicht ganz so häufige Aktualisierungen wären jedoch zuweilen schon nett. Ich habe brav wie immer, erstmal lokal probiert, was passiert, anschließend alle Datenbanken gesichert und erst dann aktualisiert... Klar fange ich jeweils erstmal mit dem Blog an, bei dem es am wenigsten auffällt, falls was wiederhergestellt werden muss. Es folgen die eigenen Blog und erst wenn da alles ok ist, gehe ich an Kundenblogs.

Plugin quote-comments

Das Plugin quote-comments (Kommentare zitieren) von Peter Kröner läuft jetzt auch hier. Nach einigem Rumprobieren und nachfragen, kam ich beim ersten Blog lokal zu einer Lösung. Ich musste die comments.php meines Themes ein bisschen anpassen, um validen Code zu bekommen. Im Plugin habe ich in der wp-quote-comments.php statt eines Paragraphs (p) auf <li class="quote_comments"> umgestellt, sonst passte es nicht in meinen Themes. Das erste, ein internes Blog, lief nachdem ich den relativen Pfad in der wp-quote-comments.js  von ../../../wp-content/plugins/wp-quote-comments/ auf absolute Pfade vom root aus /bloggt/wp-content/plugins/wp-quote-comments/ geändert hatte. Beim Rumprobieren hatte ich diverse Versionen und irgendwann wusste ich gar nicht mehr, was ich alles geändert hatte. Ich habe dann nochmal mit den Ursprungsversionen angefangen. Dabei fiel mir auf, dass die Seiten plötzlich nicht mehr valide waren. An der Stelle ist das Plugin noch empfindlicher als der Validator, bei mir verweigerte es bei jedem Fehler seinen Dienst. Da ich selbst auf validen Code achte, ist das kein Problem, aber ich hatte nicht damit gerechnet. Hier hatte ich einen Fehler zwischen den lokalen Tests und dem Hochspielen eingebaut und suchte das Problem zunächst in den Pfaden, die waren es jedoch nicht, denn kaum war der Fehler weg, war auch das Plugin zufrieden und zitierte so, wie ich mir das vorgestellt hatte. So ganz nebenbei tauchte noch ein Problem auf, welches viel Zeit kostete, für das ich noch keine Lösung habe, da ich die Ursache nicht kenne, welches aber nicht so gravierend ist. Erstmals hatte ich Unterschiede im Quelltext zwischen meiner lokalen und der Serverversion. Das Plugin schreibt mir lokal in jeden Kommentar:

id="quote_comments_loader"

Sobald es auf dem Server ist, beschränkt es sich jedoch darauf, das exakt einmal zu tun. Leider dauerte es ziemlich lang, bis ich kapiert habe, dass das so ist. Bis dahin hatte ich nach, mir unerklärlichen, Fehlern im Validator gesucht... :-(

Sprachproblem bei Update auf WordPress 2.6.1

Vor einigen Tagen, habe ich dieses Blog aktualisiert auf die Version 2.6.1. Wie immer hatte ich vorher lokal alles installiert und ausprobiert. Irgendwann bei einer Änderung, hatte ich lokal plötzlich das Problem, dass die Sprache im Adminbereich und im Blog nicht mehr deutsch war. Da ich einiges hin und her probiert hatte, auch mit verschiedenen Plugins, mal installiert und dann wieder entfernt, dachte ich es wäre nur ein lokales Problem und spielte alles hoch. Leider stimmte das nicht, auch hier auf dem Server war anschließend alles im Adminbereich englisch. Nur dieser Bereich wäre ja nicht so schlimm, allerdings sind damit auch alle Angaben wie Datum und Texte, die direkt von WordPress kommen englisch. Ich recherchierte an verschiedenen Stellen, unter anderem in der FAQ des deutschen WordPress-Forums. Ich probierte alle Hinweise aus, aber nichts half. Als nächstes wollte ich wissen, ob das Problem in der Datenbank zu suchen ist. Zuerst schaute ich mal rein, ob es da weitere Sprachinformationen gibt, da war jedoch nichts. Dann installierte ich lokal eine völlig neue Datenbank, denn mehrere andere neu aufgesetzte Blogs kamen ja mit derselben Kombination WP 2.6.1 und dieselben Plugins zurecht. Wieder kein Ergebnis, dieselben Dateien ergeben bei Neuinstallation wieder englische Ergebnisse. Nächster Schritt alle Plugins deaktivieren, umstellen auf's Standardtheme in deutscher Version und alle WordPress-Dateien aus einem Blog kopieren, die mit deutsch zurecht kommen. Vorher natürlich sicherstellen, dass auch die lokale Version gesichert ist, nicht dass die einzige Originalversion auf dem Server liegt. Wieder kein Erfolg, alle geänderten Dateien von einem Blog, welches die deutsche Sprache anzeigt als Grundlage ändern nichts daran, dass wieder alles auf Englisch ist. So ganz allmählich gingen mir die Ideen aus, denn wenn es weder die Datenbank, noch die Dateien, noch das Theme, noch die Plugins waren, was könnte denn dann noch sein? Nun, das einzige, was jetzt noch anders war, war die wp-config. Ich hatte zwischendurch schon einige Male mit Änderungen der Sprachangabe und verschiedenen Sprachdateinamen an unterschiedlichen Stellen experimentiert, da ja auch der Pfad zwischen WP 2.3 und WP 2.6.1 für Sprachdateien anders ist. Statt /wp-includes/languages findet man die Sprachdateien ja inzwischen unter: /wp-content/languages Da ich von Hand schon einige Male probiert hatte, dachte ich, die einzige Chance ist noch, die relevanten Zeilen zu kopieren. Tja, und genau das war's! Jetzt spricht alles wieder brav deutsch. Hätte ich die Kommentare in der Datei genau gelesen, hätte ich drauf kommen können. Nun, das hatte ich jedoch nicht. :-(

Lösung des Sprachproblems

define ('WPLANG', 'de_DE'); / That's all, stop editing! Happy blogging. / define('ABSPATH', dirname(_FILE_).'/'); require_once(ABSPATH.'wp-settings.php'); // define('ABSPATH', dirname(_FILE_).'/'); // require_once(ABSPATH.'wp-settings.php'); // define ('WPLANG', 'de_DE'); Na, seht ihr den Unterschied? Ich habe es mehrfach nicht gesehen. Es gibt Definitionen, die dürfen stehen wo sie wollen, z.B.

define('ABSPATH', dirname(_FILE_).'/');

, das gilt jedoch nicht für die Sprachdefinition, die muss vor dem folgendenKommentar stehen.

/ That's all, stop editing! Happy blogging. /

Wie das passieren konnte?

Für die Umbennenung des Blogs musste ich in der wp-config folgende Zeile eingeben:

define('RELOCATE', true);

Dabei habe ich wahrscheinlich versehentlich den Spracheintrag um eine Zeile verschoben... Nun gut, wieder was gelernt, jetzt sind jedenfalls wieder alle Ausgaben deutsch und vielleicht hilft es ja noch jemand... ;-)

Firefox 3 : Dialog - Lesezeichen hinzufügen - vergrößern ::: Adminize WordPress

Wie ihr wisst, mag ich Platz, große Auflösung und viel direkt übersichtlich Sichtbares. Leider wird der Spielkram zur Zeit meines Erachtens an einigen Stellen übertrieben. Im Firefox 2 war das Dialogfenster "Lesezeichen hinzufügen" noch ein ganz normales kleines Fenster. Das konnte ich also genau so in der Größe anpassen, wie ich das mag, das ist ja unter KDE alles kein Problem. Seit Firefox 3 musste das natürlich auch mal wieder toller, neuer, verspielter eingebaut werden. Jetzt ist das kein ganz normales Fenster mehr, sondern irgendsoein eingeblendetes Spielkramteil. Damit ärgerte ich mich in den letzten Wochen ständig über die doch immerhin vier! sichtbaren Einträge in meiner Bookmarks Toolbar, denn an dem Fenster ließ sich so einfach nichts verändern. Heute hatte ich jetzt die Nase voll und beschloss mal zu recherchieren. Nach ein bisschen Suchen fand ich ein Add-On, welches meine Probleme löst.

Dialogfenster "Lesezeichen hinzufügen" anpassbar

Mit dem OpenBook Add-On für den Firefox 3 geht das jetzt endlich wieder. In den Optionen gibt es eine Checkbox "Schaltfläche zur Größenänderung" anzeigen. Freundlicherweise bleiben zuletzt gewählte Einstellungen erhalten, wenn ich jetzt wieder eine Lesezeichen hinzufüge öffnet sich das Ding auf Fensterhöhe und ich kann wieder viele meiner Ordner in der Übersicht sehen, ein Traum! ;-)

Überflüssiger Spielkram

Für mich gehört sowas zu völlig überflüssigem Spielkram, denn ein ganz normales anpassbares Fenster ist schneller, einfacher anzupassen und funktioniert damit einfach besser.

WordPress Adminbereich 2.6 Spielkram

Offenbar sind solche Spielereien jedoch grad modern, denn im Adminbereich von WordPress 2.6 bekomme ich auch so hochmoderne mit JavaScript und schickem Hintergrund aufblendende Fenster, wenn ich z.B. im Standardeditor einen Link hinzufügen will. Das Ganze ist viel langsamer, bei meinen Einstellungen sind einige Schaltflächen nur zu einem Drittel sichtbar und ändern lässt es sich so auf Anhieb auch nicht. Einige der tollen modernen Neuheiten lassen sich mit Frank Bültges Adminize-Plugin freundlicherweise konfigurieren und so anpassen, dass ich auch damit klarkomme. Das an WP 2.3 angelehnte Theme, ist beispielsweise nicht in solchen Quietschfarben und lässt sich bildschirmfüllend darstellen. Ich hasse es, wenn der halbe Bildschirm leer ist, weil irgendwer ein schickes Theme mit fester Breite entworfen hat... Falls irgendwer von euch weiß:
  • wie ich statt des tollen neuen JS-Popup mit abgedunkeltem Hintergrund im Admin von WP 2.6 wieder zu einem ganz normalen Fenster komme...
dann schreibt mir einen Kommentar. Ansonsten muss ich wohl bei Gelegenheit nochmal suchen gehen... Warum ich in der Sidebar erst alles Mögliche habe und erst weiter unten meine Kategorien, muss ich auch nicht verstehen. Achja, und wenn ich nicht immer klicken müsste, um zu einem anderen Zeitpunkt als jetzt was zu veröffentlichen, wäre das auch fein.

Wunschzettel

Ich hätte gern, dass die Hersteller von Software, egal ob jetzt sowas wie Firefox oder eben WordPress statt ständiger neuer Spielereien, lieber mehr Konfigurationsmöglichkeiten bieten würden. Dass ich für eine Fenstergrößenänderung im Firefox ein Plugin brauche finde ich nervig. Ebenso, dass es nötig ist, dass es ein Adminize-Plugin braucht, weil WordPress von Haus aus so gut wie keine Konfigurationsmöglichkeiten bietet. So ein bisschen Benutzerfreundlichkeit wäre grad bei Software, die sich häufig ändert schon nett. Ich denke nur wenige Nutzer haben Zeit und Lust sich bei jeder Versionsänderung neu in ihre Software einzulernen und länger zu recherchieren, bis sie wenigstens den bisherigen Stand wieder erreichen.

Blogadresse geändert ::: Weiterleitungsprobleme mit .htaccess

Wie ja bereits erwähnt, hat sich die Blogadresse hier geändert. Die Feeds gibts neu hier:  http://miradlo.net/bloggt/feed und nicht mehr unter: miradlo.net/blog_miradlo. Ich habe sofort einige Weiterleitungen ausprobiert, die jedoch partout nicht so recht klappen wollten. Insbesondere der Feed weigerte sich und wollte sich nicht umleiten lassen. Beim Recherchieren zur .htaccess, die den Apache steuert gab's unzählige Ideen und Vorschläge:
  • wie werden Feeds zu Feedburner umgeleitet
  • welches WordPress Plugin leitet wie um
  • wie leitet man überhaupt um
Die ein oder andere Umleitung leitete zwar teilweise so um, wie ich wollte, hatte aber derart unangenehme Nebeneffekte, dass es auch keine Lösung war. Denn mit den versuchten Umleitungen für das gesamte alte Blogverzeichnis blog_miradlo auf bloggt, ließ sich der Feed nicht umleiten. Versuche, erst den Feed umzuleiten und dann den Rest gesamt, führten zu internen Serverfehlern (Error 500). Der eine oder andere sonstige Versuch hatte Probleme damit, dass es bisher noch anderer Stelle ein Bilderverzeichnis gab, was auch blog_miradlo hieß. Aber jetzt habe ich eine Lösung!

Blog von einem Verzeichnis in ein anderes umleiten inklusive des Feeds

RewriteEngine On

RewriteRule ^blog_miradlo/(.*)$ http://miradlo.net/bloggt/$1 [R=301,L]

Damit leitet es jetzt sowohl einzelne Aufrufe nach Beiträgen, wie auch den Feed brav um. Für diesen Fall ungeeignet waren folgende Möglichkeiten:

Mit direkten Umleitungen der Feeds (auch für mehrere Versionen) passierte gar nichts:

  • RedirectPermanent /blog_miradlo/wp-rss.php http://miradlo.net/bloggt//wp-rss.php
  • RedirectPermanent /blog_miradlo/feed/ http://miradlo.net/bloggt/feed

Auch angepasste Anleitungen, die einen Feed vom eigenen Blog zu Feedburner umleiten wollten nicht so, wie ich, egal ob diese: WordPress zu Feedburner umleiten oder sowas wie diese:

  • <IfModule mod_rewrite.c>
    • RewriteEngine on
    • RewriteCond %{REQUEST_URI} ^/?(/blog_miradlo/feed.*|comments.*) [NC]
    • RewriteCond %{HTTP_USER_AGENT} !^.*(FeedValidator) [NC]
    • RewriteRule ^feed/?.*$ http://miradlo.net/bloggt/feed [L,R=301]
    • RewriteRule ^comments/?.*$ http://miradlo.net/bloggt/comments/feed [L,R=301]
  • </IfModule>

Als Zwischenlösung hatte ich deshalb alles auf die Blogstartseite umgeleitet, das klappte jedoch nicht mit den Feeds und auch nicht mit den einzelnen Beiträgen, aber es war zunächst einmal besser als nichts:

  • RedirectMatch 301 ^/blog_miradlo/(.*) http://miradlo.net/bloggt/
tweetbackcheck