T3N Magazine #11 - Cover Photo

Published in T3N Magazin #11 by Carsten Lucke

Zend describes themselves as “The PHP company”. For a while now, they offer the Zend Framework – a PHP application framework – and call it “the leading open-source PHP framework”. The hype around this framework has increased significantly since it was published for the first time. This article gives an introduction to the framework and its basic principles.

Description. I wrote an introductory article on the Zend Framework for the german t3n-Magazin. It is published in issue #11 and covers all the stuff you should know, to get started with the Zend Framework:

• Basic knowledge about the request processing lifecycle
• Basic knowledge about the Controller/Action pattern applied in the Zend Framework
• Introduction the the MVC-Conponents
• Introduction to renderers, helpers, etc.

Language. German

Characters. 21500

Links:

• T3N Magazin website
• Zend Framework website
• Online version of the article

Google didn’t help much or at least I didn’t find anything useful. After some trial-and-error research with the configuration switches I found out that the ‘-s’ switch was responsible for the problems. Here’s what the documentation says about it:

‘-s’: The “waReZ protection”. Don’t allow anonymous users to download files owned by “ftp” (generally, files uploaded by other anonymous users) . So that uploads have to be validated by a system administrator (chown to another user) before being available for download.

Obviously the server was looking for a system-account (ftp) that didn’t exist, which is hardly suprising as I use other accounts for ftp-ing. I didn’t find any hints on configuring the account-id Pure-FTPd expects. This anti-warez thingy being just a switch, there seems to be no solution apart from creating the ‘ftp’ account. Thus I finally disabled the anti-warez feature. Maybe someone has the same problem and finds this post useful.

Approx. one year ago I tried to get a remote-debugging environment using PHPEclipse together with DBG. That was a PITA to set up and once it worked it was just awfully unstable. I figured out that the PHPEclipse people were developing a plugin to use XDebug but there didn’t seem to be much progress. So I stopped my efforts on free remote-debugging. Some weeks ago XDebug2 was released and I decided to give the remote-debugging thing one more shot. I tried PDT + XDebug2 and guess what – it worked out fine!

First of all you need a PHP installation with XDebug2. If you don’t have it installed yet (shame on you ), you can find instructions here. Your next step should be getting PDT. I tried the latest integration build. Additionally you need some plugins for XDebug-support that are only available from the PDT bugzilla:

• Prebuilt Binary of XDebug Support for V0.2.3 for PDT 1.0 I20070712
• Example Mapper V0.0.2 for XDebug 0.2.3

Once you have all that installed you can create a PHP-project in your PDT-eclipse and configure the environment (XDebug2 and PDT) for debugging. Daniel Holmström published a really good guide on how to install and set up everything in detail. If you follow his instructions you should have everything up and running within half an hour. After that you will be able to enjoy local- and remote-debugging of your PHP-scripts.

The new release contains a bugfix for bug #10220. The Date_Holidays::factory method called the setlocale() function in a way that very possibly may have broken the localization of applications using the package.

Additionally there were three new drivers/filters added for calculation of holidays for:

• Austria (driver provided by Klemens Ullmann <klemens -at- ull -dot- at>),
• England/Wales (driver provided by Tim Dodge <timmy -at- invisibles -dot- org>) and
• Ireland (driver and filter for calculation of official holidays provided by Ken Guest <ken -at- linux -dot- ie>).

Thanks to all contributors and bug reporters! If you experience any problems with this release do not hesitate to contact me or to submit a bug-report.

In the quickstart-section the ZF manual suggests the following configuration for Apache’smod_rewrite.

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

This rewrite-rule is pretty simple. You forward every non-resource request (everything but scripts, stylesheets, etc.) to the ZF front-controller. If you wanted to prevent requests to for instance PDF files from being routed to the front-controller script you could add the “pdf” extension to the list. The more exceptions from the rule the more tedious this is. Therefore I suggested another configuration for the rewrite-rules in my talk (see the image):

Zend Framework directory layout

The configuration shown in the image activates the rewrite-engine for the root-directory of the project and forwards every request to the front-controller (index.php). Directories containing libraries or application sources are defined to be inaccessible by the browser (deny from all). Only for the public-directory that contains resources (images, stylesheets, etc.) the rewrite-engine is disabled to allow access by the browser.

Both recommendations have one major drawback: All requests are routed to the front-controller script. It is not easily possible to put a directory (containing php-files or whatever) into the root-directory and allow access from the browser. You would always have to disable the rewrite-engine first. One attendee of my Zend Framework talk gave me a hint that mod_rewrite allows to test whether a file or directory exists. Thus it would be possible to route only requests for non-existent files/directories to the front-controller. A possible rewrite-configuration could look like this:

RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.*)$ index.php

A little too late I noticed that the ZF manual even describes that kind of configuration in the RewriteRouter section. IMHO they hid that one really good. I think it would have been more helpful if they had already mentioned it in the quickstart section. I suggest you use the preceding configuration for the root-directory of your ZF project and deny access for all other directories no web-browser must see (application source-files, libraries, etc.). You won’t need .htaccess files for public directories as they aren’t affected by the rewrite-rule for the front-controller any longer.