Test Responsive FolderGallery (RFG) 0.75

[grindmobil]

Es macht ja auch keinen Sinn, JPG-Bilder zu zippen, die sind ja bereits komprimiert.

Wird meist nur wegen "Alle auf einen Streich" gemacht, um nicht auch noch mit ftp oder sonstwas "rummachen" zu müssen.

Du kannst einfach den ganzen Packen Bilder auswählen und auf das Upload-Feld ziehen. Einfacher gehts nicht und du hast kein Problem mit Max-Filesize und sonstwas.


MySQL Strikt: Ist nicht mehr wirklich in Mode, hatte ich gar nicht mehr auf dem Radar.
Da gehts um die Anführungszeichen um Zahlen, oder? Die müssen weg(?):
...SET `modified`= '.$t.', `is_empty`= 0  WHERE `id` = '.$cat_id.';'

Das geht eigentlich mit Suchen/Ersetzen über das ganze Verzeichnis, denke ich. Sind eh immer die gleichen Kandidaten.
Aber ich kann das gar nicht mehr testen, localhost am PC hat sich ziemlich aufgehört bei mir, ich mach alles direkt am Server.

[evaki]

Hab' den Ordner "Bilder" (testseite von hgs für evaki beim Hoster) eingebunden, und - bis auf CSS bearbeiten: Sicherheitsverletzung!! Zugriff wurde verweigert!" scheint es zu funktionieren. Die unterschiedlichen Optionen habe ich noch nicht ausprobiert.

"hgs" sich morgen damit beschäftigen, und berichten.
Ob ich heute noch dazu komme - weiß noch nicht.
Jedenfalls, wenn alles klappt, kann man sich den nächsten Schritt erlauben, nämlich das Teil für MySQL-strict anzupassen. Ist vielleicht was für's Wochenende, wenn's sonst keiner macht. Alle sind ja schneller als ich es je sein werde. Ein wenig graust's mich schon, obwohl ich's ja nicht zum ersten mal mache.

MfG. Evaki

[evaki]

Es macht ja auch keinen Sinn, JPG-Bilder zu zippen, die sind ja bereits komprimiert.

Wird meist nur wegen "Alle auf einen Streich" gemacht, um nicht auch noch mit ftp oder sonstwas "rummachen" zu müssen.

[evaki]

Diese Fehlermeldung "Bei der Synchronisierung mit der DB......" darf man liegen lassen.
Scheint nur ein Laufzeitproblem gewesen zu sein (tritt hier manchmal auf: Lastproblem). 

Der Test mit den angemeckerten Dateien (bei hgs) steht noch aus, kommt aber bald.
MfG. Evaki

[grindmobil]

Kann ich denn auch zip-Files über das FE mit entpacken hochladen?
Bei der überarbeiteten FG geht das alles sehr schön im BE und die synconisieren läuft automatisch ab, da es ja was neues zu sehen gibt.

Das ist in der rFG nicht so.
Es macht ja auch keinen Sinn, JPG-Bilder zu zippen, die sind ja bereits komprimiert.

Klarer Fall: Der Hauptweg ist, die Bilder per Drag&Drop im Frontend hochzuladen.

[evaki]

Kann ich denn auch zip-Files über das FE mit entpacken hochladen?

Kann ich Dir nix zu sagen. Ich habe erstmal die Dateien direkt in ein vorher angelegtes Verzeichnis reingelegt, also keinerlei Formen des Uploads, und dann synchronisiert. Mehr will ich beim Test mit den Bildern im Moment auch nicht "herausfordern", soll also heißen, daß ich mich schrittweise herantaste. Sollte es mit Deinen bearbeiteten Dateien auch keine Probleme geben, kann man weitersehen. Unabhängig davon, kannst Du natürlich auch "andersrum" testen. 
MfG. Evaki

[hgs]

Nachtrag> @HGS: Der erste Test mit drei Original-Dateien (DSC***.jpg) verlief positiv, also keine Fehlermeldung. Wenn die bearbeiteten/beanstandeten Dateien hier sind, geht's weiter.

