Skip to content

WordPress-Gebastel - Änderungen und Bugs

die 404 auf utele.eu ScreenshotIch schrieb ja schon eine erste Runde zum WordPress-Gebastel auf uteles Blog. Dieses Mal ein bisschen was zu den Änderungen und diversen Bugs.

  • WordPress passt selbst manches an: Gut gemeint, aber aus meiner Sicht zumindest irritierend. Ich suchte, warum sich keine Seiten aufrufen ließen, sobald irgendwelche Permalinks - außer der Standardvariante - eingestellt waren. Vergleichen mit einem Blog welches ähnlich aufgebaut ist, aber noch nicht auf dem gleichen Updatestand ist, hielt ich für eine gute Idee. Im Admin rief ich die Seite Permalinks auf, um nachzusehen, was da eingestellt ist. Dabei fiel mir dann auf, dass WP hierbei den Eintrag in der .htaccess ergänzt. Klar unterm Strich lag es nicht an den Umleitungsregeln, trotzdem mag ich es nicht, wenn eine Software ungefragt und ohne Info etwas ändert.

"WordPress-Gebastel - Änderungen und Bugs" vollständig lesen

Schriften mit @font-face

So ganz allmählich lassen sich Schriftarten sinnvoll einsetzen, die nicht auf dem Rechner des jeweiligen Nutzers installiert sind.  Es gibt viele freie Schriften, die dafür genutzt werden können, jedoch für deutschsprachige Blogs eignen sich nicht alle. uteles Blog als erste Testecke, siehe Screenshot. Um einen Überblick über die Schriften zu haben und weil ich eine eigene Auswahl aus Schriften mit Umlauten wollte, habe ich mir eine eigene Seite für Schriften angelegt. Vorsicht, es dauert einen Moment bis die Seite vollständig geladen ist (eher nicht mobil geeignet): http://www.miradlo.info/schriften/ Es gibt Browser - insbesondere manche ältere Browser - die die Schriften nicht darstellen können. Für die Schriftenseite ist das natürlich ungeschickt, aber für den Alltagseinsatz ist es kein Problem, denn mit Angabe von Alternativschriften wird alles korrekt angezeigt, nur eben nicht so hübsch. "Schriften mit @font-face" vollständig lesen

KDE Kontrollleiste verliert die Transparenz

  • tux läuft
Wann genau es passierte, weiß ich im Nachhinein nicht mehr, aber plötzlich fehlte die Transparenz meiner Kontrollleiste (Ubuntu und KDE 4). Ich suchte in den Systemeinstellungen vergeblich, weder in den allgemeinen Einstellungen noch in denen des genutzten AIR-Themes änderte sich das Problem beim Ausprobieren.

Miniprogramme in der Kontrollleiste

Erstmal ließ ich es, und vermutete es wäre nach dem nächsten Booten weg. Das klappte jedoch nicht, also suchte ich nochmals unter anderem in den Einstellungen der Miniprogramme, aber auch da änderte sich zunächst nichts. Eher zufällig fand ich die Lösung, beim Sperren der Miniprogramme hatte sich wohl was verschluckt. Die Lösung war einfach:
  • Miniprogramme entsperren
  • Transparenz ist wieder das
  • Miniprogramme wieder sperren
  • Transparenz bleibt da
Manche Lösungen sind sehr einfach! :)

Projekt im Hauruckverfahren : Nein zum Konzerthaus auf Klein Venedig

