Mein CMS Entwicklungs-Thread

[Basti]

Hallo allerseits,

mein Abitur nähert sich allmählich der Vollendung (es steht nun nur noch die mündliche Prüfung aus), sodass ich in naher Zukunft wieder mehr Zeit für meine Programmierprojekte finden werde.

Einige von euch kennen vielleicht noch mein CMS-Projekt, das sf-d FlexiPanel, welches aufgrund meines Abiturs leider lange Zeit nicht weiterentwickelt werden konnte. Die Umstellung auf PHP 5 und die Entwicklung eigener Klassen beanspruchte allerdings auch viel Zeit.

Bei dem sf-d FlexiPanel handelt es sich um ein Open Source Content Management System, das in erster Linie für die Betreiber kleinerer, auch privater Seiten, konzipiert ist. Es soll eine Alternative zu den großen CMS darstellen, die für viele Benutzer häufig einfach zu umfangreich sind, und sich auf die wesentlichen Funktionen einer gängigen Seite beschränken (bspw. News, Gästebuch, Textseiten).
Außerdem war bisher vorgesehen, dass die einzelnen Seiten in eigene Designs und Seiten eingebunden werden, also kein zusammenhängendes Frontend-System existiert. Ich spiele derzeit aber mit dem Gedanken, beides zu ermöglichen, damit auch weniger erfahrende Benutzer die Möglichkeit haben, das System einzusetzen. Kommentare diesbezüglich sind erwünscht.

Nach meinen Abitur soll die Entwicklung des CMS endlich weiter gehen. In der Zwischenzeit konnte ich bereits ein paar neue Ideen sammeln, die in der neuen Version umgesetzt werden sollen. In technischer Hinsicht soll außerdem endlich MySQLi zum Einsatz kommen und sollen möglichst viele Stärken der Objektorientieren Programmierung genutzt werden.

Vorher möchte ich allerdings ein umfassendes Konzept für das fertige CMS entwickeln, damit während der Entwicklung nicht zu häufig Umstrukturierungen notwendig werden. Deshalb wende ich mich nun erst einmal an euch, da ich gerne auf eure Hilfe setzen würde.

Mein erstes Anliegen ist der Name des CMS selbst. Bisher hies dieses ja sf-d FlexiPanel, in Anlehnung an den modularen Aufbau und die dadurch vorgesehene Flexibilität. Für die neue Version spiele ich allerdings mit dem Gedanken einer Umbenennung.
Ich würde deshalb gerne von euch wissen, was ihr von dem aktuellen Titel haltet, wie einprägsam und passend er für euch ist. Eine neue Idee meinerseits war noch sly fox (zu Deutsch "schlauer Fuchs"), zu der mich ebenfalls eure Meinung interessieren würde. Der Titel sollte in jedem Fall kurz und prägnant sein, vor allem aber auch noch nicht zu viel Namenskonkurrenz besitzen.
Für weitere Vorschläge bin ich jederzeit offen.

Wenn der Name feststeht, geht es dann um ein passendes Logo. Ich selbst bin leider nicht der beste Grafiker, sodass ich mich wirklich freuen würde, falls jemand Spaß an der Erstellung eines entsprechenden Logos, vielleicht auch an der Mitarbeit am späteren Design hätte. Dies ergibt sich dann aber noch im weiteren Verlaufe der Entwicklung.

Ich habe vor, diesen Thread für die gesamte Entwicklung meines CMS zu nutzen, sodass ich neue Ergebnisse und Fragen an euch immer hier veröffentlichen werde. Außerdem ist dieser Thread dazu gedacht, euch die Möglichkeit zu geben, Anregungen und Vorschläge für das neue CMS kundzugeben.
Ich würde mich deshalb sehr freuen, falls sich der ein oder andere auf diese Weise an der Entwicklung beteiligen möchte.

[cgu]

Wir entwicklen momentan gerade selbst ein CMS, aber kein Opensource-System. Jedoch ist es immer interessant, was im OpenSource-Bereich so los ist.

Ich kann zwar keine Leistungen anbieten, aber möchte vielleicht einen kleinen Tipp bzw. mal meine Meinung zum Namen kundtun .

Der aktuelle Name ist nicht wirklich gut. Er ist zu kompliziert. Das neu angedachte Name ist besser, jedoch würde ich persönlich einen deutschen bzw. deutsch klingenden Namen bevorzugen (haben wir auch gewählt). Natürlich liegt das aber auch daran, dass unser System ausschließlich in Deutschland vertrieben wird. Bei OS-Systemen ist daher das Englische OK, denke ich.

[Andreas W.]

Hallo!
Ich finde es schön, dass dass du dein CMS weiter entwickeln willst und würde dir gerne auch dabei helfen. Im folgenden erstmal einige Anregungen.

Über den Namen würde ich mir erstmnal keine Sorgen machen. Ich denke es wäre am wichtigsten sich erstmal um die Entwicklunmg des Systems zu kümmern. Das alte Systemn war doch sehr mager und bot nur wenige Features und war auch kaum erweiterbar.