Vieleicht ist da ja der "Fehler" Ich habe die Bilder immer über Media als zip mit entpacken in das jeweilige Unterverzeichnis hochgeladen und dann im BE auf DB syncronisieren geklickt, Kann ich denn auch zip-Files über das FE mit entpacken hochladen?

Bei der überarbeiteten FG geht das alles sehr schön im BE und die synconisieren läuft automatisch ab, da es ja was neues zu sehen gibt.

[evaki]

Abseits vom Bildertest habe ich mal den wb-debug-modus eingeschaltet.
Bei der Synchronisierung mit der DB

Code Select Expand

Synchronisiere Dateisystem mit Datenbank...

Exception: "Duplicate column name 'cat_path'
ALTER TABLE `wb_mod_responsiveFG_categories` ADD `cat_path` TEXT NOT NULL DEFAULT ''" @ mysql->query(); in\framework\class.database.php

Array
(
    [file] => \framework\class.database.php
    [line] => 139
    [function] => query
    [class] => mysql
    [type] => ->
    [args] => Array
        (
            [0] => ALTER TABLE `wb_mod_responsiveFG_categories` ADD `cat_path` TEXT NOT NULL DEFAULT ''
        )

)

database->query(); in\framework\class.database.php

Array
(
    [file] => \modules\responsiveFG\admin\scripts\fix_category_data.php
    [line] => 61
    [function] => query
    [class] => database
    [type] => ->
    [args] => Array
        (
            [0] => ALTER TABLE `wb_mod_responsiveFG_categories` ADD `cat_path` TEXT NOT NULL DEFAULT ''
        )

)

include(); in\framework\class.database.php

Array
(
    [file] => \modules\responsiveFG\admin\sync.php
    [line] => 55
    [args] => Array
        (
            [0] => \modules\responsiveFG\admin\scripts\fix_category_data.php
        )

    [function] => include
)

Is also noch nich so schön wie in Bullerbü.

[evaki]

Dieses Verhalten werde ich mir genauer anschauen:
/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(duboesedatei.j pg): Process tag(x010D=DocumentNam): Illegal components(0)"

