Setting Up PHP (The Right Way*) on OS X

* By “The Right Way”, I mean following the guidance and practices at the PHP: the Right Way website. I make no claims this is the “best” way 🙂

Works n my machine badgeMac OS X is a pretty good web developer OS. It comes as standard with PHP, Ruby and Apache all out of the box, and the underlying UNIX system makes it easy to add in other languages and components to suit your needs. On top of that, some of my favourite development tools are on the Mac, so unless I’m writing .NET code, nearly all my development is on an (ageing) Mac Mini.

Now, while all that stuff comes as standard on OS X, lately it seems Apple has made it harder to get to. The versions shipped with OS X also tend to be a little behind the latest releases. As a result, most Devs I know use something like MAMP to make the server-side of their environment as easy as running an app. Personally, while I think MAMP works, and is a good time-saver (and I’ve been using it for the last year or so), but I like to get into the nitty-gritty of the system and get things running “native”. So last night I fired up the terminal and got PHP set up on my Mac with the latest version, and following the Right Way Guidelines. As a result I have PHP 5.4, Composer, the PHP Coding Standards Fixer, and MySQL all setup quite slickly (i.e. to my preferences).

The whole process was pretty easy, but does involve the command line. If this makes you uncomfortable, then it might be best to skip the rest of this post.

This all worked on my Mac, but I make no guarantees about it working on yours, and I’m not responsible if you break something.

If you find any glaring problems with this guide then leave a comment/get in touch, and I’ll make any required edits.

Step 1: Setup Your PATH

Edit the hidden .bash_profile file in your home directory. If you use Sublime Text 2 you can use the following command:

[sourcecode language=”bash”]
subl ~/.bash_profile
[/sourcecode]

TextMate has a similar mate command, or you can use vi(m)/nano/emacs/whatever.

It’s possible you already have a line defining your PATH variable. It’ll look something like export PATH=<something>. I’ve found it most useful to change the PATH so /usr/local/bin is at the start, making sure anything you install there is used over the system defaults in /bin. Add this as a line below your existing PATH definition (or just add it in, if you don’t have an existing line):

[sourcecode language=”bash”]
export PATH=/usr/local/bin:${PATH}
[/sourcecode]

Step 2: Install Brew

Strictly speaking, Brew (aka Homebrew) isn’t required, but I used it to install MySQL later, and it does make it stupid easy to install stuff into OS X. I think you should install it. The best instructions are found on the Homebrew home page, so go have a read there. There are a few pre-requisites, but nothing too difficult.

Step 3: Install PHP-OSX

Now we’re beginning to get somewhere! PHP-OSX is the latest versions of PHP compiled for OSX by Liip. Installation is a real doddle, from the command line:

[sourcecode language=”bash”]
curl -s http://php-osx.liip.ch/install.sh | bash -s 5.4
[/sourcecode]

Follow the prompts given, including entering your password. After a few moments everything will have installed. For convenience I created a symbolic link to the newly installed PHP binary in /usr/local/bin:

[sourcecode language=”bash”]
ln -s /usr/local/php5/bin/php /usr/local/bin/php
[/sourcecode]

Step 4: Install Composer

Now we have PHP installed, it’s time to look at the nice-to-haves, like a good package/dependency manager. Composer is relatively new on the block, and allows others to download your code and automatically grab any dependencies by running a simple command.

You can install Composer in your project, or you can install it globally. I prefer globally. As with PHP, installation is simple, from the command line:

[sourcecode language=”bash”]
curl -s http://getcomposer.org/composer.phar -o /usr/local/bin/composer
chmod +x /usr/local/bin/composer
[/sourcecode]

Step 5: Install PHP Coding Standards Fixer

Another nice-to-have, this little tool will try to find and fix parts of your code where it does not conform to one of the PHP Coding Style Guides. Installation is almost identical to Composer:

[sourcecode language=”bash”]
curl http://cs.sensiolabs.org/get/php-cs-fixer.phar -o /usr/local/bin/php-cs-fixer
chmod +x /usr/local/bin/php-cs-fixer
[/sourcecode]

Step 6: Install MySQL

If you installed Brew in step 2, then you’re good to go with this little command:

[sourcecode language=”bash”]
brew install mysql
[/sourcecode]

It’ll take a few minutes, but you shouldn’t need to intervene at all. Once done you will need to run two more command to setup the MySQL tables:

