eigenes CMS: modularer und pflegeleichter Aufbau

Ich erkenne daran nichts besonderes. Anders gesagt: Standard. Daher habe ich auch keine Tipps oder Ideen. Auf Innovationen musst du schon selber kommen.

Für eigene Zwecke habe ich auch schon selber ein Content Management System, kurz CMS, entwickelt. Und ich würde es immer wieder tun. Insofern kann ich deinen Drang nach einem eigenen System gut verstehen, auch wenn ich mir sage, dass man nicht immer das Rad neu erfinden sollte .

Ja, das stimme ich dir zu. Da ich diesen Drang auch verspüre und das ganze als Projekt auch ernsthaft verfolgt werden muss, hoffe ich auf Erfolg *g*
im Prinzip sind ja alle CMS gleich, wenn man es völlig verallgemeinern würde (Templates, DB, modular)
In wieweit AJAX bereits verwendet wird, um die angezeigten Inhalte stets aktuell zu halten, ist mir nicht bekannt. AJAX (und Javascript) sind für mich völlig neue Themen, habe da lediglich einige Tests durchgeführt...

Ich würde auch gerne eure Anforderungen an ein CMS hören (verweise auf das entsprechende andere Thema könnt ihr sein lassen => ausgedruckt, jedoch noch nicht gelesen )

Die eigentlichen Schwerpunkte liegen auf dem Rechtesystem und der Sicherheit (Login, direkter Dateizugriff, ...)

Da wäre wichtig zu wissen, was du dir vorstellst. Wie soll das Rechtemanagement aussehen, welche Optionen soll es geben und was muss geschützt werden.

Ok, ich will mit folgenden Möglichkeiten arbeiten:
- Gruppenrechte
- Userrechte
- Gruppenverbote
- Userverbote
=> Rechte oder Verbote die für Gruppen und/ oder einzelne User vergeben werden

- Dann die entsprechenden Gegenstücke (Voraussetzungen des Bereichs).

Funktion:
1 Verbot für einen Bereich => IMMER verbot!
1 Berechtigung => Erlaubnis, wenn kein Verbot vorliegt


- Berechtigungen/ Verbote kann man für Module vergeben (Darf ein User/ eine Gruppe das Modul überhaupt aufrufen?)
- Berechtigungen/ Verbote für Aktionen (Darf ein User/ eine Gruppe eine Aktion - eines Moduls - überhaupt ausführen?)
=> Dadurch kann man einen User zu einem Admin machen, der aber nur gewisse Funktionen ausführen darf. Meiner momentanen Einschätzung nach sollte man so eine recht freie Rechtevergabe erzielen können.
Das Rechtesystem soll dann in der Datei rechte.php sein und sobald diese aufgerufen wird, werden die Rechte anhand der übergebenen Parameter geprüft. Ergebnis sollte true oder false sein.

Ich wäre froh wenn ich endlich mal ein CMS entdecken mit korrekt umgesetzer MVC Technik, welches mir auch entsprechende Freiheiten erlaubt: Egal ob Typo3 oder Mambo, man kann sich nirgendwo austoben.

MVC-Technik? Unt er diesem Begriff kann ich mir momentan nichts vorstellen. Kannst du das genauer erläutern?

Ich wuerde mir ein CMS wuenschen, das

0. die gaengigen CMS-Features beherrscht
1. sauber OO programmiert ist
2. auf Smarty basiert und den Funktionsumfang voll ausnutzt
3. eine Datenbankabstraktion wie adoDB oder PEAR verwendet
4. modular desined und durch Plugins erweiterbar ist
5. ein Rechtesystem nutzt, das auf Rollen basiert (evtl. zusammengefasst zu Gruppen)
6. die Praesentationsebene beliebige Formate ausgeben kann (HTML, XML, CSV, etc)

Zu MVC schau mal hier:
http://userpage.fu-berlin.de/~ram/pu...jf47htuHHt/mvc
http://de.wikipedia.org/wiki/MVC bzw. http://de.wikipedia.org/wiki/Design_Pattern

@frolix:

0. Sollte so sein
1. Mal sehen ob ich das hinbekomme...
2. Kein Smarty! Kenn ich nicht, mag ich nicht. zu umfangreich
3. Wenn, dann PEAR
4. modular auf jeden Fall, Plugins wahrscheinlich auch
5. "auf Rollen basiert"? Wie du meine? Beschriebung meiner Idee => siehe oben
6. Kann ich mir momentan auch nichts drunter vorstellen

