IE6

IE5

IE8

Firefox 3.6 Ubuntu

Firefox 4 Win 7

WordPress unterstützt im Adminbereich inzwischen keinen guten alten IE6 mehr. Hätte ich wohl nicht so gemacht, aber das ist akzeptabel, irgendwann wären wir Webautoren das Ding ja schon gern mal los.

Fehlermeldungen in WordPress

Schockiert bin ich dagegen von den Monsterfehlermeldungen im Dashboard. Ich nutze – nicht übertrieben aktuell  aber auch nicht veraltet – einen Firefox 3.6 auf Ubuntu Maverick Meerkat. Für diesen Browser bekomme ich noch regelmäßige Updates. Trotzdem meint WP mit einer Monstermeldung mir sagen zu müssen:

“Dein Browser ist veraltet”

Ja, die Meldung lässt sich ausblenden, ja bei ersten Tests sieht es so aus, als käme sie auch nicht mehrfach. Trotzdem:

Ungeübtere Nutzer werden überflüssigerweise erstmal irritiert sein. Ich kann auf die Anfragen warten, wenn ich bei Kunden die neue Version eingespielt habe. WordPress mischt sich hier in etwas ein, was für meinen Geschmack definitiv nicht mehr in Ordnung ist.

IE6

Hier eine dicke rote Meldung mit

“Du verwendest einen unsicheren Browser”

zu bringen, ist in Ordnung, das Ding (Internet Explorer) ist von 2001, da ist allmählich mal Zeit für ein Update.

IE5

Ups, besser IE5 als IE6, denn hier gibt’s nur eine ockerfarbene aber keine rote Fehlermeldung.

IE8

“Dein Browser ist veraltet”

Nunja, auf Windows 7 stimmt das, aber auf einem guten alten Windows XP kann gar kein IE9 installiert werden, insofern schon auch fragwürdig.

Firefox 3.6

“Dein Browser ist veraltet”

Das ist nicht in Ordnung, in meiner noch nicht veralteten Version von Ubuntu bekomme ich per automatischem Update keinen aktuelleren Firefox.

Firefox 4 auf Windows

“Dein Browser ist veraltet”

Für mich die Krönung des Ganzen, im Moment ist für mich Firefox 4 auf Windows durchaus, Stand der Dinge, auch wenn es bereits Firefox 5 gibt.

Sonstige Browser

Die Meldungen erscheinen nur bei den Mainstreambrowsern, mein Seamonkey 2.0.11 ist in Ordnung, obwohl es 2.2 bereits gibt.

Nutzer sollen selbst entscheiden

Für mich ist es in Ordnung bei schweren Mängeln zu informieren, gegen sehr veraltete Browserwarnungen innerhalb von WordPress habe ich nichts. Aber das gilt für mich für Internet Explorer kleiner gleich IE7, ebenso bei alten Firefoxversionen, für die es keine Updates mehr gibt.

WordPress jedoch teilt die Welt in gut und böse, wie es grad dem jeweiligen Entwickler passend erschien. Das ist für mich Einmischung und ärgerlich. Daran ändern  – wie erwähnt – auch die ausblendbaren Warnungen nichts.

• WP 3.1.4. auch in deutscher Version zum Download bereit

Häufig bin ich eher genervt übers soundsovielte Update.

Pluginverzeichnis auf wordpress.org gehackt

Richtig schlecht ist jedoch das wohl gehackte Pluginsverzeichnis auf Wordpress.org

Weitere Infos siehe auch: WP-Pluginverzeichnis gehackt
Laut den deutschen WordPressentwicklern, haben sich Unbekannte Zugriff auf das offizielle Pluginverzeichnis verschafft und die drei populären Plugins AddThis, WPtouch und W3 Total Cache mit einer Backdoor ausgestattet. Durch diese Hintertür könnte wohl auf das betroffene System zugegriffen werden.