An dieser Stelle solltest du auch ansetzen. Du solltest vorallem ein abstraktes Konstrukt von Klassen schreiben, die es dir ermöglichen neue Module schnell und einfach zu erstellen. So können auch erfahrenere Programmierer eigene Module in kurzer Zeit implementieren und werden so auch auf dein CMS zurückgreifen. Für den unerfahrenen Nutzer kannst du gewisse standrad Pakete zum Download anbieten. Bei der erstellung dieser Klassen kann ich dir gerne helfen. Ich bin auch gerne bereit selbst einige Klassen zu diesem Projekt beizusteuern. Ein Frontend-System würde ich mir dabei erstmal schenken. Die wichtigsten Implementationen wären zum Beispiel:

• DataMapper (siehe Martin Fowler)
• Formular-klassen
• Filter-Klassen
• Validator-Klassen

Mit diesen Klassen denkst du bereits die Verarbeitung von Daten, die Verwaltung dieser Daten in relationalen Datenbanken, sowie die Abfrage solcher Daten ab. Aus diesen Klassen lassen sich Pakete, wie zum Beispiel ein News-System oder ähnliches in wenigen Stunden umsetzen.

Ich hoffe ich konnte dir etwas helfen.

MfG, Andy

[Basti]

Vielen Dank für eure Antworten, ich hatte schon befürchtet, mein Text wäre zu lang geworden

Einen Namen würde ich im Voraus eigentlich schon gerne festlegen, damit ich eine konkrete Projekt-Bezeichnung habe und man das System direkt mit diesem Namen assoziieren kann. Notfalls kann ich aber auch erstmal einen Entwicklungs-Namen vergeben, der eventuell später noch verändert wird. Für gute Ideen bin ich jedenfalls nach wie vor offen.

Mit den Klassen werde ich dann wohl einige Zeit beschäftigt sein, da ich aber sowieso noch nicht allzu lange objektorientiert in PHP programmiere kann ich auf diese Weise sicherlich noch reichlich neue Erfahrungen und Erkenntnisse sammeln.

Dein Hilfe-Angebot weiß ich sehr zu schätzen Avedo, dafür schonmal vielen Dank. Ich werde allerdings versuchen, die Programmierung so weit wie möglich selbst vorzunehmen, da mich bei so etwas immer der Ehrgeiz packt. Bei Fragen oder wenn ich Rückmeldungen benötige, melde ich mich aber einfach wieder hier

[Basti]

So, damit niemand denkt, es ginge nicht weiter, gibt es nun nochmal einen kleinen Statusreport.

In den letzten Wochen konnte ich bereits einige Grundstrukturen und PHP Klassen fertigstellen. Den Template-Syntax habe ich ebenfalls ein wenig überarbeitet.
Aktuell beschäftige ich mich noch mit der Fertigstellung der Grund-Klassen und experimentiere ein wenig mit TinyMCE (einem WYSIWYG-Editor, der im CMS zum Einsatz kommen soll).
Zuvor habe ich bereits ein simples Layout entworfen, mit dem ich während der Entwicklung vorerst arbeiten werde. Später wird dann noch ein fertig ausgearbeitetes Design folgen. Für die Entwicklungszeit wird das Projekt vorerst unter dem Namen sly fox laufen. Ob dies der finale Name des CMS wird, steht noch nicht fest.

Das Hauptmenü klappt bei Bedarf auf und zeigt die Unterpunkte an. Die einzelnen Unterseiten sollen über einen Dokumenten-Baum gesteuert werden (dieser erscheint dann auf der Startseite). Außerdem ist vorgesehen, dass Module auch mehrfach verwendet werden können, beispielweise wenn man zwei unabhängige News-Seiten erstellen möchte.
Des weiteren wird Mehrsprachigkeit unterstützt. Da ich sowieso vorhatte, sämtliche Sprachausgaben und Meldungen in zentrale Dateien auszulagern, bot sich die Unterstützung von Mehrsprachigkeit an.
Die Konfigurationsdatei und der Login sind bereits soweit fertiggestellt, sodass ich nach meinem baldigen Abitur mit der Umsetzung der Administrationsseiten beginnen werde.

Derzeit überlege ich noch, in wie weit AJAX zum Einsatz kommen könnte. Mit JavaScript werde ich in jedem Fall arbeiten. Wo AJAX nützlich sein könnte, wird sich vermutlich noch während der Entwicklung ergeben. An einigen Stellen könnte es die Benutzerfreundlichkeit aber sicherlich verbessern.

Zu guter Letzt hänge ich euch noch einen Screenshot vom aktuellen Administrationsbereich an. Das ganze ist wie gesagt vorerst nur für die Entwicklungsphase gedacht, die Struktur wird beim späteren Design aber vermutlich beibehalten.

sly-fox_wip.jpg

sly fox - Administration (WIP)

(54.17 KiB) 140-mal heruntergeladen

