cPanel & WHM is a very powerful piece of software, that allows server managers to more easily manage their servers. The real power, though, comes from its extendability. In most webhosting environments, cPanel accounts are built using Account Packages. To help cPanel & WHM integrators, we released a new feature four years ago, in cPanel & WHM version 11.40, called package extensions. Package extensions allow our technology partners like CloudLinux to extend cPanel account packages to include their own features. However, features that we have added starting in version 60 have caused unintended problems with package extensions. We have markedly improved this interaction in version 68.
The old problem with editing packages in 66 and below
Customers and third-party developers have successfully used our package extensions for many years. However, in the last two years or so when they attempt to edit a package to add a package extension using the editpkg WHMAPI1 call, they trigger a problematic series of events. The below scenario explains the problem we needed to fix.
Consider a package named ‘Rutabaga’ which allows accounts to use up to 1024M of bandwidth per month. Five accounts are subscribed to the package. The image below shows what that might look like.
The hosting provider then modifies account number five, allowing them to use up to 2048M of bandwidth per month. We now have a common situation where account number five is assigned to the Rutabaga package, with a custom value for the bandwidth limit. The other accounts are still using the value for bandwidth specified in the Rutabaga package.
Here is where the problem comes in: when the package, Rutabaga, is edited to add a package extension, the accounts subscribed to the package have their limits reset to the values specified in the package. In our scenario, account number five will have her bandwidth limit reset to match the rest of the accounts assigned to the Rutabaga package.
From research and conversations, the expectation is for the custom limits defined in an account to be retained, so that’s what we wanted to fix.
New functions in Version 68!
Instead of changing the functionality of the existing API function and potentially breaking existing integrations, we opted to add additional functionality that could be incorporated by our integrators over time. In version 68 we added two new WHM API 1 functions to manage package extensions on packages: addpkgext and delpkgext. In the above scenario, if the integrator uses addpkgext instead of editpkg, the custom bandwidth limit will be retained, and the customer will remain unimpacted.
If your integration has historically needed to edit a package extension setting we recommend that you now use the addpkgext function in your integration. Running the addpkgext function against a package that already has that extension defined will result in the same package extension being added with the desired setting.
Though we did not deprecate or remove the package extensions parameter in the editpkg WHM API 1 function (to avoid the aforementioned potential errors), we strongly recommend that any existing integrators modify them to use the new addpkgext and delpkgext functions to handle package extension management.
What are your other integration pain points?
These functions are now used by our user interfaces and scripts as well, to ensure a consistent experience, and we will eventually move toward deprecating the editpkg call. For now, though: What other API and integration improvements would you like to see?
If you need help with your integrations, the best place to get it is our developer forum on the cPanel Forums, but you can always comment below, find me on twitter, or send me an email!
