Hope some of you will find it useful.

The poll will probably get closed in few days so hurry.

Personally, I have voted for ZF classes to enforce MixedCasing. I find it much more readable than ACRONYMCasing. XmlHttpRequest is prettier and more readable than XMLHTTPRequest, don’t you think?

This plugin will serve HTML 4.01 Strict as text/html to IE and XHTML 1.0 Strict as application/xhtml+xml to other browsers.

The only thing you need to do is to register the plugin to the front controller during bootstrapping:

And it will take care of content negotiation. The plugin will also set a boolean view variable $view->xhtmlAllowed so you can use different markups in layouts and views if needed (<img> in HTML and <img /> in XHTML).

The sign up form should have at least these fields:

• email
• username
• password

There are few tiny things you will probably need to modify according to your application. I chose Slovak language (‘sk’) and GMT+1 time zone (’1.00′) which is a time for central Europe. I also used a controller action helper PhpbbHash above. The helper is here:

Few comments:

1. The above code is taken directly from the phpBB codebase, I only made a couple of necessary changes to make it work with Zend Framework.
2. For those of you asking why didn’t I just use phpBB API and call its native functions, there is a reason for it. The phpBB code is written to be available with PHP 4. Zend Framework requires at least PHP 5.2.4. There are lots of globals and other scary stuff in the phpBB codebase which makes it impossible for its functions to be called from ZF controllers.
3. If you think I should have done something differently or I completely forgot to do something, please let me know.

Which would produce this markup:

<!--[if IE 8]> <link href="/path/to/some/styles.css" media="screen" rel="stylesheet" type="text/css" /><![endif]-->

Adding a conditional JavaScript file is similar:

And that would produce markup like this:

<!--[if IE]> <script type="text/javascript" src="/path/to/some/script.js"></script><![endif]-->

It can pretty useful when you need to use IE conditional comments just for a single controller action. Otherwise, if it applies site-wide, it’s better to just put conditional stylesheets and/or scripts in a layout file.

1. Creating an index and updating it regularly.
2. Searching the index with a powerful query language.

First, let’s create a fresh search index. I know it’s already tiresome but I will use a simple blog application for my example implementation. To simplify it even further, it will only be possible to search blog posts. The posts schema looks like this:

CREATE TABLE posts (
id INT NOT NULL AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
body TEXT NOT NULL,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_id INT NOT NULL,
INDEX (created_at),
INDEX (user_id),
FOREIGN KEY (user_id)
REFERENCES users(id)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (id)
) ENGINE = INNODB;

Creating the search index is easy:

Pretty straightforward. You can see I have used three different static methods for adding fields to the document:

• UnIndexed: unindexed and unstored (therefor unsearchable) but they are returned with search results. Unindexed fields usually store primary keys, timestamps or file paths.
• Text: indexed, stored and tokenized. Text fields are searchable and are returned with search hits. Titles, first and last names, cities and states, post codes and street names are all good candidates for keyword fields.
• UnStored: indexed and unstored – ideal for large texts.

There are more types of fields you can use (keyword, binary) but you can read about them in the documentation.

Next thing you need to do is update the index every once in a while so the search hits return up-to-date information. There are two ways to get around this problem. The most obvious is to update the index every time a new post is published or an existing post is edited. Another approach would be to set up a cron job to run every now and then and rebuild the index. Which way you choose depends on many variables such as expected index size (a very large index can have few GBs in size).

Secondly, the index is already taken care of, so let’s search it:

That was possibly the simplest possible example of a Lucene search query. You can, however, create very complex queries with the powerful Lucene query language. You can either build queries manually in PHP or you can use Zend_Search_Lucene methods to build them. It’s so easy a baby could do it.

To search for posts with words ‘hello’ and ‘word’ in the contents field you would write this query:

hello

To search for a post that must contain ‘hello’ and may contain ‘world’:

+hello world

To search for a post that must contain ‘hello’ in the contents field and may contain ‘world’ in the title field:

+hello title:"world"

And those were just basics. You can use boolean operators, wildcards, ranges and even perform a fuzzy search.

The solution is to use partial view helper which allows you to put the repetitive XHTML into a single file. For example, this could be your partial:

And this is how you would include it in all views where the same piece of markup occurs:

It’s really easy and it saves a huge amount of time both to you and to a developer that might work on your application in the future so please, all of you Zend Framework developers, use partial helpers wherever there is a repetitive XHTML markup in your application.

1. Use different font (I have found that Arial is sometimes hard to read, a good replacement seems to be LBRITED.TTF).
2. Set lower dot and line noise level.

You can use “dotNoiseLevel” and “lineNoiseLevel” to tune down the captcha noise (and surpisingly this is not mentioned in the Zend Framework documentation):

Above I went over the top perhaps. Nevertheless, you must be able to find a compromise so that the users will be happy and the security side of your website won’t suffer too much.

The frontend and the backend adapters can take much more arguments, read the documentation to learn all possible options. I initialized the Zend_Cache object with the factory method. First argument means that we want to use the Zend_Cache_Core frontend which is the core of the Zend_Cache module. The second argument is the backend we want to use the Zend_Cache_Backend_File backend or that we want to store cached data as files in a specific directory. The other two parameters are frontend and backend options.

Now we can easily access the cache object in controllers or models:

That was easy, wasn’t it?

Cleaning the cache

You will surely also want to remove cached files at some point in your application:

That’s it for today and, by the way, Merry Christmas