I have been noticing several people challenged with calling cPanel functions via our various ways of hooking into our APIs. Unfortunately, this isn’t as cut and dry as just calling a function within a programming language.\u00a0 Various factors, such as whether the call is being made from within cPanel or from a remote system, affect how this needs to be done.<\/p>\n
To help you understand this, I will begin covering these topics in a series of posts on cPanel’s various functions and how they work. In this first post of the series, I will discuss the basics of cPanel’s APIs, and how to call API1 functions.<\/p>\n
The basics<\/strong> For the most part, cPanel’s API is divided into two sub-systems; API1 and API2. The difference between these is in how they are called and how they return data.<\/p>\n API1<\/strong> will normally print data to the cPanel interface.\u00a0 This works well when the functions are called via cpanel<\/em> tags (covered later in this article), but won’t return much useful data when called via the XML API, livePHP or CGI scripts.<\/p>\n API2<\/strong>, on the other hand, is a much more robust system, capable of returning complex data structures that can be parsed into templates contained within a cp<\/em> tag. API2 calls, as they do actually return data, will always return relevant information when called via the XML API, livePHP or CGI scripts.<\/p>\n One of my favorite features of API2 is that it uses named-based parameters that translate well into URL parameters.<\/p>\n Calling API1 functions<\/strong> So, if you wanted to call Ftp::ftpservername()<\/em>, which is used to print out which FTP server is being used, it would be called with the following syntax: Now, you will not want all functions to actually display data. For example, Mysql::adddb<\/em> is generally something that you do not want printing data, for security reasons. Instead you want to check for error handling.<\/p>\n Any data being printed from this function can be suppressed in the browser via HTML comments, like so: Sending input to the API1 function<\/strong> Inside of cPanel’s HTML parsing, we have access to certain variables. The main variables that you need to be aware of are $FORM<\/em> and $CPERROR<\/em>. <\/em><\/p>\n $FORM<\/em> is merely a variable that is populated with either GET<\/em> or POST<\/em> data passed to the page from the browser. This variable is how cPanel passes data around from page to page. To access it, you call the $FORM<\/em> variable the same way that you would call a hash in Perl ($FORM{‘element’}<\/em>).<\/p>\n So, for example, if you had a page called add_mysql_db<\/em> that was passed the following: It would contain the following: The <cpanelif><\/em> tag<\/strong> To call cpanelif<\/em>, you will do something like the following: HTML CODE HERE<\/p>\n <\/cpanelif><\/p>\n This is useful when you want to display an error message within cPanel’s interface.\u00a0 These are populated into the $CPERROR{$context} <\/em>variable.<\/p>\n Unfortunately, context is defined on the back-end on a per-module basis, so generally $context<\/em> will be the same as whatever module you are calling.\u00a0 In the case of our previous MySQL example, if we wanted to check for an error message, we would want to do the following: ERROR: $CPERROR{‘mysql’}<\/p>\n <\/cpanelif><\/p>\n Of course, you would want to also want to do !$CPERROR{‘mysql’} <\/em>around any success messages to make sure you don’t end up with “ERROR: errormsg This was successful”.<\/p>\n These are the basics of how to call API1 via .html<\/em> files. You can always use the XML API to call these functions as well, but because this is API1, you may not get any useful data.<\/p>\n","protected":false},"excerpt":{"rendered":" I have been noticing several people challenged with calling cPanel functions via our various ways of hooking into our APIs. Unfortunately, this isn’t as cut and dry as just calling a function within a programming language.\u00a0 Various factors, such as whether the call is being made from within cPanel or from a remote system, affect […]<\/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-54","post","type-post","status-publish","format-standard","hentry","category-products"],"acf":[],"yoast_head":"\n
\nBefore we can even begin going over how to call cPanel’s API functions, we need to discuss the various API types.<\/p>\n
\nAPI1 functions can be called via a tag. As previously mentioned, these print data to the cPanel interface. cpanel<\/em> tags use the following format:
\n<cpanel Module=\"function( params )\">\u2028<\/code><\/p>\n
\n<cpanel Ftp=\"ftpservername()\"><\/code><\/p>\n
\n<!--Module=\"function()\"-->\u2028<\/code><\/p>\n
\nSo, in order to pass data to an API function, we will need a way to pull in the data.<\/p>\n
\nadd_mysql_db.html?db=dbname<\/code><\/p>\n
\n<cpanel Mysql=\"addb( $FORM{'db'} )\"><\/code><\/p>\n
\nAlong with the cpanel<\/em> tag, there is also support for some really basic logic within this system, via the <cpanelif><\/em> tag. This tag allows for checking of basic boolean logic to see if a variable is set; if true, it will send whatever is contained between the <cpanelif><\/em> tags to the browser.\u00a0 <cpanelif> tags cannot be nested in any way.<\/p>\n
\n<cpanelif $VAR{''}><\/code><\/p>\n
\n<cpanel Mysql=\"adddb( $FORM{'db'} )\"><\/code>
\n<cpanelif $CPERROR{‘mysql’}><\/p>\n