Dazu werde ich mir das Format und die Bearbeitung etwas genauer anschauen.
"Eigentlich" sollte die Bearbeitung z.B. mit IrfanView keine nachteiligen Folgen habe - eher das Gegenteil. Hatte schon Bilder vom Mac/Adobe, die nicht wollten wie sie sollten, danach aber "sauber" waren.
Es kann aber u.U. auch Probleme mit der serverseitigen Bearbeitung der Grafik/Bilder nicht ausgeschlossen werden, wenn die bereitgestellten Funktionen genutzt werden (tun sie das?).
(HEIC/HEIF-Format z.B. wird serverseitig wohl niemand, außer auf dem eigenen Server, nutzen können. Gut, ist 'ne andere Baustelle)

MfG. Evaki

Nachtrag> @HGS: Der erste Test mit drei Original-Dateien (DSC***.jpg) verlief positiv, also keine Fehlermeldung. Wenn die bearbeiteten/beanstandeten Dateien hier sind, geht's weiter.

[evaki]

Da wäre gut die Hälfte meiner Kundschaft betroffen

Die andere Hälfte dürfte er dann haben   

Also, alles mal der Reihe nach...  - dann seh'n wir weiter.

Aber schön zu sehen, daß es im Forum auch lustig zugehen kann.

[evaki]

MYSQL-Strict-Mode-Lauffähigkeit.

Ha, darauf hab ich noch nicht, un so.

Erstmal dat:

Code Select Expand

Hab' mal EINE Bilddatei mit (xmp) EXIF und IPTC Daten.jpg eingeladen.
Keine Fehler bei Einbindung und Wiedergabe dieser und anderer Dateien.jpg.

Fragt man sich, wie die Daten beschaffen sein müssen, damit die "gefressen" werden.
Gibt es Voraussetzungen beim Server, oder kommt das Script ohne aus?

CSS bearbeiten wurde mit "Sicherheitsverletzung!! Zugriff wurde verweigert!" beantwortet.

Bildbeschreibungen eingefügt: Keine Fehlermeldung
Zwei Vorschaubbilder (mit und ohne Exif et.) bearbeitet (neuer Ausschnitt):  Keine Fehlermeldung

Bei EXIF, orientation usw. bin ich leider draußen.

MfG. Evaki

[Gast]

Ausschlußkriterium für mich ist die fehlende MYSQL-Strict-Mode-Lauffähigkeit. Da wäre gut die Hälfte meiner Kundschaft betroffen

[hgs]

Ich starte noch mal den gleichen Test mit den vorhandenen Bildern der FG
Bitte nicht schimpfen, wenn es Fehlermeldungen gibt
Testprot.
rFG - Seite gelöscht
rFG Modul (alte Version) gelöscht
rFG 0.79 installiert = ErrorLog keine Meldungen
Seite mit rFG erstellt = ErrorLog keine Meldung
Im BE das Verzeichnis der vorhandenen Bilder eingestellt und gespeicher = ErrorLog ist voll mit (Beispiel nur eine Meldung + die 3 letzten im Post, Erklärung ist ja schon gepostet worden.

Sun, 28 Apr 2019 11:16:12 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2014/2017/2017.11.05 Musical -Martin Luther-"
...
...
Sun, 28 Apr 2019 11:16:46 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_047.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Sun, 28 Apr 2019 11:16:47 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(David_P._01.JPG): Process tag(x2001=PreviewImag): Illegal pointer offset(x44FE76 + x6899D = x4B8813 > x8B73)"
Sun, 28 Apr 2019 11:16:48 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(David_P._01.JPG): Process tag(x2001=PreviewImag): Illegal pointer offset(x44FE76 + x6899D = x4B8813 > x8B73)""

Im FE wird alles angezeigt wie in der FG
Im FE die Ansicht angepasst = ErrorLog

Sun, 28 Apr 2019 11:22:44 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_047.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Sun, 28 Apr 2019 11:22:52 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_043.jpg): Process tag(x010D=DocumentNam): Illegal components(0)""

Im FE ein neuen Ordner angelegt und ein Bild hochgeladen = ErrorLog

Sun, 28 Apr 2019 11:24:23 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Sun, 28 Apr 2019 11:24:23 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/www/htdocs/w018ccdf/WB_Testbereich/liveseiten_im_test/media/Bilder/2017/fg-thumbs/2017.11.05 Musical -Martin Luther-): failed to open stream: No such file or directory"
Sun, 28 Apr 2019 11:24:35 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Sun, 28 Apr 2019 11:24:35 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/www/htdocs/w018ccdf/WB_Testbereich/liveseiten_im_test/media/Bilder/2017/fg-thumbs/2017.11.05 Musical -Martin Luther-): failed to open stream: No such file or directory"
Sun, 28 Apr 2019 11:25:46 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Sun, 28 Apr 2019 11:25:46 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/www/htdocs/w018ccdf/WB_Testbereich/liveseiten_im_test/media/Bilder/2017/fg-thumbs/2017.11.05 Musical -Martin Luther-): failed to open stream: No such file or directory"
Sun, 28 Apr 2019 11:26:20 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Sun, 28 Apr 2019 11:26:20 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/www/htdocs/w018ccdf/WB_Testbereich/liveseiten_im_test/media/Bilder/2017/fg-thumbs/2017.11.05 Musical -Martin Luther-): failed to open stream: No such file or directory""

Im Ordner 2017 habe ich einen neuen Unterordner wie geschrieben angelegt und nur ein Bild im FE hochgeladen, warum diese Meldungen erscheinen kann ich mir nicht erklären.
Muss ich aber auch nicht, da ich nur poste was mit dem Modul passiert.
Der neue Ordner und das Bild sind im FE sichtbar
Hoffe es hilft Euch weiter.

[hgs]

Ich starte noch mal den gleichen Test mit den vorhandenen Bildern der FG
Bitte nicht schimpfen, wenn es Fehlermeldungen gibt

[evaki]

akademische Frage

Na, eher eine Frage die sich für's Qualitätsmanagement stellt. Wer keine Fehler oder Notizen mag, muß dann bei solchen Problemchen nachbessern. Diese Frage des Nachbedarfs stellt sich aber erst wenn sonst alles funktioniert 

