undefined access to undefined

Ich steh ja so wirklich und ganz und gar auf vielsagende Fehlermeldungen. Echt jetzt. Wer möchte nicht, dass man sofort weiß, was das Problem ist.

undefined access http://www.yellowstoneaussies.de/infos/undefined

Fehlersuche

Tja. Wo fängt man an, wenn man so einen Sondermüll in seinen Serverlogs findet?

Am Besten mal dort, wo es immer so ein bisschen stinkt. Im Javascript-Bereich. Und siehe…

Netzwerkanalyse ist dein Freund

Da fällt uns sofort etwas ins Auge, was uns eine Spur zu scheinen ist:

the undefined
the undefined

Wer zum Geier sucht denn da was unter undefined? Und wieso?

Gucken wir mal, wie die Parameter dieser Anfrage aussehen – ist ja bestimmt wieder ein Ajax-Request…

really undefined
really undefined

Öhö. Ok, Verdacht auf das Übliche zu schieben, war wohl zu Unrecht.

Dann schauen wir uns die Kopfzeilen doch noch mal genauer an…

dgd
dgd

Was ist denn „dgd_scrollbox„?

Scrollen wir doch mal einen halben Kilometer in der Netzwerkanalyse nach oben und schauen uns jedes Javascript an, was das Netzwerk passiert hat (Javascript hat man grundsätzlich immer erst mal im Verdacht bei sowas).

And in the tate – there it is

dgdgdg can't you see
dgdgdg can’t you see

Da ist was mit DGD! Ha.

Suchen wir doch einfach mal nach Ajax… und wir werden fündig in einem noch völlig unklaren Zusammenhang – aber kurz nach Ablaufen des Scripts schlagen haufenweise Antworten aus dem Backend ein, die Bilder für ein Grid-Layout darstellen.

Geistesblitz

Analyse wird hier dann abgebrochen, weil wir einen Verdacht haben. Könnte es vielleicht sein, dass da ein Bild nicht gefunden wird?

Jaaaaa jetzt fragt man sich, woher diese Eingebung gekommen ist. Keine Ahnung. Kam einfach. Kennt ihr doch sicher, irgendwie „ahnt“ man was.

Und – wenn ich die Augen vorher für die Realität geöffnet hätte, wäre mir das wohl schon vorher aufgefallen – was sehen meine mittlerweile genervten und müden Augen:

white planes
white planes

Das weiße Loch da mittendrin gehört doch da nicht hin… oder… habe ich einfach kein Sinn für Ästhetik?

Falls sich jemand über das „oh oh da stimmt was mit SSL nicht“-Symbol in der Adressleiste wundert: So sieht das aus, wenn eine Seite das erste Mal nach dem Cachelöschen angezeigt wird. Ihr solltet die Seiten so niemals sehen.

Hintergrund ist, dass wir die Seiten beim erstmaligen Abruf sofort Netto anzeigen ohne die durch die Parserorgie diverser Funktionen zu jagen. Mein nächtlicher Precacher (Stichwort „Wartungsscript“) kümmert sich darum üblicherweise, wenn ich nicht grad untertägig eine Seite aus dem Cache ballern muss/möchte.

Realitätsabgleich

Looken wir doch mal im Backend nach.

Und was fällt uns da mit der Tür ins Haus?

beitragsbild not found
beitragsbild not found

Und da wir von vorherigen Recherchen wissen, dass ein Postgrid mit Bildanzeige irgendwoher sein Bild beziehen möchte, sind wir uns sicher, dass das das Corpus Delicti ist. Also setzen wir das doch mal.

suffkopp
suffkopp

Dann testen wir noch mal die Seite…

suffkopp in da info
suffkopp in da info

Und im Log… nada 🙂

Naja. Doch mehr als „nada“ – aber „undefined“ ist weg.

Fazit

Manchmal muss man sich echt einen Knoten denken und die Spurensuche aufgeben und sich einfach auf das Gefühl verlassen – dann findet man die Lösung schon.

Deshalb ist es so wichtig, dass wir stundenlang am Rechner hocken und uns die Nächte um die Ohren hauen, ohne, dass man „was sieht“ (wie meine Frau so schön sagt zum Thema nutzloses Herumgammeln).