[sourcecode language=”bash”]
unset TMPDIR
mysql_install_db –verbose –user=`whoami` –basedir="$(brew –prefix mysql)" –datadir=/usr/local/var/mysql –tmpdir=/tmp
[/sourcecode]

If you didn’t install Brew, then you will need to install MySQL through some other means, such as packages on the MySQL website. I can’t help you with that, I’m afraid.

For managing MySQL, I use the excellent Sequel Pro, which is a successor to the venerable CocoaSQL.

As a next step you should look into changing the root password of your MySQL setup. This is a local dev environment, and likely only used locally by yourself, but it’s the proper thing to do.

Bonus Step 7: A Script for Launching MySQL and the PHP Dev Server

To make things a one command startup I wrote myself a little bash script. Now, I am under no illusions this is improvable; it’s my very first bash script (ever), so probably not the “right” way to do this. It’s in a public repo, as well as the public Gist below, so if you want to improve it, feel free! Anyway, it’s functional for now and will start the PHP development server on the port you specify, and set to the (optional) directory, otherwise it will use your current working directory.

To install, run these commands:

[sourcecode language=”bash”]
curl https://raw.github.com/chrismcabz/phpsrv/master/phpsrv.sh -o /usr/local/bin/phpsrv
chmod +x /usr/local/bin/phpsrv
[/sourcecode]

Usage is straightforward:

[sourcecode language=”bash”]
phpsrv 8000 #start on http://localhost:8000 in the current dir
phpsrv 8000 ~/projects/mysite/ #start on http://localhost:8000 in ~/projects/mysite/
[/sourcecode]

Errata

  • Pear doesn’t seem to work, which is slightly annoying, but (to me) no real biggie. I didn’t test this with the built-in version of PHP, so I don’t know whether it worked beforehand. I’ll post an update once I figure it out.
  • I’d like to make bash script smart enough to stop MySQL when the PHP web server stops, but my early attempts haven’t managed to get this working (most likely due to the Ctrl-C used to stop the web server also stopping the script).
  • Throughout this process we’re running scripts directly from the web. This is pretty risky behaviour, especially with unknown/untrusted sources. You should always take a look at the raw script before running it, so you don’t get hit by something malicious.

Does Anyone Write Pseudo-Code Any More?

Back in the mists of time, when I was in University 1, one of the very first principles we were taught was writing pseudo-code.

For those of you unfamiliar with the term, pseudo-code is the practice of writing simple, “half code” down, (usually) on paper as a guide to help you work through a problem before even touching an IDE. The goal is to be as high-level as possible, and mostly language independent. It was a combination of plain english and the most basic of code – mostly simple conditionals, loops, etc. Occasionally you would write a function reference if you absolutely needed to. Something below is similar to how I remember being taught pseudo-code, but other examples can be found on the relevant Wikipedia page

I remember pseudo-code being incredibly useful at the time; problems became much simpler to think through, even as a complete novice programmer 2. I wrote pseudo-code for every new problem I had to code a solution to. Somewhere along the line though, I fell out of the habit. I would start in the IDE with a vague idea, then proceed to hack and refine (refactor) as I went along. Chipping away at a problem seems to give a greater sense of forward-momentum, so maybe that is why?

Occasionally I will still bust out the pencil and paper if I am really stuck, or thinking about the problem away from the computer, but these times are rare nowadays. It got me thinking that I don’t recall seeing anyone write pseudo-code in my entire professional career. Is it something we just learn at university and do not carry on into “the real world” as we become more experienced? Is it even taught any more?

Do you still write pseudo-code? Did you ever?

  1. Back when Turbo Pascal was being taught, and Java was yet to enter the curriculum. ↵
  2. I started my degree in computing with no prior academic experience with computers.  The little “programming” skills I had were writing simple “GOTO” loops on my Commodore 64, many years prior. ↵

Only Use RGBA If You Need To

A small anecdote on some CSS usage which tripped me up a few days ago; it’s easy to get carried away and set all your color/background-color properties using the fancy-pants new RGBA. But only do so if you really need to specify the opacity value.

i.e. if you’re setting something like this: color: rgba(213, 265,17, 1);, set it as plain old RGB: color: rgb(213, 265,17);. The latter will render fine in IE, as far back as I was able to test (IE 7, I think), whereas the former only works in newer browsers (IE9+, Firefox, Webkit, Opera).

