New Classes for WBCE CMS,  1.4.1
Documentation for all new Classes in WBCE CMS
Module Files in WBCE CMS.

Table of Contents

Here we go through all special files available for modules, explain the folder structure and handle special cases.

Basically there are 6 types of modules: Tools, Page, Snippet, WYSIWYG, Initialize, Preinit. In the following document we describe their files folders and special functions.

Generic folders and files

Basically a module consists on an info.php that defines its parametes and several other files depending on the type of module. Some folders are needed by default others are optional.

info.php

One of the most inportant file is the info.php. It defines al parameters about the module. Here is an example:

<?php
$module_directory = 'wbstats';
$module_name = 'WebsiteBaker Visitor statistics';
$module_function = 'tool,page,snippet';
$module_version = '0.1.10';
$module_platform = '2.8.x';
$module_author = 'Dev4me - Ruud Eisinga - www.dev4me.nl';
$module_license = 'GNU General Public License';
$module_description = 'Displays website statistics as an admintool';
?>

Back Up

Possible functionality

The most important part of the info.php is $module_function as it defines what functionality the core expects from that module. This is a simple comma seperated list whith no spaces. The following values are possible:

Functionalityinfo.phpVersion
Admintooltool
Page modulepage
Snippetsnippet(only frontend)
WYSIWYG(Editor)wysiwyg
Initializeinitializesince 1.2.x
Preinitpreinitsince 1.2.x

Back Up

install.php, upgrade,php, delete.php

These three files are responsible for installing, upgrading and deletion of the module. They are run when one of those actions is taken. Mostly the manage adding and deleting database tables, add or remove special files and anything thats needed on install , uninstall or upgrade of a module. Here is an example:

// install.php from Ruuds WBstats Modul
//no direct file access
if(count(get_included_files())==1) header("Location: ../index.php",TRUE,301);
$table_day = TABLE_PREFIX .'mod_wbstats_day';
$table_ips = TABLE_PREFIX .'mod_wbstats_ips';
$table_pages = TABLE_PREFIX .'mod_wbstats_pages';
$table_ref = TABLE_PREFIX .'mod_wbstats_ref';
$table_key = TABLE_PREFIX .'mod_wbstats_keywords';
$table_lang = TABLE_PREFIX .'mod_wbstats_lang';
$database->query("DROP TABLE IF EXISTS `$table_day`");
$database->query("CREATE TABLE `$table_day` (
`id` int(11) NOT NULL auto_increment,
`day` varchar(8) NOT NULL default '',
`user` int(10) NOT NULL default '0',
`view` int(10) NOT NULL default '0',
`bots` int(10) NOT NULL default '0',
PRIMARY KEY (`id`),
INDEX `day` (`day`)
)"
);
$database->query("DROP TABLE IF EXISTS `$table_ips`");
$database->query("CREATE TABLE `$table_ips` (
`id` int(11) NOT NULL auto_increment,
`ip` varchar(15) NOT NULL default '',
`session` varchar(64) NOT NULL default '',
`time` int(20) NOT NULL default '0',
`online` int(20) NOT NULL default '0',
`page` varchar(255) NOT NULL default '',
`loggedin` int(1) NOT NULL default '0',
PRIMARY KEY (`id`)
)"
);
... and so on

Again this is mostly used for module speciffic database handling, as copying the module to its destination and adding it to the modules table is done by the core.

Right now most stuff in this files must be done manually, only automatism available right now is the settings class used for global settings of your module. For more informations have a look at the docs for class Settings.

// create or edit a setting
Settings::Set("modname_new_setting","the value");
// using a setting
if (MODNAME_NEW_SETTING =="the value") echo "Horay";
// there is a get function but this is mostly used internal
$myValue= Settings::Get ("modname_new_setting");
// deleting
Settings::Delete("modname_new_setting");
Attention
This files are optional! if there is nothing to do on install, upgrade or uninstall you simply dont need them.

Back Up

Admintools (tool)

Admintools are small modules that can be used to modify global settings, configure a slider , offer additional settings for modules ,... but they are only accessible through the backend. Admintools are accesed through the admintoools section in the backend and they have no direkt display in the frontend.

info.php

In info.php you need to add "tool" to the list of functions so the core recognizes this as an admintool.

Files

Admintools basically only consist of one file the "tool.php". This is a simple self calling apeform that does something if the form posted is valid. There are some more complex admin tools but basically admintools should be kept simpe if possible. As the "tool.php" is included in an enviroment whith a lot of helper vars and functions its not a good Idea to use the save file concept used in pagemodules as those helpers aren't available outside of "tool.php"

Hints

Todays best practice would be to combine an admin tool whith a class that does the actual work. Put this class in the classes folder. And register it in "initilaize.php" (See autoloader docs WbAuto) Don't forget to add "initialize" to the function list in "info.php" There is a full article about admin tools and their new features. Admin tools news for authors.

Back Up