Proposed -- Feature-- ... implemented concept Areas

After the Areas as Feature and the file binderlib.php (originally tiki-perspectivebinder.php) turned out to be a dead end, at the TikiFestBarcelona3 (August 2012) Luci and me figured out a completely different way to generate Areas. On a Website that uses "Perspectives", Areas can be build with a custom module.

1) Areas is NOT a feature (any more)
2) Areas is a concept of structuring and setting up the navigation through out a website.
3) An Area is kind of a Spaces on a website. Areas divide the site into several subspaces with individual modules, menus and content which are "bend" together with categories.

Read more at the documentation site: Areas

old content referring to the binderlib.php

What does Areas do?

At this early stage Areas is simply based on a php file called tiki-perspective_binder.php, witch binds a structure of caterories together with a corresponding set of perspectives as related pairs.

The file checks category Ids, perspective Ids and the perspectives category-jails directly in the database.
For content objects that are categorised in the structure mentioned above, it switches to the related perspective, wich contains the actual category in its jail.

Why developing Areas?

Tiki is an amasing collaborative tool, that you can configure very detailed, based on groups, categories and goup/category permissions.

For the use as website for anonymous visitors it was limited to some small scale until from Tiki4 onwards the Perspectives feature was invented.

Perspectives allows us to make content visible in different "environments" of themes, menus and modules, independant of being assigned to a group.

Perspectives made it possible to simulate different subwebsites in one installation and gave an opportunity to build up closed Spaces for workgroups with individual sets of modules, menus and themes for each group.

As every content (if Tikiuser has the permission to see) would be visible in every perspective, it was not possible to give away links to certain content objects and same time to make sure, that the user will see the content objects in the right context of menus and modules. There was no control about in wich the perspective a content would be shown except with using cryptical links.

Examples where this behaviour might confuse anonymous non-tecchie site visitors would be for example content of local organisations, wich would not make sense in the perspective of another local organisation or on the national website.

As said, the proposed Areas feature binds content objects to perspectives via a structure of categories, with the result, that this content under all circumstances will be shown in the defined perspective.
Thus it will appear always in the right context, whilst content that is not categorised in the areas-category-structure will be still visible in all perspectives.

In the example above, local Organisations could still share the same imprint, contact forms, maps, calendars and any global information of the different branches of an organisation.

The feature is limited either to one single area per content object or to global visibility.


  • Websites of national organisations with local or regional groups
  • News portals with specific local content
  • Intranets with project areas of different customers, that shgould not become mixed up
  • All websites, with aswell content or features that need to be used cross-site as content that should be kept apart from other content based on the same group level or for anonymous users
  • ...


Integrated with brief setup instructions since version 8, see admin section Areas (tiki-admin.php?page=areas).

For previous versions (as version 6 and 7, until backported):

In this early stage as more a feature preview it is necessary to fill in the database credentials into the file tiki-perspective_binder.php which should be copied directly into the Tiki root folder.
Further more in this file the Id of the structures base category has to be entered.
In the file tiki-setup.php a line of code has to be added to include the perspective binder and make it working (in Trunk this line (145) is already committed and just needs to be uncommented after all configurations are done).

In the Tiki Admin areas you have to setup a structure of categories, whilst the base category must be at the top level and all other categories which are related to the feature would be children of this one.
All other categories will not be affected and can be used as before.

All details of the configuration are mentioned at the end of tiki-perspective_binder.php as multiline comment.

The file and the supplemented line in tiki-setup.php have been committed to trunk today at 29-Aug-2011.

For use in Tiki6 or in Tiki7 you can download the file here tiki-perspective_binder.php and you may review and comment the code on this wikipage.

Necessary for the future

*The functionality of the tiki-perspective_binder.php should be nativly integrated into Tiki.
*Thus the direct calls to the database must be replaced by the appropriate Tiki operations.
*Either by rewriting this code or by adding the functionality into different existing files.
*We need some kind of interface in between the Tiki Admin areas to configure the feature there instead of editing the php file
+ -> where we could place a dialogue for that, or will it be worth to give it an individual space between the main sections?
done, see tiki-admin.php?page=areas

  • bugs hopefully exterminated the next stage would be to enable editing of areas directly on that admin panel

The code

Here is the initial text of Merbster, who did write the code shortly before I stumbled over him in the IRC and realised that a nearly two years lasting search for the Areas feature might have come to an end.

Merbster: "This wikipage has been created to give back my hack that makes it possible to set a perspective dynamically according to the active page's categoryIds. nkoth encouraged me to post it here so that others might review it and maybe change it into a fully fledged wiki feature."

Now we will appreciate any support from coders, admins, users etc. who will help us to further develop and integrate the idea of Areas into Tiki,
cheers, Torsten

The file is already committed to trunk.

If you want to try the code in Tiki7 or in Tiki6, you can download it here:

// For documentation how to use this file please see the comment at the end of this file
$sagsSideCatId = 1; // ID of the parent category that indicates the current page is assigned to an "Area"
global $prefs;


