Since the PHP build version became so important with Zend Framework, I made a list of some (on the Belgian market) prominent hosting companies and the PHP version they offer on their shared hosting.

It does not pretend to be a complete list, but rather an alphabetical list of hosting providers I bump or bumped in to once in a while. The PHP version listed is mentioned on their site or, if not on their site, retrieved through their support.

(*) they offered to install any version required.

As you can see, Combell is worst for PHP developers. There currently is also no way to get any higher version with them. It is a sad thing.

Besides them, only Weble mentions (luckily a proper) full version number on their site. Although customers that tend to find the complete PHP version number important are probably a (growing) minority, it can make a sale.

Also, I’m surprised by the cheapest one, One. It’s the only “big” one that offers a recent version.

Please, don’t hesitate to add any others to the list.

I try to enforce Zend Framework for every new project started. If not in the requirements section of my quote, it is not that hard to convince a client of its advantages.

Tell a client how Zend Framework

• improves stability,
• lowers development time

and in particular

• makes them less dependent on you as other ZF developers can pick up projects you started a lot easier.

Now, please don’t start to think about job security. Just don’t.

But, Zend Framework has a fairly high PHP version requirement. Since version 1.7 Zend has quietly changed the requirements to PHP 5.2.4. In respect of a client’s (shared) hosting, this can be the most difficult part.
This was probably a logical thing to do since the requirements mentioned PHP 5.1.4 until ZF 1.6.2 and pre-5.2.4 versions miss some great features and contain nasty bugs (in reality some ZF components didn’t even run on PHP 5.1.4).

In Belgium however, it is difficult to find a hosting company that supports PHP 5.2.4.

The performance of frameworks has always been subject to discussion and Zend Framework is no exception.

But with the release of version 1.7 an appendix has been added to the manual with guidelines to improve performance.

Most notably:

• How to optimize your include path (even if it is in your vhost conf).
• Do not use XML translation formats if possible and certainly use caching for these framework parts.
• Different techniques to improve view rendering.

Read the complete appendix for a detailed explanation.

A bit late, but Paul M. Jones did a nice benchmark on PHP frameworks in September.

While Paul seems to have put quite some time in it, some people will probably argue about the results (like with all benchmarks). Anyway, I’m of course mostly interested in the PHP - Zend Framework comparison which shows that his Zend Framework script runs > 90%  slower than a plain PHP script. In return you get of course RAD: faster results and tighter development budgets. In my, again, humble opinion it’s more than worth it!

They have lost speed between 1.0 and 1.6 but of course so many features were added. Hopefully it can be improved a bit in future versions.

Until now I have not worked on a high traffic project in ZF so I hope my opinion won’t change then. I did hear the guys working on tv.be had some issues once traffic started coming in…

It’s a shame I missed Shahar Evron’s presentation about Scaling PHP Applications with Zend Platform on this subject. Hopefully he’ll give this talk in Europe some day.

Like recently proposed by Jason Eisenmenger, I’ve written a Zend_Pagination adapter for Propel.

It uses the DbFinder symfony plugin (formerly sfPropelFinder) which mimics Doctrine’s way of performing queries. The strictlyPHP_Propel_Finder used below is just a wrapper around that plugin.

Please note: it can certainly be improved (and I’m not sure the Zend Framework coding standards are met).

class strictlyPHP_Paginator_Adapter_Propel implements
Zend_Paginator_Adapter_Interface
{
    /**
     * @var strictlyPHP_Propel_Finder
     */
    protected $_finder;

    /**
     * @var Criteria
     */
    protected $_criteria;

    /**
     * @var int
     */
    protected $_count;

    /**
     * Constructor
     * @param strictlyPHP_Propel_Finder $finder
     */
    public function __construct($finder)
    {
        $this->_finder = $finder;
        $this->_criteria = $finder->getCriteria();
    }

    /**
     * Get count
     * @return int
     */
    public function count()
    {
         if ($this->_count === null) {
             $this->_finder->setCriteria($this->_criteria);
            $this->_count = $this->_finder->count();
         }

        return $this->_count;
    }

    /**
     * Get items
     * @param int $pageNumber
     * @param int $itemCountPerPage
     * @return array
     */
    public function getItems($pageNumber, $itemCountPerPage)
    {
        $criteria = clone $this->_criteria;
        $criteria->setOffset($pageNumber);
        $criteria->setLimit($itemCountPerPage);
        return $this->_finder->setCriteria($criteria)->find();
    }
}

