One of the things that is high on my feature list is the ability for outside people to extend the system without touching any of the core files. I am jumping for joy to say that this portion of the script was finished up today. In the rest of this post I will try and shed some light on the advantages of a system like this and some insight in how we accomplished it.

Less Bloat

By keeping the core lean and mean it makes bug tracking easy and keeps the administration trimmed down to what you actually use. What good is a product with millions of options if you only use a couple?

Easier Upgrades

If you do not have to touch the core script to add a feature then upgrading should be painless. No need to worry about every little change you made and document it. Of course if you think it is easier to not use the module the system and hack your site anyway then this will not be the case but that is why we are spending so much time building it this way.

No Waiting

With a module system you do not have to wait on a feature to be released. You have the power to add it in any time you want.

How it works

The module system was fairly complex to setup and I had to create a custom library to interact with the “module hooks” and a custom view file that loads a file from the module directory. The hooks are called through out the script like this:

$this->kb_hooks->call_hook('article_edit', $arr);

Which in turn call a module with the function “modulename_article_edit”.

Wrap Up

I am sure you can probably tell from the benefits listed above that I am excited about this module system and I think you will to once you get a chance to give a test drive. At a later date I will be writing a tutorial on how to code a module and be more in depth on how the backend works.