Eigene Ideen können natürlich nach wie vor in diesem Thread eingebracht werden. Sobald die Entwicklung weiter fortgeschritten ist, kann ich aber auch nähere Informationen zu meinem neuen CMS geben.

[Basti]

In der Hoffnung, dass mein Monolog in diesem Thread bald ein Ende findet, gibt es heute nochmal einen neuen Statusreport über meine Entwicklungsarbeit.

In den letzten Tagen konnte ich bereits gute Fortschritte erzielen und habe mich an das Konzept für die Inhaltsverwaltung gemacht.
Die Seitenstruktur soll aus beliebig vielen Ebenen bestehen. Einzelnen Seiten können hierbei unabhängig voneinander Module zugewiesen werden, bspw. einfache Textseiten, eine Newsübersicht oder eine Bildergalerie. Im Gegensatz zum Vorgänger können die Module nun also auch mehrfach verwendet werden.
Die Verwaltung dieser Seite wird über eine Baum-Ansicht erfolgen, um für die nötige Übersichtlichkeit zu sorgen. Per Rechtsklick soll für jede Seite ein spezifisches Kontextmenü erscheinen, in dem die Inhalte editiert werden können, die ganze Seite verschoben oder zeitweise unsichtbar geschaltet werden kann. Genaueres wird sich vermutlich erst bei der weiteren Entwicklung ergeben, zumal ich erst vor einigen Tagen jQuery als JS-Framework integriert habe und mich noch etwas in dieses einarbeiten muss. Außerdem überarbeite ich derzeit noch die TemplateEngine, um dynamische Substrukturen zu ermöglichen (wie es z.B. bei dem Baum-Menü nötig ist).
Mit TinyMCE habe ich ebenfalls ein paar weitere Experimente durchgeführt, allerdings muss ich noch einen Filter für unerwünschte HTML-Tags (bspw. JS) in den Einträgen schreiben. Dabei stellt sich mir auch noch die Frage, ob ich als Alternative zu TinyMCE als Editor herkömmliche HTML-Eingaben oder BB Code anbieten soll. Ich möchte nämlich nach wie vor die Möglichkeit erhalten, sauberen Quellcode zu erzeugen, sodass eine derartige Lösung sinnvoll wäre. Zwar ermöglicht TinyMCE auch eine Quelltext-Ansicht, allerdings werden die Eingaben nach dem Übernehmen trotzdem modifiziert. Ein paar Meinungen und Einschätzungen von eurer Seite zu diesem Thema würden mich sehr interessieren.

Damit auch die Augen ein wenig bedient werden, gibt es hier nochmal einen aktuellen Screenshot vom Backend. Das Design ist wie gesagt noch nicht endgültig, da es nur eine Grundlage für die aktuellen Entwicklungsarbeiten darstellt.

sly-fox_wip2.jpg

sly fox - Administration (WIP 2)

(79.94 KiB) 94-mal heruntergeladen

[markus_o]

Das hört sich schonmal echt gut an. Bei TinyMCE hat mich das auch schon sehr oft gestört, dass der Quelltext bearbeitet wird, das wäre echt toll, wenn es bei SlyFox eine richtige HTML-Funktion gäbe.

[Andreas W.]

Hallo Basti,

Ich muss gestehen, dass mir in deinen bisherigen Beiträgen ein bisschen das Programmiertechnische fehlt. Rechtsklicks, Verwaltung über eine Baum-Ansicht, mehrfache Verwendbarkeit von Modulen klingt alles wunderbar, jedoch fehlen mir einfach tiefergehende Informationen und auch einige, wie ich finde sehr sehr wichtige Funktionaliäten.

Wie gedenkst du zum Beispiel dein Rechtesystem zu gestalten? Ich beschäftige mich momentan selbst mit diesem Thema und es ist sehr umfangreich und komplex. Um überhaupt irgendeine Entscheidung in dieser Richtung treffen zu können muss man sich erstmal über die unterschiede zwischen Gruppen, Rechten und Rollen, der Zusammenwirkung etc. im klaren werden. Rollen weisen einem Benutzer Rechte zu. Moderatoren dürfen zum Beispiel lesen, bearbeiten und sperren, Administratoren an den Einstellungen pfuschen. Ein Nutzer kann zu einem bestimmten Zeitpunkt immer nur eine einzige Rolle und die damit verbundenen Rechte besitzen. Jedoch kann eine Rolle aus mehreren anderen Rollen zusammengesetzt sein. Die Rolle eines Foren übergreifenden Moderators setzt sich zum Beispiel aus den Rollen der Moderatoren zusammen, die nur in einem Forum Moderatoren Rechte besitzen. Was sind dann aber Gruppen? Gruppen werden oft mit Rollen gleichgesetzt, sind aber nach der eigentlichen Definition nur Helfer in einem Rollen basierten System. Einige Benutzer eines Forums können sich zum Beispiel zu einer Arbeitsgruppe zusammenschließen. Arbeitet ein Nutzer nun innerhalb der Arbeitsgruppe, schreibt News oder Artikel, so erhält er durch eine Role festgelegte Rechte. Verlässt er den Bereich der Arbeitsgruppe nimmt er entweder wieder seine "Standard" Rolle ein oder wechselt in eine andere, durch eine Gruppe zugewiesene Rolle. Ich wurde im übrigen gestern auf den Artikel Rollen sind keine Gruppen | Mike Wiesner - IT-Security, Spring, Acegi aufmerksam gemacht, den ich dir nur wärmstens empfehlen kann.

