To menu

Programmer's part - a bit of documentation

The whole system is based on files and directories and their tree. The tree system is based for partitioning for each part and module and their update by bundled functions.


  • Web pages with administration
  • Upload pictures, documents, videos
  • Possible more users
  • Strong modularity
  • No database
  • Defined inputs and outputs - separate work with query and answer

Elementary module

The Elementary module is file contains class, which lays in defined path - directory with modules. The class inside them implements interface for that part of KWCMS. Basically it's parameters in __construct() and return from out(). The class and the module is also connected into rest of system by module list or the menu.

#ELEMENTARY module for presentation
# modules/elementarytest/base/module.php

class elementarytest implements inModule {
 private $par = array();
 const module = 'elementarytest'; # somewhere as variable, then is possible faster change the templates

 public function __construct($params=array()) {
  global $conf;
//  if (!$conf->load(self::module)) throw new Exception ('cannot load config');
//  if (!$conf->lang(self::module)) throw new Exception ('cannot load langs');
  if (count($params) > 0)
   $this->par = $params;

 public function __destruct() { # uklid
  foreach (array_keys(get_object_vars($this)) as $val)

 public function out() { # vypust
  $r = 'Hi, I am Elementary module.';
  $t = new template(self::module, 'elementary');
  $t->change('{-GET-}', $r);
  if (count($this->par) > 0)
   $t->change('{-PARAM-}', key($this->par).':'.current($this->par));
  $t->change('{-PARAM-}', 'Nothing.');
  $r = $t->out();
  return $r;
#ELEMENTARY template in presentation
# modules/elementarytest/style/elementary.htm
 <-div class="elementary"->{-GET-}: {-PARAM-} <-/div->

For more just look onto others, already developed modules.

The libraries has more possibilities. They implements nothing, but their target is 5 operations - add, update, delete, search and details. Because they contains no every operation, it is not possible to create their interface or abstract class. Their details are also set through __construct() function.

#ELEMENTARY library for administration
# lib/libelementary.php

class libelementary {
 private $par = array();
 private $cont = array();

 public function __construct($params=array()) {
  if (count($params) > 0)
   $this->par = $params;

 public function __destruct() { # uklid
  foreach (array_keys(get_object_vars($this)) as $val)

 public function add($line) { # vloz
  $this->cont[] = $line;
  return true;

 public function update($id, $line) { # uprav
  if (isset($this->cont[$id])) {
   $this->cont[$id] = $line;
   return true;
  return false;

 public function remove($id) { # smaz
  if (isset($this->cont[$id])) {
   return true;
  return false;

 public function entry($id) { # prvek
  if (isset($this->cont[$id]))
   return $this->cont[$id];
  return null;

 public function out() { # vypust
  return $this->cont;

Modules for presentation

In modules/ rests dir named like module. In it minimally dir base/ with file module.php with module code itself. If module needs, it also appear dirs conf/ (settings), style/ (templates) a lang/ (translations).

The class making module has same name as module itself. Must implements module interface.

The parametres comes into __construct() function as indexed array. The module itself returns content depends on level - write only that, for what has rights and corresponds with level. You can see it in RSS or LANGS.

Add module into presentation is possible (yet) by edit /modules/module.X.conf and add line with module name. The "X" is level.

Add module into administration is possible (yet) by edit template /style/main.htm and add line with module into menu.

Special modules

They lays in dirs /base/modules , /admin/base/lib and /admin/comp . They are necessary for additionally system operations - here lays the database connection or (in administration) user accounts. Their organization is similar, but their outputs may come into other resources (databases).

I point out every single module may has changed style only by add template by user into correct path in his own dir.

If you want create next modules, I demand look on code of that created and mainly on their arrangement. Normally module gets minimum amount of information and what it has it could use. With dependencies is also problem. When author did not say it you only know it after code reading.

Classes, which system uses for presentation

BASE - System core, on this depends what is shown and will be added. Minimally usable for writing a module.

CACHE - Save most used data (like menu or header) as template.

CONFS - Load settings. Usable.

HEADERS - Set interfaces for modules and components.

MODULES - Load and show modules. In other worlds this class is directly on the other side than usable classes because call them. Interesting only when you began testing.

PATHS - One of most important classes. Has three tasks: at first set the paths. At second access work with file names. And at third rewrite paths to "pretty" one.

RECODE - Has simple task - change national chars with UTF8 entities. Text to recode comes as string into out() .

TEMPLATE - One of most important classes for developing modules - on this one depends style. Most used function are Change(from, to) and Out() . You can directly add own template into Template , but future responsibility for future style comes on you.

TEXTFILE - Special variant of Template (and merged in its file). Plus look for modules in page. Again only for Base class inner purposes.

Classes, which system uses for administration

AUTH - Important class. Verify user against system. Shouldn't be called outside Base and its global variable $auth shouldn't be used.

BASE - System core, choses module to load and authenticate user. Module only must know how to call it.

CAPTCHA - A little strange class. Return image with captcha text. Need only for login, not for modules.

HEADERS - Classes headers. Define an interface for modules and usable constants.

INCL - Class for including next parts. Modules uses it.

LANGS - Translations. From each part it gets array with language and recode content. Modules uses it only in ONLY_CONTENT mode. Working function is Chg() , out() makes complete translation.

MODULE - This class calls external module and catch its errors. In other ways unusable.

MODULES - At least with similarity in name it has different usage - prepare part with answer for some of them.

TEMPLATE - Most important class for creating a module - get styles from templates. Its most usable functions are Change(from, to) and Out() . You can (by hack) use only own desired template, but then responsibility for styles is on you.

Administration libraries

BANNED - Fruit storm for unallowed guests. Deny access from listed IPs. Modules has no usage for it.

DISK_SPACE - This class returns available size on volume. On shared systems can show false numbers. Return normally in out() .

CGROUPS - Managing users groups. Really specific and unusable.

CCLASSES - Managing users classes. Really specific and unusable.

LOGS - Logging problematic operations. Needs active call by programmer. Already only for manipulating with accounts.

META - Work with metadata. And this metadata are neither than menu. Modules can use it.

MIMETYPE - Works with files mimetypes. It's necessary when you has no access to functions mime_content_type() and finfo, which makes using file-dependent managing pretty problematic. Modules can use it, answer is called by mime(dir,file) .

PASSWD - Works directly with user's names and passwords. It won't be called by anything or it makes serious problem.

RECODE - Has simple task - encode all national chars into UTF8 entities. Text comes as string into out() .

USRDIR - User's directories. Never ever call it by anything! Real risk of damage!

Administration components

CSCRIPTS - Add module scripts onto page. It's called by Base , in other ways it is unusable.

CSTYLES - Same with styles.

MAIN - Strange class. Sugaring Module answer.

CHOSEDIR - Partner for Paths . Returns form with tree which Paths process.

LOCATIONS - Important class, some modules cannot run without them ( Chosedir ). Walks through dir tree on web and process it. Also one of the slowlest. Needs Mimetype .

Special constants

ONLY_CONTENT - The content is only in module's will - also with themes or translations. Need to be set before call Base .

Modules which may not be used but it complicates a life

a:LOGIN - In fact module, which write login form. Unusable.

a:LOGOUT - Also module, but this one log out users. Dangerous.

a:USERS - Setting user accounts. Dangerous.

a:GROUPS - Setting user groups. Dangerous.

a:CHSETT - Setting settings. Dangerous.

p:ERRORS - Error pages. Need set .htaccess for proper show.

p:LANGS - Languages. If more languages is set, then this module shows flags with their choose.

p:MENU - Menu tree. Needs some extra files for describing menu. Also it can use Cache.

p:LOGO - Logo. This is that image in (normally) page's corner.

p:SHORTM - Short messages. Usually they're for actualities. And page without actualities is dead.

p:THEME - Themes and styles. This class choses styles and their themes by settings.

Users directories

Every single user begins somewhere with clear dir. Here you must split cases where you have more users in system - and they have one tree or each has their own tree. This depends on settings[page][more_users]. The user paths can be updated in administration.

Primary idea for setting dirs comes from Root account (System admin) and his / (slash). So the slash in the beginning says I begin in document root with presentation. The slash in the end says there is no subdir with settings. Elsewhere it uses global home dir "user/" and data dir "data/". Free string means, paradoxically, the path goes into "user/data/" (that is no bug).

The System admin has no problems with config dirs, he automatically edits basic settings. The Content admin has similar rights. If you use sub-webs, it's recommended create one editing account with content admin rights for each one. But that content admin also could change administration settings, so beware.

Friendly warning

I know that the installator has problems with dirs. So it's good idea to have prepared FTP and make tests. Or you could did it (with restrictions for modules) from System admin account.