In Konstanz geht es manchmal ein bisschen hektischer zu. Letzten Mittwoch war ich beim ersten öffentlichen Treffen, denn da es im Web nichts an Informationen gab, wollte ich dort mehr erfahren. Sonntagnachmittag hatte ich den Auftrag ein Blog mit einigen statischen Seiten einzurichten. Nach und nach kamen Logo, Texte und weitere Infos. Ich schob deshalb so ziemlich alles was ich geplant hatte und kümmerte mich um die Seite: nein-zu-klein-venedig.de Das Ganze ist mit Serendipity aufgebaut, ist also ein Blog für die jeweiligen Neuigkeiten und hat außerdem statische Seiten zu einigen Hauptthemenpunkten: Ein bisschen mehr Zeit hätte nicht geschadet, doch da der Bürgerentscheid bereits am 21. März stattfindet, war es sehr dringend so schnell wie möglich die wichtigsten Infos und Grundlagen online zu haben. Worum es geht steht auf der Seite und auch wir haben bereits privat darüber gebloggt: Schön, wenn es bei solch zeitkritischen Projekten nur ein bisschen was schief geht. Hier fing es mit der Umleitung von Strato aus an, da klappte trotz oder gerade wegen DNS-Umleitung nicht alles auf Anhieb. Aber Serendipity war überwiegend gut zu handhaben und ließ sich meist recht problemlos so anpassen, wie ich das wollte. Einfacher wurde das natürlich auch mit einem bekannten schon mehrfach genutzten Grund-Theme und vielen Einstellungen, die ich mehrfach schon genutzt und angewendet hatte.

Serendipity installieren ::: Erfahrung bei den ersten lokalen Installationen

Vor einiger Zeit hatte ich ja schon mal einfach so kurz mit Serendipity rumprobiert, da kam dann auch irgendwas bei raus, was so ungefähr passte. Nach der Blogparade zu verschiedenen Systemen kam für mich Serendipity als beste Alternative für einen Wechsel heraus. Beim nächsten Mal installierte ich erstmals ernsthaft lokal, mit den Daten, die dann live auch genutzt werden sollen. Ich nahm die fortgeschrittene Installation, um auch gleich mal genauer zu sehen, was sich so einstellen lässt, da S9y für mich ja noch neu ist. Schritt für Schritt änderte ich die Rechte, um auch da gleich zu testen, ob Serendipity da alle Probleme anzeigt. Bis zum Ende der Installation und dem Hinweis alles habe geklappt lief es problemlos.
  • s9y Redakteursansicht Adminbereich eines Redakteurs bei S9y
Doch dann... ;)

Erster Aufruf des neuen Blogs

Ups, tja nur weil da keine Warnungen waren, war es wohl doch übertrieben direkt Umlaute zu nutzen.
"Serendipity installieren ::: Erfahrung bei den ersten lokalen Installationen" vollständig lesen

Flexible oder pixelgenaue Layouts : Ursachen und Gründe

Ich habe heute in der Linkliste auf zwei Beiträge zu flexiblen Layouts hingewiesen.

onli kommentierte daraufhin recht ausführlich. Beim Schreiben meiner Antwort fiel mir auf, dass es ein bisschen lang wird, deshalb jetzt als eigenen Artikel. onli schrieb:

"Ich bin über die Diskussionen über flexible Layouts immer wieder überrascht. Denn eigentlich führt die Diskussion am Thema vorbei. Das eigentliche Problem dürfte sein, dass CSS in derzeitiger Form ungeeignet ist für das, was ein dynamisches Layout erfordert. Man kann viele Dinge einfach nicht zuverlässig erreichen, die nötig wären: Elementen eine dynamische Größe zuordnen, aber mehreren Elementen immer die gleiche. Nachbarbeziehungen, die über ein float hinausgehen usw usf. Sicher, ich bin kein Profi, aber es scheint mir so, als sei die Ursache der Diskussion dergestalt, dass einige notwendige Layoutanforderungen mit dynamischen Layouts nicht oder nur schwer umsetzbar sind. Die Antwort sind dann aber nicht pixelgenaue Layouts, sondern Verbesserungen am Handwerkszeug. Ich werde mir bei Gelegenheit die verlinkten Videos anschauen, vielleicht beinhalten diese ja Konzepte, die meine obige Argumentation ad absurdum führt, weil damit dann alles so umsetzbar ist wie ich es mir vorstelle. "

"Flexible oder pixelgenaue Layouts : Ursachen und Gründe" vollständig lesen

Theme Wahlfreiheit für Besucher

Ich bin zur Zeit am überlegen, ob ich meinen Blog ein wenig auffrischen soll. Da gibt es Überlegungen wie:
  • Soll ich die Kategorien weiter pflegen?
  • Wieso ist Navigation und Funktion miteinander in der gleichen Liste?
  • Welches Layout sollte ich nun nutzen?
  • Gefällt das alte Design den Kunden mehr als das Neue?
