Why would I run everything locally ?

Over the last years, a lot of the development agencies in the PHP world, has found out the joys of having local, individual environments for all developers, and managing larger projects through version control like SVN, CVS or, my new favourite, Git. Most people don’t have the luxury of having their own dedicated testserver for development, but you really don’t need one either. If you just have a Mac with OS X, you’ll have everything you need.

The reasons for having a local environment are quite massive: You’re able to have a complete replica of a running website, you’ll be able to develop new features without risking the stability of your public site. You’ll have full control of every setting in Apache, MySQL and PHP, meaning you’ll have the opportunity of testing optimizations and database structures properly, without the risk of destroying everything in a production environment.

Prerequirements

To complete the setup of Apache & friends, you’ll need the assistance of Terminal. If you are not comfortable with Terminal, just feel free to copy’n'paste every command here. Of course, as time passes, and you’re using your new environment, you’ll probably notice the advantages of Terminal anyway.

Setting up Apache

As Apache 2 is bundled with Leopard, this is very easy. Apache is controlled by enabling Web sharing in System Preferences.

Setting up webroots

As you have full control of Apache’s setup, you could actually put your websites whereever you’d like. However, as you already have the Sites folder available in your home directory, I’ll just make use of that. This also ensures, that Time Machine for instance is able to create backups of your sites.

So go ahead and create a directory within Sites for your new site, and try to give it a memorable name (In this example I’ll use jesperrasmussen.com from now on) .

[shell]sudo mkdir -p ~/Sites/jesperrasmussen.com/htdocs[/shell]

While you’re at it, add a general directory for Apache’s logs within Sites, to gather all sites logs within one place, making debugging and log-analyzing a bit easier.

[shell]sudo mkdir ~/Sites/logs[/shell]

Now that that’s done, you should have a couple of nice directories for the virtualhost and its logfiles, so let’s move on.

Setting up a VirtualHost

In the default setting, Apache will see your Sites folder as one site, as it’s setup to allow one personal site per user. To make Apache recognize the new virtual hosts, you need to edit the file /private/etc/apache2/users/.conf in your favourite editor (I recommend emacs or nano for Terminal editing).

The file will look somewhat like this when you open it:

[shell]<Directory "/Users/jesper/Sites/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>[/shell]

Now, what we’ll do, is that we’ll add the lines for a new virtualhost in the configuration. Furthermore, in my example, there’s an added .dev alias to the domain, allowing me to access the local development version of the site by accessing jesperrasmussen.dev, and access the public version (On another server) by accessing jesperrasmussen.com. Anyway, add the following lines, replacing jesperrasmussen.com with whatever your virtual host is called, and save the file.

[shell]NameVirtualHost *:80
DocumentRoot /Users/jesper/Sites/jesperrasmussen.com/htdocs
ServerName jesperrasmussen.com
ServerAlias jesperrasmussen.dev
ErrorLog /Users/jesper/Sites/logs/jesperrasmussen.com-error_log
CustomLog /Users/jesper/Sites/logs/jesperrasmussen.com-access_log common[/shell]

Restarting Apache

Inorder to test the new site, we need to reload Apache’s configuration files. This is done by testing the new config files first.

[shell]sudo apachectl -t[/shell]

If this says “Syntax OK”, we should gracefully load the changes into Apache. *)

[shell]sudo apachectl graceful[/shell]

Accessing your newly created site

Now, you may think you should be able to access your new site at the domain you’ve entered. But no, you still need one more thing, changing your hosts-file into handling your domain locally (Or at least, the development version). This is done by editing /etc/hosts (Again, using emacs or nano), like so:

[shell]sudo nano /etc/hosts[/shell]

This should load your hosts-file **), which should look like this:

[shell]127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost[/shell]

Now, in the bottom of the file, insert a couple of blank lines to seperate your changes from the default parts, and insert this line:

[shell]127.0.0.1 jesperrasmussen.dev www.jesperrasmussen.dev[/shell]

This will force your machine into believing that your domain is located at localhost, thus making the request at your local Apache.