Des weiteren würde mich zum Beispiel interessieren, wie du deine Sitzungsdaten speichern möchtest. Greifst du auf die standardmäßig Dateisystem basierte Implementierung von PHP zurück oder greifst du auf eine eigene, Datenbank basierte implementierung zurück. Ich halte es zum Beispiel nicht nur für sicherer, sondern auch für praktischer auf eine Datenbank basierte Version von Sessions zurück zu greifen, zumal PHP ja sogar bereits alle Funktionen um eine solche Implementierung zu ermöglichen bereit stellt.

Besonders interessant ist auch immer, wie zum Beispiel die verschiedenen System-Objekte verwaltet werden. Erstellst du auf jeder Seite ein neues Datenbank-Objekt oder lädst du dies, wie auch Konfigurationsdaten etc. aus einer zentralen Registry, die die verschiedenen System-Objekte zentral verfügbar macht und somit auch unnötige Instanzierungen verhindert?

Wie du siehst habe ich allgemein sehr viele Fragen zu deinem allgemeinen Grundsystem und dessen Aufbau. Dies ist mir so wichtig, da ohne ein gutes Grundsystem, von dem viele User leider nie etwas sehen werden für dich die Erweiterbarkeit und Flexibilität deines Systems bestimmt. Implementierst du zum Beispiel eine geeignete Klasse zum Laden von Konfigurationen, eine zum Verwalten von System-Objekten, eine zum dynamischen Erstellen von Formularen und eine Klasse, die dir den Datenbankzugriff, sowie das generieren von Domain-Objekten erleichtert, so wirst du in Zukunft in weniger als drei Stunden einfache aber sehr brauchbare Module implementieren können.

Was mich bisher an deinem System sehr gestört hat und immernoch stört, dass die Schnittstellen, die du verwendest nicht wirklich dokumentiert sind, sodass es schwierig, bis unmöglich ist ohne großen Aufwand das System um eigene Module zu erweitern. Das ist für mich allerdings ein wesentlicher Punkt. Man mag jetzt vielleicht sagen, dass das System ja vorallem für Leute ohne überragende PHP, HTML und CSS Kenntnisse nutzbar sein soll, aber das spricht ja nicht dagegen. Zudem verbaust du dir ja auch selbst die Möglichkeit ohne große Änderungen dein System zu erweitern. Teilweise machst du es sogar unnötig korpulent. Alle Module sind im Prinzip bereits installiert und müssen nur noch aktiviert werden. Was ist aber wenn ich nur ein paar Seiten über mich verwalten möchte. Dann habe ich auf meinem Webspace ungenutzte Packages zum verwalten von Downloads, Links, einem Gästebuch und einigen anderen Funktionitäten rumliegen. Wieso ermöglichst du es nicht zu einer sehr schlanken standard Ausführung deines Systems diverse Module hinzuinstallieren lassen zu können. Dazu müsstest du nur einen Upload von tar-Archiven ermöglichen, diese entpacken und eine install.php aufrufen, die dann alle wichtigen Dateien in die entsprechenden Ordner kopiert, die Verändeungen an der Datenbank vornimmt und am Ende vom System gelöscht wird.

Zum Schluss möchte ich noch auf deine Frage bezüglich der Verwendung von HTML-Code innerhalb des Systems eingehen. Da innerhalb des Systems nur Leute arbeiten, die an ihren eigenen Dingen rumpfuschen kannst du eigentlich alles sowohl JavaScript als auch HTML ohne Bedenken erlauben, aber, und jetzt kommt es, da dein System auch von Leuten genutzt werden soll, die sich in diesem Bereich wenig bis garnicht auskennen, solltest du auf die Möglichkeit HTML und JavaScipt in den System eigenen Editoren zu nutzen verzichten. Eine unerfahrene Hand kann mit den falschen Tags nämlich schonmal ein ganzes System zerschießen. Natürlich kann man wild Filtern, jedoch einige Tags zulassen und andere nicht, aber da geht man bei diesem Arbeitsaufwand unter. Schmeiß gleich den gesammten HTML-Code vor dem Speichern der Inhalte raus und biete stattdessen die Möglichkeit auf BB-Code zurück zu greifen. Dazu würde ich dir empfehlen eine abstrakte Klasse zu implementieren, die selbst keine oder nur sehr komplexe BB-Codes direkt unterstützt. So ermöglichst du es nämlich deinen fortgeschritteneren Nutzern die Auswahl an BB-Tags zu erweitern. Außerdem solltest du auf wildes Einfügen der Tags in die entsprechenden Textfelder via JavaScript verzichten, eine gute Dokumentation oder Hilfe erspart die und allen anderen einiges an Stress und Arbeit.

