h1. Zend Framework: "Location, Location Location!"
__Some best practices on where you should be putting the Zend Framework Source Code.__
I was having a conversation with a client recently on the topic of best practices. He asked me:
bq. Where should I put the Zend Framework source code?
This is an excellent question that can not only be applied to Zend Framework, but to similar frameworks also. The question has in fact two answers in my opinion, which answer is right for you depends on how you answer this question.
h2. Is Zend Framework part of your application or part of your PHP environment?
If your application or organization matches any of the following:
* You have no control over the PHP environment your application will be installed into. For example you intend to distribute your application (e.g. Magento, phpMyAdmin).
* Your development team has low communication with your IT department.
* Once you’ve deployed your application you’re not going to touch it for long periods of time (common for consulting companies).
In these situations Zend Framework should be considered as a part of your application.
If you’re working on an application and organization where:
* You do have control over the environment.
* You are actively working on the application.
* The IT department and the development team are in good sync.
You will want to make Zend Framework a part of your PHP environment.
h2. Zend Framework is part of my application.
In this case the best practice has been clearly laid out by the Zend Framework team. In a “document by Wil Sinclair”:http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Default+Project+Structure+-+Wil+Sinclair, it states:
bq. library/ – This directory houses the library/Zend/* folder which contains Zend Framework.
The advantage of this approach is that developers will have full control over which version of Zend Framework is used in the application.
There are a few disadvantages to this approach. First, the developers are now the ones responsible for keeping the Zend Framework installation up to date. Let’s not forget that the Zend Framework team likes to get a “mini release out bi-weekly”:http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conventions .
Depending on your Software Development Life Cycle, updating the version of the framework in “production” will most likely require you to go thought a release cycle.
Another issue to consider is the bringing of the Zend Framework code into your source control system. If you’re lucky you will just be able to do something simple like set an SVN external property. If you’re not, then you will have to import every file into your source control system. With either approach when people check out the project the will be checking out the complete framework along with it. A real drag if you don’t have the speediest of development environments.
h2. Zend Framework is part of my PHP environment.
In this situation successful and effective communication between your development team and your IT department will go a long way. A way to help you visualize this approach is this is how PEAR is setup in most environments.
Now the responsibility of keeping Zend Framework up to date is the IT departments. This may be a lot easier that you thought as Zend Framework can be found as a package in Linux application repositories. So keeping your Zend Framework up to date will be akin to keeping your Apache install up to date. Something the system administrator will already have a process in place for.
There is a way to make it even easier; you could use Zend Server or Zend Server CE. If you want it to Zend Server will not only install and setup Zend Framework as part of the environment, it will also help keep Zend Framework up to date. Zend Server is available in RPM and DEB from application repositories and as a native installer (MSI) on Windows.
If you are going to do the work yourself the Zend Framework source code should be placed in a folder our site of the web root. The path to this folder should then be added to the “php.ini” file.
The drawback to this approach is that it does represent a bit of a moving target to the application. This will only really be a problem if you have applications that frequently get ignored for long periods of time. In this situation having automated tests and the use of a continuous integration system like phpUnderControl will help you identify possible problems early and before they get to production.
So you have Zend Framework setup as part of the PHP environment. Now you have a situation where you want to deploy an application and just forget about it. In this situation having Zend Framework as part of the application and overriding the include path can make sense.
h2. Working With "include_path"
h3. What’s it for?
Knowing what the include_path setting is and how to change it is an important aspect of understanding how Zend Framework loads its own files.
Believe it or not there is a huge difference between:
This is the difference between a relative and an absolute path. The first example is an absolute path and will always load the file using the root of the file system as its base directory. The second is a relative path, it will loop over every entry in include_path until it finds a match or runs out of paths. It will use the paths as the base directory when looking for your requested file.
Zend Framework loads it files using relative paths. So if you don’t have an entry in your include_path with the location of Zend Framework you will have problems.
h3. What’s it look like?
A typical value of Linux include_path setting looks like:
It breaks down into two parts, the path and the path separator.
The path separator is “:” on UNIX style systems and “;” on Windows and acts as a delimiter between multiple paths. You can also simple use the PHP constant PATH_SEPARATOR from within your PHP scripts.
You paths should be absolute and you should be careful not to add a trailing slash to the end. In the context of an include_path, a path of “.” is considered the current directory.
h3. How do I change it?
The three common ways to add a new path to your include_path are, changing the php.ini, adding a value in an .htaccess file or from within a PHP script.
Open your php.ini in a text editor and find “include_path” then add your Zend Framework path.
In an .htaccess file, add:
@php_value include_path “.:/usr/share/php:/usr/share/pear:/path/to/zf”@
h4. In a PHP File
Before you include any Zend Framework code add the following to your PHP code:
@$path = ‘/path/to/zf';
set_include_path(get_include_path() .PATH_SEPARATOR. $path);@
The earlier on in the include_path a path
you are intending to use occurs, the faster the lookup will be. So for performance reasons you should put the paths most used by your application at the beginning of the include_path
Let’s say Zend Framework is your applications most commonly used external library. We should then change our above example for php.ini file, from:
include_path=".:/usr/share/php:/usr/share/pear style="background: lime none repeat scroll 0%;">:/path/to/zf"
include_path=". style="background: lime none repeat scroll 0%;">:/path/to/zf:/usr/share/php:/usr/share/pear"
This will reduce number of folders PHP has to check, and thus file system calls, by half.
I was under the impression that the performance gain from this optimization would only be minor if using an Op-code cache like APC or Zend Optimizer+. However Matthew O’Phinney informs me:
bq. In the profiling and benchmarking I’ve done, it still makes a difference, as the opcode cache will first hit the realpath cache, which is when the path lookup will usually occur; once it determines the path, it then checks to see if it has opcodes for that path, and then merrily goes on its way. The sooner it finds a match, the faster it can identify and use the opcodes. That said, the performance difference is minor — you only notice it when you have many class files on any given request, and if you’re under heavy load. (And those were the conditions I was profiling.)
Not regularly updating you Zend Framework when security patches are released is a serious security risk. You’ve been warned.
As with anything in IT these are not hard and fast rules. This article represents what the Zend Framework team has recommended and what is common practice out in the wild.