If you have any dynamic sites that can display the same information through a variety of URLs (e.g. “somepage.php?category=cats&story=123″ vs. “somepage.php?story=123&category=cats”), Google has provided a way for you to avoid the duplicate content issue by providing a “preferred link.”

Basically, you add a special link tag to the head of your page:

When Google finds duplicate content, it will transfer the page ranks and index data to your preferred link.

Clap your hands and say yeah. You’re done.

Head on over to the Google Webmasters Central Blog for details on this tip.

Recommended reading:

This article provides a solid overview of the relatively new vector for attack that hijacks your open redirect URLs.

Official Google Webmaster Central Blog: Open redirect URLs: Is your site being abused?

No one wants malware or spammy URLs inserted onto their domain, which is why we all try to follow good security practices. But what if there were a way for spammers to take advantage of your site, without ever setting a virtual foot in your server?

There is, by abusing open redirect URLs.

Okay, this is more for me than for you, my dear reader, but if you’re struggling with any productivity-based problem, 43folders is the place for you. Here are some crucial meta links:

What Sucks?

Looking for specific answers to what sucks for you today?

“My email sucks.”
“My attention management sucks.”
“My compulsive web browsing sucks.”
“My lack of resolve to put my art first sucks.”
“My procrastination sucks.”
“No, seriously. My procrastination really sucks.”
“My fiddling with ‘productivity systems’ sucks.”
“My to-do list sucks.”
“My blog sucks.”
“My band’s stupid website sucks.”
“My meetings suck.”
“My PowerPoint presentation sucks.”
“I suck.”

MAMP is a great tool for running and managing a development server when you require more than the basic PHP configuration included with Leopard. However, getting the web server to run typically involves launching MAMP, entering your root password, and quitting MAMP.

This tutorial walks through the simple steps needed to launch MAMP silently on startup so that you do not have to enter your root password every time.

The issue with MAMP is that launching Apache must be done as root, so there’s no way to simply add MAMP to your startup items via the system’s Accounts Preferences in a way that will launch the app silently. But you don’t need to. Here’s the deal: MAMP’s launcher is just a pretty UI that opens a shell script that, in turn, launches MAMP’s Apache and MySQL servers.

You can set up launch daemons that do the exact same thing without the need to launch MAMP or enter a password.

Step 1: Create the Start-up Items

Open up your favorite text editor and paste the following into an empty document:

Create another for the MySQL start-up item:

Be sure to replace “YOUR_USERNAME” with the username for your account.

Step 2: Save the Files

Save this file as (or move the file to) /Library/LaunchDaemons/info.mamp.start.apache.plist and /Library/LaunchDaemons/info.mamp.start.mysql.plist, respectively.

Step 3: Set Permissions

If you try to launch the daemons at the moment, you’ll get a “dubious permissions” error. To correct this problem, you’ll need to change your permissions.

In your terminal, type:

You’re done! Reboot your computer and test that your development server is running as expected by opening a served page in your browser.

Are you doing iPhone development on a Mac? Do you use Dreamweaver as your IDE? If your answer to both questions is ‘yes,’ then try this simple tip.

The iPhone SDK has an iPhone simulator that is, effectively, a fully functioning, pixel-perfect iPhone on your Mac. But because it’s an app on your Mac, it is also just another browser on your system. So treating it as such in Dreamweaver is a snap.

First, download and install the free iPhone SDK from Apple’s iPhone Development Center. Since you are not releasing apps through the App Store, you do not need to pay to be a part of the Application Developer Program. You just need a free developer account on Apple’s site.

Once you download and install the SDK, open up Dreamweaver.

1. Go File > Preferences > Preview in Browser
2. Click the “plus” button to add a new browser to your list
3. Navigate to /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/
4. Select the iPhone Simulator.app
5. Click Ok, and then close out your preferences
6. Now the iPhone Simulator is in your list of browsers

