[gelöst] jQuery lädt nur auf manchen Seiten: Problem mit MD Slider

Vielleicht ist in diesem Thread etwas brauchbares für Dich:
1. mal JQuery Version testen und u.U: Jquery_Update Version neu.
2. Fehlerlog vom Apache anschauen, evt. Memory Limit hoch setzen.
Mir ist noch nie aufgefallen, daß WYSIWYG probleme mit Memory Limit zu tun haben.
Aber in dem Fall, manche laufen, manche nicht, wäre es denkbar.
3. Welche Filter sind jeweils im Einsatz (Filtered HTML, Full HTML ?)

Tut mir leid, wenn diese Gegenfrage vielleicht dumm ist, aber wie meinst Du dass ich jQuery testen soll? Das jQuery-Update-Modul scheint auf jeden Fall aktuell zu sein.

Im Apache-Errorprotokoll habe ich leider nichts Sachdienliches gefunden.

Ich verwende überall Full HTML.

Sorry, testen war ja auch ein blöder Ausdruck von mir.
Einfach mal in der Konfiguration vom JQuery Update Modul nachschauen, welche Version eingestellt ist.

Dort steht es wäre Version: 7.x-2.4
Und die Default jQuery Version selbst: 1.10 (Eine neuere ist auch gar nicht auswählbar.)

Tja, dann liegt es daran wohl nicht und weitere Ideen fallen mir auch nicht ein.

Weil ich gerade sehe, daß noch Drupal 7.31 im Einsatz ist.
Ist die Version gepatcht?
Die Frage hat mit sehr großer Wahrscheinlichkeit nichts mit dem Editor-Problem zu tun, aber da war ja diese riesige Sicherheitslücke, die letzten Oktober die Drupal-Fans (mich eingeschlossen) etwas auf Trab gebracht hat:
http://www.drupalcenter.de/node/51927

Ja montviso, ein Core-Update sehe auch ich als den nächsten logischen Schritt an. Selbst wenn die Updates nicht direkt dieses Problem betreffen kann es sein, dass eine frische Installation eines aktuelleren Systems das Problem lösen könnte.

Natürlich könnte es mir aber auch misslingen alle Adaptionen in die neue Version zu retten, da ich die leider großteils nicht alle selbst gemacht habe und ich dem entsprechend Manches übersehen könnte. Und selbstverständlich gibt es keine Garantie, dass das das Problem löst. (Wow, ich glaube ich habe bisher noch nie einen Satz mit drei "das" nach einander geschrieben. ;)

