The hack is spread across a couple of files

index.php

every module has its dispatcher in this file. The calendar module is no exception. Here, I coordinate, which function gets what input.

inc/CatMan.php

This new include file handles the new settings-addon for translating categories.

inc/CatSelect.php

Here I've implemented the code that shows the category-selector.

class/Display.php

Display handles -- nomen est omen -- the calendar display. We need to change four views: day, week, month and year.

class/Calendar.php

This is, where the actual filtering takes place. I've kicked out the old SQL-statements and made three more complex functions out of them.

I've divided the file in a couple of functions so it would be easier to handle. handle_admin_functions($command) and handle_user_functions($command) are the former admin / user dispatchers.

before handling the given url, I set up the current filter with the new written set_up_filter() function. It retrieves the current filter from $_SESSION['cal_filter'] and sets it if it is requested through the current url.

Next in line are the various new urls. cat_man calls the CatMan function of inc/CatMan.php, show_cat shows the current category-setup via a function included in index.php and cat_select calls the CatSelect function of inc/CatSelect.php.

The CatMan is very straight forward. If it gets the 'go' command, it will translate the current categories. If it doesn't, it shows all the categories together with the input-box.

inc/CatSelect.php does pretty mutch the same like CatMan. But it shows checkboxes instead of the input-fields and doesn't store anything.

After the user presses submit, he will be lead back to the last calendar-view he was on. This little piece of magic happens through the url -- I simply set up a hidden field called 'calendar[view]'.

index.php takes care of the actual change.

Every calendar-view has its own display function here. At the end of the functions, you'll usually see a final template-assignment and a call of that template.

I've intercepted that and put the category in front. The function I wrote for that is called interpretFilter($filter, $new_view) , it gets the current filter as well as the name of the current view (year, month, etc.)

The current view is needed for inc/CatSelect.php, so the user would be able to come back to his last view in case the user would want to change the filtering.

I've introduced two new functions here: genRepeatsSQL() and genStraightSQL(). Both call the new master sql-generator that is the heart of the whole hack.

genEventsSQL() gets a bunch of parameters. $fields contains the fields the calling method would like to have. The former calendar module used '*' here, but that would not work because of the joins going on now.

$table tells genEventsSQL, which table to use. $startDate and $endDate limit the intervall, $filter contains the filter and $access tells, whether the user is allowed to view inactive events as well.