Hat CMSimle XH eine Zukunft

A place for general not CMSimple related discussions
Post Reply
frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by frase » Sat Jan 12, 2019 11:22 am

olape wrote:
Sat Jan 12, 2019 10:57 am
Ich nutze für fast alles Notepad++. Ob xml jetzt Standard mit dabei ist, oder als Plugin kann ich nicht mehr sagen. Jedenfalls sind duch das syntax highlighting ganz gut, was man macht.
Ich hoffe, dass ich jetzt nicht wieder das Thema verzettele ...

Meine Bedenken sind, dass wenn die Plugin-Entwickler (oder Template-Gestalter) die XML-Datei selbst ausfüllen sollen, dann ist die Datenstruktur nicht sicher gewährleistet. Klar, wenn Fehler gemacht werden, wird halt nichts angezeigt ... ist aber auch nicht gut.

Ich könnte mir folgendes vorstellen:
Per html-Formular auf xh.org die Daten abfragen (könnte ja gleich als CSV erfolgen).
Der Datensatz erhält eine eindeutige Nummer (oder Passwort), die dem Betreffenden per Mail zugesandt wird.
Damit können dann Änderungen durchgeführt werden - registriertes Einloggen.
Die version.nfo werden zeitgesteuert abgefragt. Werden Änderungen festgestellt, geht eine Mail raus mit Aufforderung, dass das Formular aktualisiert werden muss.

Bei Erstbesuch (neues Plugin) einen Gastzugang erlauben - Datensatz bis zur Prüfung zurückhalten (Flag setzen). Dann wie oben beschrieben.

(Sorry, wenn das Quatsch ist. Mir scheint das aber irgendwie sicherer.)

Hartmut
Posts: 553
Joined: Sat Nov 05, 2011 6:13 pm
Location: Butzbach, Deutschland
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by Hartmut » Sat Jan 12, 2019 11:34 am

olape wrote:
Sat Jan 12, 2019 10:57 am
lck wrote:
Sat Jan 12, 2019 10:49 am
Die Kategorie würde ich ganz oben unter Pluginnamen einfügen (auf der Detailseite) oder zumindest so sortieren wie in der Liste (Übersicht), dann wäre das Ganze homogener.
Das wäre kein Problem, wichtiger wäre vorab eine Einigung welche Kategorien es sein sollen.
Ist erst mal angefangen, kann man zwar noch zufügen, ändern oder löschen ist dann aber immer blöd für bestehende Plugins (xml‘s). Dynamisch möcht ich das aber auch nicht haben. Wenn jeder seine eigenen Kategorien erfindet, dann geht die Übersicht flöten.
Die Kategorien würde ich wesentlich granularer (detaillierter) machen, damit der Annwender differenzierter Filtern kann.
In der bestehenden Pluginverwaltung gibt es (als Anregung) folgende Kategorien für eine grobe Übersicht der über hundert Plugins:
Admin Sonstiges
Admin Antispam
Admin Dateiverwaltung
Admin Editor
Admin Seitenverwaltung
Admin SEO
Admin Sonstiges
Admin Statistik + Counter
Audio-Video
Bereitstellung News(letter)
Bereitstellung Seite
Bereitstellung Sprache
Bereitstellung Text
Bilder / Fotos
Bildergalerie
Bildershow / Diashow
Bildpräsentationen sonstige
Blog, Chat, Forum
Diashow / Bildershow
Downloads
Gästebuch, Kommentar
Kalender
Online-Kataloge / -Sammlung
Prüfung Aktualität
Shop / Buchung
Social Media / Datenschutz
Sonstige
Unterhaltung + Spiele
Webentwicklung Funktionalität
Webentwicklung Layout
Zugangskontrolle

olape
Posts: 2731
Joined: Fri Mar 13, 2015 8:47 am
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by olape » Sat Jan 12, 2019 12:47 pm

frase wrote:
Sat Jan 12, 2019 11:22 am
Meine Bedenken sind, dass wenn die Plugin-Entwickler (oder Template-Gestalter) die XML-Datei selbst ausfüllen sollen, dann ist die Datenstruktur nicht sicher gewährleistet. Klar, wenn Fehler gemacht werden, wird halt nichts angezeigt ... ist aber auch nicht gut.
Hm, da muss ich nun wieder sagen, wer in der Lage ist PlugIns zu schreiben oder Templates zu entwickeln, der sollte auch eine xml-Datei entsprechend bearbeiten können. Per Formular, darüber könnte man im Nachgang noch nachdenken, dann allerdings eher als php für die Ausführung auf dem jeweils eigenen Webspace.
frase wrote:
Sat Jan 12, 2019 11:22 am
Ich könnte mir folgendes vorstellen:
Per html-Formular auf xh.org die Daten abfragen (könnte ja gleich als CSV erfolgen).
Der Datensatz erhält eine eindeutige Nummer (oder Passwort), die dem Betreffenden per Mail zugesandt wird.
Damit können dann Änderungen durchgeführt werden - registriertes Einloggen.
Die version.nfo werden zeitgesteuert abgefragt. Werden Änderungen festgestellt, geht eine Mail raus mit Aufforderung, dass das Formular aktualisiert werden muss.

