WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 06.02.2017 11:07:33

grindbatzn
Guest

znips Allgemein

Ich gehe mit der Idee schon länger schwanger und hab auch schon ein paar "znips" fertig/angefangen.

Grund-Idee:
Es gibt da draußen einen Haufen CodeSchnippel und Scripts, die irgendwas nettes und nützliches machen. zb Slider, originelle Menüs, oder sowas wie Isotope, sonstwas. Oder auch Deep Zoom VIewer.
Dinge, wo man sich denkt: Da könnte ich doch ein Modul draus machen.

Das Problem dabei sind immer die Settings und die Verwaltung, das trägt dann (oft unverhältnismäßig) auf, ist tw sehr schwierig.


znips sind an sich "vollwertige" Module, aber ohne Settings und Administration, sondern stattdessen eine Punkt für Punkt Anleitung:
1) Mach Schritt 1
2) Mach Schritt 2
...
Die Anleitung steht gleich in der Modify (zum ein/ausklappen). Ansonsten gibt es in der modify.php NICHTS einzustellen.
Alle Einstellungen entweder in einer config.php oder in einer für alle znips einheitlichen Tabelle, jeweils als JSON codiertes Array in einem Textfeld.

Beispiele:
http://wbce.at/tpls/unterseiten/diverse … sotope.php
DIe Anleitung dazu ist sowas wie: Lege Bilder mit bestimmten Namen in ein bestimmtes Verzeichnis.

Weiteres Beispiel: Das Accordion Menü hier:
http://wbce.at/tpls/template-acourdesz.html
Anleitung ebenso:  Lege Bilder mit bestimmten Namen in ein bestimmtes Verzeichnis.
So ein Menü will man ja auch nicht auf jeder Seite haben, Startseite reicht.

Sollte ein znip auf soviel Anklang stoßen, dass man dann doch ein "richtiges" Modul mit vielen Schalterchen draus machen will, nimmt man einfach das "znip" aus dem Namen.
znips bekommen normalerweise keine Upgrades, die tun wie sie tun und fertig.

Unklarheiten
Das ganze sollte irgendwie einheitlich gehandhabt werden, sonst hat man da schnell Wildwuchs. Einheitliche Gestaltung, einheitliche Vorgehensweisen - was dann auch letztlich die Erstellung wieder vereinfacht.
Da hab ich noch wenig (oder zuviel) Plan.

Last edited by grindbatzn (06.02.2017 11:09:27)

Liked by:

florian

#2 06.02.2017 23:01:33

norhei
Developer

Re: znips Allgemein

Wo genau liegt der Unterschied zu einem Snippet ?

Offline

#3 06.02.2017 23:44:22

grindbatzn
Guest

Re: znips Allgemein

norhei wrote:

Wo genau liegt der Unterschied zu einem Snippet ?

Dass es ein normales Modul ist. Abschnitt anlegen, da.

#4 07.02.2017 11:33:05

norhei
Developer

Re: znips Allgemein

Fasse das mal zusammen ...

  • Grundsätzlich ein Page Modul.

  • Die Modify.php zeigt nur einen Hilfetext und die Überschrift

  • Aus/einklappbar ist wichtig , da sonst zu viel Platz benötigt. 

  • Weitere Konfiguration unnötig , bis auf z.B. Bilder Upload .

  • Eigentlich ein Benutzbarer "Proof of concept"

Fragen/Kommentare:

Was ist mit mehrsprachig ?

Wär es eventuel sinvoll eine Config Datei im /var/modulname/ als Option zu haben . Damit kann dann bei Upgrades oder Umzügen weniger passieren. Also muss man sich z.B. keine Sorgen machen , das bei einem Upgrade die Config überschrieben wird. (Ist ja ein altes Problem)
Eine Solche Config Datei sollte einfach einen Array mit Werten enthalten , damit kann man nämlich erst die Originale , und dann die Custom Datei laden .
Wenn neue Werte hinzukommen , würden dann die alten erhalten bleiben , aber die Neuen nicht fehlen. (Wie mittlerweile bei den Sprachdateien)

Also :

// Standard config
include (WB_PATH."/modules/{$module_directory}/config.php");

// Custom Config
$sConfFile=WB_PATH."/var/modules/{$module_directory}/config.php"
if (file_exists($sConfFile)) include ($sConfFile);

Kennzeichnung :
$module_name mit "Znips " vorrangestellt ?
$module_directory auch ? Bei der Umstellung auf ein vollwertiges Modul wärs einfacher wenn das Directory gleich bliebe ?
$module_version <=  0.x.x    also Vorne mit 0.


Modul Typ:
Ich könnte dafür noch einen Neuen Modul Typen anlegen(tool,page, snippet,zsnips), grundsätzlich ists aber ein PageModul mit Standarisierter modify.php und Du wolltest ja WB kompatibel bleiben.   Ich glaube das ist nicht notwendig ?

