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

The Retro Style for Paper Lantern arrives with 11.48 Moving from X3 to Paper Lantern can be jarring. The clean white interface, the consistent margins and spacings, and the new flat application icons sta...
Moving Your WordPress.com site to a cPanel Server WordPress is the most commonly used CMS (Content Management Software) on the internet, with a market share of 59.5% of websites built on the internet....
Tweak to installation scripts for plugin developers Just a heads up for cPanel Plugin Developers out there:  11.50 has hit the release tier. It includes a small tweak to how the plugin installation scri...
So Where Are We Heading with Paper Lantern? I realized, as I was reading some blog coverage of Paper Lantern, that we never really laid out the direction we’re heading in with our work. Sure, we...
Spread the love

Posted by News Monkey