Noch kann ich Wünsche versuchen zu berücksichtigen, da ich erst mal ein wenig überlege, wie das werden soll

Wg. "auf Rollen basiert" hilft vielleicht das als Einstiegsthema: http://de.wikipedia.org/wiki/Benutzerrolle

Templates:
layout.tpl
box.tpl

Das Layout regelt den Aufbau und die Optik der Seite. Die Datei box.tpl enthält eine Box, nach deren Vorbild alle Boxen der Seite aufgebaut werden (kann man auch erweitern um lBox.tpl,mBox.tpl und rBox.tpl).
Grundsätzlich will ich alles in DIV-Boxen darstellen, was das ganze vereinfachen sollte. SOmit werden auch nur wenige Templates gebraucht, welche zu verstehen sein sollten.

Interessant wäre dann noch der Inhalt der Box (auch HTML => Tabellen usw.), welche evtl wiederum ein Template benötigen, jedoch dann Seitenspezifisch.

Wo sollte ich, wenn ich es so machen würde, diese seitenspezifische Templates ablegen? Im jeweiligen Modul-Ordner (Unterordner themes?) oder ebenfalls im "globalen" Themes-Ordner?
Was denkt ihr? Wie sollte man das aufbauen, damit es einfach, verständlich und sinnvoll bleibt?

Schade, denn Smarty bietet wirklich viele Vorteile. Und wenn es dir zu ueberladen vorkommt... du musst ja nicht alles nutzen. Und die Plugins werden erst geladen, wenn sie auch gebraucht werden. Ausserdem ist Smarty sehr verbreitet. Viele Leute kennen sich damit aus. Wenn ich eine Software die auf PHP basiert fuer irgendwas auswaehle, dann ist Smarty ein wichtiges Kriterium. Denn da weiss ich, dass ich die Templates ohne weiteres anpassen kann. Ohne erst wieder die Dokus (wenn denn vorhanden) lesen zu muessen. Ausserdem ist es sehr einfach, die Ausgabe in unterschiedlichen Formaten zu machen (s. Punkt 6). Internationalisierung geht auch einfach. Die Doku ist kurz gefasst und denoch sehr hilfreich. Es gibt ein gutes Forum. Wenn du auf AJAX setzen moechtest und damit noch keine Erfahrung hast, dann lernst du Smarty sicher in einem Bruchteil der Zeit.

Ich meinte damit, das die Ausgabe nicht nur auf HTML beschraenkt wird. Wenn du z.B. einfach mal die Ausgabe auf XML umstellen kannst, lassen sich leicht weitere Anwendungen bauen. Z.B. Whitelabels. Oder Mandanten. Oder eine Version fuer mobile User usw.

XML kenne ich momentan nur wenige Beispiele aus dem Internet und Zeitschriften. Hatte eigentlich nicht vor mich damit zu beschäftigen. HTML ist wohl am einfachsten und somit für jeden verständlich, während XML wenigeren nur bekannt ist. Somit werden die Templates wohl in HTML (mit einigen Template-Tags) geschrieben. Ob man eine Anpassung von XML zu html anbieten sollte, ist was anderesn (um xml-Scripte zu importieren).

Welchen nutzen hätte ich aus Smarty? Ich habe eine einfache (noch zu überarbeitende) Klasse, welche Variablen jeglicher Form, IF, ELSEIF, ELSE, FOREACH und INCLUDE (auch Verschachtelungen) unterstützt. Dazu noch eine Cachefunktion.
Mehr benötigt ein Templatesystem doch gar nicht
Ich habe mich vor längerer Zeit bereits schonmal mit Smarty befasst und nichts verstanden (damals hatte ich weniger Ahnung von der Materie), deshalb sollte mein einfaches System Anfängern zugute kommen.

Den oben beschriebenen Aufbau einer Seite finde ich zwar nicht optimal, lässt sich aber für mich momentan am einfachsten mit AJAX kombinieren und einige Ideen einfacher umsetzen. Verbesserungsvorschläge nehme ich da auch gerne an. Oder eure Meinung dazu.