Bei Erstbesuch (neues Plugin) einen Gastzugang erlauben - Datensatz bis zur Prüfung zurückhalten (Flag setzen). Dann wie oben beschrieben.
Das wäre ein ganz anderer Ansatz, wäre wesentlich aufwendiger und würde auch wieder eine weitaus aufwendiger Datenschutzerklärung voraussetzen. All das wollte ich gerade vermeiden.

Hartmut wrote:
Sat Jan 12, 2019 11:34 am
Die Kategorien würde ich wesentlich granularer (detaillierter) machen, damit der Annwender differenzierter Filtern kann.
In der bestehenden Pluginverwaltung gibt es (als Anregung) folgende Kategorien für eine grobe Übersicht der über hundert Plugins:
Admin Sonstiges
Admin Antispam
Admin Dateiverwaltung
Admin Editor
Admin Seitenverwaltung
Admin SEO
Admin Sonstiges
Admin Statistik + Counter
Audio-Video
Bereitstellung News(letter)
Bereitstellung Seite
Bereitstellung Sprache
Bereitstellung Text
Bilder / Fotos
Bildergalerie
Bildershow / Diashow
Bildpräsentationen sonstige
Blog, Chat, Forum
Diashow / Bildershow
Downloads
Gästebuch, Kommentar
Kalender
Online-Kataloge / -Sammlung
Prüfung Aktualität
Shop / Buchung
Social Media / Datenschutz
Sonstige
Unterhaltung + Spiele
Webentwicklung Funktionalität
Webentwicklung Layout
Zugangskontrolle
Und genau einen solchen Wulst an Kategorien wollte ich vermeiden.
Da man ja aber mehrer zuweisen kann, kann man das auch mit wesentlich weniger abfeiern.

Alles in allem. Ich dränge mich nicht, das als Plugin umzusetzen.
Wenn ihr der Meinung seid, das ist es nicht, dann lassen wir es.
Es bleibt alles wie es ist. Wir treten weiter auf der Stelle und wundern uns, warum es nicht so richtig läuft.
Gruß Olaf, Plugins for CMSimple_XH

Ich habe schon lange den Verdacht, dass so viele so eifrig auf Gender, Trans und Queer machen:
Weil sie für das Fachliche ganz einfach zu doof sind.

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by frase » Sat Jan 12, 2019 1:07 pm

olape wrote:
Sat Jan 12, 2019 12:47 pm
Alles in allem. Ich dränge mich nicht, das als Plugin umzusetzen.
Wenn ihr der Meinung seid, das ist es nicht, dann lassen wir es.
Es bleibt alles wie es ist. Wir treten weiter auf der Stelle und wundern uns, warum es nicht so richtig läuft.
Na, na, na - wer wird denn gleich die Flinte ins Korn werfen?
Bisher ist es ja noch ein Brainstorming.
Und man muss eben auch verschiedene Modelle bedenken.
Vergiss einfach, was ich oben schrieb.
Da du jetzt von einem "Plugin" schreibst, fällt mir noch eine Möglichkeit ein (die du vielleicht schon so gemeint hast???).
Ein Plugin, das sich Plugin-Entwickler und Template-Gestalter selbst installieren können - und das dann für die Erzeugung des Datensatzes sorgt. Wie wäre denn das?
Ich denke, dass die Datenerfassung per Texteditor o.Ä. nicht sicher und nicht simple genug ist.
Es wird immer mindestens einen geben, der eine neue Kategorie oder sonstwas erfindet.

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Hat CMSimle XH eine Zukunft

Post by Holger » Sat Jan 12, 2019 1:21 pm