Solche Gedanken hat man ja immer, wenn man eine Webseite neu gestaltet. Und deshalb bin ich auf folgende Idee gekommen:

Lass doch das Design vom Kunden auswählen

In bestimmten Rahmen kann man sich erlauben zwei- oder drei Designs anzubieten. Wenn man auf die Seite kommt, erscheint das aktuelle Design. Wenn man dann ein anderes Design, mit z.B. mehr Funkionalität, haben will, kann man dies auswählen. Das Design wird gewechselt und der Kunde hat andere Möglichkeiten als zuvor.

Ja aber, dann muss man ja Kundendaten speichern!

Wenn man will, dass der Kunde beim nächsten Mal das gleiche Design vorfindet, muss man mindestens einen Cookie auf der Kundenmaschine abspeichern. Oder noch komplizierter: Der Kunde muss sich am System anmelden. Das wäre bei einem normalen Blog oder einer normalen Webseite wirklich ein Overkill. Ich will einfach nur die Wahlmöglichkeit bereitstellen. Wenn ein Kunde dann das Design wechseln will, soll er hierzu eine Möglichkeit erhalten. Falls der Kunde Cookies zulässt, kann man immer noch über eine permanente Umstellung nachdenken.

Ist das nicht eine halbherzige Idee?

Ich denke nicht. Es lässt dem Kunden die Freiheit, zwischen verschiedenen Designs auszuwählen. Vielleicht ist der Kunde heute positiv eingestellt und will eine schöne, leuchtende Darstellung? Vielleicht will er heute nur Text, da er schnell was suchen muss? Wenn man sich den Mehraufwand leisten kann, dann wäre es vermutlich eine gute Idee mehr als ein Design zur Verfügung zu haben.

Heute ganz ohne Spielerei, Design und so... CSS-Naked-Day

  • miradlo bloggt ohne Styles ohne CSS also nacktes HTML
Wie was kein Design? Warum, was ist los?

CSS Naked Day

Einen Tag lang sollen mit der Aktion keine Styles anzuzeigen, Webstandards gefördert werden. Denn ohne Styles, Bilder und Design sieht man den Seitenaufbau genauer. Manche Seiten nutzen den internationalen "ganzen Tag" das bedeutet das CSS bleibt für 48 Stunden aus, damit es weltweit alle sehen können, dann dauert der 9. April halt nicht nur 24 Stunden. Wer sich an Webstandards hält nutzt valides und semantisches Markup in (X)HTML. Die Inhalte sind sinnvoll strukturiert, mit Überschriften, Absätzen, Listen usw. An diese Regeln sollte man sich natürlich immer halten, die Aktion ist nur ein Hinweis um darauf aufmerksam zu machen. "Heute ganz ohne Spielerei, Design und so... CSS-Naked-Day" vollständig lesen

Plugins vertragen sich nicht: Link Indication und Quote Comments

Teil 871 der "never ending story". Ich bastele ja in letzter Zeit, nach dem Update auf WordPress 2.7 an einigen Blogs, um das ein oder andere an zusätzlichen Möglichkeiten miteinander zu verbinden. Dabei habe ich einige Plugins eingebaut, manche wieder entfernt und hatte teils auch engeren Kontakt mit den Autoren. Schlussendlich lief Quote Comments, war valide, tat was es soll und alles war gut. Je nach Blog fand ich die Idee, Links zu markieren, ob sie intern sind oder nach außen führen gut. Eine weitere nette, zusätzliche Möglichkeit, die es erleichtern kann, sofort einzuschätzen wohin ein Link führt. Ich testete das Link Indication Plugin, wie immer erst lokal, es klappte alles prima, es lief und zeigte im ein oder anderen Blog, wohin die Links führen, prima!

Zitate vorführen

