{"id":46989,"date":"2017-11-22T13:00:00","date_gmt":"2017-11-22T19:00:00","guid":{"rendered":"https:\/\/blog.cpanel.com\/?p=46989"},"modified":"2017-11-22T13:00:00","modified_gmt":"2017-11-22T19:00:00","slug":"improvements-to-cpanel-account-package-extensions","status":"publish","type":"post","link":"https:\/\/devel.www.cpanel.net\/blog\/products\/improvements-to-cpanel-account-package-extensions\/","title":{"rendered":"Improvements to cPanel Account Package Extensions"},"content":{"rendered":"
cPanel & WHM is a very powerful piece of software, that allows\u00a0server\u00a0managers to more easily\u00a0manage<\/span>\u00a0their servers. The real power, though, comes from its extendability. In most\u00a0webhosting\u00a0environments, cPanel accounts are built using\u00a0Account Packages<\/span><\/a>. To help cPanel & WHM integrators, we released a new feature four years ago, in cPanel & WHM version 11.40, called\u00a0package extensions<\/a>. Package extensions allow our technology partners like CloudLinux to extend cPanel account packages to include their own features.\u00a0However, features that we have added starting\u00a0in version 60<\/span>\u00a0have caused unintended problems with package extensions. We have markedly improved this interaction in version 68.<\/p>\n 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\u00a0 Consider a package named ‘Rutabaga’ which allows accounts to use\u00a0up to 1024M of bandwidth per month. Five accounts are subscribed to the package.\u00a0The image below shows what that might look like.<\/p>\n <\/p>\n The hosting provider then\u00a0modifies account number five<\/a>, 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.<\/p>\n <\/p>\n 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.\u00a0In our scenario, account number five will have her bandwidth limit reset to match the rest of the accounts assigned to the\u00a0Rutabaga package.<\/p>\n <\/p>\n From research and conversations, the expectation is for the\u00a0custom\u00a0limits defined in an account to be retained, so that’s what we wanted to fix.<\/p>\n 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:\u00a0 <\/p>\n If your integration has historically needed to edit a package extension setting we recommend that you now use\u00a0the\u00a0 Though we did\u00a0not deprecate or remove\u00a0the\u00a0 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\u00a0 If you need help with your integrations, the best place to get it is our developer forum\u00a0on the cPanel Forums<\/a>, but you can always comment below,\u00a0find me on twitter<\/span><\/a>, or\u00a0<\/span>send me an email<\/span><\/a>!<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" cPanel & WHM is a very powerful piece of software, that allows\u00a0server\u00a0managers to more easily\u00a0manage\u00a0their servers. The real power, though, comes from its extendability. In most\u00a0webhosting\u00a0environments, cPanel accounts are built using\u00a0Account Packages. To help cPanel & WHM integrators, we released a new feature four years ago, in cPanel & WHM version 11.40, called\u00a0package extensions. Package […]<\/p>\n","protected":false},"author":77,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[49],"tags":[1893,1897,1901,1745,1905,1465],"class_list":["post-46989","post","type-post","status-publish","format-standard","hentry","category-products","tag-how-to-add-to-packages","tag-integrators","tag-package-extensions","tag-v68","tag-whmapi","tag-whmapi1"],"acf":[],"yoast_head":"\nThe old problem with editing packages in 66 and below<\/h2>\n
editpkg<\/a><\/code>\u00a0WHMAPI1 call, they trigger a problematic series of events.\u00a0The below scenario explains the problem we needed to fix.<\/p>\n
New functions in Version 68!<\/h2>\n
addpkgext<\/a><\/code>\u00a0and\u00a0
delpkgext<\/a><\/code>.\u00a0In the above scenario, if the integrator uses\u00a0
addpkgext<\/code>\u00a0instead of\u00a0
editpkg<\/code>, the custom bandwidth limit will be retained, and the customer will remain unimpacted.<\/p>\n
addpkgext<\/code>\u00a0function\u00a0in your integration. Running the\u00a0
addpkgext<\/code>\u00a0function against a package that already has that extension defined will result in the same package extension being\u00a0added with\u00a0the desired setting.<\/p>\n
package extensions<\/code>\u00a0parameter\u00a0in the\u00a0
editpkg<\/code>\u00a0WHM API 1 function (to avoid the aforementioned potential errors),\u00a0we\u00a0strongly<\/strong>\u00a0recommend that any existing integrators modify them to use the\u00a0new\u00a0
addpkgext<\/code>\u00a0and\u00a0
delpkgext<\/code>\u00a0functions\u00a0to handle package extension management.<\/p>\n
What are your other integration pain points?<\/h2>\n
editpkg<\/code>\u00a0call. For now,\u00a0though: What\u00a0other API and integration improvements would you like to see?<\/p>\n