Aber klar, aktuell geht's um Fehler, Sicherheit und natürlich darum, ob alles wie gewünscht funktioniert.
Schaun wir mal, ob noch wer testet.
MfG. Evaki

[grindmobil]

Hier ist die aktuelle Version 0.79
https://wbce.at/downloads/responsiveFG-0.79.zip

Ich hab noch einen kleineren Bug ausgebessert, der zu TimeOut führen konnte, wenn man sehr viele Bilder auf einmal hochlädt.

Die Sache mit der class.upload interessiert mich nicht sonderlich, das ist echt eine akademische Frage, von der ein User genau nichts mitbekommt.

Das Problem, dass bei einer Migration uU die Tabellen auf Kleinbuchstaben geändert werden, ist wohl etwas heikler, aber auch das sollte nicht mehr vorkommen.

[evaki]

Also nochmal reingeguckt -  Telefon am Ohr - zugehört und schreibsel...
Es betrifft also also nicht  Code: [Auswählen]

Evaki:
$this->mime_fileinfo            = true;     // MIME detection with Fileinfo PECL extension
müßte danach nur auf "false" gesetzt werden.

sondern den Abschnitt
// checks MIME type with Fileinfo PECL extension
wobei in der hiesigen Testumgebung der Ablauf um (PHP_OS, 0, 3) == 'WIN') zu entfernen ausreichen würde - grundsätzlich für win, nicht nur win32.

War diese Überprüfung  für php5.3 f. vielleicht noch sinnvoll, ist sie bei mittlerweile mit php 7. f. nun vollkommen überflüssig, könnte/sollte also komplett entfernt werden.
MfG. Evaki

[evaki]

ich sehe schon, ich kann mir das Schreiben von Erklärungen wirklich sparen

Den Guru kann ich auch    - aber ohne Frust. 
Es geht bei der erwähnten Fehlermeldung nicht um die konkrete Funktion, sondern nur um das Verhalten bei Nichtvorhandensein der PECL-Erweiterung, dieselbe seit php5.3 ja standardmäßig aktiviert ist.
Die Fehlermeldung tritt anscheinend nur bei win32-php auf, wenn dort - eben nur dort, der Ausnahmefall - sie als Erweiterung nicht installiert ist. Warum nun dort noch immer die Abfrage drin ist (php7.x).......

Ob die richtige Zeile angegeben wurde (MIME detection with Fileinfo PECL extension) wurde im Nachhinein nicht nochmal überprüft. Jedenfalls waren die daraus gezogenen Infos/Rückschlüsse (PECL extension) hierzu richtig.

MfG. Evaki

[grindmobil]

Im 2. Bier war die Eingebung, woher dieser seltsame Update- Fehler kam.

Die rFG kann beliebig umbenannt werden, sie legt Tabellen nach dem Verzeichnis-Namen an.
Da das "FG" groß ist, heißen auch die Tabellen so.

Das ist durchaus erlaubt, ebenso wie Datei-Namen Großbuchstaben enthalten können.

Der Bug liegt in phpmyadmin: wenn man die Datenbank migriert, werden uU die Tabellen auf Kleinbuchstaben geändert. Dadurch ist die Tabelle nicht mehr "vorhanden".
Ob dieser Bug immer noch ist, weiß ich nicht.

Wenn ein Modul nie genutzt wird, fällt es eben erst nach Jahren auf.

[grindmobil]

Der von Evaki gemeldete Fehler hei der Installation ist inzwischen auch bei mir mal aufgetreten.

Nach einer harmlosen DB-Abfrage in update.php (gleich die erste) passierts im fetchRow.

Da schien es sich um eine sehr alte und nie genutzte Installation zu handeln. Macht mir jetzt wenig Sorgen.

[hgs]

mea culpa 
Nach deinen (jacobi22) Erklärungen war das Thema "voller ErrolLog" eigentlich für mich erledigt, da du alles, wie immer, super aufgeschlüsselt hattest.

[evaki]

Code Select Expand

