Home

=Rock’n’Roll CMS= =Functional overview= The system is written with a simplistic functionality in mind. ==Physical parts== Content is held in the database wherever possible. The most important and mostly used file is index.php which delegates the content query to the system, rendering it dynamically from database entries. Images are not in the database for ease of manual editing. ==Logical content parts== A website has multiple main pages which render into the global frame of main navigation and header. Their loading is managed in ContentPage objects. The visual representation is managed by an Article, which in turn contains a submenu and either paragraphs or plugin content.
==Adminstration== While the website is almost exclusively rendered by php, to create the most consistent experience across browsers. The administration interface is a HTML5 app. It lives in the separate folder underneath /cgi-bin and is secured by apache .htaccess configuration. ==Memory models== Where possible the system uses session storage to prevent re-creation of objects. The two main session objects are the Singleton for the users “stay” handling user and plugin allocation, and the Singleton of the ContentMgr, which handles the, well content. The database connection does not serialise well, so the static class member instance of the DBContrl class is re-initialised on every page creation. ==Extension== Extensions to the usual content creation and presentation in the above explained manner are taken care of by so called plugins. They can either be of the self-descriptive types article, paragraph and global. To remain flexible the plugins must supply code for either DOM creation of straight rendering, which is caught in a php output buffer and then applied to the DOM, but also javascript code to render the custom data configuration. =Technical details= ==Database== Files:

• DBCntrl.php
• DBConnMysqli.php The system got written for the mysqli interface, but overriding the class interface iDBConn which just has the typical database REST commands in its contract, possibilities for connection are given. The input of SQL commands is abstracted through arrays, and a requirement object tree which encapsulates possible hierarchies of and/or conditions. ==User== Files:
• Aufenthalt.php
• Benutzer.php WIP. Currently very much tailored for the shop implementation. Needs refactoring. ==Content creation== The rendering happens in “view” classes which correspond pretty much to their layout container. The get created by the controlling ContentFactory class. Tables can have their layout defined in .xml files in the domain root. ==Administraton==
• cgi-bin/Admin/* Going to /cgi-bin/Admin/ lets you access the HTML app. The access to the folder is restricted to the users in .htuser. at the moment the jQuery powered app is only working successfully in google chrome. Once a ContentPage has been selected, the submenu and paragraph sections are filled with what’s coming from the database. jQuery-UI supplies editing tools for tables as edit in place for text, dates, time values and more. The main file loaded from the index HTML extends the jQuery module by an fn object. Its loadContent function is the interface to our database and loads AJAX/JSON requests to and from DBAccess.php. The file utils.js contains a module which helps with dynamic table rendering. If plugins are found, DBaccess lodas the objects from the Aufenthalt class, which contain a member method to get the information about where the administrational javascript render code resides. Javascript modules are loaded by the requireJS framework. ==Plugins== Extending the main functionality is done by creating a subfolder in the cgi-bin/Plugins directory. The name of the folder is the identifier used for the plugin association in page and other tables. If a file named plugin.php is found, the CMS expects a class in it overriding the IPlugin class to define the DOM rendering. Otherwise an index.php is expected to render the contents as usual, which get caught in a output buffer and appended to the DOM. The additional file include.php may define requires/includes that are done before session_start(), to (de)serialise the objects correctly. If implementing the IPLugin interface, the path to the administration rendering can be put and directed to wherever, otherwise the file admin.js is expected in the Plugin’s root folder. Examples: =TODOs and known bugs=

• A lot of germanised function and functionality naming is reading pretty awkward and has worn out its novelty factor.
• Plugins only support Article level implementation at the moment.
• Administration interface needs pepping up.
• More general security related checks would be helpful.
• User management is ancient and very specific for a one-time usage during order processes.
• Administration only works in Google chrome