Aus Sicherheitsgründen wurde alle Passwörter zurückgesetzt, darüber hatte ich mich gestern noch gewundert, die Meldung las ich jedoch heute eher zufällig, weil ich nach dem Update schaute.

Wer in den letzten Tagen eins der Plugins aktualisiert oder installiert hat – sollte dringend auf die neue Version aktualisieren und das eigene Passwort ändern.

Passwörter zurückgesetzt

Erstaunlich ist allerdings die schnelle Reaktion mit dem Rücksetzen aller Passwörter. Leider hatte ich es bis heute mittag nicht mitbekommen, dass da ein dickeres Problem ist. Vielleicht erfährt ja jemand durch diesen Artikel davon. Ich habe jedenfalls mal überall die betroffenen Plugins aktualisiert, die eventuell die Backdoor enthalten haben könnten.

Blogportal BuddyPress mit WP MU

Ab und zu kommt es vor, dass jemand Probleme beim Blog anlegen hat und ich als Administratorin dann helfen sollte. Mein erster Versuch war nicht so erfolgreich, weil das Blog anschließend mir gehörte und es scheint keine Einstellung zu geben, die den ursprünglichen Besitzer des Blogs nochmal ändern kann.

Meine Befürchtung war, dass ich beim Anlegen bereits eine Bestätigung bräuchte, deshalb gab ich meine E-Mailadresse ein. Nachdem es so nicht klappte testete ich nochmal und stellte fest, dass das nicht so ist, selbst dann nicht, wenn noch kein Benutzer existiert.

Ganz einfach klappt es auf folgendem Weg:

• Blog anlegen mit gewünschtem Namen und gewünschter Adresse
• Mailadresse des Administrators legt den Blogbesitzer fest

Beim Anlegen des ersten Artikels, wird zunächst auch immer der eingeloggte Nutzer als Admin genommen, jedoch kann im Beitrag der Autor geändert werden und so als Beitrag des Blogbesitzers angegeben werden.

Jetzt versteht auch BuddyPress korrekt, wem das Blog gehört und ordnet es dem gewünschten Besitzer zu.

Tja, “kaum macht man’s richtig geht’s”

WordPress-Versionen 2008 und 2009

• Hinweise WordPress aktualisieren

• WordPress 2.5 erschien im März 2008
• WordPress 2.6 erschien im Juli 2008
• WordPress 2.7 erschien im Dezember 2008
• WordPress 2.8 erschien im Juni 2009
• WordPress 2.9 erscheint voraussichtlich im  Dezember 2009

Das Ganze sieht schon anders aus, wenn die zwischendurch veröffentlichten kleinen Updates mit dabei stehen; die deutschen Versionen inklusive der Zwischenversionen laut Archiv von WordPress Deutschland:

• WordPress 2.5 erschien im April 2008
• WordPress 2.5.1 erschien im April 2008
• WordPress 2.6 erschien im Juli 2008
• WordPress 2.6.1 erschien im August 2008
• WordPress 2.6.2 erschien im September 2008
• WordPress 2.6.3 erschien im Oktober 2008
• WordPress 2.6.5 erschien im November 2008
• WordPress 2.7 erschien im Dezember 2008
• WordPress 2.7.1 erschien im Februar 2009
• WordPress 2.8 erschien im Juni 2009
• WordPress 2.8.1 erschien im Juli 2009
• WordPress 2.8.2 erschien im Juli 2009
• WordPress 2.8.3 erschien im August 2009
• WordPress 2.8.4 erschien im August 2009
• WordPress 2.8.5 erschien im Oktober 2009
• WordPress 2.8.6 erschien im November 2009
• WordPress 2.9 erscheint voraussichtlich im  Dezember 2009

In diesem Jahr waren es damit bereits neun Updates. Meist ging es um Sicherheitsupdates, sprich gerade die Zwischenversionen sind damit wichtig und sollten auf jeden Fall aktualisiert werden.

Plugins und ihre Aktualisierungen

