Test Responsive FolderGallery (RFG) 0.75

[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 

@grindmobil. Kannst ja mal Deine Mailadresse über PM dalassen, damit Du Dir das mal angucken kannst.
MfG. Evaki

[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

Code: [Select]

if(function_exists('edit_module_css')){ edit_module_css($sAddonName);}Stattdessen habe ich einen Direkteintrag gemacht.

Code: [Select]

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

[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

[evaki]

Bei allem Jammern  - u.a. wg. Süppchenkochereien - ist es aber sinnvoll, zwischendurch auch mal die Aktivitäten 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

[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.

[evaki]

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? 
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?

[grindmobil]

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

[evaki]

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. 

Fehler, die die Class Upload bei manchen Bildern

Kann ich nichts zu sagen, aber der Betreff/Sonderfall PECL

Code: [Select]

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 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

[grindmobil]

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.

[evaki]

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 
MfG. Evaki