[gelöst] Quelltext eines Nodes ist plötzlich verhauen
Eingetragen von montviso (2188)am 16.07.2014 - 07:59 Uhr in
Über einen automatischen Cronjob werden Datensätze von einer Schnittstelle geholt, in eine CSV-Datei geschrieben und per Feeds in einen Drupal Inhaltstyp importiert.
Bei einigen Nodes wird der Inhalt nicht mehr korrekt angegeben, sondern der Quelltext im FireFox enthält folgendes:
<html>
<head>
<link title="Lange Zeilen umbrechen" href="resource://gre-resources/plaintext.css" type="text/css" rel="alternate stylesheet">
</head>
<body>
<pre> []</pre>
</body>
</html>Beim Recherchieren nach diesen Worten habe ich Hinweise gefunden, daß ein MIME-Typ -Problem vorliegt.
Also eher ein Problem der Webserver-Konfiguration.
Das trifft sich auch mit dem, daß der Internet Explorer behauptet, die Seite sei eine JSON-Datei - statt HTML.
Es betrifft - wie geschrieben - nur einige der 5000 Datensätze.
Ob es die seit einem bestimmten Zeitpunkt neu angelegten sind, konnte ich noch nicht genau feststellen.
Bevor ich den Betreuer des Webservers frage, ob etwas verändert wurde, würde mich interessieren, ob schon mal jemand diesen Effekt in Drupal hatte?
- Anmelden oder Registrieren um Kommentare zu schreiben
da wäre interessant,
am 16.07.2014 - 08:12 Uhr
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
am 16.07.2014 - 08:36 Uhr
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...;-)
Versuche mal die gesamte Prozesskette zu überprüfen
am 16.07.2014 - 08:50 Uhr
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
am 16.07.2014 - 09:17 Uhr
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.
kann es sein
am 16.07.2014 - 09:50 Uhr
dass das erste Zeichen eine { oder [ ist?
Ich weiß nicht, wie intelligent die Dateitypenerkennung ist.
Hi, also wenn Du das ganzu
am 16.07.2014 - 09:59 Uhr
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,
am 16.07.2014 - 10:26 Uhr
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
am 16.07.2014 - 10:42 Uhr
Hallo,
das ist ja was ich meinte:
Header-Response ist Content-Type: application/json
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
am 16.07.2014 - 11:05 Uhr
Ich schätze, das HTML ist das, was Firefox draus macht.
Hier das Ergebnis aus FireBug:
Cache-Control no-cache, must-revalidate, post-check=0, pre-check=0Connection Keep-Alive
Content-Language de
Content-Length 3
Content-Type application/json
Date Wed, 16 Jul 2014 09:30:24 GMT
Etag "1405503024"
Expires Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive timeout=5, max=100
Last-Modified Wed, 16 Jul 2014 09:30:24 +0000
Server Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
X-Drupal-Cache MISS
X-Powered-By PHP/5.3.8
und das Gleiche bei dem funktionierenden Datensatz:
Cache-Control public, max-age=86400Connection Keep-Alive
Content-Encoding gzip
Content-Language de
Content-Length 6818
Content-Type text/html; charset=utf-8
Date Wed, 16 Jul 2014 09:44:44 GMT
Etag "1405500028-1"
Expires Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive timeout=5, max=100
Last-Modified Wed, 16 Jul 2014 08:40:28 +0000
Link <http://unser-server/node/8531>; rel="shortlink",<http://unser-server/reiseziel/alverca>; rel="canonical"
Server Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
Vary Cookie,Accept-Encoding
X-Drupal-Cache HIT
X-Generator Drupal 7 (http://drupal.org)
X-Powered-By PHP/5.3.8
Hallo,also dann ist es genau
am 16.07.2014 - 11:24 Uhr
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:
<html><head>
<link title="Lange Zeilen umbrechen" href="resource://gre-resources/plaintext.css" type="text/css" rel="alternate stylesheet">
</head>
<body>
<pre> []</pre>
</body>
</html>
Das ist kein JSON!
Die zweite Response (die funktioniert) sagt:
Content-Type text/html; charset=utf-8
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
am 16.07.2014 - 13:46 Uhr
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
am 16.07.2014 - 13:57 Uhr
Hallo nochmal,
sind die beiden Nodes vom gleichen Content Typ?
Jedenfalls gibt der Fehlerhafte Node einen fehlerhafen Response zurück.
Dazu kommt das Json-Client Modul von Drupal zum Einsatz.
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
am 16.07.2014 - 14:14 Uhr
Beide sind vom gleichen Typ.
Hier kannst Du selbst schauen:
INSERT INTO `node` (`nid`,`vid`,`type`,`language`,`title`,`uid`,`status`,`created`,`changed`,`comment`,`promote`,`sticky`,`tnid`,`translate`,`uuid`) VALUES ('8531','8531','reiseziele','und','Brook Park','0','1','1393578898','1394534242','1','1','0','0','0','86149501-ea8c-4519-89cf-c63b60fc3d51');INSERT INTO `node` (`nid`,`vid`,`type`,`language`,`title`,`uid`,`status`,`created`,`changed`,`comment`,`promote`,`sticky`,`tnid`,`translate`,`uuid`) VALUES ('8532','8532','reiseziele','und','Brownsville','0','1','1393578898','1401066103','1','1','0','0','0','78dfe74b-5d84-416a-b8bd-c7ea4d725228');
In field_data_body sind für die beiden Nodes noch keine Einträge mangels Inhalt.
Hmm, irgendein Modul muss da
am 16.07.2014 - 14:38 Uhr
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
am 16.07.2014 - 15:50 Uhr
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:
<?php
function abholort_rueckgabe_autocomplete($string) {
$matches = array();
$schnittstelle = new JsonSchnittstelle();
$resultSearchSuggestion = $schnittstelle->getSearchSuggestionList($string);
foreach($resultSearchSuggestion['result'] as $key => $val)
{
//Baue Optionen
$matches[wert] = value;
}
drupal_json_output($matches);
exit();
}
?>
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!
du bekommst die Treffer
am 16.07.2014 - 16:19 Uhr
(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
am 16.07.2014 - 16:37 Uhr
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
am 16.07.2014 - 21:56 Uhr
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:
//Baue Optionen
$matches[wert] = value;
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
$matches[$wert] = $val
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
dpm($matches[$wert]);
in Deiner Funkion ;-)
Ach sorry, daß ich das nicht
am 17.07.2014 - 05:37 Uhr
Ach sorry, daß ich das nicht deutlicher geschrieben habe.
//Baue Optionen
$matches[wert] = value;
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
am 17.07.2014 - 09:27 Uhr
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
Zitat: Wie es aussieht wird
am 17.07.2014 - 09:43 Uhr
Wie es aussieht wird die autocomplete Funktion nur bei den fehlerhaften Nodes
ausgeführt, welche dann JSON statt HTML zurückliefert.
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.
ist es Absicht,
am 17.07.2014 - 09:58 Uhr
dass das Sucharray als JSON zurückgeliefert wird?
Was passiert, wenn einfach das Array zurückgegeben wird?
Wer ruft
abholort_rueckgabe_autocomplete($string)
auf?
Was macht diese aufrufende Prozedur mit dem Ergebnis?
Das konnte ich wirklich nur
am 17.07.2014 - 19:29 Uhr
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.