Ich kenne kein WordPress-Blog welches nicht auch einige Plugins einsetzt, um weitere Funktionen hinzuzufügen. Die Plugin-Updates kommen irgendwann zwischendurch und auch hier kann es sein, dass es um Sicherheitsprobleme geht, die gelöst wurden. Anfangs machte ich regelmäßig Plugin-Updates sobald diese veröffentlicht wurden. Doch als ich mehrfach danach einen oder mehrere Fehler hatte, weil die neue Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsten werden Plugins nur noch gemeinsam mit einem Update aktualisiert.

Die Zwischenversionen bestehen ja nur aus einigen Dateien, die überspielt werden können, es ist also keine vollständige Änderung aller Dateien nötig. An sich sollte diese Zwischenupdates daher problemlos funktionieren und keine Seiteneffekte haben. Doch das klappt leider oft nicht, mal ein Beispiel wie es bei einem Update lief, welches schon ein bisschen länger her ist:

Aktualisieren mehrerer Blogs

Wie schon mehrfach beschrieben, ich aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch – wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins.

Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen.

Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren.

Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: “Juhu! ein Update!” Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online.

Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn eine Lücke bekannt wird und groß genug ist, um repariert zu werden. Ich kann jedoch in meinen Arbeitslauf nicht ständig vorsichtshalber drei Tage einplanen, in denen ich sofort, wenn ein Update erscheint, alles andere stoppe und absage, um mich dann um WordPress zu kümmern.

Unterm Strich kostet mich eine Aktualisierung pro Blog zwischen einigen Stunden bis zu ein oder zwei Tagen, wenn eine Fehlersuche aufwändiger wird. Ginge es hierbei um ein Update pro Jahr, dann wäre es noch akzeptabel, bei einem Update etwa alle sechs Wochen geht das einfach nicht, denn kein Kunde ist bereit das nach Aufwand auch nur annähernd zu bezahlen. Denn selbst bei einem Stundensatz von nur 50 Euro wären das jährlich rund 2500.- Euro nur für Aktualisierungen und kleine Anpassungen.

Ich bin deshalb inzwischen dazu übergegangen, dass ich für neu aufzusetzende Blogs WordPress nicht mehr anbiete, eine Ausnahme sind Portale mit WordPress MU und BuddyPress, weil sich da der Aufwand ja auf viele Einzelblogs verteilt und weil es zur Zeit keine echte Alternative dafür gibt.

Doch irgendwann las ich von dem Tipp, den Button “Medien einbetten” zu nutzen. Wunderbar, da musste ich nur den Link eingeben und alles andere klappte von selbst.

Wieder nicht mehr valide

Gestern habe ich auf uteles Blog wieder mal ein Video eingebunden und zunächst gar nicht überprüft, ob alles passt, weil ich das an sich ja weiß. Aus einem anderen Grund prüfte ich heute kurz und “ups, Mist, Fehler”.

Nun gut, mal kurz nachsehen, was ich wohl falsch gemacht habe; Quelltext des Videos, welches Fehler wirft:

<p><object classid=”clsid:d27cdb6e-ae6d-11cf-96b8-444553540000″ codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0″ height=”350″ width=”425″><param name=”src” value=”http://www.youtube.com/v/Frx0Wc1cxbo”><embed type=”application/x-shockwave-flash” src=”http://www.youtube.com/v/Frx0Wc1cxbo” height=”350″ width=”425″><a class=”mjedzjfsfvwhkvyhhsjp” href=”http://www.youtube.com/v/Frx0Wc1cxbo”></a></object></p>

Ok, stimmt, da steht was von type=”application/x-shockwave-flash” also mal nach einem alten Video schauen und sehen, was sich da unterscheidet:

<p><object data=”http://www.youtube.com/v/6a_KF7TYKVc” type=”application/x-shockwave-flash” height=”350″ width=”425″><param name=”src” value=”http://www.youtube.com/v/6a_KF7TYKVc”></object><a class=”mjedzjfsfvwhkvyhhsjp” href=”http://www.youtube.com/v/6a_KF7TYKVc”></a></p>

