WBCE CMS Forum

boeseroeser

Gast

Grundsätzliche Fragen zu znips

Zur Erinnerung: Warum überhaupt znips
Das, was ein Modul im Frontend machen soll, ist meist relativ einfach zu entwickeln und oft auch griffbereit im Web zu finden.
Die Mühe der Ebene ist aber das Backend, bzw: die Verwaltung.
Bei znips soll diese Ebene wegfallen und ein kleines Modul in wenigen Stunden gemacht sein. Das würde die Einstiegshürde stark herabsetzen und die Zahl der verfügbaren Module drastisch erhöhen.

Warum überhaupt der Name "znip_irgendwas"
Klar: damit diese Module am Ende der Auswahlliste beisammen stehen - und ein bisschen auch, weil sie die alten "Snippets" ablösen sollten. Ein  "znip_anyitems" ist viel handlicher als diese mühsamen Code-Snippets.

Das Problem:
Ganz ohne Einstellungen geht es nicht. Die Verwendung einer module_config.php ist eine Krücke mit vielen Nachteilen.
Andererseits: Wenn ich die narrensicheren EInstellmöglichkeiten mache, dann sind sie keine znips, sonder wieder volle Module.

Was kann man machen?
Die Einstellungen sollten in die Datenbank, aber möglichst einfach. Daher eine gemeinsame Tabelle für alle znips. Da jedes znip in der Regel nur einen Eintrag braucht, wird die DB nicht übergehen.

EIne Möglichkeit wäre, die module_config.php in die Datenbank zu schreiben - als php-code, wie die Module Code(2), und mit eval() auszulesen.
Eine andere Möglichkeit: als JSON codiertes Array in einer standardisierten Form.
Da beides in einem Text-Feld gespeichert werden kann, wären auch Mischformen möglich.

Damit nicht jedes znip eine eigene Verwaltung mitbringen muss, könnte man ein Admin-Tool "znip_Master" machen, in dem alle EInstellungen aller znips gemacht werden (müssen).
Praktisch würde das dann so aussehen: Das znip schreibt bei der Installation einen Eintrag in die DB, mit den Default-Werten.
Diese können dann über das Admintool ausgewählt und per Code-Ansicht editiert werden.
Das sollten nur Admins können; normaluser sollten da nicht rankommen, auch wenn sie Berechtigung für das jeweilige znip haben.
Denkfehler: Die Berechtungen wären ja für znip_master nötig, die kann man ja entsprechend setzen.

Strukur der znip-Master Tabelle:
id //BRauch ich eine ID? Naja, schadet nicht.
section_id //0 = allgemein gültig, Wert: nur für diese Section gültig.
znip_name //Klar: Der Name des znips, für das die einstellung gilt
Daten //Array oder PHP-Code.

Eventuell: what_is //php oder Array (oder sonstwas)? Wie soll Daten gehandhabt werden, wie gespeichert?

Eine weitere Möglichkeit, mit der ich lange schwanger war, aber nie gekreißt habe:
Ein znip-Master, das ähnlich wie globalupload gar nicht in erscheinung tritt, sondern sich nach einem Schema in ein znip einfügt, um dort die Verwaltung zu erledigen. Hat aber Nachteil: kann schnell ein Klotz am Bein werden, wenn sich Dinge anders entwickeln.

Jepp
Gibt es Dinge, die ich nicht bedacht habe? Mögliche Schwierigkeiten?

Beitrag geändert von boeseroeser (20.05.2019 19:10:31)

berny

Mitglied

Re: Grundsätzliche Fragen zu znips

was, wenn es ein Znip-master modul gibt, bei dem die Einträge der entsprechenden znip configs mittels Formular geändert werden können?
Also ein admintool, wo alle configs gelistet werden ->per Klick ausgewählt -> gelesen-> geschrieben'> fertig.

somit wäre die Änderung aus dem Adminbereich auch ohne DB und codegefrimmel möglich.

Dies setzt voraus, dass in den configs entsprechende Grunddaten (Name usw) und die Parameter auch eine genormte Form haben.

und ja, da in Datein geschrieben wird: Berechtigung, Schutz der Daten usw....

boeseroeser

Gast

Re: Grundsätzliche Fragen zu znips

Das grundsätzliche Problem mit den (module_)configs: Die werden bei einem Upgrade überschrieben.

Ja, ich kann es so machen wie bei Topics: Da gibt es 2 configs:
module_settings.php //kann leer sein. die ist für User-EInstellungen
defaults/module_settings.default.php // die darf vom User nicht verändert werden, weil die wird beim Upgrade überschrieben

Das ist heikel: Wenn ein Modulautor vergisst, dass die module_settings.php NICHT im Modul-Zip drin sein darf, wird sie überschrieben.

