Ich kann den Fehler bei all-inkl.com mit keiner freigegebenen php-Version für WB2.13.3 nachvollziehen.
selbst bei der Testversion mit php8.2 habe ich keine Probleme ein Modul über das AFE 4.0.6 herunter zu laden.
Scheinbat gibt es immer wieder Probleme mit (IONOS und Strato), da hat Dietmar schon oft ein Fix nachschieben müssen.

Hilft dir jetzt nicht weiter, aber das noch zur Aufklärung: die höheren PHP 8.1er Versionen wie 8.1.14 oder 8.1.17 usw sind eher an PHP 8.2 dran und meckern schon mal Dinge an, die erst für PHP 8.2.x geplant waren. Bei IONOS hab ich nur die Auswahl zwischen PHP 8.1.17 oder PHP 8.0.27, von daher gehts im Zweifel eher zu einer PHP 8.0.x. In der Praxis geht die Empfehlung aber schon zu einer PHP 8.1.x, schon allein, weil eine PHP 8.0.x seit Dezember 2022 keinen offiziellen Support mehr erhält, nur noch Security Support bis Ende des Jahres. Im Gegensatz dazu kommt bei PHP 8.1.x noch jeweils ein Jahr drauf.

Mit deinen bzw unserem Problem hat das aber wenig zu tun. Local kann ich auch mit der neuesten PHP 8.2.2 arbeiten, online kann ich aber mit dem AFE auch mit PHP 8.0.x nicht runterladen. Ist also nicht zwangsläufig ein Problem im Code des Addons

Moin moin,
da bin ich wohl durcheinander geraten...

Ich hab den Editor von https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=02D8BA1 geladen. Den meinte ich auch.
Hab eben mal das Modul entfernt und neu installiertm Browsercache gelöscht, Error500 bleibt leider.

Hab getestet mit Chrome, FF und Edge.

PS. Umstellen auf PHP 8.1 war keine Option, ich hatte erst eine Über 8.0 hatte Probleme mit WB und hab irgendwo im Forum gelesen, das 8.0 empfohlen war. Nachdem ich zurück auf 8.0 gewechselt bin ging WB wieder fehlerfrei. Nur das Modul geht nicht mehr.
Ist nur ein kleines Problem (editieren geht ja noch). Nur wenn man kein FTP nutzen kann und das original Template nicht mehr zur Hand hatte, war das sehr geschickt.

nur am Rande... bitte unterscheiden zwischen AddonFileEditor und cwsoft-addon-editor. Das sind mittlerweile zwei unterschiedliche Paar Schuhe. Für WB gewartet und empfohlen wird der AddonFileEditor, aktuelle Version wäre die 4.0.6
Beide Module nutzen unterschiedliche Installations-Ordner unter /modules und konnten auch gleichzeitig betrieben werden, haben aber identische Funktionen.
Der cwsoft-addon-file-editor war mal Ausgangspunkt für die heutigen Versionen der Nachfolger und wird unter diesem Namen für das CMS WBCE weiter betrieben (aktuelle Version 3.2.3). Ob sie kompatibel zum jeweils anderen CMS sind, müßte getestet werden, der genannte Vorgänger war es unter diesem Namen jedenfalls. Also bitte noch mal checken und ggf korrigieren.

Aktuelle Fehlerausgabe bei mir im AddonFileEditor 4.0.6 unter PHP 8.1.14 und PHP 8.0.27 bei verschiedenen Providern (IONOS und Strato)
[12-Feb-2023 09:51:39 UTC] PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /usr/lib/php8.1/HTTP.php on line 500" mit Folge, das keine Downloads möglich sind.

Fehler ist bei mir nicht reproduzierbar
- WB 2.13.3 r166
- PHP 8.1
- AFE 4.0.6

Vielleicht hilft ein einfaches Browsercache löschen?
Kannst du auf PHP 8.1 umstellen? Ist der Fehler dann weg?

Hi Leute, hat jemand von Euch auch den o.g. Editor am laufen.
Vom Prinzip her funktionierte der bisher gut und wird auch auf der WB Seite unter Downloads (Admintools) in Version 4.0.6 angeboten.

Unter der neuen WB Installation 2.13.3 r166 gibt's mit dem Modul ein kleines Problem beim Download von Files (Erweiterung, Templates... egal was), nach Klick auf das Zip+Download-Icon kommt unter der URL https://xxx/modules/AddonFileEditor/code/download.php?aid=43 nur der HTTP Statuscode Error 500

Hat da jemand schon die gleiche Erfahrung gemacht und einen Workaround im Angebot. Das CMS läuft unter PHP 8.0.

der Wunschzettel kommt für jetzt zu spät  Hab jetzt mit der anderen Galerie begonnen, weil ich da mehr Dringlichkeit sah