Fehlersuche

Ich schaute mir das Ganze mal in der HTML-Ansicht von WordPress an und da stand bei beiden Beiträgen dasselbe (außer dem Link zum Video selbst natürlich):

<object classid=”clsid:d27cdb6e-ae6d-11cf-96b8-444553540000″ width=”425″ height=”350″ codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0″><param name=”src” value=”http://www.youtube.com/v/MpIOClX1jPE” /><embed type=”application/x-shockwave-flash” width=”425″ height=”350″ src=”http://www.youtube.com/v/MpIOClX1jPE”></embed></object>

Das konnte jedoch irgendwie nicht sein.

Ich versuchte es mit einem weiteren Beitrag mit Video und siehe da, da stand was anderes:

<object width=”425″ height=”350″ data=”http://www.youtube.com/v/Frx0Wc1cxbo” type=”application/x-shockwave-flash”><param name=”src” value=”http://www.youtube.com/v/Frx0Wc1cxbo” /></object>

Reparieren

Ich gab das in HTML-Ansicht des Beitrags ein, und siehe da, schon passt es wieder und die Startseite ist fehlerfrei, die Unterseite hat wie immer den einen Fehler, bei dem der Validator noch nicht auf dem aktuellen Stand ist. Allerdings wieder mit dem alten Problem, nicht mehr auf die visuelle Ansicht umschalten, sonst ist es wieder kaputt.

Ich suchte nochmal, denn irgendwas war da komisch und nach erneutem Öffnen des Beitrags, der zwar gleich aussah aber valide war, sah ich das Problem, es gab eine automatische Speicherung, diese zeigte die falsche Version, aber die tatsächlich publizierte Version war eben doch mit anderem Code.

Fazit

Na prima, da konnte WordPress auf ganz einfache Art mal Videos valide einbinden und jetzt ist es wieder kaputt. Ich hab jetzt nicht gesucht, kann sein irgendein Plugin ist schuld, vielleicht ist es auch grad diese Version und die nächste dann wieder nicht…

Ganz ehrlich: Es ist mir egal, es nervt einfach.

als Spammer markieren

Je aktiver eine WP-MU-Installation ist, desto beliebter ist sie bei Spammern. BuddyPress, was wir teilweise einsetzen, braucht zwingend ein WP-MU und meist ist das auch sinnvoll, denn es geht ja um ein Netzwerk nicht nur zum Plaudern und sich Austauschen, sondern es geht meist auch um mehrere Blogs.

Um den Spam zu bekämpfen könnte man natürlich die Registrierung einfach schließen, aber das hieße bei echten Interessenten, dass ich sie von Hand freischalten müsste. Deshalb ist das auch keine gute Idee, einerseits weil Interessenten dann warten müssten und auch, weil ich nicht jeden Nutzer selbst anlegen möchte.

Einiges an Spam lässt sich reduzieren, indem ich die betroffenen IPs, von denen die Spammer kommen, blocke. Bevor ich das machte kamen tatsächlich von nahezu jeder IP mehrere Registrierungen. Akismet kann man laut Adminbereich über die Spammer benachrichtigen. Doch selbst bei sehr hartnäckigen Spammern, mit derselben IP und immer einem nahezu identischen Nutzernamen, die ich auf mehreren Installationen sperrte half es nicht, sie konnten sich immer wieder registrieren, teils sogar mit identischem Benutzernamen. Insofern ist Akismet an dieser Stelle völlig überflüssig.

Die Liste der IP-Sperren in .htaccess ist jedoch inzwischen sehr lang geworden und jede IP benötigt einen Eintag:

deny from 74.53.xxx
deny from 74.53.xxx
deny from 74.53.xxx

Insofern war ich schon länger auf der Suche nach einer besseren oder zusätzlichen Lösung. Was ich von grafischen Captchas und ähnlichem halte, habe ich ja schon mal erwähnt.

