Nginx is quickly becoming a popular, low resource alternative to Apache for many websites. This doesn't come without challenges, such as using PHP as CGI due to not having mod_php available. Nginx also does not use any Apache configuration rules, nor does it use .htaccess or anything like it, so it requires additional configuration regardless of the web application being deployed. A big help in getting Nginx started with Drupal is António P. P. Almeida's drupal-with-nginx configuration, which makes it fairly simple to deploy in Linux. But what about local development on OS X? Read on to learn get all of the required components set up for your system, as well as the modifications necessary to get drupal-with-nginx set up on OS X.

I am tremendously, overwhelmingly, and kind of absurdly excited to announce the alpha release of the new Backbone module for Drupal. Why? Because the oddball combination of new-kid-on-the-block Backbone with venerable-ol'-stallwart CMS Drupal is actually a suprisingly well matched and powerful one.

With Backbone.js, Drupal is no longer a drag when making dynamic, JS-based functionality...in fact, it's kind of awesome. Backbone works by creating lightweight model objects in the browser that are then easily bound to the vast array of interaction events and views using a flexible client-side templating system. Drupal is a great tool for producing the sort of structured JSON data that Backbone consumes: we get the full power of Drupal's Field API and content administration tools on the server side, but don't have to deal (much) with Drupal's theme layer and rendering stack, getting Backbone's lightweight awesomeness in our UI code. It's kind of a marriage made in web development heaven.

The Backbone module for Drupal provides a foundation for building Backbone apps within Drupal sites. Following the Backbone philosophy, it extends Backbone's Model, Collection and View objects to work with Drupal nodes, views and templates, respectively, via the Services module's REST server functionality. While a few default views and example templates are also included, the rest is left up you, the developer, to build on as you please.

I had previously written a post on one method of upgrading PHP from 5.1 to 5.2 on CentOS and Red Hat servers by creating new RPMs. Since then, I have found a much better way to create PHP 5.2.17 (or newer) RPMs to easily upgrade (and later remove, if you want) the older version available by default. I'll presume you have no prior experience building PHP RPMs.

I've just released version 2.3 of the Sites module, which has been quietly under off-and-on development for a couple of months now here at EchoDitto Labs. Sites was originally conceived as a way to make it easy to create multi-site Drupal configurations without the problems and complexities incurred by using Domain Access. Sites is a less-articulated solution than Domain Access: it has fewer features at present, and does not integrate as deeply into the Drupal access stack, but is consequently more stable. Most importantly, it avoids rebuilds of the node_access table, which can be slow (and, in the case of very large sites, can even cause your servers to grind to a halt).

There are several considerations that came into play in the decision to write the module. First, we wanted to be able to create multi-site installs of Drupal wherein some views could show content existing across sites, while others could discriminate between those sites and show only content from the current site. If we simply created a new folder under /sites, there would be no clean way to know at the level of the controller (nodeapi, Views, etc) what site was being used to access content. Furthermore, if we decided to segregate content into different databases, it would be difficult to share that content across sites (the easiest alternative would probably be to publish feeds, which seemed like far more trouble than should be necessary).

Time for part two of my series on iPhone development basics. Last time, I gave some tips on writing settings to a binary file using Apple's Foundation Library. This time I'll show you how to retrieve those settings -- either from a cached version of the property list or from the filesystem itself. As with the first article, let's dive in head first with some code.

First of all, you'll want to add a static NSDictionary member to your settings data controller class for storing the cached settings.

In your .h file:

In your .m file:

Here's the loadSettings function. As you can see, I've implemented it as a class method -- there's really no reason to treat your settings data controller as anything other than a singleton with some class methods. Some argue against using singletons in Objective C. In most cases, I could be persuaded to agree; however, app-wide settings don't really make any sense implemented as anything except as global variables, and singletons are essentially the OOP equivalent of globals. I'd love if someone wanted to discuss this in a comment thread, however.