Da ich mit einer Art Baukastensystem arbeite, geht es zumindest rein optisch immer recht zügig voran. Das System ist eine Co-Produktion zwischen Dietmar und mir. Knifflig wird es immer dann, wenn es darum geht, Altlasten zu erhalten, in deinem Falle wäre das die Frontend-Optik, die man erhalten sollte. Im Fall der Image Gallery sind das die alten Ausgabeformen mit separatem Code für Header, Loop und Footer.
Da, wo ich nicht abwärtskompatibel sein muß, arbeite ich mit Twig-Templates für die Frontend-Ausgabe, das kann aber pro Section unterschiedlich sein. Aber im Fall der Image Gallery wird es wohl so bleiben, wie es der alte Standard vorsah.
Grundsätzlich ist es dann immer so, das jede Section ihre eigenen Settings hat und wenn solch Setting die Einstellung von Farben vorsieht, dann werden auch die dort reingeschrieben. Wie ich das dann mit Abwärtskompatibilität verbinde, weiß ich noch nicht, aber das sehen wir dann.

Aktuelle Ansicht unten im Backend der Image-Gallery mit Ausgangspunkt der reparierten Version 2.1.0 etwas weiter oben  hier.
Das Modul hat die zentralen backend.css und frontend.css, dazu eine frontendUser.css, die auch zentral ist. Dazu kommen pro eingesetztem Frontend-Template noch einmal je eine frontend_default.css und backend_default.css. Die backend.css und frontend.css im Hauptordner liefern allgemeines CSS, die frontendUser.css kann sich jeder selbst anlegen, wird nicht mehr überschrieben. Und die letzten beiden CSS-Dateien sind dann eher Template-spezifisch. Diese CSS lassen sich dann alle im Backend editieren (siehe Bild). Alles dynamische kommt dann aus der Datenbank.

Problem wird hier definitiv die Sortierung der Bilder. Im Bild noch mit der Drag&Drop-Funktion oder halt den gewohnten Pfeilen. Der Haken ist, das er Bilder,, die als Subbilder vorhanden sind, also Galerie in der Galerie, immer mit durchnumeriert. Das Problem kann man eigentlich nur lösen, wenn man Subbilder separat behandelt, aber das muß man dem Anwender auch beibringen.

Guten Morgen,
ich habe bisher nur die Änderungen entsprechend Ticket durchgeführt:

                                if (!empty($sContent) && $isActive) {
                                    $bPrintAnchor = ($bAnchor && ($sSectionIdPrefix == 'none')||($sSectionIdPrefix != 'none'));
                                    $sAnchor = "\n".'<div id="'.$sSectionIdPrefix.$section_id.'" class="section m-'.$module.' '.$sAttribute.'" >';
                                    $sBeforeContent = ($bPrintAnchor ? $sAnchor : '');
                                    $sAfterContent  = ($bPrintAnchor ? '</div><!-- INFO '.$module.$section_id.' -->' : '');
                                    // echo $sContent = $sBeforeContent."\n".$sContent."\n".$sAfterContent."\n";
                                    echo $sContent = \ltrim($sBeforeContent."\n".$sContent."\n".$sAfterContent."\n", "\n");
                                }


Fetten Dank für das Feedback. Ich weiß ja jetzt, wo ich reinschauen muss um noch mal Hand anzulegen. Mittlerweile habt Ihr netter Weise auch ein Ticket erfasst, so dass ich mir bei späteren Updates keine Gedanken machen muss, was noch abzuändern wäre.

EINEN GROSSEN DANK AN ALLE BETEILIGTEN.

Hallo,

danke für deine Erläuterungen. Das deckt sich mit dem, was ich mir so zusammengereimt habe.

1.)Thumbs:
Ich sehe in dem jetzigen Vorgehen eigentlich mehr Vorteile als Nachteile. So wird der Thumbs Ordner bei einem Upgrade auf aktuellen Stand gebracht und alte "Karteileichen" (nicht mehr vorhandene Bilder von denen die Thumbs noch existieren) entsorgt. Das kann man ruhig so lassen. Wann das reingekommen ist? Keine Ahnung.
Mein persönliches kleines Problem ist, dass ich vereinzelt Thumbs aus der Galerie auch noch an anderen Stellen meiner Seiten einbaue. Die sind dann halt nach einem Upgrade solange weg, bis die entsprechende Galerie einmal aufgerufen wurde. Das sind aber auch bei mir nur Einzelfälle und ist verschmerzbar.

2.)Css
Das mit der frontendUser.css gefällt mir sehr gut. Entspricht der Logik und der Vorgehensweise bei anderen Modulen und beseitigt mit vertretbarem Aufwand diesen kleinen Fehler für alle Zeiten.

