Now that the Zend Framework ships with a command line tool, it’s even easier to get started using the Zend Framework. In this tutorial, I will show you how to set up the command line tool for use on Mac OS X.

First, download the newest version of the Zend Framework. Both the full and minimal versions come with the Command Line tool. For this tutorial, I will be using version 1.9.3.

Once the folder has downloaded, it will need to be extracted and moved somewhere you can find it. I will be moving this folder to the top level “/Library/” directory so it will be easy to type. Within the ZendFramework directory, there is a directory called bin. Within this directory is a file called zf.sh. This is the command line tool. So if you want to use the tool, open the Terminal application and navigate to the directory that you want your project created.

cd Sites

Then, type:

/Library/ZendFramework/bin/zf.sh create project InsertProjectNameHere

A new Zend Framework project will be created in the Sites directory with the name of InsertProjectNameHere. But this is more than I’d rather type on a regular basis, so we should create an alias. To create an alias, type the following:

alias zf=/Library/ZendFramework/bin/zf.sh

Now all we have to type is:

zf create project MyApp

That’s it! By running this command in the command line, we have just created a new Zend Framework project in the current directory.

In my search for the best PHP mailing list software, I’ve come across some pretty bad ones, and some pretty good ones.

My criteria for a “good PHP mailing list” is the following:
-easy install
-easy integration
-double opt-in subscription
-sends mail even after browser window has closed (imagine waiting for your PHP script to finish sending an email to thousands of subscribers, one at a time).
-customizable admin interface
-open source (and free!)
-not a hosted solution

That may be a dream, but I just found a new PHP mailing list that may meet the criteria. phplist.com may just do the trick. I will try it out and let you know what I think.

Finally! We can start testing our Controllers! I will assume that your application has the same directory structure as the Zend Framework Quick Start tutorial. Here’s an overview of what our directory structure will look like:

/myApp/application/controllers
/myApp/tests/application/controllers

Our tests directory will mirror our application. We might also include a ‘library’ directory in the tests directory so we can test our custom library components. For now, we’ll just keep it simple and test our controllers.

Now, we’ll create a file that will take care of auto loading. Create a new file called ‘loader.php’ in you tests directory. All of our tests will require this file.

1
2
3
4
5
6
7
8
9
10
11

<?php
 
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application/'));
 
set_include_path( APPLICATION_PATH . '/../library' . PATH_SEPARATOR .
APPLICATION_PATH . '/models' . PATH_SEPARATOR .
APPLICATION_PATH . '/forms' . PATH_SEPARATOR .
get_include_path() );
 
require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();

Now let’s create a simple controller test. We’ll call this ‘IndexControllerTest.php’ and put it in our tests/application/controllers directory. We just need to set the location of our bootstrap file. When Zend_Test_PHPUnit_ControllerTestCase constructs, it will look for the bootstrap file that we set here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
 
require_once '../loader.php';
 
class IndexControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '../../application/bootstrap.php';
 
    public function testIndexAction()
    {
    $this->dispatch('/index');
    $this->assertController('index');
    $this->assertAction('index');
    $this->assertResponseCode(200);
    }
 
}

That’s it! All we have to do is run this file with our PHPUnit command line interface (that we used in the last tutorial).

Now that we’ve installed PEAR and PHPUnit, we can verify that PHPUnit is working correctly by writing our first test.

Since we installed PHPUnit through PEAR, and we have properly configured our include_path variable in our php.ini file, we can create our test files anywhere and PHP will know where to look to find PHPUnit. So I will create a new file in my /Users/andrew/Sites directory and call it FoobarTest.php with the following contents:

<?php

class FoobarTest extends PHPUnit_Framework_TestCase {

public function testFoobar() {
$this->fail();
}

}

By writing our function name to start with “test”, PHPUnit will know to run this function as a test. Typically you will want to name your test functions with names similar to the functions that you are testing, preceded by “test”.

Now let’s run our test!

cd /Users/andrew/Sites
phpunit FoobarTest.php

You should see something like the following:

PHPUnit 3.3.15 by Sebastian Bergmann.

F

Time: 0 seconds

There was 1 failure:

1) testFoobar(FoobarTest)
/Users/andrew/Sites/FoobarTest.php:6

FAILURES!
Tests: 1, Assertions: 0, Failures: 1.

Yay! It works! “But wait,” you say, “it says failures. Why is this a good thing?” Test-driven development is all about writing tests first. Remember this saying: Red, Green, Refactor. Start by writing the test, which will fail, of course, because you haven’t written any code yet! Then write the code until your test passes. Then STOP. There’s no need to keep writing. The code is finished. You know it works because you have the test to prove it. Tests are written to fail. Code is written to fix the tests.

However, this is a poor example of a test, so let’s write a real one.