Mhhh ist doch ein sehr langer Post geworden, aber ich hoffe ich konnte dir auf der einen Seite helfen und auf der anderen Seite Denkanstöße für die zukünftige weiterentwicklung deines Systems geben. Dabei würde ich mich persönlich, wie bereits gesagt, über nähere Informationen über die Basis deines Systems freuen. Auf eine offene Diskussionen über allgemeinere Aspekte eines Systems, dessen Module oder Basisklassen, lasse ich mich natürlich auch sehr gerne ein.

MfG, Andy

[Basti]

Danke für deine sehr ausführliche Antwort, Avedo. Ich werde mal versuchen, einige deiner Fragen zu beantworten.

Das Rechtesystem ist bislang noch nicht fertig konzipiert. Zunächst muss ich noch eine gute Lösung für die neue Modulverwaltung finden, da das Rechtesystem ja auch von deren Aufbau abhängig sein wird. Ich habe allerdings vor, das Rechtesystem möglichst einfach zu halten, damit es nicht für Verwirrung bei den Benutzern sorgt (was in einigen CMS ja durchaus der Fall ist).
Danke übrigens für den Link, ich werde mich bald einmal intensiver mit dem Thema auseinandersetzen.

Die Sitzungsdaten werden in einer Session gespeichert, dies ist allerdings nur die User-ID und die Client-IP (um Manipulationen zu vermeiden). Alle übrigen Daten werden anhand der User-ID mit einer separaten Klasse aus der Datenbank ausgelesen bzw. dort eingetragen.
Wie würde denn deine Datenbank-basierte Implementierung aussehen? Bislang habe ich davon in diesem Zusammenhang noch nichts gehört.

Die grundlegenden System-Objekte und Konfigurationsdaten werden über eine zentrale Datei eingebunden. Lediglich seitenabhängige Objekte werden erst auf den jeweiligen Seiten initialisiert.

Ich hoffe ich konnte damit wenigstens ein wenig Licht ins Dunkle bringen. Es ist aber auch wirklich so, dass viele Elemente noch fehlen und erst umgesetzt werden müssen. Ich werde mich aber bemühen, das System so flexibel wie möglich zu gestalten (was auch für den späteren Frontend-Bereich gelten soll).
Achja, eine ausführliche Dokumentation hast du bisher vermisst, weil ich beim FlexiPanel zeitlich einfach nicht dazu gekommen bin. Außerdem stellte sich ja nach kurzer Zeit heraus, dass das System bald komplett neu geschrieben werden würde, sodass es nicht mehr sinnvoll erschien. Mein neues CMS werde ich nach Abschluss der Programmierarbeiten aber ausführlich dokumentieren. Das ganze erfordert eben nur noch einmal enorm viel Zeit und momentan ist ja erst einmal das Programmieren von größerer Bedeutung.

[Andreas W.]

Das die Sitzungsdaten in einer Session gespeichert werden, davon bin ich auch ausgegangen , aber die Frage war, wie die Sessions gespeichert werden.

PHP stellt mit der Funktion session_set_save_handler() die Möglichkeit zur Verfügung die standardmäßig Dateisystem basierten Session-Funktionen zu überschreiben. Ich habe anstatt der im Manual vorgestellten Funktionen eine Klasse geschrieben, die es mir ermöglich Sessions in einer Datenbank zu speichern. Das ist mir auch gut gelungen. Um das ganze zu verwenden arbeitet man eigentlich ganz normal mit den Sessions. Man muss zuvor nur eine Instanz der Klasse erzeugen.

Code: Alles auswählen

/* instance SessionHandler */
new SessionHandler();
   
/* assign some values to the session */
$_SESSION['name'] = 'avedo';
$_SESSION['mail'] = 'test@avedo.net';
   
/* get some session value */
echo 'logged in as ' . $_SESSION['name'];
   
/* delete session */
session_destroy();

Das speichern von Sessions in der Datenbank hat meiner Meinung nach mehrere Vorteile. Zum einen kann man bei einem Mehrbenutzersystem auch direkt auf die Session-Daten zugreifen und zum Beispiel alle Benutzer und Gäste ausgeben lassen, die momentan online sind. Außerdem halte ich diese Art des Session-Handlings für deutlich sicherer als die Dateisystem basierte Variante, da es schwerer ist an die Daten zu kommen. Natürlich kann man auch ein Interface basteln, dass dann wohl in etwa wie folgt aussähe.

Code: Alles auswählen

interface SessionHandler
{
     public function open($save_path, $session_name);
     public function close();
     public function read($id);
     public function write($id, $sess_data);
     public function destroy($id);
     public function gc($maxlifetime);
}


Auf Basis dieses Interfaces könnte man nun zwei verschiedene SessionHandler implementieren, einen Dateisystem basierten und einen Datenbank basierten. Bisher habe ich allerdings noch keinen Sinn darin gesehen. Ich habe meine SessionHandler Klasse mal unten angehängt. Du kannst sie gerne nutzen.