modularer Aufbau:
Soweit möglich wird alles mit einem Modul gelöst (soweit möglich und sinnvoll). Dazu gibt es eine module-Table in der DB, in der die grundlegenden Informationen abgespeichert werden (Modulname, AUfruf, Version, Zugriffsberechtigungen usw.) und mindestens eine weitere Tabelle zum Modul (z.B. news_rechte), in welcher die einzelnen Berechtigungen für die Aktionen des Moduls festgehalten werden. Ansonsten gäbe es eine recht große gemeinsame Tabelle, in der ALLE Rechte zu allen Modulen gespeichert werden, was zu einer extrem großen Tabelle führen würde...

Das Rechtesystem will ich gruppenbasierend machen. Die Rechte, die man den Usern direkt vergeben kann, sollen die Möglichkeiten nur erweitern.

Sicherheit:
Das ganze könnte ungefähr so aussehen/ ablaufen...

1) Direkter Aufruf nur für index.php erlaubt
2) Prüfen nach Hackversuchen durch die URL
3) Prüfen auf Existenz/ Gültigkeit des gewählten Ziels
4) Prüfen der Berechtigungen
5a) Ok, ausführen
5b) Fehler aufgetreten, Errorseite und Fehlerlog

Diese Punkte werden der Reihe nach abgearbeitet. Dadurch sollen nur gültige und zulässige Aktionen ausgeführt werden.

Welche (globalen) Variablen muss ich auf diese Art und Weise testen, damit sich da nichts ungültiges einschleichen kann?
$_POST, $_GET und $_REQUEST? Gibt es noch weitere?

Bezüglich Sicherheit kann ich dir auch dieses "Handbuch" empfehlen: http://phpsec.org/projects/guide/

MfG MaMo

Danke, sehr interessat. Muss ich mir aber in Ruhe durchschauen

Ach ja, ich will in php5 programmieren. Nur mal so am Rande...

Hi eBoy

Lies dir diesen Beitrag zum Rechte-System durch:Ideales Rechte-System

So nun zu den anderen Punkten:
In meinen Augen is AJAX eine nette Sache, nur bietet es sehr viele Angriffmöglichkeiten, die man ned unterschätzen sollte.
Durch diese Technik, wird es noch einfacher Daten zu manipulieren.

Smarty, is in meinen Augen auch sehr überladen, wobei man immer unterscheiden muss, wo das Einsatzgebiet ist.

• Anzeigen, die sie rasch Ändern
• oder eher Konstant sind

Bei einer Konstanten Ansicht, bringt Smarty sehr viel, da es Cached.
Bei einer häufigen Änderung der Ansicht zieht Smarty zuviel mit, zumindest in meinen Augen

MVC:
Sowas in der Art hast du schon angeschrieben: Trennung von Daten und Layout
nur meint man damit, dass das Ausgabe-Format egal ist.
Zb: (x)HTML, XML, PHP, OpenOffice-Dokument, ...
Is nix anderes als eine Template, die das Format angibt

Modul-System:
Suche mal nach dem Begriff Hook-System.
Bedautet: Das System weiß welche Module vorhanden sind, auch wenn sie ned geladen sind.
Kann diese im Notfall nachladen
Zusätzlich können die Module untereinander verbinden.

Danke, das bringt mir wieder einige neue Sichtweisen auf die Geplanten Features
Auch MvC habe ich nun besser verstanden. Gute kurze Erläuterung deinerseits!

AJAX:
Ich will AJAX nur nutzen, um Anfragen an den Server zu stellen und Daten zurückzusenden. Diese Daten werden mittels DOM aus der Seite gezogen und vom Server vor der Verarbeitung nochmals geprüft.
Kann man heutzutage (bzw. bis zum Ende meines Projekts - offiziell läuft das Projekt vom Feb. 2007 bis Mai 2007) Javascript als Standard voraussetzen oder sollte ich ganz normal (php, hmtl) programmieren und zusätzlich dann AJAX realisieren?
Ich kann euch mal mein AJAX-Beispiel demnächst posten (jetzt keine Zeit), dann könnt ihr mir mal die Schwachpunkte nennen

Ich würde zumindest eine Alternative für Benutzer anbieten bei denen, aus welchen Gründen auch immer (Barrierefreiheit, alter Browser,...), Javascript nicht funktioniert.

Hi @gain

In meinen Augen is AJAX eine spielerei
sicher hilft es den Daten-Flut zuminimieren, bzw. auch eine gewisse Usibility zu verbessern.

Es zeichnet sich ein Trend im Web ab, den wir eigentlich schon mal hatten => HTML 1.0
XHTML bzw XML is nix anderes, nur etwas erweitert.