Besser wäre es daher, wenn die module_settings.php woanders steht. In einem eigenen verzeichnis (außerhalb des Modulverzeichnis) oder eben in der DB.

Das lesen und schreiben in die DB ist ja kein THeater; wenn das immer gleich abläuft ist das Copy/Paste - fertig. Das Lästige ist das machen der Eingabemasken, die Rechte-Prüfung, Sicherheitsaspekte.. für DInge, die man kaum mal braucht. das soll ja wegfallen.

Wenn ich das weiter denke:

Abseits der znips - also nicht nur! - sollte es eine DB-Tabelle geben, in der verschiedenste configs gespeichert werden können, und ein Admin-Tool, mit dem diese Einträge verwaltet werden können.

Auch Templates könnten Einstellungen haben. Die sind oft oben in der index.php, aber ideal ist das auch nicht.
Urls des Logos, Headerbilder-Ordner, sonstwas..

Die Colorbox zb, auch die lässt sich konfigurieren - derzeit so irgendwie in den Eingeweiden.

Und zusätzlich gewisse "globale" EInstellungen, die für mehrere Zwecke (Module, Templates) verwendet werden können, zb:
facebook, twitter, ...
Kontakt-Telefonnummer..
Adresse, Geokoordinaten.

Und jetzt das große ABER
Ich hab keine Lust, da ein Süppchen zu kochen und hintennach raunzen die Leute wegen dem oder dem, das hätten sie alles ganz anders gemacht und überhaupt.
Also lass ich es.

boeseroeser

Gast

Re: Grundsätzliche Fragen zu znips

OK, ich denk das mal weiter, als Notiz..
Das wäre eine Tabelle

addon_configs
Ohne mod_ weil es sollte irgendwann zum Core gehören. Diese Tabelle kann auch nicht deinstalliert werden.

id //laufende Nummer

ps_id //0 = allgemein gültig, Wert: nur für diese Page gültig. section_ids könnte man als negative Zahl angeben, dann eben gültig für diese section.
Oder klassisch getrennt: page_id, section_id. Das Problem ist: Wie bekomme ich mit einer DB-Abfrage alles kaskadierend raus, was ich brauche.
Also: das passendste: 0 -> page_id -> section_id
EDIT: Bei Globalcomments ist das so gelöst: Grundeinstellung: -999999, page_id: negativ, section_id positiv. Dadurch bekomme ich durch sortieren und Limit stets die hier gültigen Daten. Also: wenn es Einstellungen zur Section_id gibt, werden diese geliefert, ansonsten page_id ansonsten generelle EInstellungen.

addon_name: String in der Form des Pfads: tempates/templateverzeichnis oder modules/modulverzeichnis oder zb "social_media" usw
Das würde weitere Möglichkeiten offen lassen.

what_is
'str': ein String, zu editieren "as is", zb für Telefonnummern oder URLs Bringts nicht, stabiler ist json1
'php': als PHP zu editieren, Verwendung per eval();
'js': als Javascript zu editieren, Verwendung direkt im Modul;
'html': der Ordnung halber.
'json1': Ein flaches Array JSON codiert.
'json2': Ein verschachteltes Array JSON codiert.

für php und json1 kann man im Admin-Tool eine standard-Editier-Funktion machen. json2 ist zu komplex, da muss ein Modul selbst was bereitstellen.
Bei json1 einfach: key: Feld(value) untereinander. Die Typen: Gespeichert wird alles als String. Was was ist, muss dann eben das entsprechende Modul wissen und ggf konvertieren.
Bei php muss das Modul eine Art "was_geht.txt" enthalten, das neben dem Formularfeld dargestellt wird, sonst kennt sich keiner aus.
Welcher der Einträge zu bearbeiten ist, muss das Modul wissen und einen direkten Link bereitstellen. Das ist kein großes Theater.

Nicht zuletzt
data: Typ Text wird wohl reichen.

WIe würde das insgesamt funktionieren:
Jedes Modul, das diese Funktionen nutzen möchte, installiert die Tabelle, wenn nicht vorhanden. Dass man das Admintool  addon_configs installieren SOLLTE:; Da wird nur drauf hingewiesen, wenn das Modul-Verzeichnis /modules/addon_configs nicht existiert.
Das ist einfacher Copy/Paste-Code, den man leicht mal einbauen kann.

Templates müssten eben abfragen, ob vorhanden und dann ggf installieren. Auch das: Copy-Paste, kein Theater.

Das AdminTool addon_configs sollte die Eingabemasken auch im Frontend-Edit Modus bereitstellen, damit man es als iFrame in ein Modul einhängen kann. Eventuell auch mit AJAX. Geht ja heute alles.

Beitrag geändert von boeseroeser (21.05.2019 11:43:17)