There’s one quirk. The iPhone Simulator must be running in order for it to accept browser pages from Dreamweaver, so if you trigger it from Dreamwever and all you see is the iPhone’s Home Screen, then do it again in Dreamweaver. The second time, the page should come up in the iPhone’s browser.

One thing that will inevitably come up when setting up a web server using MAMP on OS X Leopard is the need to add the PHP and PEAR binary paths to the Terminal $PATH variable. Fortunately, this is dead-simple.

Open a Terminal window and type the following (assuming you’ve installed MAMP in /Applications):

If you’re using PHP4 instead, you’ll want to specify that path instead.

Now type the following to see your newly edited $PATH environment variable:

You should see your MAMP PHP binary path tacked onto your $PATH string.

Now type the following:

If everything went according to plan, you should see the output from Pear updating itself.

If you create any sort of training videos for your clients, then you’ve most likely been using Ambrosia’s excellent SnapzPro.

SnapzPro has been the mainstay of desktop capture for years, but it’s somewhat of a one-trick pony. It captures the desktop action very well, but it offers nothing in the way of editing capabilities. It also restricts you more or less to a small view window, and you basically had to do everything in one clean take or bring multiple clips into a video editor to bring everything together.

Now, we have ScreenFlow from Vara Software. This $99 Leopard-only app lets you capture your desktop just like SnapzPro, but it does a whole lot more.

For starters, you can capture your entire desktop and pan around in a cropped version for optimal output. You can even capture your mug via your iSight and edit this into your video to add some variety to your output. There are callouts and cursor effects that you can layer in after the fact–something you used to be able to do only at run-time with OmniDazzle. Finally, there’s the timeline where you can edit, trim and otherwise perfect your output for professional results.

ScreenFlow is a huge timesaver and lets you produce training videos of a quality that was previously possible only with an expensive video editing package and multiple “takes” with Snapz.

Get the free demo of ScreenFlow here. You’ll be able to do everything you need to evaluate the software, but any output will be watermarked. The demo is otherwise identical to the unlocked version.

I was listening to MacBreak Weekly 73 in which Merlin Mann mentioned a backup routine that he uses that takes the approach of rsyncing your entire drive every night for the day WHEN your main drive fails. He mentioned briefly that JWZ (a.k.a. Jamie W. Zawinski) recommended this method on his LiveJournal blog [link].

JWZ’s piece is both funny and helpful. It’s well worth a minute to read.

Now get those hard drives replicating!

One of the great advantages of developing web sites on a Mac is the fact that all of the tools you need to run a web server are pre-installed. Getting them to work and play well together requires a little work—especially in Leopard.

If you are simply wanting a web server to host your personal web site, then you might want to consider stand-alone, point and click apps like XAMPP and MAMP. These turnkey solutions set everything up for you and are great solutions if you are just starting or have simple needs.

However, if you want to set up a development environment running multiple test sites using the free tools already installed on your Mac, and you aren’t afraid of the terminal, then read on.

UPDATE: Based on preliminary testing, these instructions remain up to date for Snow Leopard (10.6).

UPDATE: Since posting this tutorial, I have learned that the stock installation of PHP does not include several critical libraries. After several days of experimenting, I finally landed on MAMP as my production solution. I have published a walk-through for setting MAMP up on your machine [link].

NOTE: This guide is specific to getting a server running on Leopard 10.5. Earlier versions of the OS are not covered here.

This guide will walk you through the steps needed to get a development environment set up and running on your copy of Leopard. In this, we will do the following (click on each to jump to the corresponding section):

1. Enable your root password
2. Install the Xcode Tools
3. Edit your Apache configuration file
4. Set up your first virtual host
5. Start/Restart Apache
6. Test Apache
7. Test PHP
8. Load MySQL
9. Install phpMyAdmin
10. Install PEAR

Overview