Dann gehen die damit ermittelten Informationen aber für alle verloren
Dann eben Schalter, je nach Servereinstellungen dann off/on, also ohne die Datei editieren zu müssen. 
Ob der Anwender dann wirklich weiß was er da tut steht aber auf einem anderen Blatt.

Man könnte auch schauen, welche Systeme der Autor da im Auge hatte, wo Dateioperationen fehlerbehaftet sein können. Dann wäre es von den ermittelten Bedingungen abhängig.

Da wir aber jetzt mehr oder minder wissen "wat dat janze soll", kann man an diesem Punkt wie von Dir vorgeschlagen 'ne Abfrage machen, un jut ist.  Wenn den Anwendern bekannt ist oder gemacht wird, daß sich das Modul je nach Serverkonfig. u.U. fehlerhaft verhalten könnte, genügt so'n Beipackzettel.

Letztlich geht's darum den auftretenden Fehlern nachzuspüren, wie bei jedem anderen Modul auch, um dann zu entscheiden wie und ob gehandelt wird.  Also nicht den Boten töten, büdde.

MfG. Evaki

[Gast]

ich sehe schon, ich kann mir das Schreiben von Erklärungen wirklich sparen

Thu, 25 Apr 2019 05:59:01 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_044.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"

kein Fehler, sondern hier die Verwendung des Fehleroperators @ - Du bist mit deiner Fehlerausgabe im Developer-Mode.
Nicht jedes Bild nimmt alle EXIF-Daten mit, in den genannten Bildern fehlt der Wert für die Orientation, d.h. Hoch- oder Querformat. Die Bilder wurden (wahrscheinlich) gedreht, aber die Info darüber nicht ins Bild geschrieben. exif_read_data() gibt im Normalfall 20 Werte (Komponenten) zurück. Meine CANON schreibt all diese Werte, das Vorgängermodell hat da z.B. nicht die Gerätemarke eingetragen. Solche fehlenden Daten sind eingeplant und sollen unterdrückt werden. Im Production-Mode wirst du diese Fehler nicht bekommen.

@ hgs: Eine einfache Umstellung der PHP-Fehlerausgabe zum Production-Mode hätte hier 90% der Fehler eleminiert und eine Menge Trubel vermieden. Den Unterschied zum Developer-Mode solltest du als langjähriger Tester aber mittlerweile kennen.

Falls ja, könnte man das default setzen.

Dann gehen die damit ermittelten Informationen aber für alle verloren.....

Das @ ist immernoch ein ein erlaubter Operator in PHP zur Unterdrückung eingeplanter Messages bei fehlenden Informationen.
Die Meldung in der error-log ist mit eingeschaltetem Developer-Mode lediglich eine Information für Entwickler (engl: Developer), an welcher Stelle sich diese Fehlerunterdrückung befindet. Wenn ich etwas aus der Datenbank auslesen möchte, aber, warum auch immer, keine Ergebnisse bekomme, möchte ich gern wissen warum, darum wäre die Unterdrückung an solcher Stelle falsch, zumindest aus Sicht eines Developers.
Wenn aber bei der fileinfo von 20 Werten einer fehlt, weil die Kamera dies nicht überträgt, ist das kein Fehler des Moduls oder des CMS. Im speziellem Fall fehlte die sog Orientation. Das Bild wurde nachträglich gedreht, aber das Programm hat diese Info nicht in den EXIF-Daten angepasst

[evaki]

Hab' mal gerade - noch vor'n Wochenendeinkauf -in die class.upload.php reingeschaut, und zwar wegen der Fehlermeldung (bei einigen Systemen) Der Autor gibt hierzu hilfreiche Anweisungen.

Code Select Expand

$this->mime_fileinfo            = true;     // MIME detection with Fileinfo PECL extension
müßte danach nur auf "false" gesetzt werden.

Kannst ja mal schauen, ob dann die Dateioperationen auf Deinem System weiterhin sauber laufen.
Falls ja, könnte man das default setzen.
MfG. Evaki

[grindmobil]

Keine Panik, Evaki

Du hast mich nach dem Teil gefragt und du bekommst es auch.