Ein, zwei Tage später wollte ich jemand zeigen, wie die Zitate funktionieren, dass ein ganzer Kommentar zitiert wird, wenn man auf den Link klickt, bzw. eben nur Teile davon, wenn man den gewünschten Text markiert. Tja, wollte! Denn das klappte nicht, da kam kein Zitat, weder direkt, noch nach Markieren eines Textteils. Och nö, nicht schon wieder! :-( Inzwischen testete ich mal genauer. Zunächst suchte ich nach anderen Plugins, die sich auf die Kommentare beziehen, aber da gab es keinen Fehler. Daher suchte ich dann nach allem, was geändert war, seit ich das letzte Mal Quote Comments getestet hatte und fand dabei was nicht klappt:

Link Indication und Quote Comments vertragen sich nicht

Läuft nur eins von beiden ist alles gut, es tut was es soll. Sind beide aktiviert, dann läuft Link Indication weiterhin, aber Quote Comments zitiert nichts mehr. Ich weiß nicht, was sich da verhakt. Ich kann auch nicht einschätzen, welches der beiden "schuld ist" oder ob es einfach ein unglücklicher Zufall ist. Ich lasse jetzt mal verschiedene Kombinationen stehen und schreibe die Autoren an, vielleicht hat ja einer der beiden eine Idee. Sonst muss ich halt in Zukunft je nach Blog entscheiden, was wichtiger ist.

Eckpunkte

  • alle getesten Blogs laufen mit WordPress 2.7
  • am Theme liegt's nicht auch mit dem Default-Theme läuft es nicht
  • aktivieren und deaktivieren anderer Plugins hat keinen Einfluss auf das Verhalten der Zitate

Blogs und Varianten der Plugins

Aktiviert ist/sind:
  • hier im Blog nur Quote Comments
    • und es funktioniert
  • in Rolands Guggat emol Blog nur Link Indication
    • und es funktioniert
  • in uteles Blog Link Indication und  Quote Comments [aktualisiert: 13.2. da mir dort die Zitate wichtig sind habe ich jetzt auch hier Link Indication deaktiviert]
    • damit läuft Link Indication weiterhin
    • Quote Comments zitiert nicht mehr
Jetzt bin ich mal gespannt, ob einer der Autoren eine Idee hat.  Ärgerlich finde ich einmal mehr, dass tatsächlich jede kleine Änderung sich an ganz anderer Stelle auswirken kann. In Kombination mit automatischen Aktualisierungen nicht nur von Plugins, sondern demnächst auch von WordPress selbst ist das ziemlich ungeschickt. Denn das automatische Aktualisieren führt noch leichter dazu, dass mal eben per Knopfdruck etwas geändert wird, mit dem Risiko, dass an anderer Stelle plötzlich irgendwas nicht mehr funktioniert. So schön die vielen Möglichkeiten mit Plugins sind, wer Wert auf ein stabiles und funktionierendes System legt muss schon sehr intensiv testen, um sich das zu erhalten. Ich wünsche mir eine Sicherheitsschicht mit definierten Schnittstellen für Plugins, so dass die sich nicht in die Quere kommen können. Nö, mich interessiert dabei nicht, dass das so nicht machbar ist... ;-)

Webprojekt-Vorlage für neue Webauftritte

Je nachdem, wie häufig man ein neues Webprojekt startet, bei dem es anfangs zunächst immer um dieselben Grundlagen geht, lohnt es sich, dafür eine Vorlage, ein Basisprojekt, zu erstellen. Wir nutzen inzwischen ein ganzes Basisprojekt, in dem die relevanten Templates und Strukturen bereits enthalten sind. Schritt für Schritt geht es um folgende Vorlagen:

CSS-Vorlage

Wohl die meisten, die häufiger ein neues Projekt beginnen, nutzen ein CSS-Template. Ich ändere diese Vorlagen immer mal wieder, aber im Grunde gehe ich prinzipiell immer von derselben Struktur aus:
  • basis.css in dieser Datei definiere ich Grundelemente, wie z.B. Überschriften, Absätze usw.
  • layout.css diese Datei ist fürs eigentliche Layout zuständig und enthält die Definitionen, der div-Container, wie sie bei uns möglichst immer eingesetzt werden. Ausnahmen gibt es nur, wenn es gar nicht anders geht, ansonsten nutzen wir:
  • spezielles.css alle speziellen Definitionen stehen hier:
    • seien es genutzte Konstrukte, die stabil und browserübergreifend Bilder einbinden
    • die ein oder andere zusätzliche Klasse
    • ein spezieller zusätzlicher Container
  • etwaige sonstige Stylesheets, z.B. für den Druck, zur Anpassung der Internet Explorer per Conditional Comments, oder was sonst eventuell nötig ist