In der README der aktuellen WP-MU-Version fand ich Hinweise zum Spamschutz, manches gefiel mir nicht, aber der Hinweis auf Blocken per Referrer ist eine prima Idee. Zu finden ist die Anleitung auch im WP-codex, das habe ich aber erst später entdeckt.

Insgesamt ist damit mehr Ruhe, aber es bleibt ein Restrisiko, dass ernsthaft interessierte Nutzer versehentlich geblockt werden. Deshalb jetzt dann mal einen speziellen Artikel dazu.

Im Moment leite ich Spammer auf einen Spamartikel um, auf Dauer will ich jedoch den Hinweis hier geben, dass es auch mal jemand treffen kann, der kein Spammer ist.

Wer also versehentlich geblockt wurde, bitte melden, per Kommentar, oder über die Impressumsangaben.

Nach den letzten Updates habe ich trotz vieler Versuche noch immer in mehreren Blogs nicht wieder alles so laufen, wie ich wollte.

Die aktuelle WP 2.8.4 ist ja wegen unzähliger Probleme und Lücken ihrer Vorgänger zwingend nötig.

Die Meldung bei Golem berichtet aktuell schon wieder von einer Sicherheitslücke für alle vorigen Versionen.

Bereits im Juni habe ich in einer Blogparade nach Erfahrungen auch mit Serendipity und anderer
Blogsoftware gefragt.

Ich habe gestern beschlossen, dass es jetzt reicht und ich in Zukunft Schritt für Schritt von WordPress Abstand nehme.

Mein Hauptproblem sind grad noch die sozialen Netzwerkfunktionen, die BuddyPress mit WP MU bietet.

Deshalb habe ich auch mal bei identica und twitter gefragt. Es gab kaum Joomla-Fans, wenig ganz andere Ideen, aber viele Drupal-Empfehlungen.

Ich werde demnächst mal suchen gehen, wie sich ein Theme bei s9y bauen lässt, fein wäre ein leeres Grundgerüsttheme…

Wird sich alles zeigen, vielleicht lassen sich ja Teile der WP-Themes übernehmen.

Aktuell jetzt also WP 2.8.4 und meine Begeisterung hält sich gewohnt in Grenzen.

Auf den ersten Blick scheint zumindest im Bereich für euch, alles soweit in Ordnung zu sein, falls ich was übersehen haben, bitte schreibt mir, danke.

Dazu ein anderes Mal mehr.

Hab die Gelegenheit noch genutzt jetzt die Dents von identi.ca in der Seitenleiste anzuzeigen, ich werde auch mal testen, ob jetzt Blogbeiträge von hier brav zu indentica gesendet werden. (Klappt! )

Ich nutze dafür die minimal angepassten Twitter-Tools, die Anleitung das für identi.ca zu nutzen, gibt’s bei Helmut, der Tipp dazu kam von dunkelangst.

Leider passiert es auch immer wieder, dass Updates schief gehen. Mit 2.8 hatte ich es kurz auf einem Testblog probiert und da es gar nicht klappte beschlossen, dass ich es erstmal lasse, danach kamen einige Meldungen, dass es nicht geklappt hatte. Inzwischen las ich von manchem Zurückgehen auf eine kleinere Version und von Problemen sowohl mit 2.8 wie auch schon mit 2.8.1, nur mal so die mir in den letzten Tagen nochmal auffielen:

• Boris
• Dieter
• alte Kiehvotz
• Rio

Ich habe ja inzwischen schon ein paarmal erwähnt, dass ich grad buecherbrett.org betreue, welches mit WordPress MU und BuddyPress läuft. Für WPMU gibt es inzwischen auch die 2.8.1, aber da es seltener genutzt wird auch noch nicht viele Rückmeldungen. Von BuddyPress habe ich inzwischen die dritte Version in zwei Monaten, die vierte, die dann zu MU 2.8.1. passt ist schon angekündigt.

