ModuleLayout

Created by: Andrew Slater, Last modification: 01 May 2005 (06:30 UTC) by Stephan Borg

How it Works

At the risk of writing what may be obvious to many of you I thought I would write some about how the module management works in tp and what I think the solution to this particular problem is. I wrote the code for the "Active Modules" page, but not the "Configure Layout" page. I didn't do any of the base work setting up the basics of module management but I did do a fairly significant overhaul a few months back and I'm sure there is still lots of room for improvement.

First off, there are what we call modules and center pieces. It's important to understand that center pieces are really just modules in themeselves but they are always assigned to position 'c' (center) as opposed to column modules which can have position 'r' or 'l' (right or left respectively). Other than that distinction they are basically the same and I will be referring to them both as "modules" from here on out.

There are three tables which you should be familiar with if you want to understand how modules are managed: tiki_module_map, tiki_layouts_modules, and tiki_layouts. Let's break these down:

Table "public.tiki_module_map"
ColumnTypeModifiers
module_idintegernot null default nextval('public.tiki_module_map_module_id_seq'::text)
module_rsrccharacter varying(250)not null

Indexes: tiki_module_map_pkey primary key btree (module_id)

Example data:
module_idmodule_rsrc
1tikipackage:users/mod_login_box.tpl
2tikipackage:kernel/mod_application_menu.tpl
3tikipackage:blogs/center_list_blog_posts.tpl
4tikipackage:blogs/mod_last_blog_posts.tpl
5tikipackage:users/mod_user_blogs.tpl


tiki_module_map is the table which allows the mapping of every module which has ever been activated on an install to a unique integer. This allows us to turn on/off modules (activate/deactivate) and still have them retain a unique id which can be referenced by the other tables. This is also so we do not have to store and join on mod_rsrc strings all over the place and can instead simply join on module_id.

Table "public.tiki_layouts_modules"
ColumnTypeModifiers
module_idintegernot null
availabilitycharacter varying(1)
titlecharacter varying(255)
cache_timebigint
rowsinteger
paramscharacter varying(255)
groupstext


tiki_layouts_modules is a table which is holds every module which is activated. The options held for each module in this table can be considered as the defaults. These can be overriden by the columns with the same names in the tiki_layouts table (more on this later). It's important to note that group permissions are only stored in this table and not in tiki_layouts. Just because a module is listed in this table does not mean that it is set to be displayed anywhere on the site (that's what tiki_layouts is for). If a module is listed in this table it will be available for users to add to their custom layouts. When you are modifying options on the "Active Modules" admin page you are modifying the entries in this table. If you activate a module on that page it will be inserted into this table; if you deactivate a module it is removed.

Table "public.tiki_layouts"
ColumnTypeModifiers
user_idintegernot null
module_idintegernot null
layoutcharacter varying(160)not null default 'home'
positioncharacter varying(1)not null
rowsinteger
paramscharacter varying(255)
ordintegernot null default 1


The rows in tiki_layouts determine what layouts modules get displayed in and where they appear in that layout. These rows are what you are editing on the "Configure Layout" admin page. This brings me to the bug in question. You'll notice there is no groups column in the tiki_layouts table. It appears that currently the "Configure Layout" page is storing the group settings in the tiki_layout_modules table (pehaps rows, cache_time, etc as well — im not sure). I believe the "configure layout" page should only be modifying columns in the tiki_layouts page. One exception being the case where a module is assigned to a layout before it has been activated on the "Active Modules" page. In this case a row must be inserted in the tiki_layouts_modules table in order to activate it as well as adding a row to the tiki_layouts table. Based on this I think we can just remove the "Groups:" section of the form on the "Configure Layouts" page.

You'll also notice that the "Configure Layouts" page does not have the uber-complex javascript madness that the "Active Modules" page does. The reason I wrote all that javascript is so module options can be recalled for any module in the list. Otherwise the options for modules are lost every time they are displayed (e.g. the "Configure Layouts" page).

So that's my basic rundown of how I see module management working. I hope this has made some sense. If I've been unclear or omitted anything just ask and I'll try to answer to the best of my ability. It's been a while since I've looked at any of this code so I could slightly wrong about some of the details. Anyway, if anyone wants to try and tackle this bug (or the other issue that is solved by the javascript on the "Active Modules" page but is still a problem on the "Configure Layouts" page) then go for it! Otherwise I'll get to it when I get a chance. I'm pretty swamped with other stuff right now but I'll try and knock ASAP unless someone beats me to it.

Cheers,
Andrew Slater

Module Layout Defaults

The following is an excerpt of code, used as default module layout values during installation. The code is found in <package>/admin/schema_inc.php and will insert a module into the layout (as part of the install), using the following parameters.
{CODE()}$moduleHash = array(
'mod_server_stats' => array(
'title' => 'Server Statistics',
'groups' => array( 'Admin' ),
'ord' => 2,
'pos' => 'r',
'module_rsrc' => 'tikipackage:kernel/mod_server_stats.tpl'
),
);
$gTikiInstaller->registerModules( $moduleHash );{CODE}</package>