In den Vorlagen dieser Dateien stehen Grundwerte, die so meist benutzt werden. Verändert wird das Layout, individuell sind Logo und Hintergrundbilder, angepasst werden noch Farben und einige weitere Kleinigkeiten pro Projekt. Viel mehr ändert sich jedoch nur selten, denn der Hauptunterschied liegt ja im Layout des jeweiligen Projekts. Grundelemente werden immer benötigt und Farben eben ans Layout angepasst. Der Vorzug einer Vorlage ist, dass ich es dort sofort nachziehen kann, wenn mir bei einem Projekt etwas spezielles auffällt, oder ich mal wieder was vereinfachen kann.

HTML-Vorlage

Eine Vorlage der Grundstruktur bieten natürlich auch bereits die meisten Editoren, z.B. der bei uns genutzte Quanta. Wir setzen jedoch so gut wie nie ausschließlich HTML ein. Meist gibt es entweder noch einige eigene Entwicklungen in PHP oder eine Software wird darüberhinaus eingesetzt.

Software-Vorlage ::: z.B. WordPress-Blog

Je nachdem, was man häufig nutzt, bei uns zur Zeit WordPress, ist es sinnvoll sich auch da die relevanten eigenen Anpassungen als Vorlage zu nutzen. Es gibt eine Reihe von Plugins, die wir üblicherweise nutzen, da sich die jedoch sehr schnell ändern, packe ich ins Basisprojekt nicht alle relevanten Dateien. Keinesfalls gibt es dort das gesamte WordPress, sondern die jeweils aktuelle Version wird genutzt. Extra sichere ich jeweils die in einem Plugin geänderten und angepassten Dateien, nur selten unterscheiden die sich pro Blog, meist sind diese Anpassungen für alle Blogs identisch. Als Vorlage gibt es jedoch das Template, von dem ich üblicherweise ausgehe. Dieses habe ich mir aus der leeren und gut kommentierten Vorlage von texto.de erstellt. Bei gravierenden Änderungen in WordPress schaue ich mir die dort jeweils aktuelle Vorlage nochmal an und passe mein Template an. Das jeweilige Theme ist abhängig vom jeweiligen Blog, bzw. Webauftritt mit WordPress, die Grundstrukturen sind jedoch überwiegend wieder gleich.

PHP-Vorlage

Manches läuft bei uns auch in Projekten, die keine weitere Software einsetzen mittels PHP. Es ist einfach nicht sinnvoll reines HTML zu nutzen, da vieles automatisiert einfach besser geht. Jedes Projekt benötigt eine Navigation, automatisiert wird meist irgendwo ein Datum genutzt, Metadaten die nicht projektspezifisch sind werden für alle Seiten gleich eingebunden, es gibt ein Kontaktformular... Diese Grundlagen, die immer dieselben sind, stehen in unserer PHP-Vorlage. Sobald wir Neues nutzen wird das auch hier nachgezogen, beispielsweise um Spam zu vermeiden, ändert sich regelmäßig etwas.

...noch eine Vorlage?

Ja, eine habe ich noch ;-) Nein, es ist nicht direkt "eine Vorlage" hilft aber trotzdem ungemein:

Layoutbildervorlage

Sinnvoll benannte Layoutbilder bilden zunächst einmal das Gerüst, mit dem bereits ein erstes Design möglich ist. Später können die Bilder einfach reinkopiert werden, unter demselben Namen, damit spart man sich das Anpassen der Pfade. Klappt auch für Favicons, Bilder auf Fehlerseiten und ähnliches, was man häufig nutzt. Falls ich was vergessen hab, oder ihr noch einen praktischen Tipp habt, gerne...