MfG, Andy

Code: Alles auswählen

/*
* The SessionHandler class imlements all methods to use a
* database based session management instead of using text files.
* This has the benefit thatt all session data can be accessed
* at a central place. This class is supported since the PHP version 5.0.5
* because it uses the register_shutdown_function() function to ensure that
* all session values are stored before the PHP representation is destroyed.
*
* @package SessionHandler
* @version 0.1
* @author Andreas Wilhelm <Andreas2209@web.de>
* @copyright Andreas Wilhelm
* @link http://avedo.net
*/ 
class SessionHandler
{
   /**
    * @var mysqli $mysqli The MySQLi object that is used to access the database
    * @access private
    */
   private $mysqli = null;

   /**
    * Sets the user-level session storage functions which are used
    * for storing and retrieving data associated with a session.
    *
    * @access public
    * @param mysqli $mysqli The MySQLi object that is used to access the database
    * @return void
    */
   public function __construct(mysqli $mysqli)
   {
      /* assign the mysqli object */
      $this->mysqli = $mysqli
   
      /* set session handler to the class methods */
      session_set_save_handler(
         array($this, 'open'),
         array($this, 'close'),
         array($this, 'read'),
         array($this, 'write'),
         array($this, 'destroy'),
         array($this, 'gc')
      );
      
      /* start a new session */
      session_start();
      
      /* make sure that the session values are stored */
      register_shutdown_function( array($this, 'write') );
      register_shutdown_function( array($this, 'close') );
   }
   
   /**
    * Is called to open a session. The method
    * does nothing because we do not want to write
    * into a file so we doesn't need to open one.
    *
    * @access public
    * @param String $save_path The save path
    * @param String $session_name The name of the session
    * @return Boolean
    */
   public function open($save_path, $session_name)
   {
      return true;
   }
   
   /**
    * Is called when the reading in a session is
    * completed. The method calls the garbage collector.
    *
    * @access public
    * @return Boolean
    */
   public function close()
   {
      /* call the garbage collector */
      $this->gc(0);
      
      return true;
   }
   
   /**
    * Is called to read data from a session.
    *
    * @access public
    * @access Integer $id The id of the current session
    * @return Mixed
    */
   public function read($id)
   {
      /* create a query to get the session data */
      $select = "SELECT
            *
         FROM
            sessions
         WHERE
            id = '" . $id . "'
         LIMIT 1;";
      
      /* send select statement */
      $result = $this->mysqli->query($select);
      
      /* a session was found */
      if( count($result) > 0 )
      {
         return $result[0]["value"]
      }
      
      /* no session found */
      return '';
   }
   
   /**
    * Writes data into a session rather
    * into the session record in the database.
    *
    * @access public
    * @access Integer $id The id of the current session
    * @access String $sess_data The data of the session
    * @return Boolean
    */
   public function write($id, $sess_data)
   {
      /* check if some data was given */
      if( $sess_data == null )
      {
         return true;
      }
   
      /* query to update a session */
      $update = "UPDATE
            sessions
         SET
            last_updated = '" .time() . "',
            value = '" . $sess_data . "'
         WHERE
            id =  = '" . $id . "';";
      
      /* send select statement */
      $result = $this->mysqli->query($update);
      
      /* database error */
      if( $result === false )
      {
         return false;
      }
      
      /* current session was updated */
      if( $this->mysqli->affected_rows > 0 )
      {
         return true;
      }
      
      /* session does not exists create insert statement */
      $insert = "INSERT INTO
            sessions
            (id, last_updated, start, value)
         VALUES
            ('" . $id . "', '" . time() . "', '" . time() . "', '" . $sess_data . "');";
            
      /* send insert statement */
      $result = $this->mysqli->query($insert);
      
      return $result;
   }
   
   /**
    * Ends a session and deletes it.
    *
    * @access public
    * @access Integer $id The id of the current session
    * @return Boolean
    */
   public function destroy($id)
   {
      /* create a query to delete a session */
      $delete = "DELETE FROM
            sessions
         WHERE
            id = '" . $id . "';";
            
      /* send delete statement */
      $result = $this->mysqli->query($delete);
      
      return $result;
   }
   
   /**
    * The garbage collector deletes all sessions from the database
    * that where not deleted by the session_destroy function.
    * so your session table will be stay clean.
    *
    * @access public
    * @access Integer $maxlifetime The maximum session lifetime
    * @return Boolean
    */
   public function gc($maxlifetime)
   {
      /* period after that a session pass off */
      $maxlifetime = strtotime("-20 minutes");
      
      /* delete statement */
      $delete = "DELETE FROM
            sessions
         WHERE
            last_updated < '" . $maxlifetime . "';";

      /* send delete statement */
      $result = $this->mysqli->query($delete);
      
      return $result;
   }
}


[Basti]