Now, everything should work, try putting a dummy index.html file in your new htdocs directory, and try loading the site in your browser. Next time I’ll have a look at enabling PHP and MySQL support on your standard machine.

Further reading

It’s come to my attention that Patrick Gibson has a fine shellscript for handling the VirtualHost part, making this a lot easier.
You might want to check that out

* Gracefully restarting Apache lets Apache apply the configuration more smoothly, by allowing it’s child processes to keep running with the old configuration, but loading the new configuration for all new processes. This is usually done in production environments, to avoid hard restarting servers, thereby avoiding possible downtime.

** The hosts-file is OS X’s way of overriding DNS locally. It allows you to force a domain to a specific IP-address rather than the one specified in the domains DNS. This is especially useful for testing a development or staging environment with the correct domainname.

I usually spend 20-30% of my day in Terminal, doing administrative tasks, ssh’ing to the servers I use for development and for my work, watching logs, debugging etc. This might not be typical behaviour for an OS X user (Which is good, as I think Terminal should be an addition for those who wants the power of it, and not a necessity for “regular” users) , but I find working directly with Terminal to improve my workflow when it comes to the previously mentioned tasks.

As some Mac-users will know, OS X currently comes with bash as the standard shell. Even though bash is often perceived as one of the best shells available in the Unix-community, quite a lot of other shells exist, all with different features, and approaches to shell-work. A couple of years ago I decided to try out Z Shell, also known as zsh, and I’ve never regretted this.

Why run zsh ?

To begin with, it’s not even a big deal switching or trying zsh out. If you are currently using bash, you’ll feel right at home. Zsh uses a lot of the same shortcuts, has support for most of the features bash uses, and this means the only thing you’ll actually notice, is how the extra features just make things easier. Some of the key features for zsh are:

• Nice autocompletion for commands, aliases etc. Zsh allows you to tab through completions if there are multiple possibilities, showing possible completions in a nice grid, browsable even by arrow keys, to make it simple and fast to find exactly the completion you want.
• Autocompletion for remote files. If you are using scp to transfer a file to a remote server, zsh will figure out what you are doing, so if you try to autocomplete while typing the remote part, it will try to connect via ssh and actually perform autocompletion on the remote side.
• Functions in addition to aliases. It’s possible to create entire routines as zsh functions with arguments, allowing for complex functionality for running multiple commands in succession easily.
• Share history across sessions. When running multiple instances of zsh at the same time, the instances are able to share a common history, rather than being limited to only each its own. One of the most frustrating things to a bash user is typing in a long command, then searching for it again the next day via Ctrl+r, only to find it nowhere in the history.

Ok, so how do I change my shell to zsh ?

Enabling zsh in OS X Leopard is really easy. Previously, you had to install zsh from MacPorts, but in Leopard it’s part of the base install, and as such is easily accessed. try writing “zsh” in your bash, and bang! You’re running zsh! To set zsh as your default shell in OS X, and make it run every time you start Terminal, load up Terminal’s settings, and set your default theme to run the command “zsh” on startup.

To change it in older OS X versions, you should be able to use the chsh command. But there are other suggestions as well.

But, but, it’s not working like you promised ?

You’ll need a .zshrc file to take full advantage of zsh. The .zshrc is zsh’s configuration file, and will setup most of the features I’ve mentioned earlier. There’s a couple of ways of getting hold of a .zshrc. You could google for it, and you’ll find a bunch of examples. Another way is to take a look at my sample file . This is not an exact copy of my running .zshrc, but it has a bunch of the most common setups.

To make it work, you have to save the file as .zshrc in your home directory.

Be aware that zsh holds a bunch of more features than I’ve talked about here, and there’s much to explore. Feel free to use my sample file as a starting point, and do change it anyway you’d like. If you find any other useful features in zsh, please let me know, and I’ll make some notes about it here.

Further reading

If you want to know more about the glorious world of zsh, try checking out the official zsh website, containing documentation, the manual as well as some pointers to getting started with scripting in zsh.

Zsh homepage

My sample .zshrc

Zsh Wiki