Fehlersuche und aktualisieren auf WP 2.7

Ich bin ja seit ein paar Tagen an einigen Ecken an den Blogs und bastele dran rum. Teils die Optik, teils die Funktionen, teils die Anpassungen am Theme, um es für die Wordpressversion 2.7 lauffähig zu bekommen. Einige Funktionen und Plugins habe ich inzwischen beim ein oder anderen Blog hinzugefügt, manches Plugin fordert doch noch einige Anpassungen, bis es genau das tut, was ich wollte. Im Großen und Ganzen hat nach ein bisschen Überredungskunst das meiste soweit geklappt. Mit dem Update-Hinweis hatte ich kein größeres Problem, der ließ sich leicht abstellen. Aber leider bleibt ein dickes Problem:

Wp 2.7 Adminbereich im Dashboard nur Menü, kein Inhalt

Ja, alles andere geht, ich kann hier schreiben, Kommentare funktionieren, Plugins de- und aktivieren geht usw. Aber das Dashboard selbst, hat das Menü und die Kopfzeile und sonst nichts. Bei anderen Blogs mit denselben Dateien und ähnlichem Aktualsierungsverlauf geht es, hier geht es nicht.

Das Problem begann mit irgendeiner 2.6x glaube ich:

Mit 2.6 konnte ich noch den Link ändern, dann erschien der Inhalt. Klar, das war etwas lästig, aber möglich. Seit 2.7 bleibt das Dashboard leer, da ist das Menü und sonst nichts. Bei anderen Installationen klappt alles, nur hier nicht

Gemeldet habe ich das inzwischen dickere Problem hier:

#8260 (A false linking to dashboard in the sidebar after upgrade) - WordPress Trac - Trac Nach vergeblicher Suche einer Lösung habe ich mal in den relevanten Threads beim deutschen Wordpress-Forum um beim Supportforum von WordPress nachgefragt.

Vergebliche Lösungsversuche

Übrigens, ja ich habe alles versucht, was mir einfiel. Das Problem besteht sowohl bei der lokalen Installation als auch bei der Liveversion. Mir war es lokal nicht aufgefallen, da lokal das Dashboard ja nicht so wichtig ist, beim Testen nutze ich alle anderen Administrationsseiten stärker, als jetzt diese. Ursprünglich hatte ich gehofft, das Linkproblem wäre bei einer neuen Version dann weg. Dass es jetzt erst noch da war, aber kein Inhalt mehr ist lästig. Nach dem Umbenennen aller leeren index.php-Dateien in index.html war tatsächlich das Linkproblem weg, das ist schön. Ich habe jedoch immernoch keinen Inhalt im Dashboard. Ich habe Plugins de- und aktiviert, gelöscht neu hochgespielt. Ich habe alle, aus meiner Sicht eventuell in Frage kommenden WP-Dateien nochmal geprüft, ob sie wirklich so sind, wie auf den Blogs, auf denen alles klappt. Ich mit dem Adminize-Plugin gespielt, nicht nur mit de- und aktivieren, sondern auch mit den Menüeinstellungen, aber es half alles nichts. Egal ob:
  • mit oder ohne Plugins
  • mehrfaches Hochspielen
  • Themes und Einstellungen ändern
  • Logfiles nach relevanten Einträgen absuchen
  • ...
die Seite bleibt leer. Falls irgendjemand noch eine Idee hat, ich würde mich sehr freuen...

WordPress und Plugins : nicht immer problemlos...

Ich bin ja schon immer sehr vorsichtig, was Plugins angeht. So praktisch es einerseits ist, dass es nahezu jedes Feature als Plugin gibt, so schwierig kann andererseits die Fehlersuche werden, wenn mal was nicht klappt. Bei Prinzzess gab es kürzlich ein Problem, als die Seiten zwar am Anfang brav:

<meta name="robots" content="index,follow" />

auslieferten, jedoch weiter unten im Header das Ganze überschrieben wurde:

<meta name="robots" content="noindex,nofollow" />

