Drupal 8, Flexslider: Nach Core Update scheint kein JavaScript mehr zu laden

Ich habe Flexslider auch schon ne Weile in D8 im Einsatz und keine Probleme.
Welche Version Drupal und Flexslider hast Du?
Die Neueste Version ist stabel.
Ab 8.9 braucht man keine Library mehr, lese ich hier gerade:
https://git.drupalcode.org/project/flexslider/-/blob/8.x-2.x/README.md

Welche Drupal Version hast Du?
Wie wurde das Update gemacht? Mit Composer oder händisch?
Die Struktur sites/all/libraries ist ja eher noch von D7. Bei mir liegt der Library-Ordner inzwischen parallel zu sites, modules, themes ect.

Vielen Dank, Regina, für Deine Nachricht! :)

Aaaalso, ich hab händisch auf Drupal 8.9.3 aktualisiert, den FlexSlider auf 8.x-2.0. Das Libraries API Modul in Version 8.x-3.0-alpha1

Bei der Flexslider Installation vor ca. 6 Wochen bin ich nach der FlexSlider Readme vorgegangen. Da wurde sites/all/libraries als eine Möglichkeit angeführt, wo das flexslider Verzeichnis hingepackt werden kann.

Hat auch bislang wunderbar funktioniert.

Versteh ich richtig, dass Dein libraries/flexslider Verzeichnis direkt im Hauptverzeichnis liegt?

Ahhh, hab mein Libraries Verzeichnis jetzt auch ins Hauptverzeichnis verschoben und... siehe da: Mein Slider geht wieder!!! :))))

Du bist wirklich mein rettender Engel - das hat mich diese Woche wirklich einige Stunden rumprobieren gekostet und wusste wirklich nimmer, was ich noch machen soll! :D

LG und ganz, ganz herzlichen Dank :)
Hans

Oh das freut mich. ;-)
Auf Dauer gesehen würde ich auf einer Composer Struktur umstellen.
Ich weiß gar nicht, wie das bei der Migration zu D9 läuft, ob da händisches Update überhaupt noch funktioniert.
Also bei mir liegt der libraries unter web/libraries, was die Root ist. Der Domainnamen switched hier her.

Wenn Du die readme.md im Ordner von flexslider 8.2.0 ansiehst, dann steht da, dass libraries (auf oberer Ebene) die Standard Location ist.
Warum da der Hinweis auf sites/all/libraries ist, was ja eigentlch aus D7 Zeiten stammt, weiß ich nicht.

Ich weiß - der Thema Composer-Umstieg liegt mir schon ne Weile schwer im Magen.

Ich hab seit einigen Jahren kaum noch was in PHP gemacht und hab etwas Respekt vor dem Umstieg, weil ich noch nicht viele Anleitungen gefunden hab, wie dann der komplette Workflow bis zum Deployment aussieht.

Dürfte ich Dich mal fragen, wie da Dein Workflow aussieht? Läuft Composer auf dem Webserver auch? Oder machst Du lokal die Updates, etc., und schiebst dann alles auf den Server? Wenn ja, dann womit? GIT oder ftp?

Ich möchte das gerne jetzt endlich mal vernünftig strukturieren und würde mich wirklich freuen, wenn Du mir kurz sagen würdest, wie Du bei Dir das Deployment eingerichtet hast.

Ich bin bei meiner Suche nach brauchbaren Anleitungen zu diesem Thema bislang noch nicht fündig geworden.

Zu dem Thema habe ich gerade einen Blog geschrieben:
https://www.montviso.de/blog/drupal-update-von-8613-zu-893-unter-compose...

Inzwischen komme ich mit meinem Workflow gut zurecht.
Ich habe Drupal-Kunden u.a. bei 1&1 (Ionos) und bei All-Inkl wo ich selbst von HostEurope mit unseren Projekten hin gegangen bin, weil Composer eine Weile gut funktioniert ist.
Leider ist das jetzt auch nicht mehr der Fall.

Man braucht für bestimmte Vorgänge mit Composer (Require) bis zu 2GB Memory. Bekanntlich gibts beim Hoster, auch auf der Konsole, selten mehr, als 512 MB.

Ich habe nun bei mir lokal auf Windows 7 Composer zufriedenstellend am Laufen (in der php.ini 2Gb memory_limit eingestellt).

Alternative wäre DrupalVM, Docker ect. was u.a. hier diskutiert wird, falls Du ein Facebook-Konto hast:
https://www.facebook.com/groups/drupal.8/?post_id=1504346279744597

D.h. Kunden-Installation wird bei mir runter geladen per FTP, mit Composer auf neuen Stand gebracht, hoch geladen.
Aufwand ist hoch, aber Drupal ist nun mal inzwischen eine Enterprise-Lösung und das kommuniziere ich auch so.

Alternativ kann man, wenn man zwei Strukturgleiche Drupal Installationen (was Module angeht) hat, lokal den Require durchführen, die so veränderten Dateien composer.json und composer.lock auf den Server schieben und dort auf der Konsole composer install durchführen. Install benötigt weniger Memory, als der require Befehl, der die Abhängigkeiten zusammen sucht.
Sicherer ist die Methode, die ganze Installation lokal upzudaten und dann wieder hoch schieben.
Aber wenn ich nur ein Modul unter Composer-Kontrolle installieren will, dann geht es mit dieser Methode.

Quintessenz, die ich auch in meinem Blog-ARtikel zum Ausdruck bringen möchte:
Je konsequenter man sich auf Composer-Installation / Update einlässt, desto problemloser ist es.
Und ich denke, in Hinblick auf D9 ist das unumgänglich.

Die gute Nachricht: Es soll bald eine neue Composer-Version geben, die viel weniger Memory-Ansprüche hat.
Das habe ich auch auf Facebook aufgeschnappt. Wird sich zeigen.
Dann könnte man beim Hoster eine Testumgebung parallel halten und könnte die Updates schneller machen und Live stellen.

Das ist wirklich sehr interessant, Regina!

Ich bin mit dem Drupal 8 Projekt, an dem ich grad werkle, noch bei HostEurope, hätte aber gern vor dem Livegang eine stabile dauerhafte Lösung.

Aus diesem Grund bin ich grad schwer am überlegen, ob man nicht über so etwas wie Pantheon.io nachdenken sollte. Der Workflow dort kommt mir schon sehr durchdacht und extrem produktiv vor. Hätte es vor einer Woche nicht Probleme bei der Migration gegeben, wäre mein Umzug wohl schon vonstatten gegangen. Meine Testmigration vor ein paar Wochen ging ohne Probleme, nach dem Drupal Update ist das etwas hakeliger.

Lokal hab ich mir diese Woche auf meinem Win10 Laptop WSL 2 mit Debian eingerichtet. Läuft jetzt gut, aber das ist ja nur ein Teil des ganzen Prozesses. Die Hostingfrage und den Deployment Prozess hab ich aber leider noch nicht geklärt.

Sowas wie Pantheon.io ist bei mir keine Lösung, weil ich ja auch immer wieder Kunden-Webseite bei Hoster XY übernehme.
Könnte ich höchstens mit unseren ca. 10 eigenen Seiten machen. Aber dazu bin ich mit All-Inkl zu zufrieden.
Deshalb bleibt es halt bei dem Download/Composer/Upload-Workflow.
Aber lese immer gerne mit, wie es andere machen.