Da habt ihr noch ein Argument, wieso das, was wir tun, gut & richtig ist.

Gern geschehen 🙂

 

Ajax Backendanfragen cachen – unmöglich…?

Auf unserer Webseite benutzen wir viele Elemente, die dynamisch mit Content aus dem Backend versorgt werden.

Beispielsweise die Liste unserer Informationsartikel:

ya info
ya info

Die Elemente dieser Liste werden per Ajax aus dem Backend gelutscht – einzeln.

Requests ohne Ende

Also hustet so eine „Grid“-Übersicht mal eben ein paar Dutzend Backendanfragen in Richtung Webserver – und dann passiert das hier:

  • Webserver findet, dass admin-ajax.php eine PHP-Script ist und fährt erst mal eine Instanz des PHP-Interpreters hoch
  • Das Script wiederum möchte gerne das WordPress-Imperium im Zugriff haben, also wird die Maschinerie in Gang gesetzt und das WordPress-Backend macht sich breit (ein paar hundert PHP-Scripte werden geladen und Dutzende Datenbankabfragen losgeschickt – bevor irgendetwas tatsächlich passiert).
  • Dann verarbeitet admin-ajax.php netterweise auch mal den Ajax-Request bzw. leitet den an die zuständige Stelle weiter.
  • Diese fragt dann ihrerseits diverse Tabellen ab – über WordPressroutinen üblicherweise. Also wp_query und Konsorten, die allesamt nicht gerade den Ruf genießen hochperformant optimierten SQL anzuwenden – kann jeder bewundern, wenn er sein MySQL-Slowlog anschmeißt und sich dann mal per explain die dicksten Statements erklären lässt…
  • Wenn dann alle Beteiligten glauben, dass der Content so weit generiert ist, beendet sich das PHP-Konglomerat und stellt eine Antwort für den Ajax-Request bereit.
  • Der wiederum wird dann vom rufenden Javascript in die Seite gelötet.

Das stellen wir uns jetzt mal ein paar Dutzend vor und wir wissen, wie schön es ist, ein sich langsam inkarnierendes Postgrid zu bewundern – Ladezeiten im mehrstelligen Sekundenbereich sind die Folge.

Da möchte man doch mal – Cache?

Klassischer Anwendungsfall eines Caches ist, dass Daten, die sowieso gleich sind, nicht aus der langsamst möglichen Ecke geholt werden sondern von dort, wo es sonnig und warm ist; idealerweise aus dem Arbeitsspeicher, wenn es nicht anders geht, so zumindest aus der Tiefkühltruhe und nur noch schnell in die Micowelle (also servierfertig und nur dezent zu bearbeiten).

Angeblich geht das mit WordPress-Ajax nicht.

Selten so gekichert… natürlich geht das. Man muss nur die schulterlangen Gummihandschuhe anziehen, Nasenklammern drauf und dann in der Suppe wühlen, bis man die richtigen Stellen gefunden hat, an denen man was anflanschen muss.

Jetzt passiert das hier:

  • Ajax-Request schlägt im Backend auf.
  • admin-ajax.php wird immer noch durch eine neue PHP-Interpretinstanz interpre… ausgeführt.
  • ohne WordPress hochzufahren wird erkannt, dass die gewünschte Action mit dem passenden Schlüsselzeugs schon in der „Datenbank“ herumlungert und die Antwort umgehend an den Anfrager zurückgeworfen.

Dabei heißt „Datenbank“ hier ein Key im Redis-Inmemory-Store.

redis cache
redis cache

Aber einmal muss ich durch den Cache…

Die allererste Anfrage muss natürlich durch den gesamten Dschungel, sonst weiß der Redis ja nicht, wie die Abkürzung aussieht.

Das muss aber nicht zwingend mit dem ersten Besucher passieren, der sich auf die Webseite traut.

node.js precache
node.js precache

Das kann ein nächtliches Script machen, was bei der routinemäßigen Wartung mitläuft und die relevanten Ajax-Requests simuliert, die tagsüber so auf das Backend einschlagen. Dieses Script wiederum nutzt node.js und jsdom und diverse andere ähm „Hilfsmittel“ – darüber schreibe ich ein anderes Mal, mir ist schon schlecht 😉