Damit wären die Seiten relativ bald nicht mehr von Suchmaschinen indiziert worden. Wer jedoch gefunden werden möchte, sollte das natürlich vermeiden. Entdeckt hat es zufällig Michael, vielen bekannt von greensmilies, der jedoch auch noch das Blog niedermeyer betreibt. Mir fiel direkt der Beitrag auf, weil sich Prinzzess fragte, ob ihr Blog wohl gehackt wurde. Ein erster Blick in Quelltext schien kein Problem zu zeigen, denn da war ja ein index, follow. Doch bei genauerem Suchen, sah ich dann, dass es überschrieben wurde.

WordPress Seitenaufbau

Nach einigen Installationen, Versuchen, Themes erstellen usw. habe ich gelernt, dass WordPress im Grunde sehr einfach aufgebaut ist. Der Hauptteil, der vom Theme kommt steht meist am Anfang, dann kommen die jeweiligen Einschübe der Plugins, da die sich ja nur an fest definierten Stellen anhängen können. Die Zeile mit noindex, nofollow, stand im Quelltext direkt nach der Einbindung des Stylesheets des Hangman-Plugins, erst kurz danach folgten weitere Einschübe anderer Plugins. Bei Prinzzess liefen zu diesem Zeitpunkt immerhin 61 Plugins, deshalb ist der Quelltext nicht ganz trivial zu lesen. Michael bekam von ihr Zugang und konnte schließlich bestätigen, dass es tatsächlich an dem Plugin lag. Nach einer Überarbeitung konnte es wieder aktiviert werden und verhindert nun nicht mehr, dass die Seiten indiziert werden.

Plugins vorsichtig nutzen

Für mich war dieser Vorfall ein weiterer Hinweis, dass es gut ist, vorsichtig mit Plugins umzugehen. Insbesondere, wenn viele Plugins eingesetzt werden, können auch Seiteneffekte entstehen, weil sich Plugins nicht vertragen. In unserem Mitarbeiterblog, welches nicht für die Öffentlichkeit sichtbar ist, bin ich etwas experimentierfreudiger, habe jedoch auch schon öfter Probleme festgestellt. Insbesondere, die sehr praktischen und einfach einzusetzenden Widgets, verursachen immer mal wieder Fehler. In manch einer Situation ziehe ich Anpassungen am Theme vor, auf manches nette Feature, verzichte ich ganz bewusst. Nach meiner Erfahrung, sind insbesondere Plugins und Eigenschaften, die mittels JavaScript realisiert wurden, häufig eine Fehlerquelle. Nein, ich glaube nicht, dass JavaScript böse ist, allerdings bin ich sicher, dass es leider viele gibt, die mit JavaScript nicht sorgfältig umgehen. Ich kenne kaum eine Seite, die JavaScript einsetzt, bei der nicht zumindest einige Warnungen ausgegeben werden, selbst gemeldete Fehler kommen regelmäßig vor. Bei JavaScript ist das Problem ähnlich, wie bei PHP, vieles funktioniert noch, obwohl es nicht korrekt genutzt wird. Im Web können sich Fehlerquellen so immens häufen, denn verziehen werden zunächst: Fehler im HTML, im CSS, im PHP und im JavaScript. Dass es da, ab und an auch mal richtig knallt, ist kein Wunder. Nicht selten werden ganze Systeme, wie z.B. WordPress genutzt, in denen, oft auch noch veraltete Versionen laufen, zuweilen kombiniert mit noch älteren oder ganz neuen Plugins. Im Grunde ist es eher erstaunlich wie häufig solche Kombinationen noch einen lauffähigen Webauftritt ergeben.

Meine Lösung

Ich werde weiterhin versuchen, so wenig Plugins wie möglich einzusetzen, mir sind die zur Zeit meist etwa 15-20 genutzten Plugins pro Blog im Grunde schon zuviel. Bei manchen kommt da ja noch Google Analytics hinzu, mehrere eingebundene Links und Bilder, wie z.B. zu Blogverzeichnissen oder geschaltete Werbeanzeigen. Insbesondere bei der Ladezeit einer Seite, macht es sich dann doch bemerkbar, was alles Zeit braucht, bevor die Seite vollständig angezeigt wird.

...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... :-(
tweetbackcheck