olape wrote:
Sat Jan 12, 2019 12:47 pm
Und genau einen solchen Wulst an Kategorien wollte ich vermeiden.
Da man ja aber mehrer zuweisen kann, kann man das auch mit wesentlich weniger abfeiern.
+1
olape wrote:
Sat Jan 12, 2019 12:47 pm
Alles in allem. Ich dränge mich nicht, das als Plugin umzusetzen.
Wenn ihr der Meinung seid, das ist es nicht, dann lassen wir es.
Es bleibt alles wie es ist. Wir treten weiter auf der Stelle und wundern uns, warum es nicht so richtig läuft.
Ich finde es mehr als gut, dass Du angefangen hast und die Sache jetzt angehst.
Und auch das jetzt schon vorgestellte Ergebnis finde ich schon gut und einen großen Fortschritt.
olape wrote:
Sat Jan 12, 2019 12:47 pm
frase wrote:
Sat Jan 12, 2019 11:22 am
Ich könnte mir folgendes vorstellen:
Per html-Formular auf xh.org die Daten abfragen (könnte ja gleich als CSV erfolgen).
Der Datensatz erhält eine eindeutige Nummer (oder Passwort), die dem Betreffenden per Mail zugesandt wird.
Damit können dann Änderungen durchgeführt werden - registriertes Einloggen.
Die version.nfo werden zeitgesteuert abgefragt. Werden Änderungen festgestellt, geht eine Mail raus mit Aufforderung, dass das Formular aktualisiert werden muss.

Bei Erstbesuch (neues Plugin) einen Gastzugang erlauben - Datensatz bis zur Prüfung zurückhalten (Flag setzen). Dann wie oben beschrieben.
Das wäre ein ganz anderer Ansatz, wäre wesentlich aufwendiger und würde auch wieder eine weitaus aufwendiger Datenschutzerklärung voraussetzen. All das wollte ich gerade vermeiden.
So in etwa hatte ich mir das auch vorgestellt, wenn die Sache mal etabliert ist und es wirklich Zuwachs bei den Plugins / Pluginentwicklern gibt, der den Aufwand rechtfertigen würde. Spätestens dann kann man die Sache ja weiter entwickeln.
Die Basis könnte aber durchaus auch die jetzt vorgeschlagene XML-Lösung sein. Und mit dem, was bisher enthalten ist, lässt sich doch schon eine ansprechende Darstellung generieren, finde ich.

Also lasst uns doch jetzt festlegen, was an Infos gesammelt werden soll. Vielleicht sollten wir Christophs Hinweis auf diesen Post viewtopic.php?f=29&t=6524&start=10#p42477 noch einmal näher anschauen.
Hat es Vorteile eine DTD zu definieren? Macht das nicht Sinn, weil man damit Pflichtfelder und Formate definieren kann? Lässt sich das dann auch auswerten?
Mir geht es darum, dass das Format möglichst flexibel und erweiterbar bleibt (im Gegensatz zum Updatecheck). Und was ist mit Templates? Dafür könnte am Ende das gleiche Tool zur Generierung der Inhalte zum Einsatz kommen. Dazu müsste dann halt ein Tag "Template", statt "Plugin" definiert sein.

Was ich auch noch wichtig fände:
von wo kommen die XML-Dateien? Muss das vom Pluginentwickler "angemeldet" werden? Sollte das Tool einen festen Speicherort auf dem Webspace des Entwicklers voraussetzen?
Wollen wir auch (öffentlich verfügbare) Plugins ohne die Mitwirkung des Entwicklers einfügen?

Aber immer der Reihe nach.

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Hat CMSimle XH eine Zukunft

Post by Holger » Sat Jan 12, 2019 1:27 pm

olape wrote:
Fri Jan 11, 2019 6:36 pm
Ich habe das heute mal auf die Schnelle fertig gemacht.
Optisch nicht schön, html unvollständig, aber mir geht es um die Funktion.
Und um die Rückmeldung, ob wir das in dieser Art und Weise machen wollen.

Wer möchte kann ja mal eine xml nach dieser Vorlage ausfüllen und auf seinem Webspace zur Verfügung stellen.
Und mir anschliessend natürlich die entsprechende URL der .xml zusenden.
Ich hab Dir mal eine Testdatei auf meinen Server kopiert:
http://holgerirmler.de/temp/testplugin.xml

Vielleicht hilft's bei der Prüfung des externen Zugriffs.

olape
Posts: 2731
Joined: Fri Mar 13, 2015 8:47 am
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by olape » Sat Jan 12, 2019 2:28 pm

Holger wrote:
Sat Jan 12, 2019 1:27 pm
Ich hab Dir mal eine Testdatei auf meinen Server kopiert:
http://holgerirmler.de/temp/testplugin.xml

Vielleicht hilft's bei der Prüfung des externen Zugriffs.
Habe ich eingebunden.
Funktioniert.

Tata hat mir da eine weitaus schwieriger Aufgabe gestellt.
Erstens hat er in die Beschreibung html-tags ol, li mit reingemogelt, was so nicht gedacht ist.
Und Zeilenumbrüche und an denen hänge ich im Moment. Die schleppe ich mit in die csv und das bringt natürlich alles durcheinander.
Diese Dinge abzufangen, soweit war ich noch gar nicht.
Nur, ich bekomme die Zeilenumbrüche ums verrecken nicht raus.
Gruß Olaf, Plugins for CMSimple_XH