Let’s start by thinking about what we want to build. How about we build a class called Foobar (to make things easy since we already have a FoobarTest) that has a function called getMessage(). However, getMessage() doesn’t return a string like we might expect, it returns an array. A test for that might look like the following. Also note that our function name is a little more verbose. Tests can serve as a sort of documentation. Think of underscores as commas and name your functions to explain what happens in the test.

<?php

class FoobarTest extends PHPUnit_Framework_TestCase {

public function testGetMessage_ReturnsAnArray() {
$foobar = new Foobar();
$message = $foobar->getMessage();
$this->assertTrue(is_array($message));
}

}

Now if we run our test again, we should see the following:

PHPUnit 3.3.15 by Sebastian Bergmann.

PHP Fatal error:  Class 'Foobar' not found in /Users/andrew/Sites/FoobarTest.php on line 6

Fatal error: Class 'Foobar' not found in /Users/andrew/Sites/FoobarTest.php on line 6

Now we have an error that says PHPUnit can’t find our Foobar class. Well that’s because we haven’t created it yet! So create a new file in the same directory as our test, name it Foobar.php, and give it the following contents:

<?php

class Foobar {

}

Next, let’s update our test so it knows where to find our new class:

<?php

require_once('Foobar.php');

class FoobarTest extends PHPUnit_Framework_TestCase {

//...

That’s all we need to do. Remember, all we are trying to do is get the test to pass. Right now the test tells us that we need to create a Foobar class so that’s what we’ve done. Let’s run our test again and see what it says.

HPUnit 3.3.15 by Sebastian Bergmann.

PHP Fatal error:  Call to undefined method Foobar::getMessage() in /Users/andrew/Sites/FoobarTest.php on line 9

Fatal error: Call to undefined method Foobar::getMessage() in /Users/andrew/Sites/FoobarTest.php on line 9

Hooray! We no longer have the same message as before. Now we need to create our getMessage() function in our Foobar class.

<?php

class Foobar {

public function getMessage() {

}

}

Run our test again and we should see another change:

PHPUnit 3.3.15 by Sebastian Bergmann.

F

Time: 0 seconds

There was 1 failure:

1) testGetMessage_ReturnsAnArray(FoobarTest)
Failed asserting that <boolean:false> is true.
/Users/andrew/Sites/FoobarTest.php:10

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

getMessage() doesn’t return anything, so let’s change that:

<?php

class Foobar {

public function getMessage() {
return array();
}

}

That should be enough for us to get our test to pass. Let’s see if it works.

PHPUnit 3.3.15 by Sebastian Bergmann.

.

Time: 0 seconds

OK (1 test, 1 assertion)

It works! We’re done. I think you get the picture. Let’s move on to some actual controller tests.

Question: How do I get started using Zend_Test? What is the process necessary to start using Zend_Test for testing my Zend Framework application?

Answer: Zend_Test extends PHPUnit. Therefore, we need to start by installing PHPUnit. The easiest way to install PHPUnit is by installing PEAR. Therefore…you get the idea. We need PEAR. I’ll walk you through the process I took to install PEAR on Mac OS X 10.5 (Leopard).

Open up your trusty Terminal application by going to /Applications/Utilities.

First, we’ll switch over to a user that has enough permission to do anything, our super user:

sudo su -

Next, we’ll change directories to /usr/local by typing:

cd /usr/local

Then, we’ll download and run the pear installer:

curl http://pear.php.net/go-pear | php

Press enter to begin the installation process. Press enter again to use no HTTP proxy. You should then see a screen with seven installation locations. The first one should say /usr/local. If this is not the case, press 1 and enter. Type /usr/local and press enter again. Now we should all be on the same page.

Press enter to continue with the installation. When asked, you can accept the additional PEAR packages by typing Y and pressing enter.

The installer will run through the installation, downloading and installing the necessary packages. Eventually the installation will finish. You may receive a warning that your php.ini file does not contain the PEAR PHP directory we specified (/usr/local/PEAR). This is okay. We will be editing this file in the next step. So simply type n and press enter. Press enter againto finish the installation. PEAR should now be installed and ready to use. Let’s see if it works by typing:

pear version

We should see a few lines including the version of PEAR we just installed, PHP version, etc. But wait, we’re not done yet! We still need to edit our php.ini file. If you don’t have a php.ini, you’ll need to create one by copying the php.ini.default:

cp /etc/php.ini.default /etc/php.ini

Now were ready to edit our php.ini file. Open the file with Pico (or any other text editor):

pico /etc/php.ini

Scroll down about 1/3 and find the line that says:

;include_path = “.:/php/includes”

The semicolon at the beginning of the line means it’s commented out. Replace this line with the following:

include_path = “.:/usr/local/PEAR”

