[[https://github.com/rkCSD/rkCSD-WebsiteEngine|Github]] | [[http://wiki.reneknipschild.net/en:dev:web:rkcsdengine|English]]

====== Einleitung ======

Da das alte CMS ständig von einem Projekt zum anderen geschleppt wurde und deshalb mit der Zeit immer unübersichtlicher wurde und außerdem relativ unflexibelwar, war eine Neuentwicklung fällig.Auch weil das Alte CMS so gut wie gar nicht Dokumentiert war, was eine Erweiterung des bestehneden Systems schwierig machte.

====== Übersicht ======

===== config.ini =====

Die Konfigurationsdatei config.ini befindet sich im Unterorder /config.Grundlegende Funktionen werden über die config.ini gesteuert:

<code>
[mysql]
host = "localhost" 
user = "CMS"
password = "O2nkupO9xByFvz6p"
dbname = "CMS"

[templating]
templates = "content/tpl/"
basepath = ""
title = 'WebsiteTitle'
content = 'render_output'
template = 'main_template.tpl'
cache = "cache/"

[system]
timezone = 'Europe/Berlin' ; http://php.net/manual/en/timezones.php
debug = false
</code>
  * mysql: Enthält die Mysql-Zugangsdaten
  * templates: Enthält den Ordner, an dem das Haupt-Template zu finden ist.
  * basepath: Enthält den Pfad, der vor alle Aufrufe Gestellt wird, im normalfall ein “/” oder den Unterorder, in dem sich die Website (relativ zur Domain) befindet.
  * title: Enthält **nicht** den Title der Website, sondern den Namen der Smarty-Variable, in die der Titel ins Template geschrieben wird (Siehe App-Referenz)
  * content: enthält **nicht** den Inhalt der Website, sondern den Namen der Smarty-Variable, in die der Inhalt ins Template geschrieben wird (Siehe App-Referenz)
  * template: Enthält das Haupt-Template, relativ zum Templateverzeichnis
  * cache: Enthält den Ordner, welcher von Smarty zum Cachen verwendet wird
  * timezone: Definiert die Zeitzone, unter welcher das CMS ausgeführt werden soll. Die Zeitzone sollte ein Format von http:%%//%%php.net/manual/en/timezones.php haben. In neueren PHP-Versionen muss die Zeitzone explizit gesetzt werden.
  * debug: Wenn true, werden PHP-Fehlermeldungen angezeigt, ansonsten unterdrückt

===== Inhalte =====

Um eine saubere Struktur einzuhalten, sollte aller Inhalt, der nichts mit Apps oder Erweiterungen zu tun hat - also alles was für das Layout der Website benötigt wird (auch das Haupt-Template), in den Order content gespeichert werden.

===== Apps =====

Das CMS ist modular aufgebaut, weitere Anwendungszwecke können (und sollten) einfach mittles sogenannter “Apps” realisiert werden. Die Apps werden über eine ’config.php’, welche jede App braucht, gesteuert. Das CMS selbst kann (fast) nichts, außer einzelne Apps aufrufen. Sämtliche Anwendungen sollten also mit eigenen Apps realisiert werden //(und nicht mit komischen Hacks in der Main.php)//, da beim alten CMS die Logik meist vollständig in rkcsd.php stattfand, wodurch das System komplett unflexibel wurde.\\
Momentan gibt es sieben Apps:

  * Contact - eine App zur Verwendung eines Kontaktformulars
  * CookieTasting - Informiert den Nutzer darüber, das Cookies gesetzt werden
  * Navigation - Baut aus einer Datenbank einen Navigationsbaum auf
  * News - Zeigt konfigurierbare News an
  * Pages - Zeigt einfache, editierbare statische Seiten an
  * Slides - Zeigt konfigurierbare Slides an
  * WebAdmin - bietet Möglichkeiten, die Seite zu verwalten

===== 404-Fehlerseite =====

Wenn der HTTP-Statuscode 404 ist, wird die Fehlermeldung aus der Datei ’404.txt’ ausgelesen und angezeigt.

===== ’Nicht installiert’-Meldung =====

Wenn das CMS noch nicht installiert wurde, wird eine entsprechende Seite angezeigt. Diese lässt sich über die Datei ’not-installed.html’ im Hauptverzeichnis anpassen

===== Meta-Tag ’Generator’ =====

In die Smarty-Variable //$meta_generator// wird eine Ausgabe der Form ’rkCSD-WebsiteEngine v3.1.0 (www.rkcsd.com)’ geschrieben. Diese kann dann im Template in ein Meta-Tag “Generator” überführt werden:

<code>
<meta name="generator" content="rkCSD-WebsiteEngine v3.1.0 (www.rkcsd.com)"/>
</code>
====== App-Referenz ======

Für die Apps gibt es eine Reihe von Config-Pararmetern sowie funktionen. Das CMS geht alle Apps innerhalb von /apps durch und führt sie je nach Config-Pararmetern aus.

Diese Config-Pararmeter werden in einer config.php angegeben, die zwangsläufig im Grundverzeichnis des App-Ordners liegen muss - Alle anderen Dateien können prinzipiell irgendwo anders innerhalb dieses Ordners liegen, sie müssen dann nur korrekt verlinkt werden.

Config-Pararmeter werden mittels $rCONF[’Pararmeter’] = ’Wert’; angegeben.

Es gibt vier verschieden Config-Pararmeter, alle akzeptieren Strings oder Arrays als Werte.

  * //$rCONF[’name’]// Name der App
  * //$rCONF[’base_url’]// Basis-Url der App
  * //$rCONF[’base_file’]// Basisdatei der App, wird z.B. ausgeführt, wenn //$rCONF[’base_url’]// ausgeführt wird - Siehe App-Typen
  * //$rCONF[’type’]// Typ der App - Siehe App-Typen
  * //$rCONF[’alias’]// Enthält ein Array mit aliasen nach dem Schema [’Alias’ => ’PHP-Script’] (’phpscript’ wird ausgeführt wenn ’Alias’ aufgerufen wird)
  * //$rCONF[’param’]// Wenn der Pararmeter in der aktuell aufgerufenen Url vorkommt, wird die in base_file angegebene Datei ausgeführt.

===== App-Typen =====

Es gibt drei App-Typen, zwischen diesen unterscheidet man wie folgt:

==== Page ====

“Lebt” in einem Unterverzeichnis, welches mit base_url angegeben wird. Immer, wenn innerhalb dieses Unterverzeichnisses was aufgerufen wird, wird base_file ausgeführt.

Eine Konfiguration braucht mindestens diese Pararmeter:

<code>
$rCONF['name'],
$rCONF['base_url'],
$rCONF['base_file'],
$rCONF['type']
</code>
==== Static ====

In diesem Fall wird base_file bei jedem Seitenaufruf mit ausgeführt, dies ist z.B. bei der Cookie-Meldung im Einsatz.

Eine Konfiguration braucht mindestens diese Pararmeter:

<code>
$rCONF['name'],
$rCONF['base_file'],
$rCONF['type']
</code>
==== Param ====

Wenn in der aktuellen Url param vorhanden ist, wird base_file ausgeführt.

Eine Konfiguration braucht mindestens diese Pararmeter:

<code>
$rCONF['name'],
$rCONF['base_file'],
$rCONF['param'],
$rCONF['type']
</code>
===== App-Funktionen =====

Innerhalb jeder App sind bestimmte Funktionen verfügbar, welche mit\\
$rkWeb->funktion($parameter) aufgerufen werden kann. Darüber hinaus sind innerhalb von $rkWeb alle Smarty-Funktionen verfügbar.

==== setContent($content) ====

Setzt $content als Inhalt, welcher in die in der Config.ini gesetzte content-Variable geschrieben wird. Bei mehreren Aufrufen wird der Inhalt aneinandergehängt.

==== getContent() ====

Liefert den mit setContent($content) gesetzten Inhalt.

==== setTitle($title) ====

Setzt $title als Titel, welcher in die in der Config.ini gesetzte title-Variable geschrieben wird.

==== getTitle() ====

Liefert den mit setTitle($title) gesetzten Titel.

==== setResponseCode($code) ====

Setzt den HTTP-Status-Code. Wenn diese Funktion nicht ausgeführt wird, ist der Statuscode 404 und der inhalt der Datei 404.txt wird ausgegeben.\\
Es ist also sinnvoll, setResponseCode(200) immer auszuführen, wenn Inhalte gesetzt werden, da diese sonst überschrieben werden.

==== getResponseCode() ====

Liefert den mit setResponseCode($code) gesetzten HTTP-Statuscode.

==== debug($debug) ====

Wenn $debug = true, werden alle PHP-Fehlermeldungen ausgegeben. Standard ist false.

==== getUrl() ====

Liefert die aktuell aufgerufene Url (ohne Get/sonstige Pararmeter). Diese Funktion wird selten innerhalb einer App benötigt, da das App-Handling bereits vom CMS übernommen wird.

==== getBaseUrl() ====

Liefert die aktuelle Basisurl zurück, also alles jenseits von basepath. Ist Quasi das aktuelle “Unterverzeichnis”.

==== config[’configparam’] ====

Array, liefert die Configpararmeter der config.ini so, wie sie parse_ini_file zurückgibt.

==== apps[’appname’] ====

Array, liefert die Configdateien aller apps nach dem Schema apps[’appname’][’appconfig’]. Dabei haben die ’appconfig’-Variablen die selben Namen, wie in ihrer jeweiligen Configdatei festgelegt.

==== version() ====

Liefert die aktuelle Version des CMS.

===== Templates innerhalb Apps =====

Da das Haupt-Template in der Config.ini festgelegt wird, ist es nicht ohne weiteres Möglich, Apps eigene Templates anzeigen zu lassen. Im Haupt-Template wird das dann so realisiert, dass mittels

<code>
{if $responseCode == 404}
    {$render_output}
{else}
    {include file=$template}
{/if}
</code>
das Template aus der Smarty-Variable $template eingebunden und ausgeführt wird. Diese kann man wie Gewohnt über einen Aufruf von

<code>
$rkWeb->assign('template', 'pfad/zum/template.tpl'); 
</code>
definieren.

====== Best Practice ======

Es ist sinnvoll, in jeden Appordner, der keine index.php enthält, eine index.html einzufügen - So kriegen neugierige Nutzer oder Bots nichts zu sehen.

===== Templates =====

Jede App sollte alle Templates, die sie selbst benötigt, in ihrem unterordner haben, nicht im Haupt-Templateordner. Diese Templates müssen dann (von Hand, dafür kann man dabei den Platz im Haupt-Template wählen) ins Haupt-Template via {include file=’pfad/zum/template’} eingebunden werden.

====== Impressum ======

Autor:

Konrad Langenberg, langenberg@rkcsd.com

René Knipschild Custom Software Development

http://www.rkcsd.com

Postfach 1468, D-34484 Korbach