Ich habe schon lange den Verdacht, dass so viele so eifrig auf Gender, Trans und Queer machen:
Weil sie für das Fachliche ganz einfach zu doof sind.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by cmb » Sat Jan 12, 2019 3:25 pm

Holger wrote:
Sat Jan 12, 2019 1:21 pm
Ich finde es mehr als gut, dass Du angefangen hast und die Sache jetzt angehst.
Und auch das jetzt schon vorgestellte Ergebnis finde ich schon gut und einen großen Fortschritt.
+1
Holger wrote:
Sat Jan 12, 2019 1:21 pm
Hat es Vorteile eine DTD zu definieren? Macht das nicht Sinn, weil man damit Pflichtfelder und Formate definieren kann? Lässt sich das dann auch auswerten?
Ja, zumindest ein DTD sollte sein (evtl. sogar Schematron und/oder RelaxNG). Das ist gerade der besondere Vorteil von XML für diesen Zweck: man kann automatisch validieren lassen (sowohl der, der das XML schreibt, als auch bevor es vom Plugin gelesen wird).
olape wrote:
Sat Jan 12, 2019 2:28 pm
Tata hat mir da eine weitaus schwieriger Aufgabe gestellt.
Erstens hat er in die Beschreibung html-tags ol, li mit reingemogelt, was so nicht gedacht ist.
Und Zeilenumbrüche und an denen hänge ich im Moment. Die schleppe ich mit in die csv und das bringt natürlich alles durcheinander.
Diese Dinge abzufangen, soweit war ich noch gar nicht.
Nur, ich bekomme die Zeilenumbrüche ums verrecken nicht raus.
Wenn als CSV gespeichert werden soll, dann würde ich fputcsv() und fgetcsv() verwenden, wobei als $escape_char bzw. $escape Paramter am besten "\x00" gewählt wird (eine leere Zeichenkette wird erst ab PHP 7.4.0 unterstützt werden; bis dahin tut's für uns der Workaroung mit "\x00"). Auf jeden Fall sollten dann Zeilenumbrüche keine Rolle mehr spielen.

Ein minimales Markup für die Beschreibungen finde ich gut. Im anderen Thread war mal eine Wiki-/Markdown ähnliche Auszeichnung im Gespräch, aber ich denke, dass HTML-Tags hier auch sehr sinnvoll wären, und die könnte man auch leicht per DTD einschränken. Und soweit ich es überblicke, sollte es auch kein Problem darstellen, die paar relevanten Tags direkt ins HTML auszugeben.
Christoph M. Becker – Plugins for CMSimple_XH

olape
Posts: 2731
Joined: Fri Mar 13, 2015 8:47 am
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by olape » Sat Jan 12, 2019 3:57 pm

cmb wrote:
Sat Jan 12, 2019 3:25 pm
Wenn als CSV gespeichert werden soll, dann würde ich fputcsv() und fgetcsv() verwenden, wobei als $escape_char bzw. $escape Paramter am besten "\x00" gewählt wird (eine leere Zeichenkette wird erst ab PHP 7.4.0 unterstützt werden; bis dahin tut's für uns der Workaroung mit "\x00"). Auf jeden Fall sollten dann Zeilenumbrüche keine Rolle mehr spielen.
Ich nutze fgetcsv, aber Zeilenumbrüche und Tabs bleiben so leider erhalten.
Aber ich habe meinen Fehler auch schon gefunden.
Wer die Elemente eines Array nach-bearbeitet, muss anschließend natürlich auch das bearbeitete Array nutzen und nicht das Original. :oops:
cmb wrote:
Sat Jan 12, 2019 3:25 pm
Holger hat geschrieben: ↑12 Jan 2019 14:21
Hat es Vorteile eine DTD zu definieren? Macht das nicht Sinn, weil man damit Pflichtfelder und Formate definieren kann? Lässt sich das dann auch auswerten?
Ja, zumindest ein DTD sollte sein (evtl. sogar Schematron und/oder RelaxNG). Das ist gerade der besondere Vorteil von XML für diesen Zweck: man kann automatisch validieren lassen (sowohl der, der das XML schreibt, als auch bevor es vom Plugin gelesen wird).
Darum kümmere ich mich später.
Gruß Olaf, Plugins for CMSimple_XH

Ich habe schon lange den Verdacht, dass so viele so eifrig auf Gender, Trans und Queer machen:
Weil sie für das Fachliche ganz einfach zu doof sind.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Hat CMSimle XH eine Zukunft

Post by cmb » Sat Jan 12, 2019 4:50 pm

olape wrote:
Sat Jan 12, 2019 3:57 pm
Ich nutze fgetcsv, aber Zeilenumbrüche und Tabs bleiben so leider erhalten.
Ist doch aber auch nicht weiter schlimm.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply