It’s a well know fact that you can preform HTTP requests with CURL. Zend Framework does the same job with Zend_Http. Especially Zend_Http_Client can be used to “replace” the usual client – the browser, and to perform some basic requests.

I’ve seen mostly GET requests, although Zend_Http_Client can perform various requests such as POST as well.

// new HTTP request to some HTTP address
$httpClient = new Zend_Http_Client('http://www.example.com/');
// GET the response
$response = $httpClient->request(Zend_Http_Client::GET);

Here’s a little snippet showing how to POST some data to a server.

// new HTTP request to some HTTP address
$client = new Zend_Http_Client('http://www.example.com/');
// set some parameters
$client->setParameterPost('name', 'value');
// POST request
$response = $client->request(Zend_Http_Client::POST);

Note that the request method returns a response. Thus if you are simulating a form submit action you can “redirect” to the desired page just like the form.

// new HTTP request to some HTTP address
$client = new Zend_Http_Client('http://www.example.com/');
// set some parameters
$client->setParameterPost('name', 'value');
// POST request
$response = $client->request(Zend_Http_Client::POST);
echo $response->location;

First of all there are several things to know about Zend Framework and caching. Whenever you work on a big web application caching is one of the mostly used mechanisms of speeding up the app and improve user performance. In general the task and the solution are pretty simple and natural.

As the application grows up the visitors become more and more impatient about what they receive. A single page is becoming slower and slower and the result is painful. First of all every time a user hits a page the application server uses the web server, a script interpreter, a database server and potentially the file system. But that’s not all. After all this output is generated on the server, as HTML in the most cases, it is sent to the client where again CSS and JavaScript engines parse and execute them.

In this scenario it’s easy to imagine how many time is spent. While there are several techniques to optimize the client side by optimizing JavaScript, CSS and the static images used for the design of the site, here I’m going to talk more about the backend.

Beside the Optimization

Let’s assume we’ve one of the very used combination between Apache (as a webserver), PHP (as server scripting language) and MySQL (as database server). Here you can choose to optimize all three of them. However beside the optimization of them one of the most simple steps you can do is to cache the output generated by these three branches of your web app.

Caching the Content

In fact you can cache only single parts of the whole process. For instance you can cache only the result returned by some slow database query. Let’s imagine a query takes about 2 seconds to execute. Now you can cache the result into a file and during the cache is active, i.e. it has not expired, the application takes it from a file stored somewhere in the file system.

In a typical Zend Framework scenario you can first setup the frontend and backend options of the cache.

$frontendOptions = array(
	'lifetime'                => 600, // in seconds - this is 10 seconds
	'automatic_serialization' => true,
);
$backendOptions = array('cache_dir' => 'cache/');
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
		
$cacheKey = md5('mykey');

if (!$cache->load($cacheKey)) {
	$slowQueryResult = $article->fetchAll();
	$cache->save($slowQueryResult, $cacheKey);
} else {
	$slowQueryResult = $cache->load($cacheKey);
}

You can setup different options here by setting up the cache directory, lifetime, etc.

Note that the cache directory must exists and with write permissions and Zend Framework doesn’t create it for you and will throw error.

The problem here is that now you cache only part of the generated content and in many cases this is still too slow for most of the users. However all the work (in most of the cases) of the web server, the script interpreter and the database server result in a simple HTML output. What if you have this output generated or cached for you and when the user hit the page the server will return this pre-generated code?

This is indeed very fast, because it’s similar to return a text file, as the HTML is simply formatted text.

Caching the Entire Page

Before I proceed, I’d like to say that I work with Zend Framework 1.9.x. Now in the latest versions of ZF there are new mechanisms of caching the output even Zend_Cache_Frontend_Page works fine on them.

You can simply setup the page cache within few simple lines of code:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
	'cache' => true,
         'cache_with_cookie_variables' => true,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

However my advise is to place this code as high as possible, because this will cache everything generated as output. It’s a good practice if you place this even in the bootstrap before you make the connection with the database. Actually you don’t need a database connection when you’ve to return a simple text(html) file.

This will improve your app’s performance a lot!

However there are few things to know. When you setup the cache to work even with cookie variables, you can see that hitting the page with different browsers Zend Framework will generated different cache pages. This is quite useless because than you don’t have any benefit of caching the content.

First of all let me say that THIS IS NOT A BUG! of ZF. Simply the framework will use the cookie variables to generate the cache key. It’s obvious that different browsers, even more different users, will have different cookie set and the framework will generate different cache keys for them.

Thus you’ve to change the setting to generate the cache key from cookie variable by explicitly set this option to false:

$fo = array(
    'lifetime' => 600,
    'regexps' => array(
        '^/' => array(
		 'cache' => true,
         'cache_with_cookie_variables' => true,
         'make_id_with_cookie_variables' => false,
        ),
    )
);

$bo = array(
    'cache_dir' => 'cache/'
);

$cache = Zend_Cache::factory('Page', 'File', $fo, $bo);
$cache->start();

Note that in this example we cache every single page generated by the framework explained in the regexps. This is not so good especially when the users have the possibility to login and to see customized content for them, so you can be careful what you cache.

A typical problem that this solution solves is when your application uses Google Analytics. As you may know Google Analytics sets up a cookie every time when an user hits the page, so every time the framework will generate a different cache for him and in result he won’t see any benefit and performance improvement from your site.

 true,
            'lifetime' => 60
        );

        $backendOptions  = array(
            'cache_dir' => realpath(APPLICATION_PATH . '/../cache')
        );

        $cache = Zend_Cache::factory('Core',
                                     'File',
                                     $frontendOptions,
                                     $backendOptions);

        Zend_Registry::set('cache', $cache);
    }
}

Than add it as a front controller plugin:

// cache plugin
$frontController->registerPlugin(new CacheInit());

Since native RSS format is not designed to deliver media content, there is a need for newer format supporting video and audio. There is such format – Media RSS introduced by Yahoo! in 2004. Actually now RSS supports some king of pseudo audio and video with the enclosure tag.

Although there is a standardized format, there is not a Zend Framework native module. There is however a proposal, but that’s far not enough.

Possible Solutions

For me there are two possible solutions. The first is writing Zend_Feed_Mrss and extend the Zend_Feed_Rss functionality, but that appears to be a non-trivial task. The second solution is to write custom view returning XML, which I’m choosing for now. I hope I can paste some code soon!

As you may know in PHP you can access everything in the request uri by accessing the global $_GET array. If there is something like that in the browser’s address field: www.example.com/index.php?controller=index&action=test, you can simply get the values by that:

echo $_GET['controller']; // this will print "index"
echo $_GET['action'];     // this will print "test"

Zend Framework, Uri & Request Params

If you code with Zend Framework, you should know already, and that’s perhaps the first thing you’ve learned about Zend, that $_GET params can be accessed by calling the requrest’s getParam() method. But first of all the request uri will be different. The Zend’s convetion is to place after the domain name first the module name (which is omited when there’s only one module), than the controller’s name followed by the action and the key value pairs of all parameters. In that scheme the request uri above will look like that:

http://www.example.com/index/test

Here the keywords “controller” and “action” are omitted. This is cool – it’s more user friendly and it definitely helps the SEO.

Get the $_GET

Once the uri is setup like so – /index/test you can access it via the Zend way:

echo $this->getRequest()->getParam('controller'); // this will print "index"

The cool thing is that in the first case you don’t have any prevention of a missing value, while in the second case there is a second parameter or the getParam() method that does this job. What if the uri is www.example.com/index.php?controller=&action=test than by printing the $_GET[‘controller’] you’ll get nothing. In other hand even this:

echo $this->getRequest()->getParam('action'); 

won’t return “test” if the uri is http://www.example.com/index/

Note: actually here the default “index” action will be referenced!

That’s where the power of the framework comes. In the first case the solution is:

echo (empty($_GET['controller']) ? 'default': $_GET['controller']);

while in Zend there’s more elegant solution:

echo $this->getRequest()->getParam('action', 'test');

Thus when the action param is missing the “test” value is considered as default! Very useful!

Can anyone tell me how to manage this abstraction over the PHP upload process work?

This is a common task. You’d like to know whether the image on the remote server exists. Zend Framework gives the answer of this question and in particular this can be completed with Zend_Http_Client.

Content-Type and Content-Length

The little problem is that checking for content-type is not always correct, because it will return an image content type even when the image does not exists, so it’s better to check for content-length.

Code

The simple way to check this is like that:

$client = new Zend_Http_Client('http://remote-machine/image.jpg');
$response = $client->request('head');
if ( NULL == $response->getHeader('Content-Length') )
    // do whatever if the image does not exists.

In fact here, in this example I don’t check for GET request, because is way to slow than the HEAD method, but you should be aware of incorrect responses when using HEAD. In fact if you request the HEAD of a FLV video it will be returned text content-type, while using GET everything’s working fine but slow though.

The caching is not a process invented in the last year, it’s useless to describe why do you need it, but however my intention is to describe how to make it work with Zend Framework.

The docs page of Zend_Cache is pretty clear about everything and I’ll describe the most important part of the cache setup.

First setup the cache back and frontend options. You need to decide where to save the cache files, how to cache them, and what lifetime do they need.

The most used cache configuration is, as you may guess, this one described into the doc page. Setup the front and backend options is just as simple as:

$frontendOptions = array(
     'lifetime' => 7200, // cache lifetime of 2 hours
     'automatic_serialization' => true
);

$backendOptions = array(
   'cache_dir' => './tmp/'
   // Directory where to put the cache files
);

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core',
                             'File',
                              $frontendOptions,
                              $backendOptions);

Because all this is well described into the doc page, which you can found here I won’t talk about it. But I’ll talk only about one sole thing. How much the cache must live? What should be its lifetime.

The answer is simple. If you have some basic statistic of your site traffic and you don’t change much the data you can prefer longer cache period. But imagine the site’s making 1000 visits per minute! Than even if you cache every minute and the cache expires every minute will be a success and the user perception will be really great. From those 1000 visitors only few will wait until the cache’s built and the other hundreds will receive really fast response!

Be careful when you cache only because you can overflow the directory where you cache, which will be difficult though.

In other way many people are thinking about Zend Optimizer and its work with Zend_Cache. These are really different things. Zend Optimizer has nothing to do with your code it is a PHP caching tool. As you may know PHP interpreter mingles the code into “machine like” code, which in turn can be cached into the RAM with the help of Zend Optimizer. Checkout more here.