In Kombination mehrerer Blogs und Plugins, könnte ich mich wohl Vollzeit mit nichts anderem als den WordPress-Installationen befassen. Dazu habe ich weder Zeit noch Lust. Deshalb warte ich nach jeder Veröffentlichung erst einmal einige Tage ab, schaue dann was so an Fehlermeldungen einging und teste dann erstmal lokal, danach auf einem Testblog und nur wenn das beides klappt, probiere ich das auch auf den anderen Blogs.

Plugins, die mit einer Version laufen, aktualisiere ich zwischendurch nur, falls es Sicherheitslücken gab, ansonsten aktualisiere ich diese dann nur mit einer neuen WP-Version, also einmal testen. Neue Funktionen, weitere Plugins handhabe ich ebenso, wenn es nicht ganz dringend ist, gibt es auch Zusätzliches nur beim Upgrade.

Ich überlege für einzeln installierte Blogs jedoch immer mehr, ob sich nicht ein Wechsel der Blogsoftware anbietet. BuddyPress hat gerade keine Konkurrenz, damit müsste ich dann noch leben, aber für den Rest… Schade, dass auch WordPress mit steigender Zahl an Nutzern immer mehr Monopolisten-Allüren hat…

Das war der Hauptgrund für mein ichphone, nö iphone sage und schreibe ich nur selten, denn Marken und Statussymbole sind mir nicht wichtig.

Was ich jedoch wollte ist von so einem Ding aus bloggen, wenn mir grad was einfällt, so wie jetzt grad auf dem Balkon.

Über den Browser wie sonst wäre per Mobile schon sehr mühsam, aber mit einer speziellen Applikation geht das wirklich gut.

Mich interessiert, ob jemand weiß wie das bei anderer Blogsoftware ist, gibt’s da auch Applikationen? Falls nicht wie klappt bloggen per Browser?

Ich fände es prima, wenn da jemand was drüber weiß…
Das Bild ist ein Screenshot, der sich wie andere Bilder ganz einfach mit der Anwendung einfügen lässt.

Nun, ich fürchte keinPlugin schafft es, dass meine Beiträge bereits vorm Schreiben so optimiert, dass die Suchmaschine schon mal Platz 1 freihält, weil da mein kommender Beitrag stehen wird.

Etwas überspitzt formuliert, aber von ein paar Grundlagen wie vernünftigem Code mal abgesehen, glaube ich ja immer noch, dass auch der Inhalt die Platzierung beeinflusst. Deshalb ist mir Suchmaschinenoptimierung auch nicht so wichtig. Klar ich achte auf einige Punkte, wenn die passen fein. Aber ich bin nicht bereit für jeden Beitrag nochmal sehr viel Zeit aufzuwenden.

Mein Plugin muss mir deshalb zwei, drei einfache Möglichkeiten bieten, mit denen ich etwas pro Beitrag anpassen kann, mehr brauche ich nicht.

HeadSpace2 hat Einstellungsmöglichkeiten pro Blog, pro Seite sowie pro Beitrag, ich kann einen anderen Titel angegeben und eine eigene Beschreibung. Für mich ist das so genug. Ich habe mir auch WP-Seo schon mal angesehen, das kann dieses Punkte natürlich auch. Intensiver habe ich nicht getestet, denn im Moment bin ich mit HeadSpace zufrieden.

Warum sollte ich für ein Plugin zahlen, wenn ich eins kostenlos haben kann, was das tut, was ich möchte?

Mich stört nicht grundsätzlich die Idee auch mal zu zahlen. Nur meine ich, dass muss das Plugin Funktionen haben, die ich haben möchte und die ich anders nicht bekomme. Für meine Zwecke ist das bei WP-Seo nicht gegeben, es kann wahrscheinlich noch vieles, aber das will ich grad nicht, deshalb nur für mich gibt es keinen Grund zu wechseln.

• Firefox-Logo: trademark of the Mozilla Foundation

Da ich grad mal noch einen Rechnertest machte, aktuellster Firefox auf KDE 4 und auch frisch installierte Add-Ons auf meinem Zweitrechner, testete ich auch gerade mal, wie es jetzt hier mit der Geschwindigkeit ist.

