Skip to content

Fehlersuche am Beispiel: Inhalt im Dashboard fehlt bei WordPress 2.7

Wie schon berichtet, hatte ich hier den Fehler, dass kein Inhalt mehr angezeigt wurde. Ansätze, gab es beispielsweise bei ayudawordpress ("no-puedo-accesar-a-mi-panel-de control" spanische Seite, die Idee in /wp-admin/includes/plugin.php zu suchen), gemeldet hatte ich es beim WordPress-Trackingsystem, da vermutete ich noch einen Zusammenhang mit dem dort beschriebenen Bug. Jedenfalls fand ich keine Lösung für dieses Problem. Irgendwann beschloss ich, es erst einmal zu lassen und machte an anderen Blogs weiter mit neuen Einbindungen, Designänderungen usw. Dabei hatte ich gestern dann plötzlich live zwei kaputte Dashboards und lokal gleich drei. :-(

Lösung suchen

Ich ging vor wie immer, erst einmal überlegen, was und wo habe ich zuletzt geändert. An keiner Stelle hatte ich den Adminbereich angefasst. Es waren neue Versionen von Plugins, teils neue Plugins, teils Änderungen und Ergänzungen am Theme.

Vorgehen

  • Plugins abschalten
  • Änderungen rückgängig machen
Das half jedoch nicht, das Problem blieb, zwar ein Menü und ein Header, der noch Dashboard anzeigte, aber keinerlei Inhalt. Also nochmal im Netz suchen, ob irgendjemand diesen Fehler schon hatte und eventuell eine Lösung dazu. Schwierig hierbei ist, dass je nach Sprache das Dashboard nicht so genannt wird. Bei deutschem WordPress war es lange der Tellerrand und auch in anderen Sprachen war es teils übersetzt. Auch wer englisch schreibt stellt die Frage daher nicht immer mit Dashboard. Wie schon einige Tage zuvor fand ich wenig hilfreiches, ein zwei Ideen, wo ich weitersuchen könnte, aber mehr nicht.

Nächster Versuch das Problem zu finden

  • Code vergleichen zwischen funktionsfähiger und nicht funktionierender Lösung
  • mit HTML-Einfügungen wie "hier" "da" "davor" "dahinter" prüfen an welcher Stelle im Code das Ding aussteigt
  • sobald das etwas klarer ist dasselbe innerhalb der PHP-Teile mit
    • echo "da";
  • testen, um rauszufinden, wo genau überhaupt das Problem liegt.
Klingt langsam? Ja, ist langsam, ist Fummelei, da viele Dateien miteinander erst das ganze Dashboard ergeben. Im Core-Code von WordPress kenne ich mich nur sehr schlecht aus, deshalb eine wirklich mühsame Suche. Schon vor einigen Tagen hatte ich da einiges probiert und insbesondere auf selbst veränderte Teile geachtet. Ich hatte auch schon mal allen eigenen Code entfernt, aber bekam damit noch mehr Fehler. Letztes Mal gab ich irgendwo da dann auf. Dieses Mal war ich mir relativ sicher an den passenden Stellen bereits geprüft zu haben und testete nicht ganz konsequent alles.

Noch ein Versuch zu einer Lösung zu kommen

Immer, wenn sich ein Fehler partout nicht finden lassen will, ist es eine gute Idee, sich selbst zu überprüfen. Das klappt allein nicht, mit Partner ist es sinnvoller (Pair-Programming). Gut ist jemand, der ebenfalls etwas vom Thema versteht, jemand, der jedoch überhaupt zuhört genügt oft schon:
  • zuerst einmal zeigen, was ist das Problem
  • zeigen an welchen Stellen, man was getan hat
  • nebenbei erklären, warum man es gerade dort versucht hat
Dieses Mal hatte ich Glück, Roland versteht deutlich mehr von PHP als ich, deshalb gerade beim Suchen, was sieht denn komisch aus, was könnte ein Kanditat für ein Problem sein, da ist er besser. Die Vorgehensweise bleibt gleich, aber von Roland kamen mehr Rückfragen, was macht das, lass uns da mal noch probieren... Roland traute einer von mir integrierten Funktion nicht, bei der ich sicher war, den Ausbau bereits getestet zu haben. Hatte ich auch, allerdings hatte ich etwas übersehen. Das fiel erst jetzt auf, als wir ganz sicher gehen wollten, dass hier nicht die Ursache ist. Ich kenne Programmieren in PHP in etwa  in dieser Form:

<?php if($position == "header"){ ?> <div id="header" > <h1>Gib mir das Dashboard ;-)</h1> <? } ?>

