Revision as of 22:59, 10 April 2017

WHMCS 7.2 introduces the ability to associate Product Add-ons with Provisioning Modules.

For many provisioning modules, this won't require any changes at all. For some modules, some small changes may be required.

The following document describes these changes.

Will I need to make changes?

You will almost certainly need to make changes if your module does any 1 or more of the following:

• Performs database updates to tblhosting (the table used to store services information)
• Uses custom database tables or tracks relationships based on the service id
• Makes use of custom fields

Detailed Information

Database Changes

Whereas previously it was safe to assume that any time a module action was invoked, it was being invoked for a product/service which lived in the tblhosting database table and that you would always receive a serviceid, that is no longer the case.

Now the module actions can be invoked for add-ons too, and in those cases, you will receive all the same module parameters as before but with the addition of addonId which will contain the ID of the add-on for which the module action has been invoked for (tblhostingaddons.id).

There are two ways to determine the type of product being acted upon:

1. You can check for the existence of addonId. If defined, the module action has been invoked for a product addon.
2. You can assert the type of the model provided to you:

if ($params['model'] instanceof \WHMCS\Service\Service) {
    // Method was invoked for a Service
} elseif ($params['model'] instanceof \WHMCS\Service\Addon) {
    // Method was invoked for an Add-on
}

Custom Fields

Many provisioning modules often require storing of additional information relating to a product. For this, you use custom fields. Custom fields were not previously available for Product Addons, but along with the introduction of module support in WHMCS 7.2, we also introduced support for custom fields.

To make it easier to work with custom fields, and to aide module developers, WHMCS 7.2 introduces the concept of Service Properties.

A Service Property is a key/value pair relating to a given instance of a product or add-on. Stored in custom fields, service properties allow module developers to interact with custom fields in a simple programmatic way that is consistent for both products and add-ons.

If you store any values into custom fields as part of your module code, relating it to the serviceid for which the action is being performed, you likely need to make some changes. You can read more about how to work with the new Service Properties functionality here.