Little improvement for Another Image Gallery

[evaki]

>>MySQL strict mode
eben solcher ist so bei uns eingestellt.
Danke, danke...
MfG. Evaki

[ruebenwurzel]

Hallo,

Another Image Gallery in der Version 2.3 hat Probleme mit MySQL strict mode. Modul müsste angepasst werden. Habe damit im Jahre 2016 mal angefangen, hab es aber nie wirklich zu Ende gebracht.

In der Anlage mein Stand vom Mai 2016. Keine Garantie, dass das Paket überhaupt läuft. Kann aber vielleicht als Ansatz für Adaptionen verwendet werden. Denke die Hauptarbeit ist in der add.php, der save.php und der info.php.

Schönes neues Jahr wünscht
Matthias

[evaki]

Da die Wahrscheinlichkeit des Auftretens nicht besonders groß ist, wird sich da wohl niemand dran abarbeiten wollen. Bei neuen Modulen scheints ja schon in die "richtige Richtung" zu gehen, also def. Werte zwingend. Könnte mir aber auch vorstellen, daß solche Dinge generell vom Core abgefangen werden.
MfG. Evaki

[msfrog]

Mir fällt da nur eine Lösung ein: Modul umschreiben und so einen Fehler abfangen und behandeln.

[evaki]

Wahrscheinlich war "irgendeine" Störung verantwortlich, wie sie "einfach so" halt auftreten kann.
Für mich steht die Frage im Raum, wie man die Folgen unterbinden/abfangen kann, immerhin 'nen php-error, ganz zu schweigen von anderen Nebenwirkungen. 
MfG. Evaki

[msfrog]

Das Modul identifiziert anhand der Section ID den zu ladenden Datenbankeintrag, glaub ich. Ist der falsch ist das genauso als würde er ganz fehlen. Warum der bei dir falsch war entzieht sich aber meiner Kenntnis. Das hab ich noch nie gehabt.

[evaki]

Beim aktuellen Verhalten fällt auf, daß es anscheinend nur den fehlenden/falschen section_id-Eintrag betrifft. Ein hier eingetragene Wert müßte also zwingend der richtige sein. Warum nun der fehlende bzw. falsche Wert zum K.o. führt, liegt wohl "irgendwo" im Code begründet.
MfG. Evaki

[msfrog]

P.S.: für alle neuen oder überarbeiteten Module werden von uns jetzt überall solch default-Werte gesetzt und sollten in einer settings-Tabelle eines Moduls keine Werte enthalten sein, werden sie automatisch für diese Section eingetragen

Sowas wird von dem Modul ja auch gemacht. Dumm nur, wenn das Query, was da ausgeführt werden sollte, einen SQL-Fehler erzeugt (und das nicht vom Modul erkannt / abgefangen wird). Ich hab grad mal eine alte Version der add.php mit meiner aktuellen verglichen. In der alten wurde die Spalte picdir nicht befüllt, was zu einem Fehler führte, weil das Feld nicht NULL sein darf. Warum das bisher trotzdem funktionierte - keine Ahnung, in einer aktuellen MySQL-Installation führt das jedenfalls dazu, dass beim Anlegen einer Seite oder eines Abschnitts kein zugehöriger Datenbankeintrag erzeugt wird und das Modul deswegen nicht funktioniert. Meine Lösung war dann einfach, ich hab in den INSERT-Befehl noch picdir mit aufgenommen und schreibe da einen leeren String rein.

[Gast]

so was sagte ich oben schon

Auf Grund der Schilderungen (Der Fehler zeigt sich sofort, also grundsätzlich. In der Datenbank befindet sich keinerlei Eintrag) wird hier wohl das Problem sein. Das Script findet den Startordner nicht, wird aber auch nicht abgebrochen.

aber das konnte es ja nicht sein.... 

P.S.: für alle neuen oder überarbeiteten Module werden von uns jetzt überall solch default-Werte gesetzt und sollten in einer settings-Tabelle eines Moduls keine Werte enthalten sein, werden sie automatisch für diese Section eingetragen

[evaki]

Evaki: Bei welchen fehlenden Werten nun php "im Dreieck springt" habe ich nicht weiter untersucht.

Aber jetzt
Ändert man die section_id, wars das! (Zumindest so der aktuelle Eindruck)

MfG. Evaki

[evaki]

So, nun wie angesagt nochmal reingeguckt, ich wollts ja etwas genauer wissen.
Herausgekommen ist:
Installiert: Tabelleneinhalt nicht vorhanden.
Erst das Anlegen eines Abschnitts (in page) mit diesem Modul erstellt die default-Werte in der Tabelle.
Das erfolgte wohl bei meiner lokalen Installation nicht, denn es ist die Situation nach der Installation zu betrachten: Tritt beim Anlegen eines Abschnitts eine Störung auf, dann ham wir den Salat. Die default-Werte sind nicht vorhanden.
Der besagte Fehler (Speicheranforderung ganz groß) trat immer nur dann auf, wenn die Tabelle mod_imagegallery_settings existiert, dort aber keine def. Inhalte vorhanden sind.