Huch, siehe da, zwar noch nicht traumhaft, aber statt der mühsamen rund 20 Sekunden sind 7,3 Sekunden nicht rasend schnell, aber noch akzeptabel benutzbar. Klar, eigentlich finde ich fürs Speichern eines Artikels in WordPress dürfte nicht mehr Zeit drauf gehen, wie fürs Laden der Startseite eines unserer Blogs, denn da stehen immerhin jeweils sieben Artikel und es wird noch die ein oder andere Spielerei geladen, letzte Beiträge usw.

Miserable Speicherzeiten mit Firefox im WordPress-Adminbereich unter KDE 3.5

Allerdings ändert das im Moment noch nichts an den miserablen Zeiten mit KDE 3.5. Leider hatten ja alle Alternativen ebenfalls ein deutliches Problem: Opera wurde wohl nicht berücksichtigt, denn das Absätze verlorengehen im Grafikmodus ist schon ein sehr trauriges Bild. Klar, Seamonkey kommt soweit klar, ist ja auch dieselbe Grundlage, wie Firefox, aber nach rund zwei Wochen, war ich so genervt von dem völlig veralteten Browser, für den es auch viele Erweiterungen nicht gibt, dass ich zunächst wieder Firefox nutze.

Für Konqueror müsste ich einerseits viele meiner Einstellungen ändern und zumindest was weitere Tools angeht, wie z.B. Firebug, YSlow, Pagerank usw. hilft der Konqui ja leider auch nicht weiter. Google Chrome gibt es inzwischen zwar in einer Ubuntuversion auch ohne den Umweg über wine, aber zumindest direkt als Linuxversion von Google nach wie vor nicht. Insofern sind die Alternativen eben doch keine ernstzunehmende Option für den täglichen Umgang.

Andererseits ist Firefox auch nach einem Update auf 3.0.7 nicht schneller, sondern eher noch langsamer geworden. Während es beim Webseitenaufruf noch geht – zumindest deutlich schneller als IE8 – ist es in den WordPress-Dashboards eine Katastrophe. Heute hatte ich für einmal speichern eines Artikels mit 106 Wörtern den traurigen Rekord von 48,8 Sekunden…

Irgendeine Lösung brauche ich jetzt dringend, denn es macht keinen Spaß zu bloggen, wenn ich mit solchen Zeiten rechnen muss. Insgesamt hat sich das Ganze nochmals verschlechtert nur noch selten klappt es wenigstens in 20 Sekunden zu speichern, im Schnitt sind es eher dreißig. Ich habe schon ein Stück weit umgestellt und beschränke meine offenen Tabs von sonst eher um die fünfzig auf eher unter dreißig, aber trotzdem dauert jede Aktion ewig.

Firefox kann auch nicht mehr im Hintergrund speichern, sondern der eine Tab legt zeitweise alle anderen Tabs lahm. Für einige Sekunden braucht er sogar das gesamte System und ein Wechsel in andere Programme ist nicht mehr möglich. Ich schreibe selten einen Beitrag einfach am Stück nur mit Text und einmal speichern, sondern viele Beiträge entstehen Stück für Stück, zuweilen kommt noch ein Bild dazu, erst am Ende setze ich die Tags, mal ändere ich noch etwas an der Beschreibung der Metadaten, mal finde ich später noch einen Tippfehler, den ich kurz ändern möchte… Deshalb ist es für meine Arbeitsweise unmöglich mich mit diesen Zeiten zu arrangieren.

Firefox und WP in KDE 4

Ursprünglich wollte ich ja noch ein bisschen warten mit KDE 4, weil die ersten Tests zeigten, dass da doch auch noch einiges an Arbeit wartet. Doch ich werde jetzt meine Tests mit KDE 4 verstärken und doch schon früher als geplant darauf umstellen. Unterm Strich kostet das Einarbeiten in KDE 4 und das Anpassen, bis alles wie gewohnt klappt, wahrscheinlich weniger Zeit, als das Warten auf den Firefox, beim regelmäßigen Nutzen von mehreren Blogs…

