OS X Lion comes with most of the tools you would need to do "MAMP" (Mac OS X, Apache, MySQL/MariaDB, PHP) development, as outlined in my previous posts once you add a database. So then why would you want to use MacPorts? Setting your development environment up in MacPorts isolates the binaries, libraries, and configuration files, completely separate from the existing OS X install (with the exception of startup scripts). You can also tweak the configuration files on your own, apply your own patches, and apply updates that MacPorts may get before Apple pushes them. It will take more time because you'll be compiling everything, but you have all of the control. Read on for how to get things set up.

OS X Lion ships with Apache and PHP, which both require a little bit of tweaking to get fully-functional for "MAMP" local development. The one thing Lion does not ship with is a database. This will be very similar to my previous post on local development but this time we'll be using Homebrew to install either MySQL or MariaDB for the database. Since we'll be using a compiler for Homebrew, I'll also cover how to add APC and other PECL modules that you can add to OS X.

With the release of Lion, there are some subtle differences to setting up a local MAMP (Mac OS X, Apache, MySQL, PHP) environment compared to Snow Leopard. In an effort to keep this from being overly wordy and just get to the good stuff, we'll dive right in, so read on to get started.

It seems to be standard for Drupal, at least in version 6, that Watchdog is enabled and used to write errors/warnings/notices to the watchdog table in the database. Depending on the verbosity of your PHP output, amount of 404s, or other information that would be going into this log, it could mean a lot of writes on your database. While you should trace errors/warnings and solve them, sometimes you may want this increased information for debugging. If your site receives a lot of traffic, this could mean decreased database performance. A solution to this is to instead utilize the core Syslog module instead of Watchdog. Here's how I got it set up in Drupal 6 on CentOS 5 servers.

We're big fans of Drush. It's installed on all of our servers and it's a great way to perform maintenance tasks, download core and modules, and much much more. I'm not a big fan of installing from zip files though, so let's use git to easily keep our Drush install up to date.

Here's a one-liner to dump each table in a database to it's own .sql file. Crack open your shell of choice and follow along.

On Snow Leopard, you can install drush without using sudo. A dependency for installing drush is downloading a Pear library. The following example should allow you to be able to use the following commands to install drush to /usr/local/drush with a symlink in /usr/local/bin/drush, but it fails on the 'pear download' step, even though it's writing to a user-writeable directory. Read on the figure out how to fix this annoying problem.

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.

In addition to hosting Drupal sites, we also host a number of WordPress sites. Similar to checking all of our Drupal core versions, we needed an easy way to quickly see what versions we are running on all of our WordPress sites. Kudos to Ethan for getting this one kicked off; here is a bash script to check your definable $WEBHOME (where you deposit all of your WordPress webroots) and scan for WordPress versions.

At EchoDitto, we host a lot of Drupal sites. Just about all of our web servers contain more than one completely separate Drupal cores since we develop most of our websites independently. We also keep an eye out on Drupal Security and when to apply core updates. Since we're not using Aegir, nor do we run every site off of a single multi-site core install, we need a quick and easy way to see what versions we're running.

Apple OS X comes with Apache and PHP built-in but need some tweaking to work. It also does not come with MySQL. Because of this, many developers have chosen to use MacPorts, Homebrew, or MAMP to install new binaries for Apache, PHP, and MySQL. However, doing this means your system would have multiple copies of Apache and PHP on your machine, and could create conflicts depending on how your built-in tools are configured. This tutorial will show you how to get the built-in versions of Apache and PHP running with an easy to install version of MySQL.

Dropbox hardly needs any introduction; put files in your Dropbox and they show up everywhere else you have Dropbox installed and dropbox.com. A feature about Dropbox that is probably not as widely known is that free accounts come with 30 days of undo history and Pro accounts can get "Pack Rat" that keeps unlimited history of changes. The history of files, including reverting deleted files, was particularly interesting to me, since I could hook in my latest daily MySQL dumps from AutoMySQLBackup to Dropbox and have 30 days of backups for free available from anywhere dropbox.com is accessible.

The problem is that we use CentOS for our servers and the Dropbox Linux builds are geared for distributions like Ubuntu and Debian that have updated versions of required software like Python, libc, and others, that I did not want to upgrade by hand on my systems and risk the integrity of the system packages. But, I got it to work anyway, read on for how I got Dropbox CLI installed on CentOS without replacing any system files.

Today I was made aware of some strange MySQL errors on our development server that ended up being related to a lack of sufficient disk space. Upon inspection, the /tmp partition had completely filled up. A majority of the files were temporary files created by the Drupal module devel with devel_themer enabled. Turns out these temporary files are not deleted at the end of a session. There were also CURLCOOKIE files related to cron jobs to hit cron.php on various dev and production sites, and some other temporary files that if left unattended could result in the same errors.

My solution is to have these files deleted every night, but only if they're three days old, which should be adequate time for the developer to need access to these temporary files. I added this to root's cron.

Similarly, I have a cron job to remove old Apache logs, which is helpful since an old project will never have it's logs deleted unless they're removed manually.

Do you have other ideas for managing temporary files that don't clean up after themselves? Let us know in the comments.

An updated, easier method can be found here.

Here at EchoDitto, most of our servers are running CentOS Linux, which is a 100% binary-compatible version of the industry standard Red Hat Enterprise Linux (RHEL) without any of the fees. The problem with RHEL/CentOS is that they shipped with PHP 5.1.6, and as of this writing PHP is at 5.2.9. That's not a big deal, being a minor point revision behind, until you come across an application or module that needs a minimum of version 5.2. The last thing I want to do is install packages from a third-party or build it from source and risk breaking other packages. So what's the answer? Building it from the source rpm. There's no better way to keep the system free of third-party packages but also up to date.