Zend_Http_Client and Garbled Response Body

May 28th, 2009

Using Zend_Http_Client to make a simple REST GET request to a web service and the body of the response I got back was completely mangled – i.e. the characters were not even remotely readable. That’s strange I thought, and pasted the url in my browser and it came back fine. Looking at the response headers, I saw the content encoding was gzip ([Content-encoding] => gzip), which made sense as my browser would uncompress the response, while PHP would not automatically do that.

Rather than trying to uncompress the response, I modified the request header to not accept gzip and it came back un-encoded and ready to use in PHP:


<?php
$client 
= new Zend_Http_Client($url);
$client->setHeaders(array(‘Accept-encoding’ => ‘’));
$response $client->request();
print_r($response);

?>


Zend_Service_Technorati, Exceptions and partialLoop

May 22nd, 2009

I am utilizing Zend_Service_Technorati to tag search and when I return the results and loop through it via a partialLoop, an exception is thrown occasionally. One of the results does not have a valid uri and Zend_Uri_Http is throwing the exception based on the path (not sure whether Tehnorati is returning a invalid url or Zend_Uri_Http is declaring a valid url invalid). The problem is I am using partialLoop to dynamically loop through result sets other than Technorati, such as Youtube and Flickr, and it is nice just to call the appropriate partial based on the result set object.

However, there is no easy way to catch the Exception. If I wrap the entire partial loop in a try/catch, then it doesn’t display any results when there is an exception, even though there is only one offending result:


<?php
     
try {
        echo 
$this->partialLoop(‘adminexternalmedia/_result’ $this->collection->type ‘.phtml’,$this->resultSet);
    } catch(
Exception $e) {
        echo 
‘problem’;
    }

?>


I can’t catch the exception in the partial that handles the display, because the exception is created once the individual result is grabbed from the set and before the partial is “rendered” - i.e. triggered in the foreach call. Since the result sets implement SeekableIterator, I can use a while loop and call partial, instead of relying on the partialLoop, and handle my exception as I deem fit:


<?php
    $this
->partial()->setObjectKey(‘model’);
     while(
$this->resultSet->valid()) {
         try {
             
$result $this->resultSet->current();
             echo 
$this->partial(‘adminexternalmedia/_result’ $this->collection->type ‘.phtml’,$result);
         } catch (
Exception $e) {
             echo 
‘problem<br /><br />’;
         }
         
$this->resultSet->next();
     }

?>


Zend_Gdata and Fatal error: Allowed memory size

May 2nd, 2009

Querying Youtube for videos via Zend_Gdata and ran into memory issues when searching for up to 20 videos. It was a simple fix, just had to up my memory_limit in php.ini. It was at 8M and I set it to 12M and am not running into any more issues. If you are on a shared hosting environment, you can use init_set within the page:


<?php
ini_set
(“memory_limit”,“12M”);

?>


Just be careful what you set it to, as too high a limit could cause problems.If you have a page that consumes a lot of memory and you set it high, say 50M, and along comes something that requests the page a lot, maybe a search spider gone bad or malicious user, you could run out of memory on your server…

PHP 5.1.4 and Apache Problems

April 30th, 2009

I know, I am behind the times. PHP 5.3 is almost ready for prime time, but I was still using PHP 5.1.4 I was having some major issues with Apache recently, although I don’t think it was Apache that was the problem. I wasn’t able to diagnose the problem, but I believe connections to MySQL were hanging and causing Apache to choke. It was very sporadic, but as I rolled out a couple sites that made heavy use of MySQL (and not enough use of caching), the problems became more frequent. My server was detecting too high a load on Apache and restarting it a couple of times a day, and every month of so, MySQL would completely choke and require a killall and restart.

My sites get such low traffic amounts, it wasn’t like the server was getting crushed under the load. I upgraded to PHP 5.2.6 and MySQL 5.0.67, and no problems since the upgrade (its only been 48 hours). I have a feeling it was PHP, but don’t know for sure. So if you have PHP 5.1.4 and are running into Apache choking, try upgrading to the latest PHP stable and see if that cures the problem.

Zend_Paginator and Zend_Paginator_Adapter_Null

April 19th, 2009

I have been playing around with Zend_Paginator a little more, and came across a use case where I didn’t want the Paginator to manage the data, i.e. I was feeling lazy and didn’t feel like writing a custom adapter. You can use Zend_Paginator_Adapter_Null to manage the pagination controls and simply pass in the total number of results into the constructor. I.e


<?php
$paginator 
= new Zend_Paginator(new Zend_Paginator_Adapter_Null(‘43′));
$paginator->setCurrentPageNumber(‘1′);
$paginator->setItemCountPerPage(‘20′);
$this->view->paginator $paginator;

?>


The 43 I am passing into the constructor is the total number of results, and would likelu not be a static number, but coming from some other data source. For example, if you were using Zend_Service Flickr, it would look like this, assuming the variable $flickr has already been set up:


<?php
$paginator 
= new Zend_Paginator(new Zend_Paginator_Adapter_Null($flickr->totalResultsAvailable));
$paginator->setCurrentPageNumber(‘1′);
$paginator->setItemCountPerPage(‘20′);
$this->view->paginator $paginator;

?>


Follow the manual on setting up the actual display of the pagination. Now I need to get some more spare time and write a custom adapter for flickr and other Zend Services and also familiarize myself with caching of the paginator.