Also im Endeffekt eine Vorlage für die Modify.php  machen sich auf Namenskonventionen einigen, kürz über Mehrsprachigkeit nachdenken , fertig .
Und mit Bianka zusammen tun um eine entsprechende Vorlage für ihren Modul Ersteller zu haben. cool

Offline

#5 07.02.2017 12:54:54

grindbatzn
Guest

Re: znips Allgemein

Auf Kompatibilität zu WB lege ich keinen Wert. Das ist klar was anderes und es sollte keine Verwirrung geben.

Einstellungen:
So ganz ohne wird es wohl nicht gehen. Bei Teasers hab ich da nicht lang gefackelt, sondern einfach alles in ein Array gesteckt und das im Stück (JSON-codiert) in ein Textfeld gesteckt.
modify-settings/save-settings sind einfach ein Loop durch alles und passt. Hat den Vorteil, dass man beliebig erweitern kann. (bei Teasers ist das NICHT vorbildlich, aber ich denke, das kann man verbessern ;-)

Das wäre einfach so drin: $settings['feldname'] = [typ, wert];
Wenn es in der Sprachdatei einen EIntrag zu propertyname gibt, wird der angezeigt, ansonsten eben "feldname".
Mit klick auf eine Property wird Feld Typ mit Wert angezeigt und man kann es ändern.
Überprüfung auf Sinnhaftigkeit muss das Modul selbst machen. 
Brachial, nicht schön, aber effektiv und schnell gemacht.

Ich habe auch daran gedacht, das übergreifend zu machen (Einstellung zu section_id = 0), zb: facebook-account, Website-Telefonnummer, breite-höhe des Headers, Headerbilder-Verzeichnis  usw. Dann könnten zb alle, die einen Header darstellen, gleich die Einstellungen haben.
Ist aber vielleicht zu weit gegriffen.

Mehrsprachigkeit: Da sehe ich kein Problem. Ist ja trotzdem ein normales Modul.

#6 07.02.2017 23:07:40

norhei
Developer

Re: znips Allgemein

Auf Kompatibilität zu WB lege ich keinen Wert. Das ist klar was anderes und es sollte keine Verwirrung geben.

Frage ist hätte ein eigener Modul Typ  irgendwelche Vorteile , da es technisch eigentlich immer noch ein Page Modul ist und nur die modify.php etwas abgespeckt ist  ? Ansonsten dürfte das Prefix eigentlich reichen , um die Module zu erkennen. Eigene Kategorie im AOR , macht Sinn , eigene Kategorie in Technischer Hinsicht ??? Da ist die Frage nach dem Vorteil/Nutzen?


So ganz ohne wird es wohl nicht gehen. Bei Teasers hab ich da nicht lang gefackelt, sondern einfach alles in ein Array gesteckt und das im Stück (JSON-codiert) in ein Textfeld gesteckt.
modify-settings/save-settings sind einfach ein Loop durch alles und passt. Hat den Vorteil, dass man beliebig erweitern kann. (bei Teasers ist das NICHT vorbildlich, aber ich denke, das kann man verbessern ;-)

Der einzige Nachteil ist , wenn keine Validierung der Eingaben stattfindet , kann der Benutzer der dieses Textfeld bearbeiten kann , einfach alles Injecten was man sich so vorstellen kann . Sprich Sicherheit ist nicht existent , solange nur Admin User Zugang haben ist es unbedenklich (Die dürfen sowieso alles.) Ansonsten kann sehr wahrscheinlich jeder Benutzer sich damit Admin Rechte einstellen. 

Ich habe auch daran gedacht, das übergreifend zu machen (Einstellung zu section_id = 0), zb: facebook-account, Website-Telefonnummer, breite-höhe des Headers, Headerbilder-Verzeichnis  usw. Dann könnten zb alle, die einen Header darstellen, gleich die Einstellungen haben.
Ist aber vielleicht zu weit gegriffen.

Global für die Gesamte Seite :

Settings::Set ("site_facebook_account", "meine.fb.adresse@facebook.com");
Settings::Set ("site_twitter_account", "bla@twitter.com");
Settings::Set ("site_impressum_name", "Klaus_Willibald");

Und schon liegen die immer und überall als Konstanten vor :
SITE_FACEBOOK_ACCOUNT
SITE_TẀITTER_ACCOUND
SITE_IMPRESSUM_NAME


Brauchst nur ein Tool, das diese Einstellungen auch setzt .
Wenn du dich damit befassen magst , schau dir einfach mal das Modul settings_maintainance_mode oder die anderen settings_irgendwas Module an.

Mehrsprachigkeit: Da sehe ich kein Problem. Ist ja trotzdem ein normales Modul.

Also Sprachdateien und fertig... ok.

Offline

#7 07.02.2017 23:16:29

norhei
Developer

Re: znips Allgemein

Nachtrag , mit :

$aSiteSettings=Settings::GetPrefix("SITE_");

Würde $aSiteSettings dann alle Settings mit Prefix "SITE_" als Array enthalten, ist ganz nützlich wenn es viele sind.

Offline

Board footer

Powered by FluxBB

up