A commonly used web server solution consists of 3 major components: Apache web server, a MySQL database, and the PHP scripting engine. This is the "AMP" in LAMP. (The "L" is "Linux"). This set up is widely used in the development community for two reasons: 1) it’s free and open source, 2) it’s very mature. "AMP" components are included in every copy of OS X, but getting them to work requires a few steps.

Step 1: Enable your root password

1. Open the Directory Utility: In the Finder, navigate to the Utilities folder (tip: click on the desktop, hit Cmd+Shift+U).
2. Click on the padlock to allow edits.
3. Go Edit > Enable Root Password
4. Enter and re-enter your password.

Now, you are set to access protected areas of the system via the terminal.

Step 2: Install the Xcode Tools

While this isn’t strictly necessary, it’s good practice for developers to install the Xcode tools provided for free on your Leopard disc. You’ll need it at some point, so go on and install it.

1. Insert your Leopard DVD
2. Navigate to Optional Installs > Xcode Tools > XcodeTools.mpkg
3. Run the installer.
4. Go get a cup of coffee.

Step 3: Edit your Apache configuration file

Note: throughout this guide, you will need to edit configuration files. There are several ways to do this. My preferred method is to use an app called BBEdit that allows you to edit protected files more gracefully than, say, TextEdit or the terminal window. However, BBEdit is not free. For the purposes of this tutorial, I’m going to stick with the terminal method that uses the editor called "nano" just because it’s included on every system.

In the terminal, type:

sudo nano /private/etc/apache2/httpd.conf

Note: "sudo" is a command that lets you perform a specific task with root privileges without having to log in as the root. This is the recommended method of mucking about in the terminal as it is safer than being logged in as root.

1. Scroll down to about line #114. You’ll see the following:
   #LoadModule php5_module      libexec/apache2/libphp5.so

2. Remove the hash mark as follows:
   LoadModule php5_module       libexec/apache2/libphp5.so

3. In order to run multiple sites on this server, you will want to use virtual hosts. Scroll down to the bottom of the document (about line #461) and remove the hash from the Virtual Hosts entry as follows:
   Include /private/etc/apache2/extra/httpd-vhosts.conf

4. Exit and save httpd.conf.

Step 4: Set up your first virtual host

Virtual hosts are Apache’s way of letting you serve up multiple sites on a single server. Name-based virtual hosting is a convenient way to do this.

For this example, we’re going to set up a test site called "site1". With a name-based virtual host, all we’d type in is "http://site1/ ".

In order to make this work, we’ll need to edit the hosts file on your machine. (Note: In Tiger and previous versions of OS X, you accomplished this through the NetInfo dialog. Since the NetInfo dialog was killed in Leopard, we do this the same way you do this for *nix and Windows by editing the hosts file directly).

To edit your hosts file, type in the terminal:

sudo nano /etc/hosts

Below the default entries, you’ll add the following:

# My sites
127.0.0.1 site1

Save your changes.

Now, we’ll need to add a corresponding virtual host. But first, Apache wants us to add our existing default directory as the very first virtual host. This is critical, so do not skip this step.

To edit your virtual hosts file, type in the terminal:

sudo nano /etc/apache2/extra/httpd-vhosts.conf

Replace the two example virtual hosts with the following:

<VirtualHost *>
  DocumentRoot "/Library/WebServer/Documents"
  ServerName localhost
</VirtualHost>

Next, add your first virtual host similar to the following:

<VirtualHost *>
  ServerName site1
  DocumentRoot /path/to/site1
</VirtualHost>

Who do we have to add our default directory first? According to the Apache Docs on Virtual Hosts, they recommend the following:

If you are adding virtual hosts to an existing web server, you must also create a <VirtualHost> block for the existing host. The ServerName and DocumentRoot included in this virtual host should be the same as the global ServerName and DocumentRoot. List this virtual host first in the configuration file so that it will act as the default host.

Note: Failing to add my default directory as the very first virtual host tripped me up for days. If your virtual hosts are defaulting to an unexpected directory, this is likely to be the culprit.

Step 5: Start/Restart Apache

1. If you haven’t done so already, go Apple Menu > System Preferences > Sharing
2. Ensure that “Web Sharing” is checked

Tip: To restart Apache in the future, you can come to the same control panel, uncheck and recheck the Web Sharing item.

Tip: Alternatively, you can type the following into a terminal:

sudo /usr/sbin/apachectl graceful

Tip: Alternatively, you can create an Automator script as follows:

1. Open a new, blank, custom workflow
2. Add a “Run AppleScript” action.
3. Type the following, replacing values as necessary:
   do shell script "sudo /usr/sbin/apachectl graceful" password "[YOUR ROOT PASSWORD]" with administrator privileges
4. Save the workflow as an Action.

Step 6: Test Apache

In a browser, load your localhost: http://localhost

If you see the default Apache home page (which contains a red and blue feather image), your Apache server is set up correctly. If you do not, then you might try checking your Apache config syntax:

sudo apachectl -t

Step 7: Test PHP

In your favorite code editor, create a new php file and call it "info.php". In this file, enter the following code:

<?php phpinfo(); ?>

Save the file to the root of your local host directory (e.g. "/Library/WebServer/Documents/info.php") directory. In your browser, navigate to the file (e.g. "http://localhost/info.php").

You should see a purple and white table containing all the PHP variables, modules, and settings. If you don’t see this table, backtrack to Step 3 above to ensure you’ve enabled PHP in your Apache config file correctly.

Step 8: Load MySQL

1. Download and unzip the MySQL Package for Mac OS X.
2. Install the main MySQL installer.
3. Install the Start Up Script.

As of this writing, MySQL has not been updated to support Leopard. You will be downloading the package for Tiger (10.4) and making the following modifications:

1. Do NOT install the MySQL control panel. As of this writing, it does not work with Leopard.
2. Start MySQL manually by typing the following into a terminal:
   sudo /usr/local/mysql/support-files/mysql.server start

MySQL should now be running silently in the background.

A new issue with Leopard’s installation of PHP is that it expects MySQL to be somewhere other than where it is installed by the package. To fix this, we need to create a new MySQL configuration file. To do this, create a text file and save it as "/etc/my.cnf". Enter the following text:

In a terminal window, type the following in order to create a folder where the MySQL sock file will live:

sudo mkdir /var/mysql
sudo chown _mysql /var/mysql

Note: If you are using any of the MySQL Tools (e.g. MySQL Administrator, etc.), you’ll need to tell them where to find the sock file. To do this, click the Advanced drop-down on the connection dialog, and enter “/var/mysql/mysql.sock“.

At this point, you should have a fully functioning database. Now, let’s get some data in there.

Step 9: Install phpMyAdmin

phpMyAdmin (PMA) is a popular and free tool to manage your MySQL databases. It is an integral part of most LAMP development environments.

1. Download and unzip the latest stable release of phpMyAdmin.
2. Copy the files to a directory of your choice. For this example, we’ll install it in "~/Sites/phpmyadmin/".
3. Per Step #4 above, add this directory as a virtual host called "pma".
4. Restart Apache to initialize your new virtual host.
5. Follow the installation instructions provided in the PMA download to set up the config file.
6. If you can navigate to PMA (e.g. "http://pma", you’ve good to go.

Step 10: Install PEAR

PEAR is a companion to PHP that is typically installed by default along with PHP. PEAR is a set of applications, modules and pre-packaged classes that provide a wealth of functionality to your apps with minimal effort. One example covered on this blog is how to implement an elegant caching mechanism with just a few lines of code. Using PEAR is highly recommended.

In a terminal window, type the following:

curl http://pear.php.net/go-pear > go-pear.php
sudo php -q go-pear.php

This will auto-install and pre-configure PEAR for you.

Now, we need to tell PHP to look for the PEAR files. To do this, we’ll need to modify the php.ini config file. First, copy the default config file and rename it php.ini by typing the following in a terminal window:

sudo cp /etc/php.ini.default /etc/php.ini

Now, edit the php.ini file:

sudo nano /etc/php.ini

Scroll down to line #469 or so and edit the include_path variable by removing the comment hash and adding the PEAR path as follows:

include_path = ".:/php/includes:/usr/lib/php:/usr/share/pear"

Restart Apache and ensure everything loads and runs as expected.

Conclusion

By this point, you should have a fully functional development server that you can extend and expand as you take on new projects.

Please feel free to add comments below if you find errors or problems with the guide above.

Good luck.

Cache Lite (or Cache_Lite) is a PEAR package that takes the pain out of server-side page caching. If you have a site with more than a moderate amount of traffic, or simply want to ease the server load rendering a particularly complicated PHP page, you should consider using this Cache_Lite.

Caching Overview

Let’s take the example of a real news site I built for a client, McKinneyNews.net. There is a lot going on on the front page: the main body has a story flow that is updated several times a day, blog posts are summarized as needed, and windows to other parts of the site (e.g. calendars & sports schedules) are shown via widgets in the sidebars. All of this dynamic content comes at a huge server performance penalty. Simply put, the home page is expensive to render.

This is where caching comes to the rescue. In the case of news and blog posts, these are updated several times a day, but certainly don’t need to be re-rendered with every page view. In fact, the front page changes perhaps a dozen times a day. Thus we do the heavy lifting in the back-end when content is published, not every time site visitors request the page. On heavy pages like this, caching can decrease load times and improve server performance dramatically.

Cache Lite

When looking for a caching solution, I was concerned with three things: 1) ease of implementation, 2) modularity so it could be used for blocks of content, not just entire pages, and 3) security.

Implementation couldn’t be easier. Simply install the Cache_Lite package (or request that your host install it for you). As a super-user in a terminal, type the following:

pear install Cache_Lite

Now you’re ready to start using Cache_Lite. A very good tutorial on the use of the Cache_Lite package can be found here, but the basic structure is as follows:

<?php
// Include the package
require_once('Cache/Lite.php');

// Set a id for this cache
$id = '123';

// Set a few options
$options = array(

    'cacheDir' => '/tmp/',
    'lifeTime' => 3600

);

// Create a Cache_Lite object
$Cache_Lite = new Cache_Lite($options);

// Test if thereis a valide cache for this id
if ($data = $Cache_Lite->get($id)) {

    // Cache hit !
    // Content is in $data
    // (...)

} else { // No valid cache found (you have to make the page)

    // Cache miss !
    // Put in $data datas to put in cache
    // (...)

    $Cache_Lite->save($data);

}

?>

Since it is a rare case that an entire page is presented to all users identically (e.g. if the page contains a slug that welcomes a user by name), caching only parts of a page becomes a necessity. Instead of using the code above to draw an entire page, use it to draw only a portion of it (e.g. a news block), leaving the other, lighter portions of the page to be rendered dynamically with each page draw.

Likewise, let’s say that the block you want to cache can be drawn one of several, finite ways. Let’s take for example the case where only part of a story is shown to users who are not logged in, while the full story is presented to those who are. If you are not careful, you could cache the whole story and present the logged-in state page to users who are not logged in. The key here is to pick an $id that is unique and state based, and call it back based on that same state.

Finally, security: Cache file corruption because of concurrent read/writes is always a concern, but Cache_Lite takes care of this via hashing and checksums. If the data has been tampered at all or is incomplete due to a write-in-progress, live content is used.

In the time it has taken you to read this article (and thank you for doing so!), you could have Cache_Lite up and running on your site. It’s that simple. Read the documentation (it’s painless) and give it a shot. Your server and your users will thank you for it.