Sprich:

  • mach was <?php
  • Klammer auf {
  • hör mal kurz auf ?>
  • gib mal was aus <div id="header" >...
  • Klammer zu }
Gesehen hatte ich in WordPress schon häufiger mal ein

<?php endif; ?>

Bisher hatte ich jedoch kein Problem damit, und habe es schlicht ignoriert. Gerade bei WordPress bin ich meist eher pragmatisch, ich mache genau so viel, bis ich eine Lösung für mein Vorhaben finde, dann höre ich auf. Ich habe bisher noch nie versucht den Code genauer zu lesen und zu analysieren, um zu verstehen, was genau da wie passiert. PHP-Programmieren überlasse ich meist anderen und bastele nur soviel, wie gerade nötig. Nach kurzer Recherche, weil die Klammersetzung nicht so klappte wie wir es erwarteten, fand Roland heraus, dass dieses endif ursprünglich von alten PHP-Versionen kommt und nichts anderes tut, als eine Klammer zu ersetzen. Prima, das hätte mir mal jemand sagen können... ;-) In diesem Fall war es nicht, wie sonst oft, dass die schließende Klammer irgendwo anders gesetzt wird, sondern das endif am Ende des ganzen Inhalts schloss erst meine Klammer.

Hä? Was hilft das jetzt?

Nun damit war klar, wenn hier etwas schief geht, dann geht gar nichts mehr. Wir putzten den Aufruf der "Vorgesehenen Beiträge", der an dieser Stelle drin war, setzten die Klammern sauber, eliminierten das endif und siehe da: "Kaum macht man's richtig, geht's" ;-)

Fazit dieses Fehlers

Offensichtlich liefert WordPress, wenn keine vorgesehenen Beiträge da sind, etwas anderes zurück als bisher. Denn genauso war diese Funktion in mehreren Blogs unterschiedlicher Versionen schon mal drin. Problem bei der Suche:
  • nur, wenn es keine vorgesehenen Beiträge gibt, taucht das Problem auf
  • Entwürfe und bereits publizierte Beiträge sind dafür irrelevant
In meinem Fall tauchte der Fehler im Mitarbeiterblog gar nicht auf, dort gibt es immer ein paar vorgesehene Beiträge, da wir einen Kalender einsetzen, wer wann da ist, welche Termine anstehen, diese Termine werden mit einem Beitrag in der Zukunft veröffentlicht. In uteles Blog gibt es fast immer ein, zwei Beiträge, die ich mal zwischendurch tippe und aufhebe, falls ich grad nichts Aktuelles habe. Hier im Blog kam ich in letzter Zeit nicht dazu, mehr als mal einen Entwurf zu schreiben. Rein zufällig fiel mein Hochspielen mit der Veröffentlichung des letzten vorgesehenen Beitrags in  uteles Blog zusammen. Deshalb sah es so aus, als gäbe es einen Zusammenhang. Im Nachhinein hätte ich mir die anfängliche Suche sparen können, denn es lag weder am geänderten Code, noch an den aktualisierten Plugins. Der Haken an der Fehlersuche ist: ich weiß ja leider anfangs nicht, was das Problem ist.

Unterm Strich

Gut war jetzt, dass der Fehler gerade nochmal auftrat, als ich noch am Basteln war. Sonst hätte ich wohl zunächst einmal an ein Versionproblem geglaubt und nicht weiter gesucht. Jetzt ist die Stelle repariert und abgesichert, die Gefahr, dass hier nochmal ein Fehler auftritt somit geringer. Der Fehler, dass das Dashboard keine Inhalte mehr anzeigt ist weg, die Funktion ist geputzt. In diesem Zusammenhang fiel mir noch eine alte Funktion auf, die ich nebenbei grad repariert habe. Und, weil ich schon dran war, habe ich grad noch was ergänzt. In meinem Dashboard gibt es jetzt wieder diese netten kleinen Hinweise, die ich jetzt in einigen Versionen nicht oder nur teils hatte, doch dazu ein anderes Mal mehr.

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...