function HandleObjectCategories($objectCategoryIds)
    global $categlib;
    global $sagsSideCatId;
    if (!empty($objectCategoryIds))
        foreach($objectCategoryIds as $categId)
            if ($categlib->get_category_parent($categId) == $sagsSideCatId) // If parent category has ID equal to value of $sagsSideCatId
             $foundPerspective = GetPerspectiveId($categId);
                if ($foundPerspective != $_SESSION['current_perspective']) // If the found perspective is different than the current perspective, update it.
            else // If parent category id does not equal $sagsSideCatId set the default perspective (0)
                if ($foundPerspective != $_SESSION['current_perspective'])
    else if ($_SESSION['current_perspective'] !== 0)

function GetPerspectiveId($categoryId)

	try {
	$DAL = new PDO('mysql:host=XXXXXX;dbname=XXXXXX', 'XXXXXX', 'XXXXXX'); //TODO Fix centralized place to store db credentials
	$selectSql = "SELECT 
				FROM `XXXXXX`.`tiki_perspective_preferences`
				WHERE pref = 'category_jail' ";

	$statement = $DAL->prepare($selectSql);
            while ($row = $statement->fetch(PDO::FETCH_ASSOC)) 
            		$categories = unserialize($row["value"]); // categories are stored as serialized PHP in the database.
                            if (in_array($categoryId, $categories))
				 return $row["perspectiveId"];
       	return 0;
        catch (Exception $ex)
function SetPerspectiveId($perspectiveId)
    // Set the perspective in session var so it will last across several pages. (URL Parameter "perspectiveId" is only temporary across diff. pages.)
    $_SESSION['current_perspective'] = $perspectiveId;

    //Reroute browser back to calling script after we have applied our hack.
    header("Location: ". $_SERVER['REQUEST_URI']);	

+++ Description of Perspective Binder / Areas +++ 

This file is a hack to make it possible to divide a Tiki-Website in different individual * areas * by using categories and perspectives.

Most configurations are to be done in this file, which requires ftp-access to the Tiki root.
This is not a long term solution and only a workaround until this feature will be integrated natively in Tiki as "Areas".
Thus in the future all configurations will be done in the Tiki admin dialogues.
This file is just a first development preview based on a code, Jesper Merbt has written for a company project, but it is already possible for you, to use it semi-productive, if you need this function.

Whilst the "Workspaces" function makes complete sets of content-objects only visible for certain groups and leaves all contained content visible in all perspectives (for permitted users), the "Areas" function structures content related to the context and makes it visible only in one specific perspective (for permitted users). The "Areas" feature is independant from membership in groups and is usable also for anonymous non-registered visitors.

+++ Configurations +++

Please make sure, that on your webserver PDO is active - In this early stage this feature will only work with PDO and not with different database drivers.

Step 1 of 6‪still

This file tiki-perspective_binder.php must be saved in the tiki root folder.
Include this file in the file tiki-setup. php * after the categories lib has been loaded * with the following line:

//	include_once ('tiki-perspective_binder.php');
-> deleting the " // " AFTER all other necessary configurations will activate the tiki-perspective_binder.php

In a Tiki 6.3 this line could be included for ex. under line 131 of tiki-setup.php
In a Tiki 7.1 this line could be included for ex. under line 137 of tiki-setup.php .

Step 2 of 6

Then you have to get the database connection datas from db/local.php and fill them in above in THIS file in line 49 and line 55 this way:
line 55:	FROM `DATABASENAME`.`tiki_perspective_preferences`

Step 3 of 6

In Tiki you need to setup a structure of categories:
A basic category must be a "top category" with no parent.
You can name it for example "Areas"
Then you create one or several child categories of this category, wich you can name "Area1", "Area2", "Area3", etc.

Step 4 of 6

Please activate "categories used in templates" in your Tiki installation: 
Admin->Categories check tick box "categories used in templates

Step 5 of 6

Setup one perspective for each of the categories in the areas-structure.
Assign one category Id of this structure to the category jail of the related perspective, in the way that each perspective Id=X has one category Id=Y in its jail to bind exact one category and one perspective together.

Step 6 of 6

Go back to tiki-setup.php and uncomment line 138 by deleting the two slashes " // ".

+++ using the feature: +++

Once you proceeded all steps, you can assign objects like wikipages to ONE of the areas-categories and it will always be shown in the related perspective.

Thus you can built up "areas" as "subwebsites" and the (categorised) content, you call in the browser, will always be visible in the "environment" of theme, modules, etc., that you defined for the related perspective.

If you do not assign a content object to one of the areas-categories, it will still be visible in every perspective.

You can still assign objects to several categories, but please only assign to one of the areas-category structure, to make Tiki not confused what area an object is assigned to. You CAN assign objects only to one single area, OR leave it visible in all perspectives like it is the default. You CANNOT assign objects to several areas.

Now you can combine very specific content, that mainly makes sense in a specific context and is always automatically adressed in the related perspective, together with global content like imprints or general information, wich remains accessible in all perspectives across the whole Tiki website.

Examples of usage would be:

* Project related content, that only should be visible in the perspective and context of the specific project.
* Subwebsites of local groups 
a) that should not appear on the national website
b) whith content that automatically should be adressed to the right local website without cryptical urls, even if the same Tiki installation is shared for several groups
* News Websites with specific regional or local related content and common content in the same Tiki installation
* List may be continued over time

+++ End of Description +++