{"id":189,"date":"2011-10-05T13:44:12","date_gmt":"2011-10-05T18:44:12","guid":{"rendered":"http:\/\/blogs.wp.stage.cpanel.net\/?p=189"},"modified":"2011-10-05T13:44:12","modified_gmt":"2011-10-05T18:44:12","slug":"livephp","status":"publish","type":"post","link":"https:\/\/devel.www.cpanel.net\/blog\/products\/livephp\/","title":{"rendered":"LivePHP"},"content":{"rendered":"
Currently, if you want to write a Plugin for cPanel, you can write it in either LivePHP<\/a> or cPPHP<\/a>. 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.<\/em> <\/p>\n 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.<\/p>\n Consider the following standard use case:<\/p>\n 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.<\/p>\n 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: At least without wanting to tear their hair from their heads.<\/p>\n LiveAPI (aka LivePHP) resolves all of these problems.<\/strong> 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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: 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/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":[],"class_list":["post-189","post","type-post","status-publish","format-standard","hentry","category-products"],"acf":[],"yoast_head":"\n\n
\n<?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 ><\/code><\/p>\n
\nLivePHP 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.<\/p>\n
\n<?php
\ninclude(\"\/usr\/local\/cpanel\/php\/cpanel.php\");
\n$cpanel = new CPANEL();
\n$res = $cpanel->api1('Branding', 'include', array('stdheader.html') );
\nprint $res['cpanelresult']['data']['result'];
\n?>
\n<div class=\"body-content\">
\nHello World!
\n<\/div>
\n<?php
\n$res = $cpanel->api1('Branding', 'include', array('stdfooter.html') );
\nprint $res['cpanelresult']['data']['result'];
\n$cpanel->end();
\n<\/code><\/p>\n