[gelöst] Quelltext eines Nodes ist plötzlich verhauen

wie die Quelle nun wirklich aussieht.
Vielleicht hat sich auch die Schnittstelle verändert?

Vielleicht kann man auch in der CSV irgendetwas erkennen?

Der Output spricht wirklich für ein leeres JSON-Objekt.

Es werden via JSON Daten abgefragt und in eine CSV-Datei geschrieben.
Dazu kommt das Json-Client Modul von Drupal zum Einsatz.
Diese CSV-Datei wird via Feeds importiert.
Also dürfte den Node doch gar nicht interessieren, daß mal JSON eine Rolle gespielt hat.

Ich habe nun neue Erkenntnisse:
- Die Problematik tritt auch lokal auf der Windows-Test-Umgebung auf
- Die Problematik betrifft eine Reihe von Nodes, die an einem bestimmten Tag erstellt wurden. Das war bereits im Februar und ist nie aufgefallen.
Spätere Datensätze wurden wieder korrekt erstellt.
Es werden nur einzelne der Datensätze zusätzlich händisch verpflegt und dann auf der Oberfläche ausgegeben.
Und nur in dem Fall fällt die Problematik auf. In den anderen Fällen befüllen die Felder (Ortsnamen) nur ein Autocomplete-Feld eines Formulars und das funktioniert.

Ich habe jetzt zwei Node-ID's ermittelt, eine davon funzt, eine nicht.
Für beide vergleiche ich jetzt alle Einträge in allen Tabellen der Datenbank.
Evt. kann man da ja einen Unterschied erkennen und daraus Rückschlüsse ziehen.

Es bleibt nichts übrig, als die Fehlerhaften Nodes händisch ermitteln, im Backend löschen und neu anlegen lassen. Solange sie noch nicht qualitifiziert verpflegt wurden, ist das unkritisch.
Aber natürlich wüßte ich zu gerne die Ursache, weil oft mag ich das nicht machen...;-)

Wie sehen die Daten der Quelle aus?
Was macht die Umwandlung in CSV daraus?
Wie wird dies dann importiert?

Irgendwo auf dieser Strecke gibt es den "Unfall".

Frage: warum diese Umwege?
Wäre es nicht sinnvoll, die Nodes mit einem eigenen Modul direkt aus den JSON-Daten zu generieren?

Bei der Quelle handelt sich um UTF-8 Daten und die CSV-Datei wird auch in UTF-8 erstellt.

Was meinst Du mit Umweg?
Zuerst in ein CSV schreiben?

Nun ja, das wurde deshalb so gewählt, weil hintereinander aus dem gleichen CSV verschiedene Node-Typen befüllt werden, die zum Teil auch noch in einer Referenz zueinander stehen.

Das Modul für den Cron bringt die ganzen Vorgänge vom JSON-Schnittstellen-Zugriff über CSV-Erzeugen bis zum Import via feeds zusammen.
Der Feedsimport deshalb, weil die Möglichkeit offen bleiben sollte, daß die Nodes auch noch aus anderen Quellen befüllt werden.
War aber bislang nicht der Fall.

Sicher hätte es auch andere Wege gegeben, die Aufgabe zu lösen...

Da nur ein paar Nodes betroffen sind, vermute ich, daß das der Fehler ganz am Anfang passiert ist, als ich noch diverse Methoden des automatischen Imports via Elysia ect. getestet habe.
Einmal angelegte Nodes werden danach bei jedem Import upgedated aber offensichtlich dadurch nicht repariert.

Die Frage aller Fragen bleibt für mich:
Weshalb glaubt der Node, eine JSON-Datei zu sein?
So ist die Info dazu gespeichert?
In der Datenbank kann ich keinerlei Unterschiede im Aufbau eines funktionierenden bzw. eines nicht funktionierenden Datensatzes erkennen.