Valider Code ::: Webstandards einhalten in Blogs oder CMS

Früher oder später werde ich einfach nur sauer, wenn ich mal wieder feststelle, dass valider und dokumentierter Code noch weit davon entfernt ist zu einem Webstandard zu werden. Da hatte ich den Kommentarfeed glücklich wieder zum Laufen gebracht, und schaute mal eben wegen irgendwas, ob die Seite noch valide ist... Doch dann:

Plugin zum Zitieren von Kommentaren nicht valide

Na gut, also doch nochmal nach was anderem schauen.
  • Tja, da war jedoch die eine Version für die ich gleich wieder alles mögliche umbauen müsste mit JavaScript-Bibliothek im Theme, das wollte ich möglichst nicht.
  • Die bisherige Version nochmal angesehen, die war mir von jetzt eingesetzten Plugin überspielt worden, beim letzten automatischen Update. Tja, irgendwie wäre die wohl lösbar, beim Autor wird sie mit WordPress 2.7 eingesetzt. Allerdings mit einer ganz anderen Kommentarstruktur. Die Anleitung war noch nicht für diese Version, das hätte größeren Umbau bedeutet.
Nochmal kurz überlegt, da war was mit auskommentieren... Ja, ich gebe es zu, das ist keine ganz saubere Lösung, auf Dauer taugt die so nicht, aber vielleicht lässt sich der Autor ja überzeugen seine nächste Version auch valide anzubieten... Wenn auch nicht optimal, aber erstmal soweit valide: <script type="text/javascript"><!-- // hide from really old browsers that noone uses anymore // also hide from browsers that use the XHTML DTD // content of your Javascript goes here // --></script>

Valider Code mit Gewalt sinnvoll?

Nein, natürlich ist das noch keine optimale Lösung. Mir geht es jedoch gerade darum einige fremde Einbindungen auszuprobieren und zu testen, dafür brauche ich eine valide Grundlage. Wenn ich schon vorher unzählige Fehler habe, habe ich keine Chance rauszufinden, ob die Einbindungen valide möglich sind. Ganz nebenbei waren da noch die kleinen Haken, die überflüssig sind und einfach nerven:
  • ein Button der ein border="0" im img-Tag stehen hat
  • ein kopierter Link der mal wieder das unsägliche, veraltete und mit XHTML strict, nicht kompatible target="_blank" nutzt
  • die JS-Fehlerkonsole mache ich schon gar nicht auf, nur ganz selten mal ein JavaScript das nicht zumindest reichlich Warnungen, wenn nicht sogar Fehler schmeisst...
  • das Plugin, damit WordPress eine valide Galerie baut habe ich schon drin
  • an anderer Stelle musste ich jetzt doch wieder ein Bild von Hand codieren, weil auch ein Bild natürlich nicht valide eingebunden wird (ich wollte es doch nur mal einmal ausprobieren...)
  • subscribe to comments nicht valide, repariert mit einem umschließenden <p> für die input-Felder des Formular zum Abonnieren, ohne kommentiert zu haben
  • in der Themevorlage der neuen comments.php habe ich übersehen, dass ein <div> nur geöffnet, aber nicht mehr geschlossen wurde
  • was bleibt ist ein Fehler, der jedoch völlig in Ordnung geht, weil der Validator da langsamer ist, als die Möglichkeiten zur Barrierefreiheit, siehe den Artikel WP 2.7 nicht valide bei Monika
Was mich an solchen Aktionen ärgert ist, dass sie unterm Strich alles zusammen Stunden kosten, bis wieder alles auf allen Blogs passt. Würden viele Autoren von WordPress und seinen Plugins Wert darauf legen, validen und womöglich noch einigermaßen aktuell und gut dokumentierten Code zu schreiben, dann wäre es einfacher. Ich wünsche mir, dass es bei WordPress in Zukunft keine Zweifel mehr gibt, dass valide Seiten sinnvoll sind. Für mich passt die Barrierefreiheit berücksichtigen auf der einen Seite nicht zu kaputtem Code, wie immernoch in den internen Galeriefunktionen. Mein zweiter Wunsch ist ein Hinweis bei jedem Plugin, so wie die Version dabei steht, will ich valide oder eben nicht haben. Dann wüsste ich es vorher, würde mal sehen, wie aufwändig die Reparatur ist oder es eben dann lassen und ein anderes Plugin nutzen.