Although Doctrine has its advantages, I still like Propel. It does its job and it does it fairly well.
If you integrate Propel with Zend Framework, you basically only need a Zend_Log wrapper that implements the BasicLogger interface Propel requires. This lets you use Zend_Log as the only log class in your application instead of creating one especially for Propel.

/**
 * Wrapper for Zend_Log for use as Propel log
 * @author Sam Hauglustaine
 */
class strictlyPHP_Propel_Log extends Zend_Log implements BasicLogger
{
    /**
     * Log
     * @var Zend_Log
     */
    private $_log;

    /**
     * Constructor
     * @param Zend_Log $log
     */
    public function __construct(Zend_Log $log) {
        $this->_log = $log;
    }

    /**
     * Log message of specified severity
     * @param string $message
     * @param int $severity
     */
    public function log($message, $severity = null) {
        $this->_log->log($message, $severity);
    }

    public function emergency($message) {
        $this->log($message, Zend_Log::EMERG);
    }
    public function alert($message) {
        $this->log($message, Zend_Log::ALERT);
    }
    public function crit($message) {
        $this->log($message, Zend_Log::CRIT);
    }
    public function err($message) {
        $this->log($message, Zend_Log::ERR);
    }
    public function warning($message) {
        $this->log($message, Zend_Log::WARN);
    }
    public function notice($message) {
        $this->log($message, Zend_Log::NOTICE);
    }
    public function info($message) {
        $this->log($message, Zend_Log::INFO);
    }
    public function debug($message) {
        $this->log($message, Zend_Log::DEBUG);
    }
}

(the Zend_Log priority constants nicely match their Propel equivalents.)
You then need to extend the main Propel class to do the wrapping:

/**
 * Wrapper for Propel
 * @author Sam Hauglustaine
 */
class strictlyPHP_Propel extends Propel
{
    /**
     * Set Propel log (required)
     * @param mixed $log
     * @return void
     */
    public static function setLog($log)
    {
        if($log instanceof Zend_Log)
            $log = new strictlyPHP_Propel_Log($log);

        parent::setLogger($log);
    }
}

That’s all. You can then call your Propel wrapper’s static methods in your bootstrap or a front controller plugin (I implemented that last option for a brand new project, a directory for stallion owners):

strictlyPHP_Propel::setLog($myLog);
strictlyPHP_Propel::init($myConfig);

Of course the bigger part is using the Propel class generator itself but that’s something for another post.

Last month I developed an online bikini store for a design company based on Zend Framework and some jQuery widgets. It wasn’t only a fun subject - the site also performs very well. Both on organic search and on conversions.

One thing that I found to be a life saver: use caching for Zend_Currency.

$cache = Zend_Cache::factory('Output',
                             'File',
                             $configFrontend,
                             $configBackend);
Zend_Currency::setCache($cache);

Or another caching mechanism of course - this will visibly speed up page loading.
Edit: also do this for Zend_Translate but you could have thought of that yourself.

Besides that the finishing touch is a local touch: Clickini loves your country (if they are shipping to you that is). Thanks to my flexible hosting company (who installed Maxminds PHP GeoIP extension) & the world’s favorite icons, that was easy to accomplish.

Let’s dive right into it:

About a week ago I put on the JavaScript text-typing mode and developed a CMS with ExtJs and Zend Framework. Thanks to FireBug life is great. At least, until that last final test in that other browser. Ouch.

One thing that solves almost all issues: watch your JavaScript object notation (JSON) values separator. FireFox doesn’t complain about that last comma before the closing } or ] but Internet Explorer isn’t so keen on that.
Well… maybe that is a good thing.

Perhaps an easy way out is validating the stuff you type.