WebsiteBaker Support (2.13.x) > Hilfe & Support (deutsch)

WB V. 2.13.1 und Modul Image Gallery V.2.0

<< < (6/7) > >>

sternchen8875:
zur anderen Image Gallery 2.0.0 von Ryan und anderen Kollegen, deren letzte öffentliche Version aus 2009 stammt.

Ich habe diese Version repariert, sie läuft mit den aktuellen WB-Versionen und im Testbetrieb mit PHP 8.2.1, die aktuell neueste PHP-Public Version. Diese Galerie-Version möchte ich ungern im Addon-Bereich sehen. Wer Bedarf hat oder diese Galerie einfach nur testen möchte, siehe Anhang

Was kann diese Galerie?
Einzel- und/oder Mehrfachbilder (eine Galerie in der Galerie)
Wysiwyg-Textbeschreibung
Mehrfach-Upload, Anzahl vorher einstellbar, aber kein Drag&Drop-Upload
Sortierung der Bilder manuell per Pfeiltasten, nach Name oder Änderungsdatum
Bild- und Thumbgrößen pro Bild einstellbar

Warum (noch) nicht in den Addonbereich? Die Optik des Backends und der Codeaufbau entspricht wohl nicht mehr dem, was in WB aktuell eine Art Standard ist (siehe Bilder unten).
Ein Umbau auf Templatebasis und modernerem Code ist aber nicht über Nacht zu machen. Für unseren Addon-Bereich wäre es ein "neues" Modul und dann, so denke ich, sollte es schon etwas ansprechender aussehen. Wie lang solch Umbau dauert, kann man nicht verbindlich sagen, ein, zwei Wochen vielleicht.

Bilder aus dem aktuellen Backend:

hgs:
Danke (Y) (Y)
imagegallery_v2.5.5.zip
Erfolgreich mit WB 2.13.3 und php8.1 getestet.
Erfolgreich mit WB 2.13.4 und php8.2 getestet.

einmalige ErrorLog-Meldungen pro Vorschaubild wegen Kommazahl wurde ja schon erklärt

sternchen8875:
Another Image Gallery
einen Fehler gab es noch, der unter PHP 8.0.x auftrat. Dank an hgs für's Testen

Eine aktualisierte Version 2.5.6 ist im Addons-Bereich -> https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=087522B

ruebenwurzel:
Hallo,

na jetzt geht es aber voran. Eine Version der "Another Image Gallery" jagt die nächste.  :-D

Beim Upgrade von 2.5.5 auf 2.5.6 wurden bei mir wieder alle bestehenden thumbs inklusive deren Ordner gelöscht. Würde mich interessieren, ob das jemand reproduzieren kann. Wenn ja, was ist die Ursache?

Auch nicht grad schön beim Update, da die frontend.css mit ausgetauscht wird werden die darin am Anfang gespeicherten Farbwerte zurückgesetzt. Die individuellen Farbeinstellungen des Backends werden erst wieder in die frontend.css übernommen, wenn man eine Galerie abspeichert. Wenn man es weiß, ist das kein großer Act. Man muss es aber halt wissen. Schöner wäre es, wenn die einmal ausgesuchten Farbwerte bei einem Upgrade automatisch mit übernommen werden.

Ansonsten aber super tolle Arbeit. WB macht richtig Spaß.

sternchen8875:
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  :-D

Navigation

[0] Message Index

[#] Next page

[*] Previous page