Press Control + O, then enter, to save your changes. Then, Control + X to exit Pico. Restart your Apache server and you should be good to go!

apachectl restart

Question: I have a website that I don’t want accessible to the general public. What is the best, most reliable and secure way to add password protection to my website (or section of my website) to make it secure?

Answer: there are a few different ways to add password protection to sites and pages: PHP, JavaScript, and htaccess. Depending on what you are trying to do with determine which method will be best for your application.

If I had a section of my website that was for members only (who I would like to sign up on my site), I would use PHP to manage the accounts created by the users, and logging users into the “members only” section of my website.

However, let’s look at a different case. Let’s say I’ve been developing a website for a client, locally, on my machine. Now I’m ready to show the client, but I don’t want the rest of the world to be able to see my “work in progress.” This is an example where htaccess would be best.

With htaccess, you will create a file on your server, telling your server to restrict access to only those people who provide the correct login credentials. Htaccess is EASY to set up and is among the most secure options available.

For a tutorial on how to set up htaccess, I found this tutorial to be quite helpful: Comprehensive Guide to .htaccess

Now that I’m getting into Object Oriented PHP programming, and the Zend Framework, I need an editor that can keep up with the complexity of my projects. Integrated Development Environments can make developing websites go so much faster and more smoothly. I’ve been using Aptana for all of my PHP projects, but it just feels bloated at times. Sometimes I just want a simple text editor and some FTP software. I decided to try TextMate, the glorified Mac OS X text editor, and was relatively impressed but really wished there was some sort of integrated FTP functionality. At work, I’ve been using Subversion to keep files in sync with my co-workers. I really like the “synchronize” feature of using Subversion, and really wish I could have some feature like that with FTP.

Well I recently came across an application called Espresso. It’s in public beta right now, but so far, I am very impressed. The software is so simple and intuitive. I don’t know if you could technically call it an IDE, but it sure covers most of the features I use most of the time. It feels like TextMate, only simpler, with a bunch of integrated features like FTP, code completion, syntax highlighting, outline view, file search, live preview…the list goes on. My personal favorite is the “Publish” feature. This is like a mix of FTP and Subversion, making it possible to “synchronize” your local changes with the current state of your remote files. Again, this feature is so intuitive. It made it really easy to see which files I had changed, and allows me upload all my changes in a single click.

Another cool feature, is the ability to add extensions. These extensions are called Sugars (which you add to your Espresso. Clever, eh?). I can’t wait to see what sorts of Sugars are in the works!

I would definitely recommend checking out Espresso. Especially if you’re getting started with PHP programming, or want to get better at building websites. This may become a valuable tool that will help you learn faster and get things done easier.

Update: Espresso 1.0 has just been released!

Q: How do I set up PHP, Apache, MySQL, and Virtual Hosts on my Mac OS X 10.5?

A: That’s a good question! I’ve installed Apache, PHP, PEAR, Virtual Hosts, but haven’t had any luck with getting MySQL up and running. If you figure it out…please let me know!! Right now I’m using MAMP. Not the ideal working environment, but it’s getting the job done for now.

This tutorial may be helpful in your journey of how to install MySQL on a Mac.

Question: How do I write a function to compare the differences between two arrays?

Consider the following scenarios:

$alreadyInTheDatabase = array('name' => 'Joe', 'address' => '123 Fake St');
$newFormValuesArray = array('name' => 'Joe', 'address' => 'My address has changed');

$alreadyInTheDatabase = array('name' => 'Joe', 'address' => '123 Fake St');
$newFormValuesArray = array('name' => 'Joe'); //a bad form has address missing from the array

$alreadyInTheDatabase = array('name' => 'Joe'); //address was never in the database to begin with
$newFormValuesArray = array('name' => 'Joe', 'address' => '123 Fake St');

I’m writing a function to check whether or not I need to update a field in a database, so my function will tell me what the differences are between what’s already in the database, and what form fields have changed. If the field is the same as the one that’s in the database, I won’t need to update it. If the values are different, I’ll update. If the form has a field that doesn’t even exist yet in the database (because it hasn’t been created yet), I’ll need to know that too. So I’ll just return an array of the keys that differ.

There are a lot of PHP functions that exist to solve all sorts of scenarios where you would want to compare arrays, but none of them return an array of the differences between both arrays.