Bei welchen fehlenden Werten nun php "im Dreieck springt" habe ich nicht weiter untersucht. Wäre schon sinnvoll, das Verhalten in dieser Situation zu ändern. (In der nächsten WB-Version gibts wohl die Möglichkeit verschiedene Parameter bei der (De-)Installation abzufragen).
MfG. Evaki

[msfrog]

Ja, das Problem mit der leeren Settings-Tabelle hatte ich auch. Ich dachte aber, das wäre inzwischen gefixt. Weiß gar nicht mehr, ob ich das selber gemacht hatte oder ob ich den Fix anderswo herhatte. Grund war schlicht das SQL-Statement, das mit neueren MySQL-Versionen einen Fehler warf.

[evaki]

Auf Grund der Schilderungen (Der Fehler zeigt sich sofort, also grundsätzlich. In der Datenbank befindet sich keinerlei Eintrag) wird hier wohl das Problem sein.

Das war von mir falsch formuliert, bitte um Nachsicht. Sag es deshalb, weil sonst möglicherweise die falschen Schlüsse gezogen werden. Also "mod_imagegallery_settings" war vorhanden, aber ohne Inhalte.
Was mich nur immer wieder wundert ist, daß man zigmal zig Webanwendungen installiert, ohne daß Probleme auftauchen, und dann eben sowas. Das Gemeine ist ja, daß man sich auf diese Verläßlichkeit stützt, und dann kirre wird, wenn ein und die gleiche Installation + Serverneustart + pi pa po mit den selben Symptomen daherkommt. Übrigens, nach dem LAN-Server auch nochmal lokal wiederholt (vor ner halben Stunde), und es funktionierte! Bei sowas stehste kurz vor der Einweisung.
MfG. Evaki

[msfrog]

Das dürfte hier nicht der Fall sein. Die fragliche Stelle wird aufgerufen, noch bevor irgendwas mit den Thumbnails angestellt wird.

Ausgabe über ein Template wäre natürlich der beste Weg, würde aber praktisch das Schreiben eines komplett neuen Moduls erfordern. Mit Verlaub, das ist mir dann doch zu viel des Guten Ich wollte einfach nur diese kleine Erweiterung haben, da das Modul ansonsten tut, was ich brauche.

[Gast]

Ich hab echt keine Erklärung dafür... Zumal Zeile 298 lediglich nen echo-Befehl enthält

der Memory ist eine Kiste mit begrenzten Volumen. In diesem Fall hier sollen (wenn nicht vorhanden) die Thumbs generiert werden, anschließend wird der Bestand entsprechend den Moduleinstellungen ausgelesen und in einen Buffer gepackt bis die Kiste voll ist oder die Ausgabe erfolgen kann. Hier wurde das Limit wohl mit Hinzufügen der Seitennummern inkl Code und Style erreicht.
(* übrigens auch ein Grund, warum die Ausgabe über ein Template erfolgen soll und nicht innerhalb der PHP-Datei. Im Template sind jeweils nur Platzhalter zu ersetzen, in der PHP-Datei wird der komplette Ausgabe-Code, die HTML-Struktur, generiert, also ein zig-Faches der Datenmenge.)

Auf Grund der Schilderungen (Der Fehler zeigt sich sofort, also grundsätzlich. In der Datenbank befindet sich keinerlei Eintrag) wird hier wohl das Problem sein. Das Script findet den Startordner nicht, wird aber auch nicht abgebrochen.
Die Datenbank heißt übrigens TABLE_PREFIX.mod_imagegallery_settings, falls da wer nach irgendwas mit another_image_gallery sucht

[evaki]

Habs bei uns im LAN auf den Server gepackt. Hier scheint der Fehler nicht aufzutreten.
Es ist wohl schon bei der Installation auf dem lokalen Arbeitsrecher (der "in die Knie ging") etwas schiefgelaufen. Bei "unerklärlichen" Fehler bzw. Verhältnissen ist das bei uns der einzige Fall, wo wir's ins LAN (Server) packen dürfen, damit wir uns "nicht den Wolf suchen". Nur damit funktionieren die Testtools richtig.
Aber Jacobi22 hat ja schon Ergänzungen angemerkt. Das etwas genauere Hinschauen hat also zumindest das gebracht.
Glücklich sind die, die nicht auf hausgemachten Fehlern sitzen bleiben  Das hat ja auch was.

Ach ja, das Erscheinungsbild ist nach der Installation auch erfreulich, nämlich vollständig 
Trotzdem würde ich immer noch gerne wissen, warum bzw. bei welchem Zustand dermaßen viel Speicher angefordert wird.
MfG. Evaki

[msfrog]

