The document provides documentation on creating WHMCS addon modules. It covers getting started, configuration, activation/deactivation, content output, sidebars, multi-language support, hooks, upgrades, and resources. Creating modules allows extending WHMCS with custom admin pages and hooks. Modules are managed through the Addon Modules interface in the WHMCS admin area.

1. WHMCS | Addon Module Documentation 1
WHMCS Addon Module Docs
Last Updated: 7th December 2010

2. WHMCS | Addon Module Documentation 2
Contents
3. Introduction
4. Getting Started
5. Configuration
6. Activating/Deactivating
7. Content/Output
8. Sidebar
9. Multi-Language
10. Hooks
11. Upgrades
12. Useful Resources

3. WHMCS | Addon Module Documentation 3
Introduction
Addon modules allow you to create both admin pages and hooks to extend WHMCS further.
Modules can consist of just an admin page, or just hooks, or both. And they are all managed
through the Setup > Addon Modules interface.
Once activated, the modules will display in a dedicated “Addons” dropdown menu within
the admin area for quick & easy access from any page.
Management options consist of activating and deactivating of the modules, aswell as access
control which allows full admins to define exactly which of the administrator roles are
allowed to access each addon module.
Why would I use a module for a hook?
You might be asking why would I create an admin module when I could just create a hook?
And the answer to that would be that creating a module provides an easy way for users to
install and remove the addon through the dedicated addon modules

4. WHMCS | Addon Module Documentation 4
Getting Started
To get started, you need to begin by choosing a name for your module. This name should be
unique among all the modules in WHMCS, and should contain only letters & numbers, all
lowercase. Underscores are on the only special characters that are accepted. For example,
valid names would be:
mymodulename
my_module_name
my_module_v5
Once you have chosen your name, you need to create a directory and module file for it. The
directory should be in the format /modules/addons/your_module_name/ and then the key
module file within it should be named “your_module_name.php”.
We have created an example module file which you can use as a basis for all your custom
modules to help with getting started, and that can be found at the path
/modules/addons/addonexample/ within your WHMCS installation.
Now let’s move onto customising the module…

5. WHMCS | Addon Module Documentation 5
Configuration
The first step in the module is defining the configuration data. This includes the module
name, version number, author, description and any configuration fields that might be
needed. Below is an example of the config function function:
function your_module_name_config() {
$configarray = array(
'name' => 'Friendly Display Name Here',
'version' => '1.0',
'author' => 'Your Name Here',
'description' => 'Description of your Addon/Module Here',
'fields' => array(
'username' => array("FriendlyName" => "API Username", "Type" => "text", "Size" =>
"30", ),
'password' => array("FriendlyName" => "API Password", "Type" => "password", "Size"
=> "30", ),
'signature' => array("FriendlyName" => "API Signature", "Type" => "password", "Size"
=> "50", “Description” => “You will find this in your account settings“, ),
),
);
return $configarray;
}
The first 4 fields: name, version, author & description should all be fairly self-explanatory.
These just need to contain the name you want displaying within the admin area for your
module, version number, your name/company and a brief description of the addon.
The fields section is where you can define the input you need from end users to be able to
make the module work. In this example we are asking for some API related information.
Supported field types are “text”, “password”, “yesno” (checkboxes), “textarea” and
“dropdown”. If using the textarea option then you can add a “Rows” parameter to define
the height of the box, and if using the dropdown type, then you must specify an “Options”
parameter with a comma separated list of values.
There is an optional language variable you can also include if you will be using language files
for your module - we’ll look at those in more detail later on.

6. WHMCS | Addon Module Documentation 6
Activating/Deactivating
Modules can contain both activate and deactivate functions which run when an admin user
activates or deactivates the module in the Addon Modules configuration area.
These functions can be used to create custom tables, database entries, perform license
checks, or anything else you need to run at the time of initial activation or final deactivation.
The deactivation function should undo everything that the activation function does in order
to fully remove the module from the users system.
One point to note is that there will already be an active database connection when the
module is run, so to access the WHMCS database you won’t need to reconnect to the
database.
So for example, the activate and deactivate functions could create and drop a table for use
by the custom module as below:
function your_module_name_activate() {
$query = "CREATE TABLE `mod_customtable` (`id` INT( 1 ) NOT NULL AUTO_INCREMENT
PRIMARY KEY ,`key` VARCHAR( 16 ) NOT NULL ,`value` TEXT NOT NULL )";
mysql_query($query);
}
function your_module_name_deactivate() {
$query = "DROP TABLE `mod_customtable`";
mysql_query($query);
}

