WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: henri on December 22, 2018, 09:26:45 AM
-
Installation went without problems.
When testing module Responsive FolderGallery (RFG) 0.75 I get the following error message in WebsiteBaker 2.12.1 r188 when I go to the website itself from admin section.
There was an uncatched exception
Class 'Template' not found
in line (520) or (/ modules / responsiveFG / view.php):
-
Hi, maybe this helps: https://forum.WebsiteBaker.org/index.php/topic,31088.msg216743.html#msg216743
Before your line 520 in /modules/responsiveFG/view.php
if (!class_exists('Template')) {require(WB_PATH.'/include/phplib/template.inc');}
$template = new Template( $template_dir );
-
Hello dbs
This code was on line 520:
if (file_exists(dirname(__FILE__) . '/templates/thumbstyle' . $thumb_style . '.htt')) {
$viewTemplate = 'thumbstyle' . $thumb_style . '.htt';
$t = new Template(dirname(__FILE__) . '/templates', 'remove');
} else {
die();
}
I have inserted your proposed code for line 520:
if (file_exists(dirname(__FILE__) . '/templates/thumbstyle' . $thumb_style . '.htt')) {
$viewTemplate = 'thumbstyle' . $thumb_style . '.htt';
if (!class_exists('Template')) {require(WB_PATH.'/include/phplib/template.inc');}
$template = new Template( $template_dir );
$t = new Template(dirname(__FILE__) . '/templates', 'remove');
} else {
die();
}
Now I get error message:
Template Error: set_root: is not a directory.
Halted.
I do not know if I did well
-
Oh, sorry, "before" was not exatly before.
You can add the two lines somewhere at the beginning of view.php.
Hope it work.
-
Hello dbs
I place your code on line 2 after <? Php
then I get the same error message:
Template Error: set_root: is not a directory.
Halted.
I place your code for <? Php
then I get the following error message:
if (!class_exists('Template')) {require(WB_PATH.'/include/phplib/template.inc');} $template = new Template( $template_dir ); There was an uncatched exception
Class 'Template' not found
in line (522) of (/modules/responsiveFG/view.php):
-
After <?php is right because it is php code.
Seems something with your backend theme is wrong.
Can you tell some more details about your system? (wb version, php version, backend theme)
-
Hello dbs
WebsiteBaker Version: 2.12.1 -r188
PHP-Version: 7.2.11
Website Baker Default Theme version 1.3.14
-
Hello dbs
Responsive FolderGallery (RFG) 0.75 works fine in the following version
WebsiteBaker Version: 2.11.0 -r79
PHP-Version: 7.2.11
Website Baker Default Theme version 1.3.2
-
Next try. Remove the second line, use only the first.
if (!class_exists('Template')) {require(WB_PATH.'/include/phplib/template.inc');}
Maybe now a notice about fredit is in errorlog.
Solution: permissioncheck.php line 8 should looks like this
$fredit = isset($fredit) ? (int)@$aRequestVars['fredit'] : ''; // >0 = frontend edit
-
Hello dbs
Now this code is added to line 2 of view.php
if (!class_exists('Template')) {require(WB_PATH.'/include/phplib/template.inc');}
I get the same error message again:
Template Error: set_root: is not a directory.
Halted.
In admin WebsiteBaker Error log shows no errors
-
My test in WB 2.12.1 works.
In the info.php of the used frontend template i added this line to the others
$template_function = 'template';But after removing this line the module work like before. So i don't know if it helps.
you have 2.11? i will try that later.
-
Hello dbs
Get the same error message
-
This is version rFG 0.75.1. Tested in WB 2.11 & 2.12.1
with PHP 7.2 & 5.6. works.
If you have problems it seems not the FG is the problem.
Is it a new WB install?
I recommend taking the normal FG.
This rFG works strangely.
-
Hello dbs
Version rFG 0.75.1 works perfectly no error messages.
WB 2.12.1 is a completely new installation
I now have rFG, Foldergallery, Minigallery and Another Image Gallery in WB 2.12.1 and they all work fine.
Thank you for the assistance.
-
Arbeitet wer mit der v0.75.1?
Angetestet
PHP-Version: 7.2.0
WebsiteBaker-Version: 2.12.1 -r188
Installation: OK
BE
Responsive Gallery (rFG)
Section > Responsive Gallery (rFG) > Optionen/Tools:
Allgemeine Einstellungen > Stammverzeichnis: anderes auswählen, speichern
(Einmal im FE aufgerufen)
ERGIBT für jedes einzelne Bild
WebsiteBaker Error log
"created: [Tue, 16 Apr 2019 14:26:25 +0000]
Tue, 16 Apr 2019 14:44:39 +0000 [E_WARNING] \modules\responsiveFG\class\class.upload.php:[2372] from \modules\responsiveFG\class\class.upload.php:[2011] upload->upload "finfo_open(S:\extras\magic): failed to open stream: No such file or directory"
Tue, 16 Apr 2019 14:44:39 +0000 [E_WARNING] \modules\responsiveFG\class\class.upload.php:[2372] from \modules\responsiveFG\class\class.upload.php:[2011] upload->upload "finfo_open(S:\extras\magic): failed to open stream: No such file or directory"
Tue, 16 Apr 2019 14:44:39 +0000 [E_WARNING] \modules\responsiveFG\class\class.upload.php:[2372] from \modules\responsiveFG\class\class.upload.php:[2011] upload->upload "finfo_open(): Failed to load magic database at 'S:\extras\magic'."Bei 'S:\extras\magic' handelt es sich um den absoluten Pfad des Systems - kein html root oder so...
Section > Responsive Gallery (rFG) > Kategorie Titel:
Kategoriedetails bearbeiten
Hier erscheint ein neues Fenster BE mit "Titel/Beschr.HochladenHinzuf.Einstellungen", aber nur ein kleiner Ausschnitt - läßt sich im Browser als TAB/Fenster separat neu öffnen (wenn man's weiß).
Über "submit" (bei "Einstellungen" gibt es dann eine Zeile zu sehen
roundedcircleshadow opaqueblurblur-revgrayscalesaturatesepianocaptionsmyclass1myclass2
Ob nun alles unter "Titel/Beschr.HochladenHinzuf.Einstellungen" - was man u.U. nicht sofort als Auswahlmöglichkeit erkennt - ein bisschen eng sieht's außerdem aus (Ansichtsache) - , funktioniert, habe ich nicht geprüft.
MfG. Evaki
-
Ich hab mir das gerade angesehen - Danke für den Hinweis!!
Es gibt noch etliche weitere Probleme..
Die Darstellung im Frontend sollte SO aussehen (für Admins):
(https://WebsiteBaker.at/media/bilder/rfg-soll.jpg)
Das funktioniert, wenn ich in permissioncheck.php nach Zeile 8 den Parameter fredit noch mal auf "Old Style" abfrage:
if (isset($_REQUEST['fredit'])) {$fredit = (int) $_REQUEST['fredit'];}
Weitere Probleme, schnell gesehen: das Beschneiden der Bilder funktioniert nicht (gleiche Fehlermeldung wie vorher in view.php, also das mit "template". In der Auflistung im Backend stimmt auch was nicht, das ist aber eine Kleinigkeit.
Ein bekannter Bug ist, dass es im Frontend Fehlermeldungen hagelt, wenn ein Nutzer angemeldet ist, aber GAR keine Berechtigungen hat, also nicht mal "pages".
-
Hochladen, Sortieren, Löschen, Benennen.. funktioniert. Auch die Effekt-Klassen (die machen natürlich nicht immer Sinn)
Thumb beschneiden liefert den Fehler:
There was an uncatched exception
Class 'Template' not found
in line (122) of (/modules/responsiveFG/admin/modify_thumb.php):
-
In meinem Anwenderkreis hatte bisher (all die Jahre) niemand FG oder rFG genutzt.
Nun wurde aber eine Site auf mobile und responsive getrimmt, wobei im Gegensatz zu früher, auch eine größere Bildübersicht inkl Unterschriften gewünscht war. Das klappt zwar konventionell inkl. Schnickschnack, aber bedeutet auch wie bekannt mehr Arbeitsaufwand. So kam man zum Kind, was sich leider noch widerspenstig zeigt.
Dank schon mal für den kleinen Einblick "so sollte es aussehen bzw. funktionieren"
MfG. Evaki
Nachtrag: Ich vermute, daß die DEV - wenn nicht auch andere - Dir behilflich sein können/werden bzgl. der geänderten Interna.
Sonst holst Du Dir möglicherweise Pickel :-D :-D :-D
-
Anbei die Version, die jetzt auf WB at läuft.
Auch das Beschneiden funktioniert jetzt (im Frontend)
Wo ich noch Probleme gesehen habe: Das Anlegen von Verzeichnissen im Frontend und das rein/raus-Schieben von Bildern in diese.
Es funktioniert "prinzipiell", wirkt aber irritierend.
Das das alles etwas ungewohnt aussieht, liegt schlichtweg daran, dass die rFG nicht nur in der Darstellung der Bilder responsiv ist, sondern AUCH in der Verwaltung. Du kannst also auch mit dem Handy Fotos machen und gleich hochladen.
Was leider nicht am Handy funktioniert: Alles Drag&Drop (Sortieren und Beschneiden)
Das würde prinzipiell funktionieren, aber es ist verdammt gefährlich. Man schiebt sich sehr schnell was versehentlich herum.
-
Das werde ich mir morgen mal anschauen, wahrscheinlich nicht nur ich 8-) -hoffentlich...
Mein Zettel für diese Woche ist reichlich lang geworden, bis Wochenende muß das weg. Sonst gibt's keine Ostereier. Schönen Abend noch.
MfG. Evaki
ps. "Man schiebt sich sehr schnell was versehentlich herum."
Ich seh' die Mehrheit der Frauen immer höllisch schnell schnippsen, da geh'n mir die Augen über. Werden wohl eher die Männers von betroffen sein
-
Habe doch schon mal reingeschaut. Ja, nun sieht man schön, schick und mehr :-D
Doch werden bei Anklicken nun die Direktlinks auf die Bilder gesetzt, sprich man sieht kein pop/modal mit Pfeilen links/rechts, sondern nur noch das einzelne Bild in den originalen Abmessungen. Anscheinend hapert's da mit Javascript.
Die Fehlermeldung mit ..."upload->upload "finfo_open(S:\extras\magic): failed to open stream..." besteht noch. Aber das Modul braucht jetzt nicht unbedingt 'nen Schnellschuß. Für mich persönlich ist es eine wirklich gelungene Überraschung (Faust auf's Auge und so...). Das darf ruhig solide daherkommen :roll:
MfG. Evaki
-
Hausgemacht, mein Fehler.
Hatte das falsche Template geladen, jetzt funktioniert auch wieder Javascript.
Flip, flip, flip.... Sieht auch responsiv gut aus (Y)
Die Seitenangabe PAGE - (Kategorie/Titel)habe ich beim verwendeten WB-Template nun zweimal dreimal vor der Nase. Wo kann ich die im rFG-Module abstellen/deaktivieren?
MfG. Evaki
-
Die Fehlermeldung mit ..."upload->upload "finfo_open(S:\extras\magic): failed to open stream..." scheint aus modules\responsiveFG\Class\class.upload.php zu kommen. Wobei "S:\*.*" in diesem
Falle unter Win der absolute Pfad ist.
Frage stellt sich also nicht nur nach dem Pfad, sondern auch danach wofür diese Verzeichnisse angelegt/gebraucht sind/werden/wurden.
MfG. Evaki
-
Scheint wohl mit PECL extension für PHP verknüpft zu sein.
Was hat's gemacht, braucht's das heute noch?
In Php7.x sehe ich nichts entsprechendes. Aber da sind wohl die Programmierer gefragt.
MfG. Evaki
-
So, nun erstmal die vorläufig letzte Meldung dazu - vor Ostern -, sonst bekomme ich hier Ärger .
Mit dem Aufruf im Frontend, also wenn "fg-thumbs" inkl. Dir. erzeugt werden, wird die Fehlermeldung ausgegeben.
Dann mal fröhliches Basteln ::Ei, Ei, Osterei::
MfG. Evaki
ps. Für class.upload.php gibt's ein Update!
-
Ich hab das Teil gerade am Arbeitstisch liegen, Leimflasche und Tapezierermesser griffbereit.
ich schau mir das an, demnächst gibt es wohl ein Update.
-
Sodanna, ich habe meine Feiertage sinnvoll verbracht und statt Eiern Fehler gesucht.
Anbei die rFG 0.77 getestet auf WebsiteBaker.at
Sollte funktionieren (sogar wenn auf der selben Seite schon eine Foldergallery läuft, die muss aber nachher sein)
-
Kann erst frühestens morgen.
Hab' erstmal Bockmist an anderer Stelle (Forum) korrigieren müssen.
Bin aber schon jetzt gespannt :-)
MfG. Evaki
-
Gerade kurz angetestet mit einer WB 2.12.2 rev. 337
Wirft eine Sicherheitsverletzu ng "Zugriff wurde verweigert!" Meldung im BE wenn ich CSS bearbeiten will.
Im ErrorLog steht leider nichts, um den Fehler einzukreisen.
Die Hilfe weißt auf WBCE.org, dort gibt es aber nur die Version 0.75 oder auf wbce.at, da ist es die Version 0.74
Wird bestimmt noch korregiert :-)
Bilder im FE hochladen geht ohne Probleme.
Soweit der "kurzTest"
-
Ja, bitte schau mal durch ob alles wunschgemäß läuft.
Die Neuerungen sind eher "hintergründig":
- Läuft auch auf WebsiteBaker
- Volle Unterstützung für Touch-Devices - auch Drag&Drop
- Läuft parallel zur Foldergallery, auch wenn diese auf der gleichen Seite ist. Vorher gabs da Fatal Errors.
Der 3. Punkt mag seltsam erscheinen, da gehts darum, dass viele Funktionen sehr generische Namen hatten, die gleichen wie die FG. Da steht jetzt überall ein Präfix davor, um jede Art von Kollisionen zu verhindern.
CSS bearbeiten (Fehler): Da wird wohl ein nicht UTF-8 Zeichen drin sein, da kann der AFE-Editor nicht damit.
Aber: Da drin hast du ohnehin nichts verloren. Viel zu komplex und bei jedem Upgrade wieder überschrieben.
Mache Anpassungen in deiner template CSS, indem du dort die Anweisungen neu = anders definierst. dann bleiben sie dir erhalten.
Oder eine eigene module.css für alle Anpassungen, die so kommen.
Ich hab mir die Tage die Foldergallery (hier aus dem AOR) installiert und angesehen. Abgesehen davon, dass die ohne Reparatur nicht läuft, gibt es nur wenig, was die kann, was die rFG nicht kann: Der multiple Upload "im Gänsemarsch" - also jeweils einzelne Übertragung - und eben mehr Fokus auf die Lightboxes, also mehr davon.
Ein verbesserter multipler Upload kommt mit Version 0.6 - also das nächste ToDo.
Die überschaubare Anzahl an Lightboxes: Da setzt die rFG voll auf responsive, und da gibt es eh nichts besseres als Photoswipe.
-
Ahja: Hilfe:
https://wbce.at/de/module/responsive-gallery-rfg.php
Drag&Drop am Handy (funktioniert am PC genauso, nur weniger frickelig ;-)
https://www.youtube.com/watch?v=fB37ho1z2xc
-
moin.
Erstmal Installationsversuc h mit irgendwelchen vorhandenen Resten aus der letzten Testversion 0.75.2 oder so...
Error:
There was an uncatched exception
Call to a member function fetchRow() on null
in line (11) of (\modules\responsiveFG\upgrade.php):
Mal alles aus DB und Verzeichnis gelöscht und - Neuinstallation: OK
Aufruf von Kategorie- und Bilddetails bearbeiten > Bilder bearbeiten: | Bilder sortieren "SPEICHERN", also ohne irgendwelche Bilder
WebsiteBaker Error log
"created: [Wed, 24 Apr 2019 08:17:12 +0000]
Wed, 24 Apr 2019 08:34:05 +0000 [E_NOTICE] \modules\responsiveFG\admin\save_files.php:[56] from \modules\responsiveFG\admin\save_files.php:[56] bin\Exceptions\ErrorHandler::handler "Undefined index: caption"
Wed, 24 Apr 2019 08:34:05 +0000 [E_WARNING] \modules\responsiveFG\admin\save_files.php:[56] from \modules\responsiveFG\admin\save_files.php:[56] bin\Exceptions\ErrorHandler::handler "Invalid argument supplied for foreach(
Weiteres habe ich noch nicht angetastet. Meist gucke ich erstmal nach was, also drück und klick, wenn noch nix los ist. :-D
MfG. Evaki
-
Drag&Drop am Handy (funktioniert am PC genauso, nur weniger frickelig (https://forum.WebsiteBaker.org/Smileys/default/wink.gif)
https://www.youtube.com/watch?v=fB37ho1z2xc (https://www.youtube.com/watch?v=fB37ho1z2xc)
Miese Qualität? Miese Vorbereitung! Akku schwach ;D
Aber tolle Features zu sehen. Ja, Drag&Drop mobil ist frickelig. Welches Script nutzt du dafür? Bei OFA verwende ich testweise DragDropTouch.js.
-
Ich hab mir die Tage die Foldergallery (hier aus dem AOR) installiert und angesehen. Abgesehen davon, dass die ohne Reparatur nicht läuft, gibt es nur wenig, was die kann, was die rFG nicht kann: Der multiple Upload "im Gänsemarsch" - also jeweils einzelne Übertragung - und eben mehr Fokus auf die Lightboxes, also mehr davon.
Was läuft da nicht, habe die FG mit über 3000 Bilder ohne Probleme am laufen.
CSS bearbeiten (Fehler): Da wird wohl ein nicht UTF-8 Zeichen drin sein, da kann der AFE-Editor nicht damit.
Aber: Da drin hast du ohnehin nichts verloren. Viel zu komplex und bei jedem Upgrade wieder überschrieben.
Mache Anpassungen in deiner template CSS, indem du dort die Anweisungen neu = anders definierst. dann bleiben sie dir erhalten.
Oder eine eigene module.css für alle Anpassungen, die so kommen.
Ich meine WB ab 2.12.x unterstütz der Core eine frontendUser.css, damit kann ein Modulupdate nie mehr meine eigene, angepasstes css überschreiben, wenn ich diese nutze, und ich ändere immer was am Aussehen der Module. Aber wenn ich nicht über den Button im BE dran komme, wird das schwer.
Ob der AFE da "schuld" ist weiß ich nicht, die Fehlermeldung kommt im BE wenn ich auf den Button CSS klicke.
-
Ob der AFE da "schuld" ist weiß ich nicht, die Fehlermeldung kommt im BE wenn ich auf den Button CSS klicke.
da fehlt eine FTAN - ist halt ein Nebeneffekt, wenn Systeme auseinandergehen
frontendUser.css
wenn ich nichts übersehen habe, kannst du diese Datei in keinem Modul mit der althergebrachten Methode editieren. Der Link ist überall hardcodet drin. Dabei wird neben dem üblichem Kram wie section_id, page_id, FTAN auch der Dateiname übergeben und da waren früher zwei Dateien erlaubt (frontend.css + backend.css) und heute sind es 4 Dateien (die zwei genannten plus frontendUser.css + backendUser.css)
-
Beides ist hoffendlich ohne große Anstrengung in das Modul einzubauen, es gibt m.E. nur Vorteile
edit: Vollzitat entfernt (by dbs)
-
@evaki
\modules\responsiveFG\upgrade.php Fehler:
Ich kann da nichts erkennen, was irgendwie seltsam oder ungewöhnlich ist. Aber so "Spezialbedingungen" wie kein Bild oder nie was gespeichert können ein Modul schon mal überfordern.. ich behalte das im Auge..
Aber generell: In der Datenbank gibt es ohnehin keine Änderungen mehr, man kann das Ding auch einfach per FTP hochladen.
@hgs
>>"Was läuft da nicht, habe die FG mit über 3000 Bilder ohne Probleme am laufen."
War vielleicht, weil die Fehlermeldungen auf "Entwicklermodus" sind, und da ist es ja ziemlich streng.
Ich hänge di view.php an, die auf WebsiteBaker.at läuft
@all
Generell ist die rFG ein WBCE-Modul, aber wenns leicht geht, sorge ich gerne dafür, dass es auch mit WebsiteBaker läuft.
Ich will mich aber nicht näher mit den WB-Feinheiten befassen. Fertiges, funktionierendes Schnippel - ich hänge es rein.
Zum CSS:
Ich kann mir nicht vorstellen, dass es ein Script gibt, dass neues CSS mit älterem, geänderten CSS erfolgreich vermischt.
Die Änderungen sind sowieso von der Art "bunte Rahmen, größere Schrift" - die gehören eigentlich zum Template dazu, und das wird man ja nicht so schnell mal wechseln.
Es gibt auch keinen guten Grund, warum man Änderungen ausgerechnet in der frontend.css eines Moduls machen soll. Was hat das für Vorteile? Ich sehe keinen.
Upload per Ajax
Hab ich heute eingebaut, muss aber noch ein wenig getestet werden...
Versions-WirrWarr - jepp: Damit ich es mir endlich merke: Die aktuelle Version ist 0.77, die mit Ajax-Upload wird dann 0.78 und wenn ich mich wieder mal nicht mehr auskenne, mach ich einfach 0.8 draus ;-)
-
Vielleicht hängt sich ja noch jemand rein, so daß es ohne Fehler(meldungen) in WB klappt.
Die Features scheinen ja anzukommen (Y)
MfG. Evaki
-
Ich hab gerade ein Upgrade getestet, lief fehlerfrei ab.
Aktuelle Version mit AJAX Uploader:
https://wbce.at/downloads/responsiveFG-0.78.zip
-
Moin Chio
Vielen Dank für deine Bemühungen das Modul ans laufen zu bekommen.
Ich habe noch mal einen Test gemacht und die aktuelle Version als Unterseiter meiner 3000 Bilder FG Seite mit den gleichen Daten angelegt.
Als DAU-Tester ist der ErrorLog natürlich immer auf Developer geschaltet um die vorhandenen Fehler zu sehen.
Der Anspruch von WebsiteBaker ist es ein leeres ErrorLog zu haben, das gleiche gilt auch für Module, die wir im addon anbieten.
Deshalb teste ich auch immer mit der höchsten Version von php, die mein Hoster zur Verfügung stellt.
Beim anlegen und syncronisieren wird der ErrorLog mit nachfolgenden Meldungen vollgeschrieben.
Da das DAU bei mir wörtlich zu nehmen ist, kann ich die Meldungen nur posten, diese aber nicht deuten.
Was mich ein wenig überrascht hat, sind Meldungen, wo der absolute Pfad seht, dass sollte anno 2019 der Vergangenheit angehören.
Hier also die gekürzten Meldungen für die Dev´s
Bei der FG bleibt der ErrorLog leer.
"created: [Wed, 10 Apr 2019 14:17:04 +0000]
Thu, 25 Apr 2019 05:55:45 +0000 [E_NOTICE] /modules/responsiveFG/admin/save_files.php:[56] from /modules/responsiveFG/admin/save_files.php:[56] bin\Exceptions\ErrorHandler::handler "Undefined index: caption"
Thu, 25 Apr 2019 05:55:45 +0000 [E_WARNING] /modules/responsiveFG/admin/save_files.php:[56] from /modules/responsiveFG/admin/save_files.php:[56] bin\Exceptions\ErrorHandler::handler "Invalid argument supplied for foreach()"
Thu, 25 Apr 2019 05:57:52 +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-"
Thu, 25 Apr 2019 05:57:52 +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-"
Thu, 25 Apr 2019 05:57:52 +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-"
......
Thu, 25 Apr 2019 05:57:52 +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-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[225] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
.......
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[227] rFG_syncDB "Undefined index: /2014/2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[227] rFG_syncDB "Undefined index: /2014/2017/2017.11.05 Musical -Martin Luther-"
Thu, 25 Apr 2019 05:57:52 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/save_settings.php:[227] rFG_syncDB "Undefined index: /2014/2017/2017.11.05 Musical -Martin Luther-"
.......
Thu, 25 Apr 2019 05:57:55 +0000 [E_NOTICE] /modules/responsiveFG/admin/scripts/backend.functions.php:[329] from /modules/responsiveFG/admin/sync.php:[49] rFG_syncDB "Undefined index: /2017/2017.11.05 Musical -Martin Luther-"
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)"
Thu, 25 Apr 2019 06:00:01 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(IMG_20160703_111521.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:00:36 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_036.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:01:00 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_032.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:01:09 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_049.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:01:21 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Thu, 25 Apr 2019 06:01:21 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/xxx/xxxxx/xxxxxxx/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"
Thu, 25 Apr 2019 06:01:46 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Thu, 25 Apr 2019 06:01:46 +0000 [E_WARNING] /modules/responsiveFG/scripts/functions.php:[650] from /modules/responsiveFG/view.php:[685] rFG_get_thumb_data "getimagesize(/xxx/xxxxx/xxxxxxx/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"
Thu, 25 Apr 2019 06:01:48 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_037.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:01:49 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_034.jpg): Process tag(x010D=DocumentNam): Illegal components(0)"
Thu, 25 Apr 2019 06:02:25 +0000 [E_WARNING] /modules/responsiveFG/class/class.upload.php:[3322] from /modules/responsiveFG/scripts/functions.php:[539] upload->process "exif_read_data(Erntedank2015_049.jpg): Process tag(x010D=DocumentNam): Illegal components(0)""
-
Naja - bei 3000 Bildern sind das eh wenig Fehler ;-)
Im wesentlichen dürften das 3 Arten Probleme sein:
1) Die Exif-Daten einiger Bilder sind nicht "sauber", da beschwert sich die Class Upload darüber.
2) Die FG (und auch die rFG) sind bekannt dafür, dass beim Sync manchmal "Leichen" entstehen, mitunter doppelte Kategorien. Ich und viele andere haben den Fehler gesucht, aber nie wirklich gefunden, deswegen habe ich ein "Korrektur-Script" eingefügt, das diese Fehler recht gut bereinigt. Zumindest ist mir seither nichts mehr aufgefallen.
Nun kommt es vor, dass beim Sync ebendiese Fehler entstehen und sich als "Undefined index" niederschlagen, unmittelbar danach werden sie korrigiert.
Zumindest nehme ich das mal so an.
3) Einige Bilder scheinen für den Zugriff gesperrt zu sein. Das kommt immer wieder mal vor.
-
Bin noch nicht dazu gekommen, mir die letzte anzuschauen, aaaaaber....
die Sache mit dem absoluten Pfad hatte ich hier
https://forum.WebsiteBaker.org/index.php/topic,31261.msg219687.html#msg219687angesprochen.
Class Upload ist die Ursache (auch in der neuesten Version). Die müßte für ein CMS angepaßt werden. Ob für die Klasse eine bestimmte php-Umgebung (PECL) vonnöten ist - also für im CMS benötigte????? Funktionen - kann man ja prüfen.
Mein Eindruck "nö, braucht's nicht, scheint ja alles zu funktionieren" (Y)
Ist schon Klasse, daß Du Dir so viel Mühe gibst.
Bringt außerdem wieder soviel Wissen um WB auf den aktuellen Stand, daß Du direkt noch'n paar von solche guten Ideen umsetzen kannst. :-D 8-)
MfG. Evaki - Der mit der Schleimspur.
-
gehen wir etwas mehr ins Detail.....
Was mich ein wenig überrascht hat, sind Meldungen, wo der absolute Pfad seht, dass sollte anno 2019 der Vergangenheit angehören.
Ist Sache des Servers, was er da schreibt. Weder das System, noch ein Modul habe da einen Einfluß, wenn man eine mögliche Fehlermeldung nicht explizit definiert. Die verwendete class.upload.php setzt ohne Prüfung voraus, das diese Extention an bestimmten Pfaden vorhanden ist. Und sie hat eben keine Alternativ-Schaltung, sollte die Extension eben nicht da sein.
Thu, 25 Apr 2019 05:55:45 +0000 [E_NOTICE] /modules/responsiveFG/admin/save_files.php:[56] from /modules/responsiveFG/admin/save_files.php:[56] bin\Exceptions\ErrorHandler::handler "Undefined index: caption"
hier wurde (wahrscheinlich) keine Beschreibung eingetragen und das Script setzt voraus, das diese eben vorhanden ist. Müßte man halt abfangen.
Nächste Meldung ist ein Folgefehler, da nun die fehlende Beschreibung in einer Schleife benutzt wird
Thu, 25 Apr 2019 05:57:52 +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-"
die Funktion wird zweimal durchlaufen. Da im ersten Durchlauf ein doppelter Eintrag gelöscht wird, ist er im zweiten Durchlauf natürlich nicht mehr vorhanden.
Das Problem der doppelten Ordner nach einem Sync ist zumindest in der WB-Version der FG schon seit zwei oder drei Jahren gelöst
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.j pg): 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.
Thu, 25 Apr 2019 06:01:21 +0000 [E_NOTICE] /modules/responsiveFG/scripts/functions.php:[631] from /modules/responsiveFG/view.php:[682] rFG_get_file_data "getimagesize(): Read error!"
Bild nicht mehr vorhanden oder kein Zugriff darauf. Ob das nun ein falscher Pfad ist oder der doch etwas ungewöhnliche Dateiname, läßt sich nicht sagen. Solch ein Dateiname wie dieser hier 2017.11.05 Musical -Martin Luther- ist auf jeden Fall etwas, das dir früher oder später unter verschiedenen Konfigurationen Probleme bereiten wird
Ob für die Klasse eine bestimmte php-Umgebung (PECL) vonnöten ist - also für im CMS benötigte????? Funktionen - kann man ja prüfen.
hat mit dem CMS wenig zu tun, ist eher eine Frage des Systems
-
Danke, jacobi22, für die Erhellung.
Das Problem der doppelten Ordner nach einem Sync ist zumindest in der WB-Version der FG schon seit zwei oder drei Jahren gelöst
Dann schau ich mal nach. Dieser Teil der (r)FG ist ja noch sehr ähnlich.
MfG. Evaki - Der mit der Schleimspur.
Weitere Features werden nicht mehr viele kommen.
Jetzt, wo auch AJAX-Upload drin ist, halte ich das Teil mal für ziemlich "fertig".
Was mir derzeit noch fehlt an der rFG ist ein Resize der Bilder schon VOR dem Upload. Das ist heute technisch möglich, per JS (Canvas), ich habs aber noch nicht behirnt. Und Drehung der Bilder, hat aber schon lange keiner mehr danach gefragt.
Ich muss zugeben, dass mir das Backend nicht recht am Herzen liegt; praktisch alle Fehler kommen auch daher. Ich schau mir das an.
Wer die FolderGallery gewohnt ist, sollte sich umstellen, weil in der rFG nahezu ALLES im Frontend gemacht wird. (Das einzige, was nur im Backend möglich ist, ist die alphabetische Sortierung der Bilder)
-
Danke, jacobi22, für die Erhellung.
Das Problem der doppelten Ordner nach einem Sync ist zumindest in der WB-Version der FG schon seit zwei oder drei Jahren gelöst
Dann schau ich mal nach. Dieser Teil der (r)FG ist ja noch sehr ähnlich.
MfG. Evaki - Der mit der Schleimspur.
Dem Dank schlie0ße ich mich gerne an (Y)
Was mir derzeit noch fehlt an der rFG ist ein Resize der Bilder schon VOR dem Upload. Das ist heute technisch möglich, per JS (Canvas), ich habs aber noch nicht behirnt.
Die überarbeitet FG für WebsiteBaker hat im BE dafür einen Schieberegler, der einmal eingestellt, schön seine Aufgabe erledigt. Der Upload geschieht dabei auch im BE vom Modul. Wie von jacobi22 geschrieben schon seit Jahren.
Deshalb ja auch meine Frage, was musste da angepasst werden? Es läuft auch mit der neusten Version 2.12.2 mit php7.3
Bin auf den test von Chio gespannt.
-
Die überarbeitet FG für WebsiteBaker hat im BE dafür einen Schieberegler, der einmal eingestellt, schön seine Aufgabe erledigt. Der Upload geschieht dabei auch im BE vom Modul. Wie von jacobi22 geschrieben schon seit Jahren.
Deshalb ja auch meine Frage, was musste da angepasst werden? Es läuft auch mit der neusten Version 2.12.2 mit php7.3
Bin auf den test von Chio gespannt.
Welchen Test meinst du?
Auf WebsiteBaker.at läuft WB 2.12.1, PHP 7.1
Das ist eine steinalte Site, wo ich eben immer wieder mal ein Upgrade gemacht habe.
Die Foldergallery 2.2.0 läuft, aber es fehlen die Beschriftungen in Common settings, das macht es etwas mühsam. Da scheint jquery-ui einen 404er zu liefern, Pfad: https://WebsiteBaker.at/modules/include/jquery/jquery-ui-min.js?_=1556192386048
Kann also leicht sein, dass ich irgendwelche Features nicht sehe.
Den Uploader habe ich gesehen, sehr modern. Aber ich will das besser integrieren - also überhaupt selbst schnitzen. Aber ich schaffe es nicht, mein JS Wissen ist noch zu mickirig.
Was mir an der FG generell nicht gefällt, sind die beschnittenen Thumbs in einheitlicher Größe, und eben dass sie von sich aus nicht responsiv ist (das ist heute ein MUSS).
Wers nicht kennt:
https://wbce.at/tpls/unterseiten/responsive-fg/mixedwidth.php?switch=lesefaken
https://wbce.at/tpls/unterseiten/responsive-fg/mixedheight.php?switch=lesefaken
Oder gleich so ;-)
http://beesign.com/webdesign/responsive.php?homepage=https://wbce.at/tpls/unterseiten/responsive-fg/mixedwidth.php
Die "alte" Darstellung gibt es natürlich ebenso noch.
Gut, das ist alles Geschmackssache.
-
Was mir an der FG generell nicht gefällt, ......, und eben dass sie von sich aus nicht responsiv ist (das ist heute ein MUSS).
Wie kommst du darauf dass die FG nicht responsiv ist?
Hier mal eine Liveseite mit angepasstem frontend.css.
https://zur-spielkiste.de/spielkiste/bilder/
Sehr schönes Template übrigens, Danke dafür :-)
-
Wie kommst du darauf dass die FG nicht responsiv ist?
Hier mal eine Liveseite mit angepasstem frontend.css.
Naja - das ist nicht wirklich responsive. Die Thumbs "purzeln" eben untereinander, weil sie klein sind. Wenn sie größer wären als der Bildschirm breit ist, stehen sie rechts raus.
Unter "responsive" verstehe ich schon, dass sich die Darstellung anpasst. Nicht nur altmodisch "fluid"
Hier werden die Thumbs auch tatsächlich kleiner:
https://wbce.at/tpls/unterseiten/responsive-fg/standard.php
Die andere 2 Darstellungen verhalten sich ähnlich, je nachdem, wie groß sie eingestellt sind.
Und die Zoom-Ansicht verhält sich wie eine Gallery-App am Handy: Reinklicken, herumschieben.
Der Grund, warum ich alle Bearbeitung ins Frontend verlegt habe: Die Frontend-Templates sind meist responsive, die Verwaltung kaum mal, zumindest macht das keinen Spaß.
Da man die Fotos meist am Handy macht, ist es naheliegend, die auch gleich da hochzuladen. Natürlich: Frickelig mit einem kleinen Smartphone, aber ein "Phablet" macht das schon ganz gut.
-
Ok, jetzt habe ich verstanden, was du unter responsiv verstehst.
Ich bin mit der FG, so wie sie arbeitet sehr zufrieden, die Großen Bilder verhalten sich genau so, wie du es für die Vorschaubilder gelöst hast.
Ein vergrößern über den Bildschirm hinaus würde ich da gar nicht wollen.
Aber das sind Geschmaksfragen, die jeder mit css nach Geschmack lösen kann.
-
Naja - das ist nicht wirklich responsive. Die Thumbs "purzeln" eben untereinander, weil sie klein sind. Wenn sie größer wären als der Bildschirm breit ist, stehen sie rechts raus.
Unter "responsive" verstehe ich schon, dass sich die Darstellung anpasst. Nicht nur altmodisch "fluid"
das ist doch aber eine Frage von CSS und verwendetem FG-Template. Die "WB-FG" gibt in den mitgelieferten Templates style-Anweisungen für die Images mit. Mit dabei ist die Thumbbreite als Pixelwert und damit eine fest definierte Breite. Entferne ich diesen festen Wert oder ersetze ihn mit %, stehen mir doch alle weiteren Optionen offen, Stichwort: 2-3 CSS-Anweisungen, ggf noch ein paar media-queries
Ein Beispiel von meiner Seite (https://i.gyazo.com/b0447e928cb2717d2e778dc2f9b5c367.mp4), nur mal schnell mit Gyazo-Gif erstellt, darum in schlechter Qualität, aber der responsive Effekt, der gemeint ist, ist da schon erkennbar
-
Na, einigen wir uns einfach drauf:
Die responsive FolderGallery ist NOCH responsiverer als die FolderGallery, weil sie ja schon so heißt.
;-)
-
Nun wollen wir die Rfg ja bestimmt nicht zerrreden.
Der entscheidende Vorteil für nicht wenige meiner Anwender ist tatsächlich die Bearbeitung ins Frontend verlegt zu haben. Wenn auf diese Art noch andere Funktionen (Modulfunktionen) ermöglicht werden können, sehe ich da ein sehr großes Potential. Da könnte z.B. jeder Autor/Reporter seinen Bereich füllen/updaten usw. Das BE ist ja nun wirklich nicht dafür geeignet.
MfG. Evaki
-
Jepp, eine kleinen Fehler hab ich noch gefunden (unnötige Script-Mehrarbeit beim multiplen Upload)
Wird beim nächsten Mal korrigiert, ist nicht so schlimm, wenn man nicht gerade 100 Dateien auf einmal hochlädt.
Ansonsten:
Ich sehe keine Fehler im php_error.log
Die riesige Liste von Harald unten kann ich nicht nachvollziehen.
-
Ahja, die Berechtigungen...
Ich weiß, das kommt manchem etwas spooky vor (Uh - im Frontend!!), ist aber halb so schlimm.
Nötig ist Pages / pages_modify und natürlich das Modul selbst.
1) Zum Frontend (view.php) gehören nur die Schalter, um die Eingabemasken zu öffnen. Das beruht auf den selben Berechtigungen, ist aber einfacher gelöst. Man will ja nicht bei jedem Seitenaufruf die ganze Maschinerie starten, nur um ein paar Links darzustellen.
2) Ob und was bei Klick auf ein Bearbeiten-Symbol passiert, ist Sache des Backends. Die grauen Overlays sind nichts anderes als das normale Backend; nur ohne das übliche Template. Eine Standard-Funktion.
-
Auch wenn ich mit "Haus und Hof" am Wochenende beschäftigt bin, werde ich Zeit für's Testen haben. Dann auch'n bisschen mehr, als nur mal Klick und Drück".
Warte zuvor aber trotzdem mal ab, was die anderen noch zu berichten haben.
MfG. Evaki
ps. bei gelegenheit will ich mir sowas mal für eine andere funktion(Modul) antun. wie sieht das abseits der gewünschten modulfunktion(en) aus, also damit überhaupt ein FE-Modus in dieser art möglich ist? Habe mich bis dato nicht damit beschäftigt. was ist grundsätzlich vonnöten - es reicht schon mal ein tip wo ich bei der rfg reinschauen und achten sollte. bzw. die dafür wichtigsten und notwendigen dateien zu benennen.
Forum: :?, erst antwort, dann frage - reihenfolge irgendwie durcheinander? Oder schlägt mal wieder meine Müdigkeit durch?
-
Die riesige Liste von Harald unten kann ich nicht nachvollziehen.
Ich auch nicht, aber vielleicht zur Erklärung was ich gemacht habe:
Modul installiert
Unterseite im BE von der FG als rFG angelegt
Im BE den Startpunkt der Gallery so festgelegt wie sie im Original FG vergeben ist.
Aufbau unter /Media ist
/Bilder/Jahr/Monat/viele Bilder
also ab 2004 bis 2018 und dann je Monat die einzel Bilder
Dann im BE auf syncronisieren DB und das wars.
Danach waren die Fehler im Errorlog zu sehen.
-
Naja, es entsteht hier der Eindruck, die rFG lässt sich zuerst gar nicht installieren und dann strotzt das Teil vor Fehlern.
Ganz so ist das nicht.. ;-)
Ich habe gar keine Fehler, und das Teil schon 100e Mal installiert.
Möglicherweise sollte man es aber nicht mit WebsiteBaker verwenden, weil es irgendwann ohnehin nicht mehr unterstützt wird.
-
Naja, es entsteht hier der Eindruck, die rFG lässt sich zuerst gar nicht installieren und dann strotzt das Teil vor Fehlern.
Ganz so ist das nicht.. ;-)
Ich habe gar keine Fehler, und das Teil schon 100e Mal installiert.
Naja, ihr habt ja auch kein eigenes Error Handling. Was sagt denn die PHP Errorlog?
Möglicherweise sollte man es aber nicht mit WebsiteBaker verwenden, weil es irgendwann ohnehin nicht mehr unterstützt wird.
Wäre möglich :-P
Dietmar
-
Die Fehler kamen ja daher, dass unter den 3000 Bildern ein paar mit unerwarteten Eigenschaften (EXIF-Daten, Dateinamen) waren.
Einer, der direkt von der rFG kam, war eh nicht dabei. Dementsprechend sehe auch ich keine Fehler im Error-Log.
Letztlich ist es mir auch egal, ob zb. die EXIF-Daten sauber sind, solange es funktioniert. Da habe ich ohnehin keinen Einfluss drauf, ich kann ja die Kamera nicht wegschmeißen deswegen.
Aber wurscht.
Die Frage, ob man Module, die auch unter WBCE laufen, für WebsiteBaker verwenden sollte, hängt wohl davon ab, wie viel Arbeit eine Rekonstruktion mit einem Ersatzmodul machen würde. (Wenn es überhaupt eines gibt)
Im Falle FG / rFG hält sich der Aufwand in Grenzen, solange man nicht allzu viele Bilder beschriftet hat.
Beim Wechsel von FG auf rFG gibt es einen Trick, mit dem man die Captions wiederherstellen kann. Umgekehrt nicht.
Bei Topics oder sowas wäre es natürlich nahezu unmöglich, gleichwertigen Ersatz zu finden UND das auch noch zu übertragen.
Topics sollte man also eher nicht mehr verwenden. Zumindest nicht bei Neuinstallationen.
-
Habe ich nur den Eindruck, daß eine ungute Stimmung in der Luft hängt?
Der Dialog verläuft nach meinem Eindruck nicht gerade konstruktiv, ich persönlich würde mich "abgebügelt" fühlen. ( :? eine Mimose, das hat noch gefehlt)
Wenn das Teil ein klares Alleinstellungsmerk mal besitzt, sollte man es akzeptieren, daß es so ist.
(Andere Mütter haben eben auch schöne Töchter )
Sonst sieht man sich in solchen Fällen u.U. gezwungen, nur noch selbst Teile zu basteln, und die im eigenen Schrank aufzubewahren. Kennt man ja auch aus anderen Ecken, mit der Folge, daß dann nichts mehr zurück fließt (add-ons), oder nur noch als Dienstleistung. Wenn das die Richtung sein soll, habe ich kein Problem damit. Irgendwann schmeißt man dann eben hin, einfach weil man's leid ist, und gut ist's.
Aber vielleicht ist's nur meine Müdigkeit, die mir einen Streich spielt. Morgen ist auch wieder und noch'n Tag.
Egal wie's ausgeht, ich danke vorab schon mal für die vielfachen Erfahrungen, die ich mit WB machen durfte. Hab' 'ne Menge gelernt, sogar wenn ich keine Lust drauf hatte :-D :-D :-D
MfG. Evaki
-
Keine Panik, Evaki
Du hast mich nach dem Teil gefragt und du bekommst es auch. :-D
-
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.
$this->mime_fileinfo = true; // MIME detection with Fileinfo PECL extensionmüß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
-
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.j pg): 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
-
Dann gehen die damit ermittelten Informationen aber für alle verlorenDann 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
-
mea culpa :oops:
Nach deinen (jacobi22) Erklärungen war das Thema "voller ErrolLog" eigentlich für mich erledigt, da du alles, wie immer, super aufgeschlüsselt hattest.
-
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.
-
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.
-
ich sehe schon, ich kann mir das Schreiben von Erklärungen wirklich sparen
Den Guru kann ich auch 8-) - 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
-
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
-
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.
-
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 :lol:
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
-
Ich starte noch mal den gleichen Test mit den vorhandenen Bildern der FG
Bitte nicht schimpfen, wenn es Fehlermeldungen gibt :oops:
-
Ich starte noch mal den gleichen Test mit den vorhandenen Bildern der FG
Bitte nicht schimpfen, wenn es Fehlermeldungen gibt :oops:
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.j pg): 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.j pg): 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.j pg): 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.
-
Ausschlußkriterium für mich ist die fehlende MYSQL-Strict-Mode-Lauffähigkeit. Da wäre gut die Hälfte meiner Kundschaft betroffen
-
MYSQL-Strict-Mode-Lauffähigkeit.
Ha, darauf hab ich noch nicht, un so.
Erstmal dat:
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
-
Da wäre gut die Hälfte meiner Kundschaft betroffen
Die andere Hälfte dürfte er dann haben :-P
Also, alles mal der Reihe nach... - dann seh'n wir weiter.
Aber schön zu sehen, daß es im Forum auch lustig zugehen kann.
-
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.
-
Abseits vom Bildertest habe ich mal den wb-debug-modus eingeschaltet.
Bei der Synchronisierung mit der DB
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ü.
-
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.
-
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. :-D
MfG. Evaki
-
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.
-
Diese Fehlermeldung "Bei der Synchronisierung mit der DB......" darf man liegen lassen.
Scheint nur ein Laufzeitproblem gewesen zu sein (tritt hier manchmal auf: Lastproblem). :-D
Der Test mit den angemeckerten Dateien (bei hgs) steht noch aus, kommt aber bald.
MfG. 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.
-
Hab' den Ordner "Bilder" (testseite von hgs für evaki beim Hoster) eingebunden, und - bis auf CSS bearbeiten: Sicherheitsverletzu ng!! 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
-
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.
-
Mit MySQL Strikt hatten hier nicht wenige Probleme bekommen, weshalb WB daraufhin optimiert wurde. Eine andere Form der Installation hat für einige Module schon Einzug gehalten.
Schau mal bei Interesse in's Verzeichnis /modules/einmodulxyz, wo Du Dateien mit der Endung .sql (install-data.sql + install-struct.sql) finden kannst.
MfG. Evaki
ps. Mein Anwenderpool guckt mittlerweile sehr begeistert auf rFG, und freut sich auf den Einsatz.
Das Ding Wonderblog oder so ist nach ähnlichem Prinzip aufgebaut?
-
Vielleicht liegts am Strict...
Nach Installation von v0.79 sehe ich im Frontend einen langen Text, der nach Upload von Bildern verschwinden soll.
Es wurde gleich im Frontend ein extra Ordner angelegt und 3 Bilder reingeladen. Die erschienen im Frontend über dem langen Text.
Der Text bleibt im eingeloggten Zustand sichtbar. Hilft auch keine STRG+F5.
Klick auf den Stift eines der 3 Bilder zeigt ein Fenster mit Inhalt: no valid parameter
Schließen lässt es sich nicht.
Verschieben geht. Fehlermeldungen keine.
Funktioniert schon fast gut.
-
"Wunderblock" ist ganz was anderes.
Das ist eigentlich eine Art erweitertes WYSIWYG "mit was daneben". Und ein bissel Effekten. Narrensicher.
Das hier ist 2x Itemz und der Rest "Wunderblock":
http://www.noe-frauenlauf.at/
-
Vielleicht liegts am Strict...
Nach Installation von v0.79 sehe ich im Frontend einen langen Text, der nach Upload von Bildern verschwinden soll.
Der Text = Die ANleitung verschwindet ab glaube ich 3 oder 4 Bilder (insgesamt)
-
Vielleicht liegts am Strict...
Strict mache ich lokal nur "auf Wunsch" an. :roll:
Bei "hgs" (Test-Server) läuft's, bis auf CSS-Edit, bisher ohne weitere Fehler.
Er wird's wohl morgen mal "durchspielen".
Bei mir sind sie alle heiß drauf, so hab ich die noch nie erlebt.....
Ich vermute, daß Wunderblock bei denen auch ankommen wird.
Aber auch klar, die Nur-Schreiberlinge tun sich mit CMS schwer, egal wie einfach es uns erscheint, da hilft auch kein Akademikerstatus. Die können auch kein Windows, aber dafür Wörd. Weisse Bescheid?
-
Klick auf den Stift eines der 3 Bilder zeigt ein Fenster mit Inhalt: no valid parameter
Hat sich erledigt. Funktioniert. Da hat mein globaler Code zugeschlagen und eine eigene Colorbox drumrum gesetzt.
Mit dem 4. Bild war dann auch der lange Text weg.
-
BE
Bilder nach Dateiname sortiern
created: [Mon, 29 Apr 2019 17:53:22 +0000]
Mon, 29 Apr 2019 17:53:35 +0000 [E_NOTICE] \modules\responsiveFG\admin\scripts\quick_img_sort.php:[70] from \modules\responsiveFG\admin\scripts\quick_img_sort.php:[70] bin\Exceptions\ErrorHandler::handler "Undefined index: PAGES"
Mon, 29 Apr 2019 17:54:09 +0000 [E_NOTICE] \modules\responsiveFG\admin\scripts\quick_img_sort.php:[70] from \modules\responsiveFG\admin\scripts\quick_img_sort.php:[70] bin\Exceptions\ErrorHandler::handler "Undefined index: PAGES""
Hat jemand 'ne Lösung für das CSS-Edit-Problem?
-
Evaki:
Hat jemand 'ne Lösung für das CSS-Edit-Problem?
Wer 'nen Debugger laufen hat, kann das schnell lösen, wenn er die Lösung nicht schon vorher kennt.
MfG. Evaki
-
"Synchronisiere Dateisystem mit Datenbank..."
Die o.a. Fehlermeldung scheint doch nicht nur temporär aufzutauchen.
Kann sie aktuell immer wieder abrufen.
Kann wer ja mal verifizieren, damit ich hier entscheiden kann, ob eine komplett neue WB-Installation in der Testumgebung fällig ist.
MfG. Evaki
-
"Synchronisiere Dateisystem mit Datenbank..."
Keine Fehlermeldung.
Dafür, in meinem alten Firefox, haben die Fensterchen im Frontend alle eine vertikale Scrollbar (um 5px nach unten zu scrollen).
Im Chrome nicht.
-
Keine Fehlermeldung.
Ich ahne es schon - mal wieder neu.
<offtopic>Irgendwann werde ich 'nen Vollscan mit allen Injection machen, und dann die DB vergleichen.
Habe seit sehr langem den Verdacht, daß so'n Scan mir etwas in der DB ändert, OHNE daß der Scanner dies anzeigt, nach dem Motto; Kenn ich nicht, gibt es nicht (kommt mir bekannt vor :evil: ) </offtopic>
Wenn noch andere Fehlermeldungen bzgl. rFG bestätigt/nicht bestätigt werden, könnten wir zusammenfassen.
MfG. Evaki
ps.Der erste Schritt zum 1. Mai ist getan: Kaiserschmarrn mit Amaretto am späten Nachmittag - kommt gut. :-D
-
Vielleicht meldet sich ja mal einer der DEV.
Der Aufruf von "Edit CSS" crasht unabhängig von sontigen Scripts des Moduls. Liegt es da nicht nahe, daß der Aufruf selbst schon "verkehrt" ist bzw, anders erfolgen muß (für WB)?
MfG. Evaki
-
Wurde hier doch schon beantwortet waran das liegt.
https://forum.WebsiteBaker.org/index.php/topic,31261.msg219767.html#msg219767
-
Danke, war untergegangen.
Hatte nur FTAN gelesen bzw mich darauf alleine fixiert, und nicht mehr weiter geschaut, also zwar gelesen aber in der letzten Konsequenz nicht alles bei mir angekommen.
Bei der jetzt genaueren Betrachtung/Untersuchung fällt es natürlich auf, daß es systembedingt ist.
Vielleicht kommt da ja noch was in Sachen Anpassung. Beispiele aus anderen Modulen scheint's ja zu geben.
Zur Not geht das mit CSS auch noch "zu Fuß", falls sonst alles ohne Fehlermeldungen zu produzieren funktioniert.
MfG. Evaki
-
Jep, funktioniert in meiner Simulation.
Habe die parallel installierte FG aufgerufen, und mir die Werte aus name und value geholt und die dann in die rFG admin/templates/modify_settings.htt für den einmaligen Aufruf von "edit css" übertragen.
Hat sofort funktioniert 8-)
Das Umstricken überlasse ich aber lieber den Könnern, auch wenn ich soeben etwas dazugelernt habe - mal wieder ungewollt :-D
MfG. Evaki
-
Ein paar Zeilen hinzugefügt, einige deaktiviert, eine Datei umbenannt, und?
Jo, Edit CSS läuft, Backend und Frontend.
Was natürlich passiert, daß der Button nun aus dem WB-Backend gestaltet kommt, und kein eigens definierter mehr ist. Heißt, daß man "eigentlich" alles auf's BE einstellen sollte. Die rFG-Admin-Templates kann man dann rausschmeißen. Vermute, daß das für Module-Autoren eine Vereinfachung darstellt, wenn die einmal wissen, wie's geht.
So'n Schei..., das wollte ich eigentlich alles garnicht wissen :cry:
@grindmobil. Kannst ja mal Deine Mailadresse über PM dalassen, damit Du Dir das mal angucken kannst.
MfG. Evaki
-
Als Anlage die Änderungen inkl. Origin.
Wichtig: Es illustriert nur die Richtung, ist kein verbindlicher Patch oder sowas.
Einfach überschreiben und testen.
Für Helferlein und Grindmobil:
Standard ist soweit ich verstanden habe die Abfrage
if(function_exists('edit_module_css')){ edit_module_css($sAddonName);}Stattdessen habe ich einen Direkteintrag gemacht.
if(function_exists('edit_module_css')) { edit_module_css('responsiveFG');}
Wie auch immer, wollte nur ein wenig Vorarbeit leisten, damit Grindmobils Engagement nicht im Frust endet. Und wenn mir als Laie das schon gelingt, dem Thema etwas näher zu kommen...
MfG. Evaki
-
@grindmobil
Falls auch Deine kommende Version bis auf "edit css" im WB laufen sollte, wäre es ja nach den bisherigen Erfahrungen sinnvoll, die vorgenommenen Änderungen vom CMS (wb/wbce-Schalter) abhängig zu machen. Da man nun weiß wo's hakt, stellt es kein Problem mehr (auch nicht mehr für mich) dar. Das kann dann auch sonstwer für sich einbauen, ist also für Dich nicht zwingend.
Hatte mir eigentlich 'ne Info aus der Dev-Ecke gewünscht, so mit Nase auf "mach das weil sich das so oder so verhält". Da sich ja anscheinend niemand für die WB-Dokumentation findet, ist man als Möchtegern (im positiven Sinne) und zudem als Laie quasi darauf verpflichtet, den Kram um WB herum zu analysieren, um etwas von der Struktur und den Abläufen zu erfahren. Im Ernst - was für'n Schei... ?
Für einen Profi, bekomme ich aus meinem Hintergrund zu hören, ist das auch für Engagierte eine Zumutung. Ohne Dokumentation und Roadmap kann man genauso gut nach Malle fahren und am Tresen philosophieren, aber hat dort Spaß, weil zumindest der Kater vorherzusehen ist.
MfG. Evaki
-
Bei allem Jammern :cry: - u.a. wg. Süppchenkochereien - ist es aber sinnvoll, zwischendurch auch mal die Aktivitäten (https://project.WebsiteBaker.org/projects/wb-2-12/activity) anzuschauen, allein schon der Anerkennung wegen. So'n Paket muß man tragen können.
Solange kreative Ideen gemeinsam in WB UND WBCE z.B. als Modul Verwendung finden können, bleibt mein Anwenderkreis dabei, da beide CMS genutzt werden, und die verwendeten Module auf beiden Plattformen funktionieren müssen. Wird's aber zu bunt, Kindergarten und so, sind wir tatsächlich draußen. Anders gesagt, Differenzen auf Kosten der Anwender, und das auf Dauer, geht garnicht.
Mittlerweile stört aufgrund der gemachten Erfahrungen eine erneute Einarbeitung in ein CMS nicht mehr, anders also als vor Jahren.
MfG. Evaki
-
Im Anhang responsiveFG_0.79de v(wb),
Sie ist - noch - außschließlich für WB gedacht.
Diese Version enthält nur zwei Korrekturen in zwei unterschiedlichen Daten des Origin-Moduls für WBCE. Die Funktion "Edit CSS" funktioniert also im WB, mit dieser Korrektur aber nicht mehr in der WBCE-Version.
Zukünftig wird man zwischen PHP- und WB-Systemfehlern unterscheiden müssen.
Will man zwischen WB und WBCE selektieren (Autom. Schalter), kann man das über den Umbau der PHP-Scripte, realisieren, aber auch über JS-Abfragen.
Sinnvoll wäre da eine Anfrage an die DEV, damit Modulautoren wissen wo's lang geht, ihre Module auch strategisch (wg. Kompatibilität) anpassen können.
Unsere Gemeinschaft (meine Anwender) sieht im Vorstoß mit FE-Edition eine Möglichkeit barrierefreien Zugang zum BE zu bekommen, was zur Zeit mit dem aktuellen BE-Template (w3C) leider komplett auf's Gegenteil hinausläuft.
MfG. Evaki
ps. Um es nicht zu vergessen, diese Version ist, wie auch das Original, - noch - nicht an MySQL-strict angepaßt.
-
Hat jemand 'ne Erklärung dafür, daß ein "fehlerhafter" Aufruf wie bei "css edit" in WB keinen PHP-Error=Aufschrei auslöst? Es liegt ja nahe, daß dies in anderen Situationen auch vorkommt, und man dann der Dumme ist. Sollte ja irgendwie nicht sein, oder doch? :roll:
MfG. Evaki
ps.
Wie ist die WB-Debug-Funktion (define('DEBUG', true); + Option) einzusetzen?
Kommunikation mit was, wem, oder so...
Manchmal gibt sie ja anscheinend "was von sich", janz unjefragt - woher kommt's?
-
So, ich habe hier den Faden verloren...
Gibt es Fehler im Modul selbst?
Die Fehler, die die Class Upload bei manchen Bildern produziert, lassen sich leicht beheben, indem man die Class Upload aus der FolderGallery rein kopiert.
Sonst was?
Der Kram um edit.css interessiert mich wenig, weil im css der rFG ohnehin niemand was verloren hat. Die rFG ist kein Form-Modul, wo man schnell mal bunte Rähmchen macht, sondern ein ziemlich komplexes Teil.
Gewünschte Änderungen am CSS gehören gezielt überschreibend ins Template.css
-
Der Kram um edit.css interessiert mich wenig, weil im css der rFG ohnehin niemand was verloren hat.
Warum ist das Teil (Button) dann überhaupt drin? Außerdem war das schon immer eine freie Entscheidung des Anwenders - gleich in welchem Modul - dort für seine Zwecke Änderungen vornehmen zu können. Warum sollte er dafür extra im Template rummachen? Wenn er das kann, hat er auch die Kenntnisse für's direkte Schreiben. Das bräuchte man aber auch nicht, da die in WB vorhandene Möglichkeit eine zweite, parallele css anzulegen genutzt werden kann. Dafür könnte man wiederum den Button gerne wegschmeißen. :-D
Fehler, die die Class Upload bei manchen Bildern
Kann ich nichts zu sagen, aber der Betreff/Sonderfall PECL if (substr(PHP_OS, 0, 3) == 'WIN') wird dadurch nicht gelöst, reicht aber statt WIN dann WINdschief reinzuschreiben, und gut ist's.
Gibt es Fehler im Modul selbst?
Abgesehen von o.a. habe ich - bis auf die komische Melddung im WB-debug-Modus- keine festgestellt, wenn denn auch die Meldung (https://forum.WebsiteBaker.org/index.php/topic,31261.msg219854.html#msg219854) unter "Bilder nach Dateiname sortiern" beseitigt ist.
Wenn Du keine Lust mehr an der Anpassung für WB verspürst, aber das Modul korrekt unter'm Fork läuft, bekomme ich das ja (hatte ich tatsächlich ich nicht gedacht) anscheinend selbst hin. Tips wie "Class Upload aus der FolderGallery" sind dabei natürlich willkommen und hilfreich.
MfG. Evaki
-
Jo..
Warum der CSS-Edit Button noch drin ist... Weil ich vergessen habe, ihn auszubauen ;-)
Das mit dem alphabetisch Sortieren schau ich mir an.
Wenn Du keine Lust mehr an der Anpassung für WB verspürst,...
Es soll da wie dort laufen, wenns leicht geht. Ein Pseudo-Fork macht Verwirrung.
Wenn du "richtig" forken willst, solltest du das Modul umbenennen, das geht ganz einfach: Anderer Verzeichnisname, diesen in der info.php eintragen, zippen, installieren. Erzeugt eigene Tabellen.
Parallelbetrieb (auf der der gleichen Page) ist aber nicht möglich, weil die Funktionen gleich heißen.
-
Wenn du "richtig" forken willst, solltest du das Modul umbenennen
Genau das habe ich mir angesehen, weil schon mal bei einem unserer Anwender ein Modul derart geändert wurde. Aber auch, weil ich für wb-css-edit - wenn der Button raus soll, nicht mehr - dann die hardgecodete Verzeichnisbezeichn ung noch ändern müßte, weshalb das zur aktuellen wb-version auch angemerkt wurde - Hinterkopf un so... Naja, is ja sowieso noch dev.
Es soll da wie dort laufen, wenns leicht geht.
Wenn ich es sogar hinbekomme - nach Tagen 3 Zeilen, aua - wird's wohl irgendwie noch geh'n :roll:
MfG. Evaki