Ich hab echt keine Erklärung dafür... Zumal Zeile 298 lediglich nen echo-Befehl enthält. Das gehört zur Anzeige der Seitennnummern der Galerie. Dort hab ich nichts angefasst, das hat bisher auch immer funktioniert, also auch mit älteren PHP-Versionen etc..

[evaki]

Bilddateigröße selbst kanns auch nicht sein (800kb). Nun hab ichs mal nicht mit Browsern, sondern in einer der Testumgebungen aufgerufen. Der Fehler zeigt sich sofort, also grundsätzlich. In der Datenbank befindet sich keinerlei Eintrag.
Vielleicht sehe ich ja heute Abend (mit dem Codeanalyzer -wo ich auch keine Ahnung hab'-  ) ein wenig mehr.
Vielleicht auch neu installieren usw. das übliche Prozedere halt.
MfG. Evaki

[Gast]

[03-Jan-2018 10:22:27 Etc/UTC] PHP Fatal error:  Out of memory (allocated 335544320) (tried to allocate 331366400 bytes) in \modules\imagegallery\view.php on line 298

lt Code werden nur jpg, gif oder png eingelesen und davon Datei für Datei Thumbs generiert
die Frage wäre, über wie viele Dateien sprechen wir und wie groß sind die Ausgangsdateien? bei 100 Bildern von der Digicam mit je 20 Mb und 5000 - 8000er Seitenlänge wird der Arbeitsspeicher sicher an seine Grenzen kommen. Wenn man dann noch Unterordner einschließt, hat man schnell eine Anzahl erreicht, die a.) niemand mehr anschauen würde und b.) obigen memory-Fehler von selbst erklärt

P.S.: weil es zum Thema gehört:

2018-01-03T11:34:30+00:00 [E_NOTICE] \modules\imagegallery\save.php:[106] from \modules\imagegallery\save.php:[106] WbErrorHandler "Undefined variable: inline"
2018-01-03T11:34:30+00:00 [E_NOTICE] \modules\imagegallery\save.php:[116] from \modules\imagegallery\save.php:[116] WbErrorHandler "Undefined index: PAGES"

[evaki]

>>Also ist der Fehler ohne die 7z weg, ja?
Ob der Fehler weg ist, kann ich noch nicht sagen. Nur kam nach der erwarteten Zeit keine Meldung mehr, das neue Fenster ging dann auch auf, aber danach ging der Arbeitsrechner "in die Knie" weil mal wieder mehr als 10 Programme geöffnet waren. Seitem nix neues mehr getestet. Mittagspause ist leider auch gleich durch...
Die Mittagspause ist zwar durch...
Der Fehler zeigt sich nach wie vor. Werde mir das am Abend nochmal anschauen. Möglicherweise wieder mal was ganz blödes. Es läuft bei Dir ja ohne Probleme.
MfG. Evaki

[msfrog]

Also ist der Fehler ohne die 7z weg, ja? Hm, ich kann ja bei Gelegenheit mal gucken, ob ich nen Fix dafür bauen kann.

[evaki]

Bei mir wars aktuell eine 7z. Hab soeben nochmal draufgeschaut, die Datei selbst ist "klitzeklein". An der Dateigröße selbst kanns dann also nicht liegen. Da ich in das Modul nur mal eben so anschauen wollte, kann ich z.Z. nix anderes als über den momentanen Zustand zu berichten. Heute komm ich nicht mehr dazu  das in derTestumgebung laufen zu lassen, wo vielleicht ein wenig mehr dabei rauskommt.

Jedenfalls ist es ja auffällig, daß es mit der 7z so komische Auswirkungen zeigt.
MfG. Evaki

[msfrog]

Wenn ich das richtig im Kopf habe filtert das Modul beim Auslesen der Dateien nach der Endung. Wenn du eine ZIP als .zip da reinlegst, sollte das auch nicht verwurstet werden. Ich hab aber das Modul jetzt nicht bis ins kleinste Detail aufgedröselt, sondern nur die für mich relevanten Stellen rausgesucht, um meine Änderung reinzubringen.

[evaki]

So...
Kanns sein, daß das Modul "alles" schluckt, was sich so im ausgewählten Verzeichnis befindet, also nicht nur Bilddateien, sondern auch mal nebenbei noch ZIP, oder 7z, oder sonstwas, sich deshalb, bei entsprechender Dateigröße, der "allocated"-error zeigt? Hab gerade mal sowas getestet. Wäre gut zu wissen, ob das auch noch anderswo so in Erscheinung tritt.
MfG. Evaki

[msfrog]

Hm, da fällt mir nichts zu ein. Tuts denn die alte Version ohne meine Anpassung bei dir? Ich hab meine inzwischen auf mehreren Servern laufen gehabt, ohne solche Schwierigkeiten. Dürfte aber alles PHP7 gewesen sein, wenn ich mich richtig erinnere.

dbs:
Die leere frontend.css hab ich wohl versehentlich aus meinem Projekt mitkopiert. Ich mach die CSS-Dateien der Module immer leer und mach das Styling selber.