LivePHP

Currently, if you want to write a Plugin for cPanel, you can write it in either LivePHP or cPPHP. Last year, we put some major effort into refactoring LivePHP. We added better debugging information, optimized the socket communication protocol, and added a few other tweaks. After a year of vetting by external developers, I can say with confidence: there is no longer any reason to use cPPHP when developing your application. cPPHP …

Spread the love

Currently, if you want to write a Plugin for cPanel, you can write it in either LivePHP or cPPHP. Last year, we put some major effort into refactoring LivePHP. We added better debugging information, optimized the socket communication protocol, and added a few other tweaks. After a year of vetting by external developers, I can say with confidence: there is no longer any reason to use cPPHP when developing your application.

cPPHP is a system that requires cPanel to parse cPanel tags and then run the result through the PHP interpreter. Alternately, it can run your code through a PHP interpreter, then parse out cPanel tags, depending on file extension. This system has a few major disadvantages.

Consider the following standard use case:

  • Grab information from database
  • Perform API call based on information from database
  • Update database

While in most ecosystems this is a very simple process, cPPHP does not make this easy because it required two separate pages. Once cPanel switches from one parsing engine to the other (e.g. PHP to cptags) there is no way to switch back. This means that to switch back, you have to grab the information from the database, POST that information to a second page, perform the API call, and then process it. This is not an ideal scenario for any plugin and leads to some ugliness that the end user doesn’t need to see.

Another problem with cPPHP is that the templating engine uses a proprietary format. While this format may work for our needs, it simply isn’t reasonable to expect a third party developer to write the following code to make & display an API call:
<?cp StatsBar::stat([tr class="row-%"][td class="stats_left"]%[/td][td class="stats_right"] % / %[br /][div class="stats_progress_bar"][div class="cpanel_widget_progress_bar_percent" style="display{colon}none"]%[/div][/div][/td][/tr],rowtype,item,count,max,percent) display=diskusage|bandwidthusage,infinitylang=true,rowcounter=mainstats >

At least without wanting to tear their hair from their heads.

LiveAPI (aka LivePHP) resolves all of these problems.
LivePHP provides an object for interfacing with LiveAPI. This API is a heavily optimized version of our XML API’s cpanel call. LiveAPI works by having an object, abstracted into a class, you can use to access cPanel’s API over a socket connection. When a LivePHP process is launched, cPanel forks itself into a special “LiveAPI” mode that acts as the socket server while the PHP script acts as a client sending commands to the server.

This solves both of the aforementioned problems. For the first case, when we wanted to grab information from a database, the interaction becomes simple. We begin by calling the database object, then call the LivePHP object, and finally call the database class again.

When calling API2, LivePHP will return the same data that’s returned by the actual API call, wrapped in some metadata. All of this data is in the same format that is used by our XML API cpanel call ). This allows you to format the data using whichever templating engine you prefer. This is a much cleaner method than the old cPPHP system. API1 calls return the same data structure through LiveAPI. The main difference is that the node containing the response data will contain a string rather than an array.

One of the major misconceptions I hear about LivePHP is that it can’t be branded. While this was true 2 years ago, before we optimized the system, it isn’t an issue now. The problem with branding used to be that calls tended to involve making an API call that had to make an API call. This caused problems with the serialization method we used, resulting in quite a few ugly nested cpanelresult data structures.

These days, it’s quite simple to brand LivePHP. For example, the following code will result in a branded LivePHP page that you can work with:
<?php
include("/usr/local/cpanel/php/cpanel.php");
$cpanel = new CPANEL();
$res = $cpanel->api1('Branding', 'include', array('stdheader.html') );
print $res['cpanelresult']['data']['result'];
?>
<div class="body-content">
Hello World!
</div>
<?php
$res = $cpanel->api1('Branding', 'include', array('stdfooter.html') );
print $res['cpanelresult']['data']['result'];
$cpanel->end();

As you can see, LiveAPI is a much more straightforward approach to the cPTags system. We have found LivePHP to be a much more robust system for developing cPanel plugins in PHP.

Facebook Comments

More Stuff

Backup Improvements for cPanel & WHM Backups are a crucial part of any hosting plan. The panic and worry of a site crashing can keep a website owner up at night. For many people, a websi...
BETA Release of PublicAPI PHP, the cPanel PHP Libr... We are pleased to announce that our PublicAPI PHP client is ready! This API query client is the sibling to Cpanel::PublicAPI that was announced last m...
Dev Update: cPanel & WHM version 56 peaks, ver... The next few weeks of cPanel’s development cycle are incredibly exciting for us. We recently pushed cPanel & WHM version 56 to the CURRENT tier, a...
Class is in Session: The New cPanel University Thousands of corporations and companies, and even more individuals, use the suite of tools loaded inside of cPanel & WHM to power their business a...
Spread the love

Posted by News Monkey