From Apis Networks Wiki

Contents 1 Usage 1.1 Using PHP5.3 1.2 Which modules are built into PHP? 1.3 Will x work on the server? 1.4 Which decoders are supported on the server? 1.4.1 Using Zend Optimizer 2 Configuration 2.1 Overriding stock configuration 2.2 Where are uploaded files stored? 3 Troubleshooting 3.1 Blank pages 3.2 open_basedir restriction message

Usage

Using PHP5.3

In order to run your site using PHP 5.3, create a .htaccess file in /var/www/html with the following lines:

RewriteEngine On
RewriteCond %{HTTP_HOST} !:9000$
RewriteCond %{SCRIPT_FILENAME} \.php$ [OR]
RewriteCond %{REQUEST_URI} ^$
RewriteRule ^(.*)$ http://%{HTTP_HOST}:9000/$1 [P,L]

All files ending in .php will be handed off for processing by the PHP 5.3 server.

Which modules are built into PHP?

See the phpinfo() page; for PHP4 module listings, see the following phpinfo() page.

Will x work on the server?

If it's built around Linux and it's a popular application, then 99.995% of the time, the answer is "Yes". All known popular open-source applications, and even closed-source applications requiring ionCube also function without issue.

Which decoders are supported on the server?

Currently we support ionCube Loader for encoded PHP scripts. We are unable to incorporate Zend Optimizer directly into the mix due stability problems and incompatibilities between APC and Zend Optimizer. Zend Optimizer is provided on an alternative port similar to how PHP4 is enabled. Instructions are provided below.

APC is configured with RFC 1867 support, which allows you to monitor file upload progress.

Using Zend Optimizer

An analogous PHP5 interpreter is installed on port 9001. The only difference is that ionCube and APC have been replaced with only Zend Optimizer— there is no caching nor optimization! You will need to file a ticket for us to setup the necessary configuration to use PHP5 with Zend Optimizer. Once done, the following .htaccess rule will transparently map all PHP files over to the slave server on 9001 running Zend Optimizer:

RewriteEngine On
RewriteCond %{HTTP_HOST} !:9001$
RewriteCond %{SCRIPT_FILENAME} \.php$ [OR]
RewriteCond %{REQUEST_URI} ^$
RewriteRule ^(.*)$ http://%{HTTP_HOST}:9001/$1 [P,L]

Configuration

Overriding stock configuration

Sometimes the default configuration with PHP is inadequate to satisfy your demands. PHP's default configuration values may be modified by using the php_value directive within a .htaccess file. For example, to modify the maximum allowable size of an uploaded file, you would use the following:

php_value upload_max_filesize 16M

Important: PHP modifications only apply to the parent directory and its children. If the .htaccess file were placed in /var/www/html, then the changes would apply to the document root and recursively to all directories within.

Where are uploaded files stored?

Uploaded files are stored in /tmp on the server. This directory is inaccessible from the FTP, shell, and File Manager due to jailing restrictions. If you need direct access to temporarily uploaded files in /tmp through another medium besides PHP, then override the upload_tmp_dir directive with your real path, e.g. in a .htaccess file

php_value upload_tmp_dir /home/virtual/site1/fst/tmp

site1 is derived from your Site ID field in the dashboard. For more information on handling file uploads see PHP: Handling file uploads

Troubleshooting

Blank pages

Corruption may occur with exotic code in APC. We have seen this happen with custom Joomla! modules and a custom Simple Machines Forum install. APC caching may be disabled by turning apc.cache_by_default off:

php_flag apc.cache_by_default off

open_basedir restriction message

The error message arises due to one of two circumstances

1. You have used the portable /home/virtual/<your domain>/ path in the construction
2. You misinterpreted the chroot'd path seen in FTP and the File Manager as the actual path. /var/www/html/ as seen in your FTP client is not the absolute path as seen by a PHP script.

In the first case of using your domain name in the path, that is actually a symbolic link to /home/virtual/site<site number>/fst. PHP's open basedir security mechanism cannot correctly transform for example /home/virtual/apisnetworks.com/var/www/html to its resolved path /home/virtual/site1/fst/var/www/html due to underlying limitations in PHP's engine.

In similar vein, case 2 may be resolved by changing the path from /var/www/html to /home/virtual/site<site number>/fst/var/www/html.

<site number> is a value derived from the Site field in the control panel under Account Overview in the dashboard.

Let's examine two quick snippets for a better understanding of the pathing issue. The first example is incorrect, because it references a path outside the domain's filesystem (case 2), while the second not only corrects the issue but provides a portable, no-frills solution if your account ever changes servers.

<?php
    $fp = fopen('/var/www/html/test.txt','w+');
?>

<?php
    $fp = fopen($_SERVER['SITE_ROOT'].'/var/www/html/test.txt','w+');
    // the following is also acceptable
    // $fp = fopen('/home/virtual/site1/fst/var/www/html/test.txt','w+');
?>

Here is another example with the incorrect path followed by the corrected version.

<?php
$doc_root = '/var/www/html';
?>

<?php
$doc_root = $_SERVER['SITE_ROOT'].'/var/www/html';
?>