MirthLab

I often use the Zend Framework from within my Symfony applications and until recently, I’ve been using the sfZendPlugin to import and autoload the library. You’ll notice that this plugin has recently been axed leaving some people confused as to how to use the library in their projects.

Adding the Library

First, you’ll need to add the Zend Framework library. Since I like to link libraries via subversion, I’ll link the Zend Framework to my project’s lib/vendor directory. Open up a terminal to your symfony project’s root directory and type this:

 svn propedit svn:externals lib/vendor/

Note: You may have to create the vendor directory (and use svn add to add it to your repository) if you don’t already have it.

This will bring up a text editor where you can add a link to an external library via subversion. Type this in:

Zend http://framework.zend.com/svn/framework/tag/release-1.5.0PR/library/Zend

… and save and close the file. This will link lib/vendor/Zend to the 1.5.0 PR release of the Zend Framework. You can, of course, use another version if you prefer. Of course, you don’t have to link this via subversion. You can simply download and copy the Zend Framework into this folder for the same effect, but using subversion is my preferred method.

Linking the Library to Symfony

All you need to do now is activate symfony’s autoloading of the library files. Open up your application’s setting.yml file (mine is at apps/frontend/config/settings.yml) and add the appropriate settings. It should look something like this:

all:
  .settings:
    zend_lib_dir: %SF_ROOT_DIR%/lib/vendor
    autoloading_functions:
     - [sfZendFrameworkBridge, autoload]

Make sure to clear your symfony cache by using:

./symfony cc

That’s it! You should be able to use any of the Zend Framework classes from within symfony without using a require statement.

Edit: As per Gerald’s comment below, the zend_lib_dir path was listed as “zend_lib_dir: %SF_ROOT_DIR%/lib/vendor/Zend” but should not included the “Zend” folder name at the end as sfZendFrameworkBridge.class.php actually adds this automatically.

In part one of this series, we looked at setting up a basic Subversion repository to house our new Symfony project on Media Temple’s Grid-Service. This article will take that a step further by explaining how to set up your OS X box for local development using said repository. Although this article will start from where we left off last time, there’s really nothing specific to Media Temple about these steps and these same basic principles can be used with any other host.

I think a lot of people don’t really understand the benefits of local development. For those who are unfamiliar, “local development” means simply that your machine acts as both client and server. This means that instead of, say downloading a file from your server, editing it, and uploading it to see changes, you simply edit and save the file right on your machine and see changes reflected instantly. There’s really no magic here, it’s just that we do the hard work up-front to have an apache server running on our local machine so that simply saving a file is saving to the server.

Requirements

Installing and configuring Apache, MySQL and PHP5 are out of the scope of this article, but we’ll be working on the assumption that these are all installed and working. Mac OS X has long shipped with an Apache server built-in, and version 10.5, Leopard, ships with Apache2 and PHP5 pre-installed. The shipping version of those two packages may be all you need, but I’ve been using Marc Liyanage’s PHP5 package with a custom Apache2 install for various reasons (namely, Apple’s PHP5 version is missing some critical libraries like mcrypt and GD). At the time of this writing there is currently no supported version of his PHP package for use with Leopard, but there are various threads on his forum about getting it working. You can also use something like MAMP (along with these setup instructions for Leopard).

Setting Up the Development Environment

We left off on the previous article with a working copy checked out of our Subversion repository into the ~/Sites/ folder. All we need to do now is map the web directory in our Symfony project to an Apache Virtual host so we can serve it up locally.

Find your apache config file and edit it appropriately. I like to have separate config files for each site that I’m working on, so I’ve edited my main config file located at /usr/local/apache2/conf/httpd.conf and added the following line at the end of that file:

# Include custom configurations for symfony
Include conf/sites/*

This basically tells the Apache server to look in conf/sites/ for any extra configuration files and load them as well. I’ve then added a config file for each site that I’m working on. For example, in conf/sites/project1.conf we’ll add this:

<VirtualHost project1.dev:80> 
    ServerName project1.dev
    <Directory />
        AllowOverride All
        Allow from All
    </Directory>

    DocumentRoot /Users/mark/Sites/project1/web

    ErrorLog logs/project1.dev-error_log
</VirtualHost>

… which will allow us to access our symfony project. Be sure to substitute your own username in the DocumentRoot directive and restart the apache server so that the changes take effect.

We’ll also have to edit our hosts file so that “project1.dev” is considered a valid hostname for our machine. In /etc/hosts/ add this line:

127.0.0.1 project1.dev

It should be noted that I like to use the “.dev” domain for my dev environment, but this is simply my own convention. I’ve heard of other symfony users using something like “.sf” instead which would work just as well.

You should now be able to pull up http://project1.dev/ from a browser and see the default symfony project page.

Some Added Sugar

At this point we pretty much have a working local copy of our symfony project. It’s running as a subversion working copy which allows us to track and check-in changes, which is great. We are also able to test our site using any browser on our machine be it Safari, Firefox, Camino or anything else that’s native to Mac OS X. The one thing we can’t do is test our site locally using a PC version of Internet Explorer, which still accounts for about 75% of browsers.

One great thing about Apple’s recent switch to Intel processors is the ability to run Windows through virtualization right from within OS X. If you’ve got VMware’s Fusion installed, we can update our setup a bit so that we can check our site from Windows, without needing another physical box.

First, boot up your Windows XP virtual machine and open a command prompt by choosing “Run…” from the Start Menu and typing in “cmd”:

Once you’ve got the prompt, type:

ipconfig /all

This will list all of your network adapters. What we’re looking for is the “Default Gateway” entry under the Ethernet adapter heading.

Copy down that IP address. Now, open your hosts file which is probably located at C:/WINDOWS/system32/drivers/etc/hosts in your favorite editor (notepad works fine).

This is essentially the same file we just edited on OS X, but there will be one major difference. We’re going to put the IP of our host machine as the mapping IP for our development domain like so:

192.168.171.2   project1.dev

Now, you should be able to open a browser on your Windows Virtual Machine and see the same symfony project that we just set up on OS X. The only downside I’ve seen with this is if your Gateway IP changes on the Windows box. You’ll have to update the Windows hosts file to reflect the new IP. I’m sure there’s probably an automated way to do that, but my IP seems to be pretty consistent unless I actually shut-down the Virtual Machine instead of just suspending it.

Next Steps

At this point you can also install and configure your database software. MySQL makes it easy with their OS X installer which even comes with a startup script. As of this writing, there is still no Leopard specific version, but there are instructions elsewhere on loading MySQL or migrating from Tiger.

Once it’s installed, you can add a database that will be for local development and then update your symfony config/databases.yml file with the information:

dev:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://user:pass@localhost/project1_db

prod:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://user:pass@internal-db.sXXXXX.gridserver.com/project1_db

…where sXXXXX is substituted with your Grid Server account number. You’ll notice that we’ve set up our dev and prod environments to use different databases. The dev environment uses the DSN for the local database you just installed while the prod environment uses a Media Temple specific DSN. This means that when developing locally, we’ll always be calling the dev environment from our browser so that we’re loading the correct database:

http://project1.dev/frontend_dev.php

Conclusion

I hope this provides some insight as to why local web development on an OS X box works so well. You get to edit and save files without the delay of saving to a server and you get to have an all-in-one testing machine that you can use to test sites in different browsers and on different platforms.