The “doh!” moment for me came when testing a stylesheet a few days ago. The layout worked fine, but for a moment I couldn’t think why none of the colours were displaying in IE8, until then I remembered I was using RGBA for everything. So off I went to create override classes for IE8, using Modernizr‘s .oldies class. I was about 3/4’s the way through the stylesheet when I realised 99% of the colours I was overriding had no opacity set (i.e. opacity value of 1), and so I could just specify them as RGB. Cue much slapping of the forehead! Lesson learned, and needless bytes saved.

Use Custom PHP Extensions on Heroku

Image representing Heroku as depicted in Crunc...

Did you know you can use custom PHP extensions on Heroku? Neither did I, cos I can’t find it in the documentation. But you can:

https://gist.github.com/1288447

I came across this while searching for a way or workaround to use the MongoDB PECL extension on Heroku (don’t get me started on that…).

If you can’t be bothered checking the link, the summary is this:

  1. Create a folder in your app called ‘ext’ or similar.
  2. Copy your extension into this folder.
  3. Create a php.ini file with the following contents:
    [sourcecode language=”text”]
    extension_dir = "/app/www/ext/"
    extension=mongo.so
    [/sourcecode]
  4. Deploy

Using the Facebook PHP SDK with CodeIgniter

the CodeIgniter logo

the CodeIgniter logoMost of my small personal projects tend to get built with CodeIgniter (CI), which is a simple to use, fast, lightweight PHP5 MVC framework.

the Facebook logoFor a while now I’ve had an itch to build something fun against the Facebook API so I can start learning how Open Graph works, and as a primer to building a “proper” Facebook integrated application. I also realised I hadn’t actually tried using CodeIgniter 2.x since it was released (quite some time ago). With an abundance of free time this weekend it seemed like the perfect time to get hacking!

Before I could build anything I would need to know one thing: just how do you connect a CodeIgniter app to Facebook?

Continue with reading

Creating a Stacked Paper Effect in CSS3

screenshot showing the paper-stack effect applied to a content block

Replicating a stack of paper is a common design found on the web; it’s an easy way to make a design a little less harsh and digital by giving it an “analog” look. For a quick example, take a look at the “Chapters” WooThemes WordPress theme.

screenshot of the chapters theme, showing the stack of paper effect done using images

In the past I would have used a couple of wrapper divs in HTML, and some background-image CSS to get a vertically expandable (but probably fixed-width without a lot more work) content box. However, with the improvements in CSS3, along with rapidly improving browser support, I wondered if it would be possible to make a similar – and more flexible – effect without images. Continue with reading

"IIS Express Website Here" Shell Extension

One of the cool things released earlier today by Microsoft was IIS Express – A lightweight but fully-featured and self-contained version of IIS 7.5. It runs on Windows XP and above, even if you already have IIS or another web server installed.

What’s really cool (I think) is it can be run a) from the command line, and b) from any directory. This makes it incredibly flexible. That said, I don’t want to have to fire up a command prompt every time I want to start a server instance in a particular directory… Wouldn’t it be much easier to have a right-click “IIS Express Website Here” context menu option in Windows Explorer? Of course it would 🙂

I’ve thrown together a shell extension using some registry edits, adapted from original work here and here, so all due credit to Phil Haack and Tuna Toksoz. What it does is add an option to your Windows Explorer context menu to start IIS Express in the selected directory, using a random port number. You can then use the handy System Tray icon to launch the site in your favourite web browser.

There are two versions of the .reg file in the Zip file – one for 64bit Windows, and one for 32bit. Only the 64bit version has been tested (certified working on my machine), using a standard WPI installation of IIS Express. Only run the .reg file suitable for your platform. Use at your own risk – I am not responsible for anything which breaks!

Download IISExpressHere.zip

UPDATE 18-Nov-2012: I’ve made a copy of the source over at GitHub, for those of you who can’t access the Dropbox link, or want to fork the code for Windows 8, etc. You can access the repository here: IIS Express Here on GitHub

Accessible, Unobtrusive New Windows with jQuery

I loves me some jQuery – without it I probably wouldn’t write any JavaScript at all (seriously, I hate the stuff). Anyway, today I needed to add some “open in new window” links to an internal application using jQuery. Being the Standardista I am, I wanted to make it a)Accessible, and b) Unobtrusive . If the user has JavaScript disabled (it happens, even on “controlled”, intranet environments), the link should just go to the new page anyway — new window be damned.