Nein, es gibt in der Tat keine Garantie, dass das das Problem löst (hähä...jetzt kann ich's auch ;-) ).

Aber in einem Punkt mache ich Dir gerne die Hellseherin:
Wenn Du weiter mit der Version 7.31 arbeitest, hast Du gute Chancen auf ein paar weitere Probleme...und das meine ich bitter ernst.

Du kannst mit den Modulen hacked! und diff ( https://www.drupal.org/project/hacked, https://www.drupal.org/project/diff ) prüfen, ob an den Core - Dateien bzw. den Modulen Veränderungen gegenüber der ursprünglichen Version gemacht wurden.
Das umfasst sowohl absichtliche Veränderungen durch Entwickler (falls Du das mit Adaptionen meinst, was eine sehr höfliche Umschreibung für eine große Unsitte ist), als auch gehackte Versionen.
Einfach die beiden Module installieren und einen Report erzeugen, dann kommt eine Liste der Dateien, die gegenüber der original ausgelieferten Dateien eine Änderung haben.

Einen schnellen Überblick, ob die Seite gehackt wurde, bekommst Du, wenn Du in die Benutzer + Rollen schaust und da plötzlich eine Rolle ist, die vorher nicht da war oder ein neuer User mit admin-Rechten existiert.

Hier ist der Thread dazu, der vielleicht auch noch als Motivationsspritze dient, das Update anzugehen (und genau zu untersuchen, ob schon was passiert ist):
http://www.drupalcenter.de/node/51973
Ich habe anfangs auch unterschätzt, welche Auswirkungen das haben kann. Allerdings hatte ich Backups und konnte mit Diffs auf die Dateien und der Datenbank feststellen, daß nichts verändert war, obwohl ein neuer User mit der Rolle bereits angelegt war.

Bei mir sind allerdings keine unerwarteten Benutzer oder Rollen vorhanden. Ich bezog die Änderungen nur auf Anpassungen meines Vorgängers, die ich vermutlich nicht alle kenne. Und er neigt im Allgemeinen dazu schnelle, wenn auch manchmal schmutzige, Lösungen zu bevorzugen...

Ja, solche gewollten Änderungen kannst Du damit auch finden.
Ich verwende das z.B. wenn ich Kundenwebseiten übernehme und updaten soll und keiner weiß so genau, was die Vorgänger geändert haben, weil es keine Doku gibt.
Als im Normalfall. ;-)

Hallo montviso,

ich konnte das Update (unerwarteter Weise) auf Anhieb erfolgreich durchführen. Jetzt ist auch mein Core auf 7.34. Nur leider hat das das Problem nicht gelöst. Die Seite verhält sich immer noch exakt wie zuvor.

Hm, was könnte ich jetzt noch versuchen?

Hallo Du, immer wieder beliebt ist die Frage nach dem Memory. 128 Mb ist oftmals etwas knapp. Wieviel hast Du eingestellt? Vielleicht bringts eine Erhöhung des Memory-Limits.

Hallo leda.ch,

meinst Du das PHP-Speicherlimit im Apache, das auch über php_info() ausgegeben wird? Das erscheint mir jedenfalls nicht logisch weil beim Anlegen einer neuen Seite ja wesentlich weniger Inhalt geladen wird als wenn ich eine alte Seite zum Bearbeiten öffne, in der schon viel Text vorhanden ist. Das erklärt aucch nicht warum nur neuere Seiten betroffen sind. Es mag sein, dass wir es nicht sofort entdeckt haben, aber so wie's aussieht passiert das eben nur mit Seiten, die seit der Jahresumstellung erstellt wurden.

Ich werde das Limit bei der nächsten Gelegenheit aber wieder überprüfen - auch wenn ich glaube, dass da mein Vorgänger schon sehr großzügig war...

Check einfach mal das momory limit mit phpinfo().
Auf der Seite, die ich Dir oben genannt hatte, war das ja auch als eine mögliche Ursache genannt.
Und nicht immer lassen sich solche Dinge per Logik erklären.
Der Fehler als solcher hat ja auch keinerlei Logik...

Laut phpinfo steht das aktuelle Speicherlimit bei 500M. Dem entsprechend liegt es wohl eher nicht daran ...

Hast Du schon mal mit Firebug und JavaScript-Debugger durchgesteppt?
Einmal auf einer Seite, wo es funktioniert, einmal, wo es nicht funktioniert.
Ich gebe gerne zu, das macht keinen Spaß.
Aber wenn es meine Seite wäre, würde ich das so machen.
Klar, vorher hätte ich in der Konsole nach Fehlern gesucht, aber da gibt es ja keine - hast Du geschrieben.

Oder einfach mal das Verhalten mit Firebug-Netzwerk untersucht?
Welche Seiten werden im einen Fall geladen, im anderen nicht?

die würde ich mal auf 1.7 oder so stellen!

Die jQuery-Version hat keinerlei Einfluss. Ich werde dann mal sehen, was ich mit dem Firebug Javascript-Debugger herausfinden kann ...

Was mir übrigens auch schon geholfen hat, ist, in einem Editor den Browserquelltext einer funktionierenden Seite mit dem einer fehlerhaften Seite zu vergleichen. Mir hat schon ein fehlendes End-Tag in einem Block mit PHP-Inhalt die Seite zerschossen...

Heute ist mir eingefallen, dass ich bereits vor Monaten das Textformat "Filtered HTML" gelöscht habe um die Benutzer nicht durch zwei sehr ähnliche Textformate zu verwirren. Heute habe ich daher versucht zu prüfen ob beim Erstellen neuer Inhalte nicht vielleicht noch dieses Textformat vorausgewählt ist. Das wäre ein plausibler Hintergrund für das Problem, dass alle neu erstellten Seiten (dieses Inhaltstyps) die eigentlich nicht mehr vorhandene "Filtered HTML"-Option brauchen würden. Leider war das aber auch nicht das Problem.

Anscheinend geistert die Option "Filtered HTML" aber immer noch in der Drupal-Datenbank herum weil sie dort in verschiedenen Datensätzen in den Tabellen "filter" und "filter_format" noch vorkommt. Könnte sein, dass das Fehlen dieses Textformats die Probleme verursacht obwohl ich es meiner Kenntnis nach nirgendwo ausgewählt habe? Vielleicht waren damals bereits alle Seiten angelegt als ich dieses (aus meiner Sicht überflüssige) Textformat gelöscht habe und es ist mir nicht aufgefallen, dass deswegen der Editor beim Neuerstellen der Seite nicht mehr geladen werden kann.

Ist es einigermaßen leicht das gelöschte Textformat wieder zu ergänzen? Den Status in der Tabelle "filter_format" von "0" auf "1" zu ändern scheint jedenfalls nicht auszureichen. Es ist auch nicht möglich ein neues Textformat mit diesem Namen anzulegen weil ich dann die Rückmeldung bekomme, dass bereits ein Textformat mit diesem Namen existieren würde. (Das erscheint in Anbetracht der Einträge in den genannten Tabellen nicht erstaunlich, aber ich weiß nicht wo Drupal sonst Daten zu den Textformaten speichert ...)

Ob das den Fehler verursacht, weiß ich nicht.
Aber hier steht, wie man den Filter wieder herstellt:
http://drupal.stackexchange.com/questions/96805/how-to-get-back-the-text...
Wenn ich den Beitrag richtig verstehe und Deine Beschreibung oben, warst Du schon auf dem richtigen Weg, einfach mal Cache löschen.
Wenn Du nicht willst, daß ein bestimmter User beide Formate sieht, dann mußt Du einfach unterschiedliche Rollen definieren.
Die eine darf Full, die ander nur Filter.

Hui, das ist dumm: Es hat auf Anhieb funktioniert das Textformat zu reaktivieren - allerdings erst nachdem ich nicht mehr in der falschen Datenbak gearbeitet habe. (Leider haben wir da anscheinend einen etwas verwirrenden Wildwuchs.)

Jetzt habe ich zwar das Textformat wieder, aber auch das ändert nichts am problematischen Verhalten beim neuen Erstellen von Ihnalten dieses Typs.

Auch ein Valdidator hat mir keine relevanten Fehler zu dem Problem ausgespuckt als ich ihn auf die Seite los ließ. Lediglich divs in einem span und ein böses "multible"-Attribut in einem Input-Tag lassen den Validator meckern. Das sind aber sowieso alles Dinge, die nichts mit den Besonderheiten meiner Seite zu tun haben, sondern die allgemein von Drupal generiert werden und auf jeder Seite gleich sind.

Leider blicke ich auch mit Firebug nicht durch, da dort zwar brav alle Ressourcen gelistet werden, aber ich kann nicht unzählige Scripte durchackern, bloß auf den Verdacht hin, dass in ihnen geheimnisvolle Fehler lauern, die sich nur unter ganz bestimmten Bedingungen auswirken.

Tja sowas passiert halt, wenn man auf ein Problem fokusiert ist. Das Gesetz vom Wald und den vielen Bäumen. ;-)

