WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => Modules => Topic started by: msfrog on December 21, 2017, 06:10:23 PM
-
Hi,
I've made a little improvement to the module Another Image Gallery. One of my customers didn't like the way the Thumbnails were created, so I added an option to let the thumbnail cover the complete space. The shorter side will match the given thumbnail size, the longer side is scaled with the correct aspect ratio, the parts of the image which exceed the thumbnail size are cut. The Thumbnail is taken from the center of the image.
Ich habe das Modul Another Image Gallery ein bisschen erweitert. Einer meiner Kunden mochte nicht, wie die Thumbnails erstellt werden. Ich hab daher eine Option eingebaut, mit der das Thumbnail immer die komplette Fläche abdeckt. Die kurze Seite des Originalbilds wird auf die eingestellte Thumbnailgröße skaliert, die lange Seite wird im gleichen Größenverhältnis verkleinert. Das, was über die Thumbnailgröße herausragt, wird abgeschnitten. Das Thumbnail ist ein Bildausschnitt aus der Mitte.
-
Hi, you should only zip the content of the folder, not the folder self.
Hi, das wird nicht installierbar sein.
Darfst nur den Inhalt vom Ordner zippen, nicht den Ordner selbst.
-
Narf... Dumm von mir, man sollte sowas nicht schnell schnell noch hochladen :/ Hier die neue Zip.
-
:-) better fast uploading as no uploading.
The gallery is simple but works. Thanks for that. (Y)
-
Question: the empty frontend.css is wanted?
Die leere frontend.css ist beabsichtigt oder ein Versehen?
-
Bei mir gibts 'ne Fehlerausgabe (php-error) im Frontend
[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
(Da bricht das CLI zusammen (php))
Es wurde noch keine Galerie angelegt.
Der Versuch eine anzulegen scheitert. Es wird "gespeichert" angezeigt, zu sehen ist aber hinterher nix.
Im Moment läufts unter PHP-7.0.0
Hakt es nur bei mir, oder...? Alles andere -was nicht wenig ist- läuft nach wie vor problemlos (oder ich habs noch nicht entdeckt :roll: )
MfG. Evaki
-
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.
-
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
-
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.
-
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
-
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.
-
>>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
-
[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"
-
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'- :-D ) ein wenig mehr.
Vielleicht auch neu installieren usw. das übliche Prozedere halt.
MfG. Evaki
-
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..
-
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 (Y) 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
-
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_galle ry sucht
-
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.
-
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_se ttings" 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
-
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.
-
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_se ttings 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
-
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
-
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.... :roll:
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
-
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.
-
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
-
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.
-
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
-
Mir fällt da nur eine Lösung ein: Modul umschreiben und so einen Fehler abfangen und behandeln.
-
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
-
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
-
>>MySQL strict mode
eben solcher ist so bei uns eingestellt.
Danke, danke...
MfG. Evaki