My first attempt (below) didn’t work as expected. The following code takes all <a> tags with a class of “newwindow” and applies an onclick event to open a new window.

[sourcecode language=”javascript”]
$(function(){
$(‘a.newwindow’).click(function(){
var w = window.open($(this).href(), ‘newWindow’, ”);
return false;
});
});
[/sourcecode]

Nothing would happen with the above, because of the return false;. Removing return false; would open a new window, but also send the opening window to the new page. In the end, the following worked the way I wanted:

[sourcecode language=”javascript”]
$(function(){
$(‘a.newwindow’).click(function(){
var w = newWindow($(this).href(), ‘newWindow’, ”);
return false;
});
});
function newWindow(url, wName, opts){
w = window.open(url, wName, opts);
return true;
}
[/sourcecode]

Basically the “heavy lifting” was moved to a seperate function. It’s slightly longer to type, but not exactly finger-breaking stuff. No doubt some bright-spark could tell me an even betterway (feel free!), but this’ll do for now.

About Elastic Layouts

Elastic layouts have been getting a bit of talk over the last few months. John, Roger and Patrick have all talked about them. I use an elastic layout in the new design.

What is an Elastic Layout?

Traditionally, web designers talk about either “fluid” or “fixed” layouts. Fluid layouts change width with the size of the browser window, while fixed layouts are set to a specific width. There are arguments for and against each type. Where elastic layouts fit in, is to try and combine the best of both worlds.

The Theory.

Text sized in em units is scalable in browsers (theoretically). So what if we were to specify the widths of our page elements in ems? Our page elements should scale inline with the size of our text.

The Reality.

Using em units to size page elements does work pretty much as expected. However, there are a few things we need to do to avoid some problems.

Global Reset for Less Hair-Pulling

If you let the browser apply its default font-size, margin, padding and line-height, you’ll be in for a very rough ride. Make things easy – apply the global reset:

*{ font-size: 100%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

This resizes the text on everything to 100% of the default size (16px by default), sets the height of a line to the size of the text, and removes any default margins or padding. By doing this, we remove a lot of the guess work. I use a percentage value because I’ve found that this makes scaling text a little less error prone in browsers. 1em is now equal to 100% or 16px.

Browsers are Crap at Maths.

All the major browsers suffer from rounding errors to some degree. I must admit that it’s been a while since I checked on this, but both Opera and Safari used to render text sized in ems and percentages wrong – 10px would render as 9px, for example. To get around this, the fix was to size text slightly larger than 100% on the top level element. 100.01% was found to be the magic number. So our global reset becomes:

*{ font-size: 100.01%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

Make the Maths Easier.

I was never very good at maths (much like the browsers), so working things out in multiples/fractions of 16px wasn’t appealing. It’s also harder to visualise how big 16px is, compared to, say, 10px. So to make things easier to work out and visualise, we reduce our base font size down to 10px (using percentages, this is 62.5%). We can apply this to the html element and it will inherit down the line:

html{ font-size: 62.5%; } /*Resize text to 10px */

1em is now equal to 10px. Much better!

Make Everything an EM.

Well, almost. I’ve found that some browsers (the Gecko ones, mostly), will not render a 0.1em thick border, when 1em = 10px. Any border you want to be equivalent to 1px by default, just make it 1px – it might not scale but it will render. Other than this small caveat, the rest should be sized in em units: margins, paddings, widths, font-sizes… Doing so will make everything proportional to the text size, stopping things looking crowded at larger sizes.

Remember – EM Sizes Compound!

By that, I mean that if you apply a font size of 1.2em to the body tag in our example, then for all elements contained in the body, 1em now equals 12px. So a 3em h1 would be 36px high, not 30px like you might have expected. It’s something you need to be on the lookout for.

A Note About Background Images

Elastic design is geared towards using repeating background images. Unless it’s something like the “Latest Little Thing” icon on the homepage, using non-repeating images will land you with holes in your design where the container is wider than the image. A great example of using repeating background images in elastic layouts is the Elastic Lawn CSS Zen Garden entry.

Give it a Try

With all this talk about maths, compounds, et al, I’ve probably put you off elastic layouts. Don’t be afraid to try them. Once you get in the swing of things, it soon becomes second nature. Practice does make perfect, so all I can say is have a go!