The (shortened) plugins workflow as follow:

• you create the plugin.php file and the index.php

• you then configure where it will be seen (in the plugins section of the administration panel)

• the main/inc/lib/template.lib.php class (around line 140) "loads" the plugins regions

• regions are defined in main/inc/lib/plugin.lib.php and the method "get_installed_plugins_by_region" allows you to know which plugin should be enabled in a specific region of the user interface

• (back to template.lib.php ~140) the template lib "loads" the plugins inside specific template variables called "plugin_[region]"

• the template variables defined are then shown by any .tpl that loads them

  TPL (template) files inside the main/template/default/ directory (see templates section above).

  For example, for the normal student "2-columns" view of the courses list (like in userportal.php), you can check layout/layout_2col.tpl, and in general they will load {{plugin[region]}}variables depending on the region the plugin defines.At the moment, there is no "region" defined for the courses list, so if you want to make a plugin appear there, you should define a new region (both inside one of the .tpl files and inside plugin.lib.php), or you could use the menu_top and menu_bottom respectively (I believe these are for the left/right menu).

Plugins in Chamilo exist to allow third party to (relatively easily) integrate new components in Chamilo, and are viewed either as a « staging » platform to include new features in the core of Chamilo in future versions, or as a « buffer » where we can make some code reside that we don't really want to integrate to Chamilo (usually for ethical or licensing reasons) but that we know might benefit our community at large.

For integrators, it is a great way to insert new code into Chamilo without having to wait for the next major version in order to incorporate database changes, as the plugins can have their own installer/uninstaller.

Plugins can be split in 2 categories : visual plugins, and back-end plugins. Back-end plugins act in the background (you'd have guessed) and require much less work (usually) from the visual design side. Visual plugins need to be crafted carefully so they integrate seamlessly into the Chamilo layout.

Although this is the major division, we won't make any distinction in the following section between these. If you develop a back-end plugin, just ignore the display part.

We will, however, differentiate between the general plugins (all but one at this time) and the dashboard plugin, as this last one represents a specific case that appears as a top menu tabulation entry and is only allowed to administrators.

Coming soon...

Whenever connecting Chamilo for Single Sign On to a third-party solution that doesn't offer compatibility with any of the supported methods, you will want to check main/auth/sso/ and "extend" (in PHP) the sso.class.php (like the example for Drupal).

These files contain explanations of what you need to add to your database to support the custom method, and how you need to call it.

If you miss inspiration for your side of the SSO (third-party solution), you can check the Drupal-Chamilo project code here: http://cgit.drupalcode.org/chamilo/tree/chamilo.module#n42

Finally, you might need to check in main/inc/local.inc.php for the "sso" term to find where it all gets managed in the Chamilo login process.

Hooks

Plugins can use "hooks", which are similar to what can be found in the Drupal CMS: places in the normal workflow of Chamilo where plugins can intervene.

It works in Chamilo by having the normal process, for example to delete a user, calling a special function that will look for any plugin installed and that implement a specific method.

The hooks are defined in main/inc/lib/hook/ and are instanciated in the normal workflow. For example, in usermanager.lib.php, we find that the UserManager::create_user() method actually instanciates the HookCreateUser object and then calls one of its method:

Hooks also have to be defined in all plugins. See for a very short note on the issue of adding hooks halfway through a minor version, and on the existence of 3 functions (doWhenDeletingCourse, doWhenDeletingSession and doWhenDeletingUser) that are not implemented as hooks yet but that should be in 2.0.

Coming soon...

Coming soon...

Coming soon...

Plugins can also use the global get_lang() function available inside the rest of the code of Chamilo, but they have to use a variation : get_plugin_lang(), that requires you to give the name of the plugin in which it is used.

Language variables have to be located in a lang/[language].php file. E.g, the basic plugin language file for plugin « abc » will reside inside the plugin's subfolder « lang »: /plugin/abc/lang/english.php

The file itself has to use the following format :

/* Plugin's language variables */

$strings['plugin_title'] = 'ABC';
$strings['plugin_comment'] = 'Plugin for managing the … website';
$strings['SelectASession'] = 'Select a session';

As you can see, the format has to be set as an array called « $strings ».

The two first array elements are mandatory. They will allow administrators to see the plugin name and a short description in their own language.

To use the variables from inside the plugin, inside a template file (.tpl)... (to be completed)

At the moment we removed the dashboard from the teacher/student view because some of the charts that show there are very slow when you have a lot of data, and we believe it would be a bad idea to show it to all users.Recently, however, we started doing a small change to allow the platform admin to see one more chart than the other admins, so there is a start for doing role-based changes.

If you want to unlock completely the dashboard for all users, you can unlock the permissions at main/inc/lib/banner.lib.php, around line 319, where you have checks on api_is_platform_admin(), api_is_drh() and api_is_session_admin(). Remove this line and you'll get it for students and teachers indifferently.

The LDAP authentication system in Chamilo has been submitted to various deep changes over time, and the current situation is somewhat confusing and always require some kind of manual update.

A patch by Eric Marguin in version 1.10.0 fixed a series of issues from previous versions, related to import scripts not using the configuration file for LDAP (main/inc/conf/auth.conf.php).

Configuring LDAP

To configure LDAP, check the LDAP variables in main/inc/conf/auth.conf.php.

By default, it will come like this (more or less), where elements to be adapted to your own LDAP server and configuration have been coloured in red :

Once you've got that file setup, you'll have to change configuration.php before a few things are added to your administration interface.

If you look at app/config/configuration.php and search for « ldap », you'll find these 3 lines:

Uncomment them to enable a few additional scripts.

When uncommenting, you'll see the following item appear in the administration panel.

This will give you access to a search list for users on the LDAP server, and options to import those users. Versions 1.9.x of Chamilo LMS, however, might have had a little issue with that, making it actually impossible to search from this screen.

To fix that, you should go and edit the ldapget_users functions in main/auth/external_login/ldap.inc.php. There, you'll see that no matter what mapping you gave in the $extldap_user_correspondance_variable in auth.conf.php, it isn't taken into account. Update that to get the search working.

Note that this should be fixed in Chamilo LMS 1.10.x.

Running synchronisations

Some synchronization mechanisms are made to be run automatically (through CRON). To find these, look deeper into the main/auth/external_login/ folder.

The ldap_import_all_users.php script, for example, can be executed to automatically insert all users from LDAP (following specific criterias defined in ldap.inc.php) into Chamilo. Please note that, once again, in version 1.9.x, this used to be slightly broken, requiring a review of the ldap.inc.php functions in order to work.