Ich glaube, wenn der Debugger nichts her gibt, würde ich mal versuchen, den Inhaltstyp 1:1 nachbauen und schauen, ab wann der Fehler auftaucht.

Wenn Du sagst, der Typ heißt "Veranstaltung", dann gehe ich mal davon aus, daß Date, Datepicker, Calender ect. auch mit drauf sind.
Vielleicht hier irgendein Konflikt?
Nicht, daß das zur Logik mit den alten Beiträge klappt, die funktionieren...aber...man muß ja an alles mal gedacht haben.

Jetzt haben wir den Fehler gefunden:

Wir verwenden auf der Seite unter anderem den MD-Slider. Damit wir einzelnen Inhalten spezifische Slider zuordnen können, setzen wir als Steuerelement das "MD Slider widget" ein. Das verursacht offenbar einen bisher unauffindbaren Fehler, der nur auftritt wenn darüber eine Sliderauswahl geladen wird. So lange also kein Slider vorausgewählt ist, entsteht auch kein Problem und alle danach folgenden Erweiterungen, die jQuery brauchen, können korrekt geladen werden.

Sobald aber das Formular mit einer Slider-Vorauswahl geöffnet wird, klappt der Rest nicht mehr. Im Quellcode kann ich leider den verursachenden Fehler immer noch nicht finden, aber das Verhalten ist reproduzierbar.

Ich vermute wir müssen die Zuordnung des Sliders irgendwie anders lösen, damit das Formular wieder zuverlässig bedienbar wird.

Vielen Dank für Eure geduldigen Tipps.

Spannender als jeder Krimi. ;-)

Ja, wirklich spannend. Aber echt mühsam, sowas auf die Schliche zu kommen...