dass das erste Zeichen eine { oder [ ist?

Ich weiß nicht, wie intelligent die Dateitypenerkennung ist.

Hi,

also wenn Du das ganzu oben von der Schnittstelle zurück bekommst vermute ich folgendes:
Das da oben ist HTML aber der Antwort Header des Servers sagt wohl,
es ist eine JSON Datei (Content-Type: application/json)

Da es nur einigte Nodes betrifft:
Kann es sein, dass wenn der Body Content eines Nodes leer ist, dein Modul HTML statt JSON zurückliefert?

MfG

Robert

der Quelltext oben erscheint, wenn ich den Node aufrufe.
Im Browser wird dann einfach [] angezeigt.

Noch mal zur Erinnerung:
Der Node entsteht durch einen Import via Feeds aus einer CSV-Datei, die via Aufruf einer JSON-Schnittstelle erzeugt wurde.
Das ganze in einem Modul, das im Background als Cron-Job ausgeführt wird.

Mit dem Body-Content hat es nichts zu tun.
Ist egal, ob der leer ist oder voll...bei den allermeisten Einträgen ist er leer.

Und stimmmt...der Header-Response ist Content-Type: application/json.
Warum auch immer.

Hallo,

das ist ja was ich meinte:

Die Response selbst, die Du oben gepostet hast ist aber HTML und kein JSON (Sonst hättest Du keine HTML Tags)!!!
Sprich Du bekommst kein JSON sondern HTML für diesen Request zurück.

MfG

Robert

Ich schätze, das HTML ist das, was Firefox draus macht.
Hier das Ergebnis aus FireBug:

und das Gleiche bei dem funktionierenden Datensatz:

Hallo,

also dann ist es genau umgekehrt:
die erste Response (die nicht funktioniert) sagt der Content Typ wäre application/json
in Fakt gibt er aber HTML zurück:

Dein Modul gibt also bei bestimmten Nodes JSON statt HTML zurück.
Ich schätze da musst Du nachsehen.

MfG

Robert

Nur wo nachschauen?
Die Ausgabe erfolgt ja ganz normal über node-Ansicht aus Drupal via node/1234.
Das ist kein Modul.
Und der Node in der Datenbank enthält keinen anderen Code, als der funktonierende Code.

Deswegen habe ich so gar keinen Ansatzpunkt, wo nach schauen.

Hallo nochmal,

sind die beiden Nodes vom gleichen Content Typ?
Jedenfalls gibt der Fehlerhafte Node einen fehlerhafen Response zurück.

Evtl. wegen diesem Modul?
Hast Du auch mal in den Tabellen node und field_data_body nachgeshen ob es da Unterschiede
zwischen den beiden nodes gibt?

LG

Beide sind vom gleichen Typ.

Hier kannst Du selbst schauen:

In field_data_body sind für die beiden Nodes noch keine Einträge mangels Inhalt.

Hmm,

irgendein Modul muss da dazwischen funken.
Durchsuch (Textsuche) mal Deinen Custom Modul Ordner (site/all/modules) nach application/json
oder drupal_json_output.
Da muss ein Modul den Drupal Header umschreiben.

MfG

Wow...Volltreffer.
Ein Block in dem mit Aufruf des Formulars mit dem Autocomplete-Feld wird in der rechten Sidebar included.
Wenn ich den raus nehme, wird der Node richtig angezeigt.

Die Funktion, die diesen Autocomplete als Optionfeld für die Selectbox erstellt, sieht ungefähr so aus:

Durch Einbinden dieses JSON-Schnittstellenaufrufs wird offensichtlich der Header manipuliert.

Ich war derart auf den Node fixiert, daß ich über die Anwesenheit des Blocks auf der rechten Seite nicht mehr nachgedacht habe.
Dann kann ich natürlich in der Datenbank nichts finden.

OK, dann muß ich untersuchen, warum an der Stelle der Aufruf des json-client-Moduls bei manchen Nodes den Header verändert und bei anderen Nodes nicht...
Ich denke, da könnt Ihr ohne näheres Wissen über Details des Gesamt-Gebildes nicht mehr helfen...

Es war mir so schon auf jeden Fall schon eine große Erleichterung, daß Ihr mir geholfen habt, das Problem einzugrenzen.
Danke für Eure Zeit!

(matches) als array, bzw. baust dieses, lieferst es aber als JSON zurück.

Gibt es keine matches, gibt es auch keinen JSON.

Liefert das System vorher schon einen HTML-Header, wird der JSON-Header unterschlagen/unterdrückt.

Vielleicht hilft das?

Hmmm...habe ich auch schon überlegt.
Haut aber nicht hin. Es gibt definitv korrekte Ausgaben mit match aus der JSON-Schnittstelle.

Da hilft nur eines:
Mit NuSphere an die Stelle debuggen und gucken, was beim einen Node passiert und was beim anderen.
Das ist zwar mühsame, aber nichts anderes wird helfen.

Zum Glück ist das Problem für den produktiv-Betrieb nicht wirklich kritisch, deshalb gibt's keinen Stress.

Hi,

freut mich dass du auf dem richtigen Weg bist.
Ich glaube zwar nicht dass Dein Problem drain liegt,
aber in dem obigen Code finde ich einiges merkwürdig:

1. value ist keine gültige PHP Variable
2. value ist in dieser Funktion abholort_rueckgabe_autocomplete auch nirgends definiert
3. $matches[wert] wo wert auch keine gültige PHP Variable ist? (kein $)

Sollte das nicht

heissen?
JSON wird in dieser Funktion immer ausgegeben, allerdings enthält $matches bei den
fehlerhaften Nodes kein JSON sondern HTML das wird Dein Problem sein.

Viel Glück ;-)

PS:
Mach mal ein

in Deiner Funkion ;-)

Ach sorry, daß ich das nicht deutlicher geschrieben habe.

war nur der Platzhalter für eine halbe Seite Code, die gewisse Manipulationen und sogar noch Datenbankabfragen macht, die aber alle nichts mehr mit der Problematik zu tun haben.

So wie es da steht, würde es wohl noch ein paar mehr Fehler auswerfen - und zwar immer. ;-)

Hallo,

ja hatte ich mir fast gedacht ;-)
Der application/json Header wird durch drupal_json_output automatisch gesetzt.
Wie es aussieht wird die autocomplete Funktion nur bei den fehlerhaften Nodes
ausgeführt, welche dann JSON statt HTML zurückliefert.

Gruss

Ne, so einfach ist es nicht.
Der gleiche Block mit der gleichen Autocomplete-Funktion (die wunderbar funzt) wird an mehreren Stellen eingebunden.
Den Ärger gibt es nur an wenigen Nodes von einem bstimmten Typ.

Ich schaue mir mal die Details im Debugger an und berichte dann.

dass das Sucharray als JSON zurückgeliefert wird?

Was passiert, wenn einfach das Array zurückgegeben wird?

Wer ruft

auf?

Was macht diese aufrufende Prozedur mit dem Ergebnis?

Das konnte ich wirklich nur durch genaues Beobachten mit Breakpoints im Debugger lösen:
Durch einen Sonderfall, den es eigentlich gar nicht geben darf (manche Orte werden von der Schnittstelle mit zwei unterschiedlichen ID's geliefert), ist die Funktion bei manchen Nodes nicht beim vorgesehende return ausgestiegen, sondern weiter bis zum drupal_json_output-Aufruf gekommen, welcher den Header verhauen hat.
Dann reiche ich das Problem mal weiter. ;-)
Bzw. habe durch eine einfache Änderung aufgefangen, daß es trotzdem in den return geht.