iWiccle has a number of options for data processing to help you extend the functionality of dynamic content on your site. This is how we create the bulk of extensions into our otherwise generic modules, and you can do the same.

Here's a simple sample case:

• Taking the "post caption" of a blog and turning it automagically into a link

Starting point. Standard blogs module with the caption displayed as text-only. I have typed in http://www.wiccle.com into the "Caption" field in the blog post form and posted it in.

Step one. Declaring a preprocessor.

Open blogs_config.php, insert anywhere in the file:

$core['module']['extension_class'] = "Blog";
$core['module']['processor_post'] = "post_preprocessor";

Step two. Creating a preprocessor.

Open blogs_class.php, insert inside the empty class:

static function post_preprocessor($data)
{
    $data['post_caption'] = "<a href="{$data['post_caption']}">{$data['post_caption']}</a>";
    return $data;
}

End result: What you type into post caption in blogs module will now be parsed as a link. As seen below.

I seriously don't think this went over the cuckoo's nest for anyone if you paid attention. Please don't feel intimidated by the funky terminology; these things need to be called something, and a post preprocessor is a very exact description of what the above does; it pre-processes the data before it goes through the regular system routines.

If you understand the basics of this fundamentally simple and generic system, and know how to use the Wiccle Builder, you can become a module developer guru if you understand English and studied mathematics in primary school. You don't need to be well-versed in PHP to be able to create new modules.

Other preprocessors in the system.

If you want to review the default preprocessors in place for members, posts, parents, categories, and most other types of dynamic content, you can look them up in class_modules.php starting at line #566 and continuing until #930. If you find something of interest there, you can copy it into one of your modules and make it a part of your own preprocessor.

If you want to further study the possibilities offered by the current system, you can also open up layout_grid.php to look up all the general dynamic content types (yes, that's the $type variable you see in many functions) you can work with; their data will automatically latch on to their respective preprocessors when one is declared. There are also additional dynamic content types available only in certain modules by default (such as favorites and mail in the members module).

How dynamic data becomes available to templates.

As a general principle, whatever is made available under the $data variable in preprocessors will also be available for your templates of the same type^(*) (see skin_post.php for the different formats) under the tags you see all around in [[SQUARE_BRACKETS]], regardless of whether it comes from the database or not.

For example, if you added $data['my_foobar'] = mt_rand(); into your preprocessor, it would make a random number available as [[MY_FOOBAR]], or if you added in $data['todays_date'] = date("r"); it would make a RFC 2822 formatted date available as [[TODAYS_DATE]] for all your post templates.

^(*) Under the same type: post preprocessor data is available for all content formats inside skin_post.php, parent preprocessor data in skin_parent.php, category preprocessor data in skin_category.php, member_preprocessor data in skin_member.php, and so on.

Homework for module students.

If you want to look at a live example of a custom preprocessor that's a bit more advanced than today's example, you can open up the files for the Articles module and see how multiple pages are filed into the post_cache field, how the multi-page dropdown is created (jump_dropdown), how the article subpage numbers are created (page_links), and how articles with 0 subpages get their page count (post_references) displayed as 1 on the fly.

Some further basic examples of what you could do:

• Search and Replace with str_replace() - for example converting certain keywords to links or ad-links.
• Change a form field in the form templates from "input" to a multi-line "textarea", then add nl2br() to convert newlines to line break tags.
• Take a field and match it to a string in language files ($lang['this_that']) -- for example as follows:
       if (!empty($lang[$data['post_caption'])) $data['post_caption'] = $lang[$data['post_caption'];
• Take a timestamp and turn it into a custom date using date():
     $data['my_post_date'] = date("y-m-d", $data['post_date']);
• Truncate the length of a field to first 50 characters:
     $data['post_text'] = substr($data['post_text'], 0, 50);
  

Please note that the above are only meant to give a general sense direction, and may not represent useful or complete solutions in and of themselves.

Going to have to read this a couple of times to get the grasp of it - I'm keen to try some of this!!

Right now I can't get past the fact that you're posting this brain-taxing stuff at 7:36am having not been to bed/sleep yet! Cripes, I'd be collapsing after those sorts of hours!

The first segment was the easy version I meant for you to look at. Start digesting with that. =) The second segment was the intermediate version. This third segment is the version for people who want to start doing what I have been doing on a similar scale in customizing all aspects of module creation. Much of the below is something that's only really in use in some of the more advanced Wiccle modules, but the structures and the potential are identically present in iWiccle.

---

Advanced Dynamic Data Preprocessing and Postprocessing

If you want to go wild creating new dynamic processors into your iWiccle/Wiccle, this is an explanation of all available and possible data processor extension possibilities. The name of your processor function can be whatever you choose; I am referencing the default names I have been using so far. For example:

$core['module']['processor_post'] = "post_preprocessor";

So far the system primarily offers hooks for post-level dynamic data, as that's where most of the action is in individualizing blog posts from article posts, quiz posts, store item posts, and all other modules' posts that use the same symmetric data structure. You can apply the principles explained in this section to create new hooks in the system. (They will be addded in for all types of dynamic data in due course, as it becomes relevant in the course of our module development work.)

Module Preprocessors and Postprocessors

Whatever dynamic data is passed through class_modules.php latches on to the following processors. (You can look up the type's "method" in layout_grid.php -- if it's "get_elements", the data will be taking the correct route for your custom processors to intercept.)

Dynamic type preprocessor extensions are detected if they are named as "type_preprocess" (type being for example "category" for a prefix). The data available to preprocessors is the raw data coming out the database, before being touched by the system's default processors.

On the other hand, postprocessors latch on to the data after it's gone through the system hops, but hasn't gone to templating yet. Postprocessors are declared and detected under the variable $core['module']['type_postprocessor'] (type again being your type of choice).

Note: There is a slight bit of naming standardization to do in the preprocessor department, as some of them are from older versions of code. However, possible future changes will not affect your modifications, as they will only make the naming conventions more loose. Whenever substantial modifications are made and brought to our knowledge, we will start legacy aliasing to support multiple versions of modifications in one system.

Dynamic Data Form Preprocessors and Postprocessors

Data can also be processed in different ways as it goes through the methods in class_forms.php. These are the standard form processing extension declarations:

$core['module']['post_add_form_extension'] = "post_add_form_extension";
$core['module']['post_edit_form_extension'] = "post_edit_form_extension";
$core['module']['post_add_prepro_extension'] = "post_add_prepro_extension";
$core['module']['post_edit_prepro_extension'] = "post_edit_prepro_extension";
$core['module']['post_add_extension'] = "post_add_extension";
$core['module']['post_edit_extension'] = "post_edit_extension";

The post_add_form_extension and post_edit_form_extension extensions process the data before when the form is loaded for editing. The post_add_prepro_extension and the post_edit_prepro_extension parse the data after the form is submitted, and before the system parses the data (using class_elements.php insert data builders). The post_add_extension and post_edit_extension parse the submitted data after the system is done with its own processing and before it's inserted into the database.

Extending Dynamic Data Processor Hooks

If you want to create a new hook for checking data processor availability, you can use the following snippet for intercepting data and customize it for "parent", "category", or whatever other dynamic content you may need to process, at whatever point in the system flow.

if (!empty($core['module']['whatever_processor']))
{
    $proc = new $core['module']['extension_class'];
    if (method_exists($proc, $core['module']['whatever_processor']) === TRUE)
        $data = $proc->$core['module']['whatever_processor']($data);   
}