Gentoo-Baby-Tux-Wallpaper

Die Grundlagen im HTML, wie man ein Bild so einbindet, dass es auch vergrößert dargestellt wird, gabs bereits gestern im Artikel Bilder in größerer Version anbieten.

Das Ganze funktioniert so auch, ist jedoch zuweilen ein bisschen aufwändig zu realisieren. Die einfachere und schnellere Variante ist es mittels WordPress zu machen, das nimmt einen Teil der Arbeit ab.

In WordPress kleines und vergrößertes Bild einbinden

Über Medien einfügen | Bild einfügen | Browserupload das gewünschte Bild in großer Version hochladen.

Hinweis:

Wer Wert auf validen Code legt, der sollte das Plugin Cleaner Gallery nutzen, sonst produziert WordPress invaliden Code.

• Bild hochladen
• Optionen des Bildes

Vorm Einfügen bietet WordPress diverse Einstellungen an. Hier hab ich im Beispiel die mittlere Größe gewählt und die URL zum großen Bild.

Jetzt ist WordPress wirklich praktisch, denn es erzeugt das Bild mittlerer Größe und ein Vorschaubild (150px*150px), weil ich das für die Galerie brauchen könnte.

Weiter geht’s: WordPress erzeugt jetzt eine Galerie, keine Angst das Ergebnis ist dann schon wie gewünscht.
In der HTML-Ansicht sieht diese wie folgt aus:

[caption id="attachment_1190" align="alignright" width="300" caption="Gentoo-Baby-Tux-Wallpaper"]<a href="http://www.miradlo.net/bloggt/wp-content/uploads/gentoo_tux_wallpaper_1024x768.jpg"><img class="size-medium wp-image-1190" title="gentoo_tux_wallpaper_1024x768" src="http://www.miradlo.net/bloggt/wp-content/uploads/gentoo_tux_wallpaper_1024x768-300x225.jpg" alt="Gentoo-Baby-Tux-Wallpaper" width="300" height="225" /></a>[/caption]

Daraus entsteht anschließend der folgende Quellcode:

<div id=”attachment_1190″ class=”wp-caption alignright” style=”width: 310px;”><a href=”http://www.miradlo.net/bloggt/wp-content/uploads/gentoo_tux_wallpaper_1024×768.jpg”>
<img class=”size-medium wp-image-1190″ title=”gentoo_tux_wallpaper_1024×768″ src=”http://www.miradlo.net/bloggt/wp-content/uploads/gentoo_tux_wallpaper_1024×768-300×225.jpg” alt=”Gentoo-Baby-Tux-Wallpaper” height=”225″ width=”300″></a><p class=”wp-caption-text”>Gentoo-Baby-Tux-Wallpaper</p></div>

Das ist alles.

Klar, kann man drüber diskutieren, warum es ein div-Element in Verbindung mit einem p-Element ist, ich bevorzuge sonst für solche Zwecke Listen. Aber der Vorzug liegt auf der Hand, ich muss das Bild nicht vorab in einem Bildbearbeitungsprogramm anpassen und meine Liste als HTML reinschreiben, sondern bekomme sofort, alles was ich brauche. Ein weiterer Nachteil, ist dass ich nicht so einfach einen Hinweis aufs vergrößerte Bild einfügen kann. Denn innerhalb der Galeriefunktion dann noch im Code rumfummeln um auf das vergrößerte Bild hinzuweisen, ist wohl kaum sinnvoll.

Für mich löse ich es je nach Fall, für Bilder, die nicht mehrere Versionen benötigen, ziehe ich meinen Code vor. Habe ich jedoch mehrere Bilder, die ich automatisiert mit Vorschaubildern anzeigen möchte, dann ist WordPress die schnellere Alternative und mittels Plugin habe ich zwar nicht so schönen, aber validen Code.