Was mich momentan an der der Farbgebung noch stört, ist, dass im CSS nur die Farbwerte der zuletzt gespeicherten Galerie-Section gespeichert werden. Hat man mehrere Galerien und will unterschiedliche Farbwerte haben, geht das nicht. Das dahingehend zu ändern, dass immer die in der Datenbank bei der sectionID gespeicherten Werte genommen werden, ist vermutlich ein zu großer Aufwand. Da man vermutlich (so ist es bei mir zumindest) auf einer Seite bei allen Galerien die gleichen Werte hat, wäre eine Option ja auch vielleicht, dass man das im Backend nur einmalig und global für alle Galerien einstellen kann, beziehungsweise, dass eine Änderung in einer Galerie Auswirkungen auf alle Galerien hat. Wenn man unterschiedliche Farbwerte für jede einzelne Galerie haben will, dann sollten die Werte für das CSS direkt aus der Datenbank gezogen werden und nicht über den Umweg des Abspeicherns in einer CSS Datei.
Soweit meine Wunschliste. Schade, dass Weihnachten grad erst vorbei ist, aber es kommt ja denke ich auch mal wieder ein Weihnachten. Will sagen, die Galerie funzt momentan auf den aktuellsten Plattformen, ich komm mit ihr wunderbar zurecht, ein zwingendes und schnelles Einschreiten ist nicht erforderlich. In einer künftigen Version kann man sich dem Thema aber vielleicht mal annehmen 

Es gibt Dinge, die lassen sich schnell erklären wie Thumbs löschen beim Upgrade, anderes (das CSS, dauert länger...

Zu den Thumbs: das halbe Script in der Datei upgrade.php ist für das rekursive Suchen, Finden und Löschen der Thumbs-Ordner zuständig. Frag mich aber bitte nicht, wann das da reingekommen ist, in der Version auf oben mal genannter, veralteter Seite ist es nicht drin.
Du warst in den Beiträgen immer sehr aktiv, eventuell hast du noch ältere Versionen, wo du mal nachschauen kannst, wann das rein kam

Das Löschen hat ja Vor- und Nachteile. Nimmt man z.b. manuell Bilder aus dem Hauptbilderordner, ist der Thumbs-Inhalt dazu eventuell unangetastet und könnte so einen Fehler erzeugen. Hat man aber komplexe Galerien aufgebaut, dauert das Neuerstellen und im WorstCase bricht er mit einem memory-Fehler ab.

Zum CSS...
bei einer Neuinstallation fügt die add.php beim Anlegen einer Section die in dieser Datei definierten Werte in die Datenbank ein. Die Module-Settings können diese Datenbankwerte nun verändern oder so lassen. Beim nachfolgenden Speichern werden diese neuen Werte wieder in die Datenbank, gleichzeitig aber auch in die frontend.css geschrieben, die im Original die gleichen Werte hat wie die add.php. Soweit, so klar. Für den weiteren Verlauf nehmen wir an, das die frontend.css angepasst wurde.
Nun kommt das Module-Upgrade, bringt wieder eine original frontend.css mit, die dort im Frontend natürlich eingelesen wird und, wie in deinem Fall, auch schon, bevor man im Backend gewesen ist. Die Module-Settings dort lesen in jedem Fall die alten Einstellungen aus der Datenbank, die man dann speichern muß, damit die frontend.css wieder überschrieben wird mit dem alten Kram aus der Datenbank. Damit läuft dann das Frontend wieder wie gehabt.

Noch ein Hinweis: es geht nachfolgend nur um ein Upgrade des Modules, das WB-Upgrade-Script hat keinen Einfluß auf den Inhalt der frontend.css und auch nicht auf das Löschen der Thumbs

Es gäbe nun mehrere Varianten, wie man das in der Galerie angehen könnte:
in #1 läßt man es so wie es ist. Wenn man es weiß, geht man halt nach einem Modul-Upgrade einmal in die Settings, speichert neu ab, fertig, erledigt.

in #2 erweitert man das Upgrade-Script des Moduls um die Funktion des Schreibens der frontend.css mit den Daten aus der DB beim Upgrade. Der Code wäre vorhanden, das meiste wär Copy&Paste. Rechne ich da aber noch die Thumb-Neuerstellung dazu, muß das Upgrade-Script in einer komplexen Galerie schon etwas rattern.

#3 ist fast so einfach wie das Nichtstun in #1. Statt der frontend.css schreiben wir das geänderte CSS in die bei WB eingeführte frontendUser.css. Die wird nach der frontend.css geladen und überschreibt diese dann. Das wäre ein einmaliger Vorgang, weil die frontendUser.css nicht mehr überschrieben wird. Diese Lösung ist kicky einfach, auch schon durch getestet, aber man muß halt einmal da durch.
Das ist aber bei allen drei Varianten so. Wer das Update schon gemacht hat, wird nicht noch eins drüberziehen wegen eines Mausklicks. Und da die Galerie auch mit PHP 8.2 läuft, ist ein weiteres Update auch erstmal nicht nötig. Aber zumindest weiß nun jeder, warum das so ist