Das klingt nach einer wirklich guten Alternative zu den Datei-basierten Sessions. Bisher war mir diese Möglichkeit Sessions zu verwalten unbekannt. Interessant ist bei diesem Ansatz, dass man Benutzer-Statistiken auf Basis der Session-Daten erzeugen kann (für den Backend-Bereich).
Ich werde mal schauen, ob ich den SessionHandler bald noch in mein CMS integriere, deine Klasse wird mir dabei sicherlich helfen. Die Integration ist ja insofern unproblematisch, als dass ich bis auf die Initialisierung des SessionHandlers in den bisherigen Scripten keine Änderungen vornehmen muss.

Eben konnte ich übrigens endlich die Generierung des Baum-Menüs mit beliebig vielen Unterebenen fertigstellen (zuvor war nur eine Unterebene möglich). Ich musste zwar auf eine Lösung mit meiner TemplateEngine verzichten - dafür war das Problem zu komplex und spezifisch - mit ein paar zusätzlichen Methoden ließ sich das ganze dann aber doch recht gut realisieren.

Über weitere Entwicklungsfortschritte werde ich euch hoffentlich bald wieder berichten können

[Andreas W.]

Die Klasse oben enthielt noch einen Fehler, den ich bisher noch nicht behoben hatte. Die Methode read() muss nämlich einen String zurückliefern. Der Fehler wurde oben im Quellcode behoben.
MfG, Andy

[Basti]

Ich bins mal wieder.

Bereits vor ein paar Tagen habe ich eine kleine aber feine Klasse für den Login geschrieben. Diese besteht im Wesentlichen aus den Methoden perform($username, $password), logout() und refresh(). perform() übernimmt die Überprüfung der Login-Eingaben und registriert bei Erfolg die nötige Session. Andernfalls wird der Fehlversuch in der Datenbank geloggt. logout() ist eigentlich selbstsprechend und löscht die aktuelle Benutzer-Session.
Mit refresh() findet schließlich die Weiterleitung zu der bei der Initialisierung angegebenen URL statt (wenn nicht angegeben ist dies der HTTP-Referrer).

Zu dem Rechtesystem habe ich mir auch schonmal ein paar grundlegende Gedanken gemacht. Andy hatte mich bereits auf den Unterschied zwischen Rollen und Gruppen hingewiesen, wobei ich vorhabe, Rollen für allgemeine Rechte zu verwenden, Gruppen und eine Rechtezuweisung an einzelne Nutzer hingegen für die Inhaltsverwaltung (also die Bearbeitung der Seiteninhalte über die ihnen zugewiesenen Module). Rollen-Rechte wären beispielsweise der Zugang zur Benutzerverwaltung (differenziert in Hinzufügen, Bearbeiten, Entfernen), zur Systemkonfiguration oder zum Profil. Es soll aber auch Rechtezusammenfassungen geben, mit der dann automatisch der Zugang zu sämtlichen Inhaltsseiten erlaubt werden könnte. Außerdem soll es einen Admin-Flag geben, der automatisch alle Rechte enthält. Standard-Rollen könnten dann zum Beispiel Gast, normaler Nutzer und Administrator sein, bei Bedarf soll es aber auch möglich sein, eigene Rollen zu erstellen.
Mit den Gruppen bzw. Benutzer-Rechten könnten dann spezifischen Modul-Rechte auf den Unterseiten geregelt werden. Dazu müsste ich mir allerdings nochmal genauer Gedanken machen. Es stellt sich hierbei nämlich die Frage, ob man nur den Zugang zu einzelnen Seiten (optional mit allen Unterseiten eines Elternglieds) regelt, und dann allgemein Modul-Rechte vergibt, also ob man beispielsweise auf allen Seiten, zu denen man Zugang hat und auf denen das News-Modul eingesetzt wird, News hinzufügen und bearbeiten, nicht aber entfernen darf. Vielleicht hat ja jemand noch bessere Ideen oder kann mir ein paar Tipps geben. Über die Datenbankstruktur für das Rechtesystem muss ich mir dann auch noch Gedanken machen.

[Basti]

Heute werde ich mal ein wenig zu meiner TemplateEngine schreiben, an der ich die letzten Tage noch einmal intensiver gearbeitet habe. Ursprüngliche Inspirationsquelle für die Syntax war die TemplateEngine TinyButStrong und die des phpBB 3. Was den Funktionsumfang und die Umsetzung angeht, bin ich allerdings eigene Wege gegangen, damit die Klasse alle Ansprüche erfüllt, die ich an meine TemplateEngine stelle.

Ich versuche einmal, die wichtigsten Elemente kurz vorzustellen. Eine ausführliche Dokumentation wird noch folgen, wenn ich mein CMS fertiggestellt habe. Eckige Klammern sollen jeweils optionale Teile kennzeichnen.
Fangen wir mit einfachen Platzhaltern an. Diese müssen PHP-seitig nicht über spezielle Methoden zugewiesen werden, sondern können einfach im Template notiert werden. Auf diese Weise ist der Zugriff auf globale Variablen, Arrays, Konstanten, aber auch Objekte und deren Variablen, Arrays und Methoden möglich. Dies erleichtert die Arbeit mit der TemplateEngine enorm. Damit die Syntax möglichst einfach bleibt, wird auf die von PHP bekannten Schreibweisen zurückgegriffen. Nachfolgend mal ein paar Code-Beispiele:

Code: Alles auswählen

Variable:  {$var}
Array:     {$array['1st_key']['2nd_key']}
Konstante: {CONSTANT}
Objekt:    {$obj->var}
           {$obj->array['1st_key']['2nd_key']}
           {$obj->method([$param]}

Auf die Inhalte der Platzhalter können darüber hinaus Funktionen oder Methoden von Objekten angewandt werden. Einige häufig verwendete Funktionen werden standardmäßig integriert sein, eigene können einfach angegeben werden. So sähe beispielsweise die Umwandlung eines Timestamps in ein Datums-Format aus:

Code: Alles auswählen

{$var;date=d.m.Y}

Weiter geht es mit einem weiteren Grundpfeiler, den Blöcken. Diese ermöglichen die leichte Realisierung von sich wiederholenden Ausgaben (bspw. für News, Benutzer-Listen, etc.). Blöcke sind durch einen öffnenden und schließenden Tag gekennzeichnet. Auf die Inhalte eines Blocks (die ist ein der TemplateEngine zugewiesener Array) kann in Form eines "simulierten" Objekt zugegriffen werden. Die Schreibweise entspricht der einfacher Platzhalter.

Code: Alles auswählen

PHP:
$template->add_block('errors', $array_with_errors);

TEMPLATE:
<ul>
<!-- BEGIN:errors -->
  <li>{$errors->value}</li>
[<!-- IF EMPTY:errors -->
No errors!]
<!-- END:errors -->
</ul>

Außerdem gibt es einige vergebene Variablen, mit der zum Beispiel der Key oder die Nummer des aktuellen Eintrags angezeigt werden kann. Optional kann auch eine Alternativ-Anzeige festgelegt werden, die greift, wenn der Block (bzw. der zugewiesene Array) leer ist. Dies kann bei MySQL-Abfragen hilfreich sein.

Als nächstes kommen wir zu konditionalen Anzeige-Bereichen. Ähnlich wie Blöcke sind diese durch spezielle Tags gekennzeichnet. Neben einem eröffnendem IF und schließendem ENDIF kann optional auch ein ELSE-Teil vorkommen. In den Bedinungen können ganz normal Platzhalter verwendet werden. Hier ein kleines Beispiel mit integriertem Block:

Code: Alles auswählen

<!-- IF {$message['show']} -->
<div class="message {$message['type']}">
  <ul>
  <!-- BEGIN:errors -->
    <li>{$errors->value}</li>
  <!-- END:errors -->
  </ul>
</div>
[<!-- ELSE -->
No message to show!]
<!-- ENDIF -->

In diesem Beispiel wir ein boolescher Wert überprüft. Wie man es aus PHP kennt, sind aber auch Verneinungen (!{$var}) und Vergleiche durch die Operatoren ==, !=, >, <, >= und <= möglich. Andere Elemente wie die Blöcke werden später vermutlich auch noch an Bedingungen geknüpft werden können.

Als letztes kommen wir noch zu der Einbindung von externen Templates, die übrigens auch an eine Bedingung geknüpft werden kann. Dazu gibt es einen einfachen Tag, der wie folgt aussieht:

Code: Alles auswählen

<!-- TPL:overall_header.tpl[ IF %bedingung%] -->

Dies sind die aktuell wichtigsten Grundelemente meiner TemplateEngine. Ich habe teilweise noch Details außen vorgelassen, um meinen Post nicht unnötig in die Länge zu ziehen, aber auch, weil einige Elemente für die finale Version noch ausstehen.
Über Rückmeldungen zu der Syntax würde ich mich sehr freuen, die Template-Klasse selbst werde ich einmal zeigen, wenn sie weiter fortgeschritten ist. Derzeit läuft sie zwar schon gut, an einigen Stellen sind aber noch Optimierungen vorgesehen.
Kommentare zu meinen Ideen rund ums Rechtesystem (siehe vorletzter Post) sind übrigens nach wie vor erwünscht.

Fortsetzung folgt

[.wired]

Hmm, sollte eine Templateengine denn wirklich nötig sein? Ich weiß, das Thema ist schon sehr ausgelaugt und es fliegt hier irgendwo auch ein Thread rum, in dem ich selber nach Hilfe für eine Templateengine frage, aber inzwischen hat sich meine Meinung denn doch grundsätzlich verändert. Ist denn PHP an sich nicht eigentlich schon eine Templateengine? Wozu noch ein Kleid für das Kleid erfinden? Das wird sogar Performance kosten (bei dir wird sich das vielleicht nicht großartig bemerkbar machen, aber z.B. bei Joomla tut es das) und dir nur Arbeit machen... Nicht böse sein^^

MfG .wired