Plugins automatisch aktualisieren : testen : WP Kommentarfeed

Mühsam ernährt sich das Eichhörnchen...

Kommentar-Feed funktioniert wieder auch mit WP 2.7

Seit einigen Tagen lief der Kommentar-Feed auf keinem der Blogs mehr, die mit 2.7 arbeiten. Ich nutze ja keinen Feedburner oder so, sondern schlicht die WordPress-Funktionen. Bei allen Blogs ist der Feed für Kommentare unter .../comments/feed/ erreichbar. Bei allen Blogs abonniere ich die eigenen Feeds, kann ich auch nur jedem empfehlen. Allerdings schaue ich nicht bei jedem Blog ständig rein und nutze den eigenen Feed direkt. Bei unserem internen Blog jedoch beispielsweise schon, und auch hier zumindest solange ich kein funktionierendes Dashboard habe... ;-( Ich habe in den letzten Tagen an einigen Ecken gebastelt, teils neue Versionen, neues Design z.B. auf uteles Blog, neue Plugins usw. Irgendwann merkte, ich dass der Kommentarfeed nicht mehr läuft. Nach längerem Suchen im Netz fand ich nur Lösungen, die nicht passten oder offene Anfragen. Heute habe ich dann mal unser Mitarbeiterblog genommen, da ist sonntags im geschützten Bereich außer mir niemand... ;-)
  • Erstmal habe ich alle Plugins deaktiviert, getestet, Feed geht.
  • Prima, das ist ja schon mal ein gutes  Zeichen. Dann nacheinander erstmal die Plugins in Zweier-Grüppchen wieder aktiviert, die ich eher nicht im Verdacht hatte.
  • Bis dahin alles ok, lief immernoch. Zum Testen musste ich zwischen dem Aktivieren natürlich immer einen Kommentar schreiben, ein weiterer Grund, das nicht hier zu machen... ;-)
  • Bei Plugins, die mit dem Problem zu tun haben könnten, weil sie an Kommentaren rumspielen, habe ich diese einzeln aktiviert.
  • Ups, und siehe da, da war der Übeltäter: Quote Comments Plugin
  • Hm, ich hatte extra nur ein Plugin installiert, bei dem 2.7 als ok gemeldet wurde...  Ich ging mal suchen, ob ich bei der Anleitung was übersehen hatte...
  • Nach kurzem Prüfen fiel mir auf, dass die lokale Version nicht diesselbe war, wie die Liveversion. Lokal war 1.1 oben die automatisch aktualisierte 1.2
    • Das mache ich übrigens immer so, wenn ich automatisch aktualisiere lasse ich lokal die alte Version stehen, von der ich weiß, dass sie funktionierte.
  • Ich überspielte die neue, mit der alten Version und siehe da, klappte in allen Blogs!
Ich habe es mal kommuniziert, z.B. hier: WP-Support comments feed selbstverständlich auch direkt beim Autor, damit dieser die Chance hat, das in der nächsten Version zu korrigieren.

Was lerne ich daraus?

Nun, einerseits, dass es sich lohnt wie gewohnt vorsichtig vorzugehen, jedoch auch dass mal nebenbei an mehreren Stellen basteln, leicht schief gehen kann. Warum "Mühsam ernährt sich das Eichhörnchen..."? Nun, das ist nur ein Teil der diversen kleinen Problemchen, die ich da grad noch habe, wie z.B. mit dem inhaltsleeren Dashboard... :cry:href="http://miradlo.net/bloggt/index.php?521-s"">Teil II Wordpress, Plugins und Updates Warum "Mühsam ernährt sich das Eichhörnchen..."? Nun, das ist nur ein Teil der diversen kleinen Problemchen, die ich da grad noch habe, wie z.B. mit dem inhaltsleeren Dashboard... :cry:href="http://miradlo.net/bloggt/index.php?621-s""> inhaltsleeren Dashboard... :cry:

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