To aid developers in wrapping their heads around the Wiccle system architecture, I have prepared an overview of the classes in Wiccle Core. This information is also applicable for iWiccle versions 1.20 upwards.

To make the most out of this tutorial, keep the files for Wiccle Web Builder 1.0 and a code editor handy and look up the files and classes referenced.

If you have any questions on any of the following, or on other aspects of Wiccle CMS Framework and the way it works, please feel free to ask in the forums.

General Architecture

Architecturally the code in Wiccle Core is a hybrid between object-oriented logic and categorically aggregated functions, tailored to keep everything well-structured and intuitively located, and to make dependency management easy. In practice, most classes are collections of static functions working in shared or similar context. Some of the classes will be split further in future builds to make the system still lighter to load.

Everything starts and ends in the index.php file, and all central site functionality (aside AJAX) revolves around it. The index.php file bundles together two configuration files (config.php and init.php) and central system classes. We don't use separate browser-accessible PHP files (except for AJAX, feeds and sitemaps) — all user-initiated requests are passed through index.php as GET or POST data.

When all the main classes are loaded, index.php calls the general wrapper function, Wiccle::make_wiccle(). If you understand what's going on in this file — and it's not awfully cryptic if you know basic PHP — you'll be able to track the data everywhere it goes, and tap in wherever you wish in order to create your own Wiccle extensions.

Wiccle System Classes

The /core folder contains all shared system classes in use across the modules. The classes are:

• class_ajax.php: class Ajax { A slim version of class Wiccle that handles AJAX output generation through ajax.php - parallel to index.php and make_wiccle(). }
• class_activity.php: class Activity { Functions for page history tracking. (And in the future, activity feeds.) }
• class_builder.php: class Builder { Functions for handling Builder layout creation and data/layout import and export. }
• class custom_forms.php: class CustomForms { Functions for display and parsing of forms created with the Form Builder. }
• class_elements.php: class Elements { Functions for transforming user input into database "objects" for the dynamic data types used ("post", "category", "parent", etc.), accessory functions for such parsing. }
• class_errors.php: class Errors { Functions for collecting, compiling, and alerting errors. }
• class_forms.php: class Forms { Functions for displaying and parsing input forms for dynamic data. (Complemented by class Elements.) }
• class_global.php: class Utility { Miscellaneous functions used across contexts, including SQL input filtering, string and array handling, date parsing, dynamic data tracking, string hashing, and smart URL parsing. }
• class_mailer.php: class Mailer { Functions for form e-mailing, general e-mailing, and content tracking notifications for both e-mail and site-mails. }
• class_members.php: class MemGlobal { Member functions used globally: usergroup permissions, login, password recovery, account validation etc. } class MemSQL { Accessory MySQL queries. }
• class_modules.php: class Modules { Functions for processing and displaying dynamic data, global data preprocessors and postprocessors, comments, rating, tags, accessory functions. }
• class_mysql.php: class MyQuery { Query handling and logging, insert/update query builders. } class Queries { Reusable MySQL queries; extends MyQuery. }
• class_search.php: class Search { Functions for search form display and search query handling. Complemented by Queries::get_elements(). }
• class_templates.php: class Template { Functions for compiling page layout, connecting builder units to classes, parsing data and languages into templates, isolating languages and skins across modules, pagination, template script handling, menu and slipstream parsing, accessory functions. } class Tp { Simple object to make system data available for template files. }
• class_uploader.php: class Uploader { Functions for handling file uploads and image rescaling. }

Of the above, class Modules and class Templates are central to all module operations and data-to-HTML template processing. The better you know them, the easier coding extensions will be for you. You should also take advantage of class Utility and class Queries to avoid redundant code duplication; many of the things you may want to do are already supported by the system, so save the trouble and learn to re-use wherever possible.

Some central functions — the generic dynamic data handler Modules::get_elements(), the unit processor Template::call_method() and the main methods under class Forms — can be extended with preprocessors, midprocessors and postprocessors, declared in module configration files on a per-module basis to tap into and modify the data that's flowing through the system. (Also see: Creating data preprocessors for dynamic content »)

Accessory System Files

The four accessory system files map diverse settings for use across the system. Two of them are user-configurable with extension files.

• config_mapper.php: Compiles system variables from database for use — available under the $core['init'] associative array.
• init.php: Initiates system paths for folders and database prefix as constants.
• layout_grid.php: Grid of all possible content types and their options — available under the $grid associative array.
• variables.php: Miscellaneous settings and variables in global use — available as associative arrays under the several $core arrays.

If you want to edit layout_grid.php and variables.php, please use the _ext extension files to overwrite them. You can also override these settings on a per-module basis using _config.php and _grid.php files in a module folder under /modules. The layout_grid.php file is particularly important to understand if you want to extend Wiccle with new content formats and data types, or add other extensions to the Builder, and from there into your site.

AJAX Handling

All AJAX calls are initiated from the template files with a javascript call to submitAjaxGet() for GET data or submitAjax() for POST data in /templates/javascript/ajax_calls.js. These functions forward the request to ajax.php and class_ajax.php / class Ajax, which are slim versions of index.php and class Wiccle.

The bulk of the /core/ajax folder consists of files that are included according to the AJAX tool request. The AJAX core.php central file maps incoming requests to corresponding files. The AJAX tool files may work whichever way you wish, as long as they return their final output under the $output variable at the end.

The second of the two files in global AJAX use is functions.php, which contains the important little establish_module() function for fetching module files for AJAX tools that are module-dependent. Use this only when necessary to keep the system load lighter. Some of the other /core/ajax files are also used in different contexts; the entire AJAX folder will be covered in an upcoming tutorial in more detail.

This tutorial will be extended by a more detailed look into the central functions that deal with language and template handling. Much of it is self-evident if you read through the central classes with an attentive mind. The code is not particularly complicated, for our development aim is for simplicity and solid structures, rather than a smörgåsbord of funky, complicated fabrications that take you forever to master.