Bestimmte Typen von Seiten (Staat, Stadt, Gemeide, bzw. Öffentliche) haben seit letztem Jahr die Richtlinie Behinderten Gerecht zu sein.
Wie wir alle wissen gibt es verschiedene Stufen von behinderungen, Hör-, Seh-, Geistig-, Motorisch-Behindert, ...
Jede dieser Gruppen kann gewisse Sachen, die die andere ned kann.
daher muss man sich auf einen Standart festlegen, mit dem man (je nach Zielrichtung) die einzelnen Gruppen bedienen kann. => XHTML / XML (beides ohne JS)

Wenn man diese Zielsetztung hat, kann man mit AJAX nichts anfangen, da man dadurch diese Leute aussperrt.


Ein Vorurteil möchte ich noch dementieren (gehört eigentlich ned ganz dazu, aber könnte folgen)
Nur weil eine Seite auch behinderten gerecht ist, is sie ned unhübsch bzw. spricht den "normalen" user nicht an.
Das stimmt nicht!
Schaut euch Zengarden an, diese kann man mit neuen Browsern (FF, MZ), mit älteren (IE, NS4) und auch Lesegeräten anschaun.

Barrierefreiheit hat erst einmal nicht so viel mit den eingesetzten Mitteln zu tun, sondern eher mit korrekten semantischen Zusammenhängen. Dabei bedeutet der Einsatz von Javascript nicht *zwangsläufig* das Abkommen von semantisch korrektem (X)HTML.

Leider bildet die aktuelle Browsergeneration immer noch eine andere Barriere, nämlich die der gemeinsamen Untermenge an Features, die diese bereitstellen. Vergleichbar mit dem X3-Standard in der Druckindustrie, die den Einsatz vorhandener PDF/PS-Features beschränkt, um maximale Kompatibilität zu gewährleisten.

Ich würde mir darum also keine großen Gedanken machen; wenn dein CMS schönes HTML schreibt und somit die Möglichkeit besteht, auch gut maschinenlesbare Quelltexte zu generieren, kannste Ajax etc. ja immer noch als optionales Feature verwenden. Da das ganze eh nur (so denke ich) im Backend Verwendung findet, sehe ich da durchaus Gestaltungsspielraum, und zur Not kannst du immer noch eine Alternative "ohne Schnickschnack" dem Endbenutzer zur Verfügung stellen.

@Reimer: Wegen MVC müssen wir beide uns mal unterhalten. Ich hatte es schon mal für unser CMS ins Auge gefasst und möchte mal hören/lesen wie du dir das genau vorstellst.

@eBoy: Solltest du nicht mal genauer definieren, was Module machen können sollen?

Nö, muss ich nicht *g*

Ok, aber ich denke da gibt es erstmal nicht vieles, das jetzt schon besonders wichtig wäre...

Module können alles mögliche sein (News, Artikel, Umfrage, Forum, DL-Archiv,...)
Das Rechtesystem prüft Zutritts-/ Aktionsrechte. Es gibt eine DB-Tabelle module mit den grundlegenden Informationen. Jedes Modul wird dazu wohl auch noch (mindestens) eine Tabelle erhalten für weiteres und z.B. die Rechte für die verschiedenen Aktionen des Moduls.
Aktionen können "Subseiten" des Moduls sein, oder das lesen, editieren oder schreiben in einem Board usw.

Grundsätzlich soll der Aufruf eines Moduls geprüft werden und dann das Modul geladen werden. Was weiter geschieht, hängt vom Module und der entsprechenden Datei ab.

Was soll ich dazu momentan noch schreiben? Habt ihr noch Fragen? Ich bin @Meisterschule und habe somit wenig Zeit. Evtl später mehr...

Gruß

Das hab ich ja auch nie behauptet. Solange eine Alternative vorhanden ist, bin ich sogar für den Einsatz für AJAX. Dabei spielt es imho keine Rolle ob das nun im Backend ist oder nicht. Woher willst du wissen ob nicht doch mal jemand das Backend benutzt der einen Browser ohne Javascript benutzt?

Hi @ll

Generell würde ich das Frontend Barrierefrei machen.

Im Backend, kann man noch immer definieren welche Komponenten Aktiv sein müssen.
Siehe RedDot
IE 6.0
WIN XP, mit SP1 aber ned SP2
JS Aktiviert