array_diff — Computes the difference of arrays
array_udiff — Computes the difference of arrays by using a callback function for data comparison
array_diff_key — Computes the difference of arrays using keys for comparison
array_diff_uassoc — Computes the difference of arrays with additional index check which is performed by a user supplied callback function
array_diff_ukey — Computes the difference of arrays using a callback function on the keys for comparison
array_intersect — Computes the intersection of arrays
array_uintersect — Computes the intersection of arrays, compares data by a callback function
array_intersect_assoc — Computes the intersection of arrays with additional index check
array_intersect_key — Computes the intersection of arrays using keys for comparison
array_intersect_uassoc — Computes the intersection of arrays with additional index check, compares indexes by a callback function
array_intersect_ukey — Computes the intersection of arrays using a callback function on the keys for comparison
array_udiff_assoc — Computes the difference of arrays with additional index check, compares data by a callback function
array_udiff_uassoc — Computes the difference of arrays with additional index check, compares data and indexes by a callback function
array_uintersect_assoc — Computes the intersection of arrays with additional index check, compares data by a callback function
array_uintersect_uassoc — Computes the intersection of arrays with additional index check, compares data and indexes by a callback functions

Quite a lengthy list, isn’t it?? Now you can sense my confusion and frustration. We want to check the values, but return the key of the value that is different. We’ll also check the keys to see if we need to create a field that doesn’t already exist in the database.

Answer: We’ll use array_diff_assoc() to return an associative array of the keys and values that differ in the first array. Then we’ll swap the arrays to check the second array against the first. We’ll merge the two arrays of differences using array_merge() and return just the keys by using array_keys().

function getDifferences($alreadyInTheDatabase, $newFormValuesArray) {

$diff1 = array_diff_assoc($alreadyInTheDatabase, $newFormValuesArray);
$diff2 = array_diff_assoc($newFormValuesArray, $alreadyInTheDatabase);

$merged = array_merge($diff1, $diff2);

$justTheKeys = array_keys($merged);

return $justTheKeys;

}

Update: I just found out about some great software that makes setting up virtual hosts with MAMP a breeze. You’d better check out this tutorial before reading mine, then go download VirtualHostX for only $9 dollars.

Or, if you want to do it for free, read on…

The super-easy, “How to set up name-based virtual hosts on a Mac, running MAMP”, Tutorial

When I’m developing a new website for a client, I like being able to open my browser and test out the site I’m working on. So lately I’ve been uploading my “work in progress” to a new sub-domain that only I know, such as http://stage.myClient.com or http://alpha.myClient.com. The problem with this approach is that even though I’m the only one who “knows” what the address is, people can still find, and view my unfinished business since it’s publically accessable. What I really want to do is test my site, in my browser, just as if it was on the web, without anyone being able to see it, but me.

There’s a really easy way to do this. It’s called Virtual Hosting. Name-based virtual hosting will allow us to associate http://stage.myClient.com with a directory on our computer, rather than going out to the internet. The great thing about this is that we can name our virtual host whatever we want. We could call it http://stage.myClient.com or http://local.myClients.clientOne. We could even name it http://foobar if we felt so inclined. http://localhost is an example of a virtual host. Go ahead and type that into your address bar. I’m not sure what you’ll get back, but it’s probably already set up and redirecting to a folder on your computer somewhere.

If you’ve already downloaded and installed MAMP, good for you! If you haven’t, you really should. If you’re developing websites in PHP, and you want to test your site without having to upload it to your server, you need to install PHP on your computer. The same goes with using a database. Setting these up individually can be a pain! MAMP is nice because it installs everything you need, you can turn it on and off, and it makes it really easy to start developing websites locally without having to set anything up. This tutorial is about setting up a virtual host, on a Mac, running MAMP, so I’m going to assume you’ve already got MAMP set up.

So one of the things you might have noticed about MAMP is that it sets its “localhost” directory to /Applications/MAMP/htdocs…which is fine, except I like to keep my sites in my /Users/andrew/Sites directory. I mean…that’s what it’s there for.

So if you want to set yours up that way…

1. Start MAMP.
2. Click “Preferences…”
3. Click the “Apache” tab
4. Browse to the directory of your choice

Now going to http://localhost should resolve to the directory that you chose. Now, let’s set up our very own virtual host!

1. Open Terminal by going to /Applications/Utilities/Terminal
2. Type: sudo pico /etc/hosts
3. Type your Administrator password
4. Edit your hosts file to look like mine, with exception to your chosen virtual host name. I’ve named my virtual host stage.myClient.com
5. Press Control+O, then Return to save the changes
6. Press Control+X to exit Pico

One last step:

1. Open /Applications/MAMP/conf/apache/httpd.conf (TextEdit is fine)
2. Scroll to the very bottom, this is where we declare our virtual host.
3. Edit your httpd.conf file to look like mine. The server name should be the name of your virtual host that you declared in the previous file, and your document root should be the directory you want your virtual host to pointing to.

We’re done! Make sure you have MAMP running when you try it out for yourself.

If you found this tutorial helpful, or if you want to tell me how much it sucks to make it even better, please leave a comment!

Thanks, for reading!

–Andrew