Enabling memcache under MAMP

I know the tech is a bit old, but sometimes you need to make do with the tools you’ve been given. Here’s how I enabled memcache under MAMP.

First, grab the precompiled binary file (memcache.so) from here. There were no problems using this on Snow Leopard (for me, at least).

Second, copy the file to your MAMP extensions directory. You should be able to find it here: /Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-[date].

Next, you’ll need to enable the extension in MAMP. Switch it off, then open up php5.ini by going to File > Edit Template > PHP5 php.ini

Find the extensions section (about line 540 or so) and add this line to the list of extensions:

Once that’s done, save php.ini and reboot MAMP. You should be able to see an entry for memcache when opening your phpinfo page.

Watching your Language

Inspired somewhat by Dave Ray’s post “Say Something Nice About Every Language You’ve Used“, I’ve decided to do the same.

Fairly easy to learn, and with an improving OO model, Web development will only get better. Syntax is pretty straight forward and it’s easy to get something working relatively quickly.

Visual Basic
Very simple syntax, and a good introductory language for learning Windows programming.

I like C (and C++) because you can do with it what you will. There’s a lot of flexibility and room to move for whatever problem you have.

It has a similar syntax to C, but automatic garbage collection makes me weep tears of joy.

One of my favourite aspects of web development is putting on my Javascript hat and adding very slick functionality to my site. Simple syntax and a lot of power for overriding default objects.

Very quick to learn the basic syntax, and it forces a separation of code into conceptual pieces that I agree with.

That exercise is actually enlightening. I think focussing on the strengths of a particular language allows you to leverage it for maximum effectiveness. I’m fairly sure I’ve picked up more languages than this in the past, but not with enough experience for any sort of nice opinion. Perhaps next time I’ll just bitch and moan about all the languages I’ve used.

Return JSON data with Zend Framework

Getting Zend to return JSON data can be tricky at times. The JSON helper likes to send the ‘official’ JSON header (application/json), and most browsers are treating that as a download link, resulting in no data to the client and an unfortunate download box.

To bypass this default behaviour, you’ll need to tell the controller how to serve your JSON data:

The key part of this stub is the exit; line. It prevents the view renderer from sending anything, keeping your JSON data intact. Note: json_encode and json_decode only works from PHP version 5.2.1

To output all of your view’s variables in this way, replace $some_var; with:

Hopefully this saved someone a headache or two when dealing with Zend’s puzzling JSON implementation.

Quick Zend Cache Setup

Here’s a quick solution to get a cache running on your Zend Framework install. It’s very simple and should provide a good solution for most small-scale sites.

You can put this code inside of your bootstrap file. I like to use the method style for invoking the bootstrapper.

What this snippet does is initialise two related caches – a core cache, and a page cache. The core cache (in this instance) is attached to our database table abstract class, which allows results to be stored as serialized strings. The page cache is invoked whenever template output is due to occur, and saves pre-rendered HTML for immediate output.

You can find all the documentation for tweaking your cache settings in the Zend_Cache documention.

Zend, SSL, and mod_rewrite

I had a Zend project in which we had to use the Apache module mod_rewrite to “toggle” our secure connection depending on what pages the user landed on. The requirements were something like:

  • User visits any administration or account pages, and SSL is off, switch it on
  • User visits a page that is not an administration or account page, and SSL is on switch it off

As it was a Zend MVC project, we also had a rewrite rule that routed everything to /index.php in the document root.

This is Zend’s recommended .htaccess rule for routing:

For the uninitiated, the block says: If the request is a valid file that exists, or it is a directory, don’t rewrite the URL, otherwise, rewrite the whole string to read “index.php.” The framework will generally just read the query string server variable and go from there.

So on to my additions for toggling SSL.

The above code checks the secure protocol, and then checks the requested path (in this case, /admin or /account). In finding that, it toggles the SSL accordingly.

Here’s the problem: because the two toggling rules only work if triggered as a redirect, the server’s request URL is rewritten twice, meaning that any “toggling” will result in a flat redirect to /index.php, breaking the application.

After hours of testing, rewriting, and Google-fu, I came up with this fix:


This means that the request is reattached to the end of the query all the time. This is hidden from the user (i.e. no ugly index.php/admin/login/ or what-have-you), and is successfully passed onto Zend to trigger the appropriate dispatcher. This works for any number of redirects.

Hope this saves someone else hours of trial-and-error.