How to get Started: A Development Overview

 

There are two important decisions that you should make before you begin development of either your block or your plugin.

1) Naming: You need to decide on a name by which your block or plugin will be referred to in your code. For a block this is not as important as it is for a plugin, unless the block consists of several functions and/or has global configuration variables. See Naming Convention in the coding style section. For a plugin a single word name is required. It becomes the name of the sub-directories in which the plugin is installed and is used by the plugin API to interact with the plugin. Throughout this documentation you will find references to {plugin-name}. The value of {plugin-name} is the name you choose here.

2) DB Table Names: It is good practice to implement a prefix system for all your database tables like Geeklog has. This allows a site operator to run multiple sites off of the same database. You can add your tables to the $_TABLES array if you want and either use the global $_DB_table_prefix or better yet create your own prefix to prevent naming collisions. To include your tables in the $_TABLES variable, include lines like these at the top of your function.inc:

$_CT_table_prefix='ct_';
$_TABLES['mytable']    = $_CT_table_prefix . 'mytable';
$_TABLES['my2ndtable'] = $_CT_table_prefix . 'my2ndtable';

 

Plugin minimum requirements

It is possible to create a plugin with only a few files and using the universal installer program and sample functions, this a should be a very easy project and a good place for plugin developers to start and get familiar. The minimum that your plugin project will require is the following:

 

User Definable Preferences

If your project has the capability for the user to define individual preferences or settings, you do not want to extend or modify the core Geeklog tables to store these values. It may appear to be the easiest method but it is highly discouraged. You will want to add a project specific table such as 'cb_userprefs' for the Chatterblock plugin. Keeping your project tables separate allow the core tables to be maintained without breaking contributed code.

Your project usersettings program will then need to check if a record already exists for this user and if not create one. In your main project code, you would check if the current user has a record for their preferences and if not - use the site defaults. You can create a record with the user id of 0 for the site defaults.

You will find example code for this method in the Chatterblock Plugin - the program cb_userprefs.php.

The one problem with this method is that there is no way to delete the user settings records should the user be deleted. Users are not normally deleted (which is not a good excuse) but there is no user admin API to hook into currently.

Discussions are underway to include additional API's in GL release 1.3.8 to support calling Plugin User admin functions when new uses are added, edited or removed.

 

A few other best practices

 

Prev Index Next