7. WHMCS | Addon Module Documentation 7
Content/Output
Output from the modules needs to be defined in the function your_module_name_output
and should be actually output, (ie. echo’d) not returned.
All output will then be captured by WHMCS and displayed within the admin interface
template. The module name is automatically prefixed to the output.
Variables
The output function is passed all of the fields defined in your modules config, along with the
values users have set for them, aswell as a “modulelink” variable which you can use to link
back to the module.
Linking/Actions
Using the modulelink variable passed into the output function, you can then create links and
forms that post back to your module. The modulelink will be in the format
“addonmodules.php?module=xxxxxx” so for links you can then append “&var1=x&var2=y”
or with forms you can use the POST form method to receive user input.
Within the output function you can then check the $_GET or $_POST variables received in
the request in order to display other output or perform various tasks once links have been
followed.
Admin User Data
You can access the currently logged in admin ID should you need that within your module
using $_SESSION[‘adminid’] and from that can lookup any additional information you need
in tbladmins.
Example
function your_module_name_output($vars) {
$modulelink = $vars['modulelink'];
$username = $vars['username'];
$password = $vars['password'];
echo '<p>Your username is '.$username.'</p>';
}

8. WHMCS | Addon Module Documentation 8
Sidebar
An addon module can also define HTML code to be displayed in the sidebar. You can do
anything you want with this, but it is ideal for creating custom sub menus specific to a
custom module.
The function is passed all the same variables as the main content output function, and so
can be used like this:
function your_module_name_sidebar($vars) {
$modulelink = $vars['modulelink'];
$username = $vars['username'];
$password = $vars['password'];
$sidebar = '<span class="header"><img src="images/icons/addonmodules.png"
class="absmiddle" width="16" height="16" /> Sample</span>
<ul class="menu">
<li><a href="#">Sample Sidebar Link 1</a></li>
<li><a href="#">Sample Sidebar Link 2</a></li>
</ul>';
return $sidebar;
}

9. WHMCS | Addon Module Documentation 9
Multi-Language
Modules can be designed to support multiple languages should you wish.
For this, the addon module simply needs a lang subfolder creating within it, and within that
language files can be created matching the names of the main WHMCS admin area language
files located in the /admin/lang/ folder.
The language variables for custom modules are kept separate in language files within the
module’s own folder to make installation and updating easier.
If language files exist, WHMCS will then automatically load these whenever the custom
module is accessed, automatically selecting the appropriate language file based on the
currently logged in administrators language profile setting. If no matching language file
exists within the custom module’s folder for the language the admin is using then it will
simply fall back to the default language you set in the module’s config array.
The language variables are then passed into both the _output and _sidebar functions
variables array using “_lang”.
Please refer to the example addon modules language file located in
/modules/addons/addonexample/lang/english.php for the format to use for your custom
language variables.
Below is a demonstration of how you specify the default language for your module in the
config array.
function your_module_name_config() {
$configarray = array(
'name' => 'Friendly Display Name Here',
'version' => '1.0',
'author' => 'Your Name Here',
'description' => 'Description of your Addon/Module Here',
'language' => 'english',
'fields' => array(
etc…

10. WHMCS | Addon Module Documentation 10
Hooks
To create hooks that your module should define within WHMCS, you simply need to create
a file named “hooks.php” within your custom module folder, and that will then be
automatically detected and any hooks loaded on every page of WHMCS.
The hook functions within that file should be defined in exactly the same way as normal.
Please refer to http://wiki.whmcs.com/Hooks for more information on creating hooks.

11. WHMCS | Addon Module Documentation 11
Upgrades
Releasing updates and upgrades to your custom modules is likely something you will want
to do at some point in time. And if those require modifying the database structure or
performing other functions that would otherwise be performed in the _activate function
when being activated for the first time, then you need some way of handling that.
With the Addon Modules system, this is a breeze with the upgrade function. The upgrade
function is called the first time a module is accessed following an update. The update is
detected by a change of version number in the _config array of the module, and so if a
change is detected, the _upgrade function will be called. The upgrade function is passed the
previous version number so that you can then decide what updates you need to run within
that function to bring it up to date with your latest version.
An example of how this function can be used is demonstrated below:
function your_module_name_upgrade($vars) {
$version = $vars['version'];
if ($version=="1.0") {
$query = "ALTER TABLE mod_customtable ADD extrafield TEXT NOT NULL;";
mysql_query($query);
}
}

12. WHMCS | Addon Module Documentation 12
Useful Resources
Here are some code samples for how to match the styles of WHMCS within your custom
code.
Data Table
Used to output a table of data
<div class="tablebg">
<table class="datatable" width="100%" border="0" cellspacing="1" cellpadding="3">
<tr><th>Col 1</th><th>Col 2</th><th>Col 3</th></tr>
<tr><td>Data Row 1</td><td>Data Row 1</td><td>Data Row 1</td></tr>
<tr><td>Data Row 2</td><td>Data Row 2</td><td>Data Row 2</td></tr>
</table>
</div>
Fields Table
Used to output form fields
<table class="form" width="100%" border="0" cellspacing="2" cellpadding="3">
<tr><td width="20%" class="fieldlabel">Field Name 1</td><td class="fieldarea">Field
Contents</td></tr>
<tr><td class="fieldlabel">Field Name 2</td><td class="fieldarea">Field Contents</td></tr>
</table>