Skip Navigation

New config folder / admin module changes / module sets

July 29, 2010 at 2:38 pm
By nwhite

We have created a new folder within the core/local split called config. The intent is to provide a space to configure components of Reason while also providing access to the benefits of the core/local split framework.

The current settings folder still exists, but we will eventually be migrating more and more settings into the config directory and the settings folder will become focused primarily on reason_package utilities (that don't use the core/local split) and on reason bootstrapping.

I'll discuss separately the two folders currently in config, module_sets and admin_modules.

Admin Modules (admin_modules)

Previously, a file reason_package/reason_4.0/lib/core/classes/admin/admin_module.php defined all the modules used by the administrative interface. If you wanted to customize or add modules to the list, you had to either edit the file in the core, or override the file with a local version at reason_package/reason_4.0/lib/local/classes/admin/admin_module.php. This complicated updates, and made it difficult to add local admin modules while taking advantage of those added to the core.

Now, there is a file reason_package/reason_4.0/lib/core/config/admin_modules/setup.php which defines the core admin modules, and looks for a file called setup_local.php which defines additional admin modules that are merged into the set Reason uses.

If you previously created a local version of admin_module.php, you'll need to define your customizations in setup_local.php to get your local modules working again. Your setup_local.php file should them be placed in reason_package/reason_4.0/lib/local/config/admin_modules/setup_local.php.

The setup of admin modules now works similarly to page_types (which will also be moving to the config folder eventually).

Module Sets (module_sets)

Module sets are a new concept that addresses an old problem. We sometimes have groups of modules that need to be grouped into a set, and we have historically hard coded the names of such modules into php code, complicating code maintenance.

For instance, the events_mini module looks for an "events" page on a site. The module used to consult a hard coded list of module names, and then look for a page on the site that used one of those modules. As a result, if you created your own events module, you would also need to modify events_mini to keep things working smoothly.

Now, events_mini consults a module set called "events_display" - if you create a new module that displays events, you can create (or modify) reason_package/reason_4.0/lib/local/config/module_sets/setup_local.php to add your module to the "events_display" set.

In this manner, you keep up to date on changes to the set in the core while having a way to add your own modules to the set.

There are various other modules that will be reworked to take advantage of module sets.

Add a comment

The following fields are not to be filled out. Skip to Submit Button.
(This is here to trap robots. Don't put any text here.)
(This is here to trap robots. Don't put any text here.)
(This is here to trap robots. Don't put any text here.)