Thanks to all those that attended my WordCamp Phoenix session on Tools for Inspecting and Development. Please feel free to comment or ask any questions. These are the same tools I use in my everyday work writing and testing code.

Your just finished reading WordCamp Phoenix 2013. For more resources like this go to C3M DIGITAL.

WordPress 3.4 will be out any time now and brings some significant changes including some tweaks to WP_Query to make things run faster behind the scenes, and a new theme customizer. Take a look at this video from the folks over at WP101, who produce a nice line of WordPress Tutorial Videos

For Developers

Nacin’s WordPress 3.4 field guide for developers

Chip Bennett explains the new themes API

Embedded Tweets

You can now directly embed tweets by just adding the url of the tweet directly into the WordPress post editor.

WordPress 3.4 is here! Update your site now to try the new theme customizer, better headers, HTML captions & more: wp.me/pZhYe-BE

— WordPress(@WordPress) June 13, 2012

Your just finished reading Whats new in WordPress 3.4. For more resources like this go to C3M DIGITAL.

I was very excited when I heard Panic was releasing a new iPad app, Diet Coda to go along with the release of the updated Coda 2 editor.

One thing that I don’t like about the app is that it encourages Cowboy Coding, the practice of editing files on a live server. Panic states that you can use it on your staging or dev server but most people use their local machine as their dev server. From reading reviews this seems like the biggest complaint people have about the app.

Even though it’s not documented anywhere you can actually use this app to work on files saved on your Mac. OS X comes with a built-in ssh server which allows you to connect using SFTP. You will need to enable Remote Login in your sharing settings on your Mac first.

Enter the IP address from above into Diet Coda’s site settings.
To do this just enter your Mac’s local IP address into the site Settings in Diet Coda. Once it connects you will be able to access any file on your computer and edit it in Diet Coda.

Diet Coda Screenshots – Working with local files

Your just finished reading Quick Tip – Work on Local Files with Diet Coda. For more resources like this go to C3M DIGITAL.

Your just finished reading Get latest 3 posts from multiple custom post types in one query. For more resources like this go to C3M DIGITAL.

I’ll be speaking at WordCamp Austin later this month. My session is “The Query, the Whole Query, and nothing but the Query”. It will include everything you need to know about the WP_Query class and how to properly query the WordPress database for posts. I look forward to meeting some new people and seeing old friends. I’ll be updating this post with slides and additional code samples. Please comment if you have any questions or suggestions.

Your just finished reading WordCamp Austin – I’m Speaking. For more resources like this go to C3M DIGITAL.

WordPress lead developer, Mark Jaquith, recently gave a talk at WordCamp San Francisco on Scaling, Servers, and Deploys that including some great advice on professional WordPress development using Git.  Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

The session from WordCamp San Francisco:

The purpose of this guide is to show you how you can add Git to your WordPress development workflow and will include the basics of securely installing Git on a remote server, using your local machine for development and deploying your changes to a live production server using SSH.

This article assumes:

• You have SSH access to a remote server running Debian or Ubuntu (The shell commands will be slightly different for other distros)
• Your using a Mac with a local development environment already set up.
• Your comfortable using the command line and able to access your remote server using SSH keys.

Step 1: Installing Git on the remote server

Install Git:

apt-get install git-core

Adding the git user. (You will be asked to enter a password for the git user. We won’t be using it but remember what it is just in case.)

adduser git

Setup SSH keys for the new git user. If you still have access to the public key you use to access your server you can add it to /home/git/.ssh/authorized_keys. If not you will need to generate a new public/private key pair and add the public key to your server. See my previous article WordPress Performance Server – Debian “squeeze” with Nginx, APC and PHP from the Dotdeb repos for more info on setting up SSH keys on your server. You can also use the ssh-keygen tutorial on GitHub.

su git
cd /home/git
mkdir .ssh
chmod 700 .ssh
cd .ssh
touch authorized_keys
cat id_dsa.pub >> authorized_keys
exit

If you need to switch back to your normal user to add your public key make sure you chown the /home/git/.ssh back to the git user by running:

chown git:git /home/git/ -R

Now lets test our SSH connection using the git username on the remote server. If you use lots of different SSH keys for different servers it helps if you add instructions to your config file to identify the right key to use when logging in.

On your local machine create if needed and open the file ~/.ssh/config

Host remote_server_domain.com
Hostname remote_server_domain.com
IdentityFile ~/.ssh/id_dsa //Your private key that matches the public key we installed on the server
User git

Now lets test our connection to the remote server

ssh git@remote_server_domain.com

If your able to connect let’s go ahead and create and initialize our remote Git repository. We’re calling this repo “project1″.

cd /home/git
mkdir project1
cd project1
git --bare init
exit

You just created your first remote Git repository!

For security we are going to restrict shell access for the git user. This will allow you to share development with other users by giving them SSH access to the repo without giving them shell access to your server.
SSH back into your server with the user with su privileges.

 
nano /etc/passwd

When you open the file find the line for the new git user we just added and change the end of the line from /bin/bash to /usr/bin/git-shell. (Do not change the user Id or group ID). It should look like this when your done:

git:x:1001:1001:Git,,,:/home/git:/usr/bin/git-shell

Test the new config by exiting and trying again to SSH into the server with the git user:

ssh git@remote_server_domain.com

fatal: What do you think I am? A shell?
connection to [remote_server_domain.com] closed.

Now we have a secure remote repository.

Step 2: Installing Git and setting up your local machine

Download and install the latest version for Mac (For Lion or Snow Leopard choose: Git Installer 1.7.6 – OS X – Snow Leopard – x86_64)

Making your first commit.
Now that we have our remote repo setup and Git installed on our local machine let’s make our first commit.

mkdir project1
cd project1
git init
touch readme.txt
git add .
git commit -m "Initial commit - added readme.txt"

The first time we use our new repo we need to tell Git where to find it.

git remote add origin ssh://git@remote_server_domain.com/home/git/project1
git push origin master

Now we are going to delete the project1 directory we created on our local machine and check out the repo so we can start doing some WordPress development. I use the ~/sites directory for my local development so lets check the new project out into that directory. If you haven’t set up your local environment using hostname aliases in the ~/sites directory check out this tutorial on WPCandy: How to improve local WordPress development on a Mac

rm -rf project1
mkdir ~/sites/wp.dev
cd wp.dev
git clone ssh://git@remote_server_domain.com/home/git/project1

We now have checked out the latest version of our repo (currently only containing the readme.txt file) and are ready to start working but first we need to decide our version control strategy.

Setting up your repo for WordPress theme and plugin development

The power of Git besides being able to track your development changes is being able to quickly deploy a complete site to your production server including the latest version of WordPress. The WordPress team uses Subversion to track WordPress core changes but luckily there is a Git WordPress clone that updates every 30 minutes.

There are couple different routes you can take when setting up your repo with WordPress. Some developers prefer to keep the wp-content directory under version control separate from the core files then sym link to the version controlled wp-content dir that contains your theme and or plugin files that you will be working on.

Keeping things separate is probably best if you want to use one master repo for all the themes and plugins you work on but for this article we are going to clone the 3.2 branch from the WordPress Git repo and merge it with our remote repo. This will make it easier to deploy until we master more advanced deploy techniques like using Capistrano to automate the deploy process.

The git pull command allows us to clone the WordPress repo and merge it with our remote repo with one command. We can also specify the branch (currently WordPress is on 3.2-branch) we want to work with.

cd ~/sites/wp.dev
git pull https://github.com/markjaquith/WordPress.git 3.2-branch
git add .
git commit -m "added WordPress core files"

You will notice that when you try to make this commit you will get a message that your branch is ahead of origin/master

# On branch master
# Your branch is ahead of 'origin/master' by 16688 commits.
#
nothing to commit (working directory clean)

There might be a better way to add WordPress and keep it under version control but using this method we inherit all the core svn commits that were made to the 3.2-branch (Don’t worry any new additions will not cause problems)

Now that we have the WordPress core files in our repo lets go ahead and push them to our remote master

git push origin master

Before we start working we need to make a few changes to wp-config.php to use the local version of our database by creating a local-config.php file. (See Mark Jaquith’s postWordPress local dev tips: DB & plugins for detailed instructions on how to use a local-config.php file and disable plugins you don’t want to run on your local environment.

We want to keep wp-config.php under version control but tell WordPress to use our local DB_NAME, DB_USER, and DB_PASSWORD settings when we’re doing local development.

You can now create your theme or plugin files and start working and commit (check them in) as needed:

git add .
git commit -m "Your commit message"
git push origin master

Step 4: Deploying to a live server

For this article I’m going to cover a very basic deploy strategy that uses the master and origin branches. There are more advanced methods like Capistrano and multiple branches for staging and production that I will cover in future articles. See the Git Reference for more info on working with branches.

Moving to our live server were going to clone repo. This assumes the production environment lives on the same server as the remote repo or we have generated a working SSH key pair to access the remote repo.

cd {root public dir}
git clone ssh://git@remote_server_domain.com/home/git/project1 .

Now anytime you make updates SSH into the live server and run:

git fetch origin
git merge origin master

If you ever need to rollback a change you can quickly do a git reset –hard your_sha. Your_sha represents a commit and to find the previous commit to roll back from run git log. This will output recent changes. Find the most recent “Merge remote branch” message and use the sha (long number after the commit message) to run your git reset command.

Conclusion
Hopefully this article gives you a basic understanding of how version control with Git works. This should give you a good start and keep you from wearing the “Pink Sombrero” I would love to hear how you use version control in your WordPress development workflow and welcome any comments or suggestions.

Resources used for this article:

• Help.GitHub.com
• Mark on WordPress: WordPress local dev tips DB & Plugins
• Clint Berry: Speed Up Your WordPress Development Cycle with Git
• WordPress.Stackexchange.com: Getting Started with Subversion, Git, or similar Version Control System to keep a History of my Files?

Your just finished reading Adding Git to your WordPress development workflow – an introduction. For more resources like this go to C3M DIGITAL.

This is a step by step guide on how to set up your own unmanaged server or vps to run as a WordPress Performance server environment.  Using this setup you will have the ability to host a large WordPress Multisite set up or numerous single installs.  This guide assumes you have a basic understanding of using SSH via the Mac Terminal app or Putty for Windows and requires an unmanaged dedicated server or VPS hosting account with either the 32 or 64 bit Debian kernal available.

In my last guide I touted a Nginx reverse proxy cache with WordPress and Apache as the ultimate WordPress performance stack but since then I have found that there is really no reason to use Apache unless you have a specific need for it.  Nginx has matured and works great with the WordPress rewrite engine and even W3 Total Cache now includes Nginx rewrite rules for page cache, minify and browser caching.

If you ever decide that managing you own web server isn’t for you then I highly recommend WP Engine WordPress Hosting WP Engine runs on Nginx and they handle all the caching for you.

Choosing a web host with Debian “squeeze” images available

Debian 6 aka “squeeze” is considered the grandfather of Linux distors and Debian is known for relatively strict adherence to the Unix and free software philosophies.  Debian is also distributed with access to repositories containing thousands of software packages ready for installation and use.

Most of the large managed hosting companies don’t give you the option of choosing your Linux distro so your going to need to find one that does.  The reason for this is that it’s much easier for a hosting company to provide support using cPanel or Parallels Virtuozzo VPS virtualization.  Virtuozzo allows them to squeeze many more VPSs on a box and control the resources and your limited to guess what – Cent OS.

Your going to need a provider that offers Xen virtualization.  Xen is a powerful open source virtualization platform that supports a wide range of guest operating systems including Linux – Debian, Ubuntu, Free BSD, Cent OS, Fedora and more.  When you set up your account have your provider load the Debian 6 aka “squeeze” image on your VPS or install it on your dedicated server.  If you have over 2GB memory go for the 64 bit version.

I use Softlayer (formally The Planet) for my dedicated server because of the state of the art data centers and major broadband backbone it’s connected to.  It also has a very powerful back end portal and allows you to connect to your box over a private VPN.  Linode, Slicehost, and VPS.net  are also very good choices.  I would stay away from Media Temple and Rackspace as I’ve had problems with both and they’ve had well documented  security vulnerabilities in the past.

Your provider will either provide you with an ip address and password to connect to your server for the first time or give you access to a control panel that you can use to load the image.

Some hosts include the network setup on the image others provide a java ssh console to connect.  If your only provided the java console you will need to set up the networking settings.

*Note: all entries in this article that require opening a file assume the nano text editor, some of you  might prefer vim or if your a real Linux Ninja Emacs (If you use Emacs you don’t need to read this article .)  If you prefer vim just substitue vi for nano.

If your provider pre-installed the image for you skip to Security.

nano /etc/network/interfaces

This is the file that contains the connection settings for each of the network cards on your server.  You will need your ip address and the gateway address which is to the router.  Your host should provide these for you.

auto lo
iface lo inet loopback
auto eth0 inet static
address xx.xx.xxx.xxx
netmask 255.255.255.0
gateway xx.xx.xxx.xxx

Ctrl-x will close your file and prompt you to save.

Next we will install the secure shell server

apt-get install openssh-server
/etc/init.d/ssh status
: sshd is running.

With networking and ssh setup you will be able to connect via ssh using Terminal or Putty

ssh root@xxx.xx.xx.xx

Enter your password at the prompt and accept the key fingerprint prompt which will add your new server or vps to your local known_hosts file.

Securing your server

The first step is securing your server.  To properly secure your server you need to disable password auth and use ssh keys to access your server.  Your key authorization will also be used for adding files via an SFTP program like Transmit.  We will also be updating all the packages and configuring the firewall using ufw.

apt-get update
apt-get upgrade-distro

Disable password authentication  in the sshd_config file.

nano /etc/ssh/sshd_config
Protocol 2
PasswordAuthentication no
UseDNS no

Open another terminal window to generate the ssh keys on your LOCAL machine.

mkdir ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa

You will be prompted for a password to further secure your key and a name to save it under. Unless you all ready have existing keys just press enter to accept the default name of id_rsa / id_rsa.pub. The id_rsa.pub file is your public key and will need to be moved to the server.

scp ~/.ssh/id_rsa.pub root@xxx.xxx.xx.xx:

You will be prompted for your server password and your public key file will be in your root directory. Now will move it to the correct place and add it to the authorized_keys file. Close your 2nd terminal window and go back to the one you were using and connected to the server with.

mkdir ~/.ssh
mv ~/id_rsa.pub ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now we will configure the firewall using ufw. UFW is an uncomplicated firewall that acts as an interface to control the servers iptables without the confusing syntax. It is shipped with Ubuntu but for Debian you will need to install: apt-get install ufw.

The following commands will open up the ports for ssh, web, smtp (php-mail), and mysql. You can add rules for any of the network services defined in the /etc/services file or roll your own custom rules.

ufw allow ssh
ufw allow www
ufw allow https
ufw allow mysql
ufw enable
ufw status

:To		Action	From
--		------	----
22		ALLOW	Anywhere
80		ALLOW	Anywhere
443		ALLOW	Anywhere
3306		ALLOW	Anywhere

Now we will restart ssh and test our connection. VERY IMPORTANT don’t disconnect your current ssh session! Test by opening another terminal window. If your on Mac you will get a keychain notice for your key password. Click the remember button so you won’t have to enter it every time.

Current terminal window

/etc/init.d/ssh reload

New Terminal window

ssh root@xxx.xxx.xx.xx

:Linux DebianLinux-001 2.6.32-5-amd64 #1 SMP Mon Mar 7 21:35:22 UTC 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jul 12 21:40:45 2011 from 108-71-13-85.lightspeed.hstntx.sbcglobal.net

root@servername ~:

If you were successful give your self a pat on the back and close your original terminal window.

The Performance Stack – Nginx, PHP-FPM, MySQL

In the past, with Debian 5, it was very frustrating trying to stay up to date with the latest versions of PHP, MySQL and Nginx because the packages were always so outdated. Debian 6 shipped with up to date versions but if you want the latest performance packages your going to need the Dotdeb repositories.

Dotdeb is a repository containing packages to turn your Debian boxes into powerful, stable and up-to-date LAMP servers :

• PHP 5.3
• useful PHP extensions : APC, imagick, Pinba, xcache, Xdebug, XHprof…
• MySQL 5.1 and its performant InnoDB plugin,
• Maatkit…

Add the Dotdeb repos to /etc/apt/sources.list

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Now fetch the appropriate GnuPG keys

wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | apt-key add -

Run apt-get update and you should see your server connecting to the dot deb mirrors.

Note: Dotdob is a one man operation maintained by Guillaume Plessis, @W_a_s_t_e on Twitter. If you benefit or prosper from his packages consider donating

Install Nginx, PHP-FPM, MySQL, APC

apt-get install nginx-full php5-fpm php5 php5-mysql php5-apc php5-mysql php5-xsl php5-xmlrpc php5-sqlite php5-snmp php5-curl

You will be prompted to accept installs and apt-get will make sure all dependencies are met and install additional packages if needed. When you get to the MySQL install a semi-graphical interface will pop up. Make sure you choose a password for the root mysql user.

If you have made it this far go grab a beer or an espresso you deserve it, Systems Administrator.

The .conf files – configuring your web server

The default .conf files included in the Dotdeb packages will almost work right out of the box. You will need to make a few adjustments.

Nginx and PHP-FPM
Before you set up the Nginx.conf files you need to decide your folder structure and where the root of your websites will live. I like to use /srv/www/sitename/public for the web root and /srv/www/sitename/logs for the error and access logs. The files in your web root need to be owned by the same user as Nginx runs under. The Debian way is to run the server as www-data.

mkdir /srv/www/yoursitename /srv/www/yoursitename/public /srv/www/yoursitename/logs
chown www-data:www-data /srv/www/yoursitename/public/ -R

File: /etc/nginx/nginx.conf
Note: be wary of some of the copy and paste guides out there. The Slicehost and Linode tutorials are out of date and contain security vulnerabilities. If you don’t understand something question it and do your own research. The following files have been tested and are in use on real production servers.

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
	worker_connections 1024;
	# multi_accept on;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	server_tokens off;
	include mime.types;
	default_type  application/octet-stream;
	index index.php index.htm index.html redirect.php;

	#Gzip
	gzip  on;
	gzip_vary on;
	gzip_proxied any;
	gzip_comp_level 6;
	gzip_buffers 16 8k;
	gzip_http_version 1.1;
	gzip_disable "MSIE [1-6].(?!.*SV1)";
	gzip_types text/plain text/css application/json application/x-javascript text/xml
                        application/xml application/xml+rss text/javascript;

	#FastCGI
	fastcgi_intercept_errors on;
	fastcgi_ignore_client_abort on;
	fastcgi_buffers 8 16k;
	fastcgi_buffer_size 32k;
	fastcgi_read_timeout 120;
	fastcgi_index  index.php;

	limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

	##
	# Virtual Host Configs
	##

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;  #Our individual site vhost server files will live here
}

If your familiar with the Apache Vhost concept you will be fine with Nginx. The Nginx server files we create act as individual site vhost.conf files and can either be in one large file or for better organization you can create a separate file for each site. The Debian way is to create 2 directories under /etc/nginx/, sites-available for the files and sites-enabled for sym links pointing to the file in sites-available. This allows you to turn off a site without having to delete it if you ever need it again.

touch /etc/nginx/sites-available/your_domain.com
ln -s /etc/nginx/sites-available/your_domain.com /etc/nginx/sites-enabled/your_domain.com
cd /etc/nginx/sites-enabled
ls -a
:drwxr-xr-x 2 root root 4096 Jun 26 02:04 .
drwxr-xr-x 5 root root 4096 Jun 26 01:50 ..
lrwxrwxrwx 1 root root   40 Jun 26 01:59 your_domain.com -> /etc/nginx/sites-available/your_domain.com

File: /etc/nginx/sites-available/your_domain.com
This is for a single WordPress install. We are also including the W3 Total Cache Nginx rewrite rules in a separate file w3-total.conf. You will need to run touch /etc/nginx/w3-total.conf and chown www-data:www-data /etc/nginx/w3-total.conf and list the path in the W3 Total Cache general settings so it can write to the file. *Note: Anytime you make a change to an Nginx server file you will need to restart.

server {
	listen 80;

	server_name your_domain.com www.your_domain.com;
	root /srv/www/domain/public;
	access_log /srv/www/domain/logs/access.log;
	error_log /srv/www/domain/logs/error.log;

        client_max_body_size 8M;
        client_body_buffer_size 128k;
        #The section below contains your WordPress rewrite rules
	location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
	}
        location /search { limit_req zone=one burst=3 nodelay; rewrite ^ /index.php; }
	fastcgi_intercept_errors off;
	location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
		expires max;
		add_header Pragma public;
		add_header Cache-Control "public, must-revalidate, proxy-revalidate";
	}

#sample 301 redirect
#	location /2011/06/26/permalink/ {
#		rewrite //2011/06/26/permalink/ http://example.com/2011/06/27/permalink_redirecting_to/ permanent;
#		}

#Send the php files to upstream to PHP-FPM
#This can also be added to separate file and added with an include
location ~ \.php {
        try_files $uri =404; #This line closes a big security hole
                             #see: http://forum.nginx.org/read.php?2,88845,page=3
        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     $request_method;
        fastcgi_param  CONTENT_TYPE       $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param  REQUEST_URI        $request_uri;
        fastcgi_param  DOCUMENT_URI       $document_uri;
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        fastcgi_pass 127.0.0.1:9000;
}

#Once you have your w3-total.conf file ready un-comment out the line below
#include w3-total.conf;

You can now start your server and see if it works.

touch /srv/www/yoursite/public/index.php
echo '<!--?php echo "<br ?--></pre>
<h1>Nginx Baby - It WORKS!!!!</h1>
<pre>
"; ?>' >> /srv/www/yoursite/public/index.php
/etc/init.d/nginx start

For more Nginx server file examples see the WordPress.org Nginx Codex

Open a browser and go to your domain or ip and if you did everything right you should see:

WordPress Multisite, alternative configuration and multiple non WordPress vhosts
If you want to host a multisite setup or add additional websites to your server or VPS you can include the WordPress Multisite rewrite rules in a separate file and simplify your per site vhosts.

File: /etc/nginx/nginx.conf

user www-data;
worker_processes  10;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
	include mime.types;
	default_type       application/octet-stream;
	access_log         /var/log/nginx/access.log;
	sendfile           on;
#	tcp_nopush         on;
	keepalive_timeout  3;
#	tcp_nodelay        on;
#	gzip               on;
	client_max_body_size 13m;
	index              index.php index.html index.htm;

	upstream php {
	#	server 127.0.0.1:9000;
		server unix:/tmp/php-fpm.sock;
	}

	include sites-enabled/*;
}

This is a sample vhost for a subdomain WordPress Multisite that uses the Domain Mapping Plugin along with a few static sites that are also hosted on the server.

server {
	 listen 80;
	#Add a server_name entry for each mapped domain
	server_name star.main-multisite-domain.com *.main-multisite.com;
        server_name mapped-domain.com www.mapped-domain.com;
	server_name mapped-domain-2.com www.mapped-domain-2.com;
	server_name mapped-domain-3.com www.mapped-domain-3.com;

	root /srv/www/wordpress/public;
	access_log /srv/www/wordpress/logs/access.log;
	error_log /srv/www/wordpress/logs/error.log;
	index index.php index.html index.htm;

        #The Multisite rules are in the include below
	include global-wp-multi.conf;
}

#Begin Static Non WP Sites
#Repeat the vhosts below for each additional static site.  Make sure you make each one a root directory
server {

	server_name static-non-wp-domain.com www.static-non-wp-domain.com;
	root /srv/www/static-non-wp-domain/public;

        error_log /srv/www/static-non-wp-domain/logs/error.log;
	index index.php index.html index.htm;

	}

File: /etc/nginx/global-wp-multi.conf
This is a default config file that will handle the rewrite rules for domain mapped subdomain multisites.

error_page 404 = @wordpress;
log_not_found off;

location / {
	try_files $uri $uri/ /index.php?$args;
}

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
	expires 24h;
	log_not_found off;
}

rewrite ^/files/(.+) /wp-includes/ms-files.php?file=$1 last;

location ^~ /files/ {
	rewrite ^.*/files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

include wp-total.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
	rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
	rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

location @wordpress {
        fastcgi_pass php;
        fastcgi_param SCRIPT_FILENAME $document_root/index.php;
        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     $request_method;
        fastcgi_param  CONTENT_TYPE       $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param  REQUEST_URI        $request_uri;
        fastcgi_param  DOCUMENT_URI       $document_uri;
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_NAME /index.php;
}

location ~ \.php$ {
	try_files $uri @wordpress;
	fastcgi_index index.php;
	fastcgi_pass php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     $request_method;
        fastcgi_param  CONTENT_TYPE       $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param  REQUEST_URI        $request_uri;
        fastcgi_param  DOCUMENT_URI       $document_uri;
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        fastcgi_pass 127.0.0.1:9000;
}

File: /etc/php5/conf.d/apc.ini

; configuration for php apc module
extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 512M
apc.optimization = 0
apc.num_files_hint = 2700
apc.user_entries_hint = 2700
apc.ttl = 7200
apc.user_ttl = 3600
apc.gc_ttl = 600
apc.cache_by_default = 1
apc.slam_defense = 1
apc.use_request_time = 1
apc.mmap_file_mask = /dev/zero
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 2M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
apc.rfc1867 = 0
apc.rfc1867_prefix = "upload_"
apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
apc.rfc1867_freq = 0
apc.localcache = 1
apc.localcache.size = 1350
apc.coredump_unmap = 0
apc.stat_ctime = 0

Php.ini is located at /etc/php5/php.ini use the production defaults explained in the file.

File: /etc/my.cnf
The default is very long and well documented. Copy it to my.cnf.back and use this as a starting place (have at least 1GB Ram before using this file)

[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
key_buffer	= 16M
max_allowed_packet  = 16M
thread_stack	    = 192K
thread_cache_size   = 16
myisam-recover      = BACKUP
max_connections     = 100
table_cache         = 256
thread_concurrency  = 16
query_cache_limit   = 4M
query_cache_size    = 128M
general_log_file    = /var/log/mysql/mysql.log
general_log         = 1
log_slow_queries    = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes

expire_logs_days    = 10
max_binlog_size     = 100M

[mysqldump]
quick
quote-names
max_allowed_packet   = 16M

[isamchk]
key_buffer	    = 16M

# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

Whenever you make changes to a .conf file you need to restart the server to apply your changes.

/etc/init.d/mysql restart
/etc/init.d/nginx restart

WordPress via svn and setting up W3 Total Cache

The server is ready to install WordPress

Create your database

mysql  -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5340 to server version: 3.23.54

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE DATABASE databasename;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON databasename.* TO "user_name"@"localhost"
    -> IDENTIFIED BY "password";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

mysql> EXIT
Bye

Install WordPress via SVN

cd /srv/www/yourdomain/public
svn co http://core.svn.wordpress.org/tags/3.2.1 .

Add your database info to wp-config.php and install by visiting yourdomain.com/wp-admin/install.php

Use the Compatibility Check in W3 Total Cache to make sure everything is set up right. Yours will look similar to this one.

Set page cache and minify to disk enhanced. Object and database to APC. You can experiment with page cache via APC but with Nginx disk enhanced will most likely be faster.

Final thoughts

If your doing this for the first time set up a test install to get the hang of if before you rely on this for a production set up or client site. Using Debian and the apt-get repos it’s pretty easy to manage your own dedicated server or VPS and you can lose the cPanel training wheels. Not only will your page load times drop you will have a good feeling of accomplishment.

To maintain your packages run apt-get update and apt-get upgrade every once in a while and you can follow @dotdeb on Twitter to stay up to date with upgrades.

Feel free to leave a comment or question. I would love to hear how this set up works for you.

Resources and further reading

• The Nginx forums
• The Nginx Wiki
• .htaccess to Nginx rule converter
• W3 Total Cache – WordPress Optimization
• Mark Jaquith on Quora – Why is Nginx so efficient?
• SCALING, SERVERS, AND DEPLOYS — OH MY!
• The Official Ubuntu Server Book 2nd Edition

Your just finished reading WordPress Performance Server – Debian “squeeze” with Nginx, APC and PHP from the Dotdeb repos. For more resources like this go to C3M DIGITAL.

This post is in response to a write up entitled “Open Source Motivations” by long time WordPress developer, contributor and plugin author, Alex King.

Alex runs a successful and well known software and development consultancy firm, Crowd Favorite, along with WordPress Help Center, a specialized WordPress support center.

In the article Alex answers some tough questions about the motivations, financial gain (or lack of), and indirect financial benefits of writing, maintaining and supporting “free” WordPress Plugins. Alex’s response to the questions along with some of the reactions on Twitter suggest that the current situation is unsustainable for developers.

I disagree with this

I actually feel strongly that the current situation is unsustainable. Unless the WordPress community at large starts to better recognize and reward the developers that create the tools that they use and rely on, the developers won’t/can’t continue to provide as they have.

Why it might not be financially beneficial for large shops like his to continue developing and supporting free themes and plugins, it is very beneficial to individual developers like myself, and others whose release of free plugins and themes have brought them great financial gain.

How do you think developers like Alex and others got to where they are today?

I strongly believe that part of the success of Crowd Favorite was due to the contributions that were made to b2 and to the WordPress community. Others like Jason Schuller, Brian Gardner and Cory Miller attributed part of the success of their Premium Theme businesses to releasing free themes to the community. You can listen to the interviews and discussion about this very topic on Jeff Chandler’s WordPress Weekly episode 94.

Contributing to the WordPress community is a way for smaller developers to make a name for themselves, get experience and prove to potential clients that they know what their doing.

WordPress.org gives you the opportunity to put your product in front of millions of people. Currently I have only released one plugin, WP Coda Slider, on WordPress.org. My plugin is pretty simple and the only options available for it have to be put inside of a shortcode or through the use of a template tag but the response I have gotten has been great. Hosting the demo of and providing support for the plugin on WP-Performance gets me around 250 – 500 visitors a day.

In fact my simple little plugin has brought 8,267 visitors to my site since I released it back in September.

Website traffic may not be that big of a deal for the well known players in the WordPress development community but it has offered me the opportunity to expose my WordPress support and development services to a great number of people. In the last three months I have gotten around 4 or 5 new really good clients who found me through my plugin. I also find it very rewarding to help others and I am amazed that people are actually using software I created on their websites.

One of the most troubling parts of Alex’s article is his sentiment towards the users of his products:

In talking with other plugin developers, it seems fairly universal that the reward for a successful plugin is a deluge of support email that includes the worst kind of sense of entitlement, rudeness and ignorance. The community as a whole seems to expect to be able to pay nothing, yet received expert and individual help and support for free.

I completely disagree that the community as a whole has this type of entitlement.

I am sure there are those out there who don’t understand how much work and effort developers like Alex put into a free product but I have found that a majority of the community is very appreciative and also very polite when it comes to getting support for a free plugin. Any time I have offered free help or support to other WordPress uses it has been a very pleasurable experience. See for yourself on my plugins support page. Almost every single request contains a thank you and is very polite. The same is true when I answer questions in the WordPress.org support forums or on Stack Exchanges WordPress Answers site.

I used to get about $100-200/month in the way of donations through my website. Unfortunately due to changes in the way plugins are presented on WordPress.org that has dried up to about $5/month.

Ask any Plugin author about the “donations” they have received for their work and they will laugh because donations for WordPress Plugins have almost always been non existent. If your counting on donations to make it or to feel appreciated then the “FREE” Plugin business is not for you. This is not the fault of WordPress.org’s new plugin page design this is how it will always be.

It is very understandable that busy dev shops with payrolls to make and lots of clients to keep them busy don’t have the time, energy, resources or find it rewarding enough to contribute then thats fine. There are plenty others who do and are thankful for the opportunity to contribute and without an open source community like WordPress none of you would be in business today.

Thanks for taking the time to read this and I welcome your thoughts and comments below.

UPDATE: There has been a lot of discussion on this topic including a great post by Jeff Chandler

Your just finished reading Response to "Open Source Motivations". For more resources like this go to C3M DIGITAL.

I recently answered a question over at WordPress Answers, Stack Exchanges new WordPress question and answer site, about best practices for using a caching plugin with a shared host.

Not all WordPress users are able to host their blog or website on a private server or VPS and need a way to speed up their websites. There are a few great WordPress caching plugins like WP Super Cache and W3 Total Cache. Both plugins are very popular, well supported by their authors and do a good job of caching.

WP Super Cache is developed and supported by Donncha O Caoimh who is a member of the Automattic team and a core WordPress contributor.

W3 Total Cache was originally developed for Mashable.com by their CTO, Frederick Townes .

W3 Total Cache is much more than a caching plugin. Along with page caching, W3 also does object caching, database caching, minifies and combines css and js files and also has built in CDN (Content Delivery Network) support. This is the only plugin available that tackles all the best practices of High Performance Websites

On shared hosting plans your caching options are limited.

You will only be able to statically cache the html output from your pages. This is the fastest way to serve pages but you loose the dynamic aspects of WordPress like making comments and seeing the latest comments on posts.

There are disk caching options available in W3 Total Cache for objects and database but for object caching you will only see gains if your host is running fast drives and most sites have far too many queries per page (due to poorly written plugins) to see any advantage from database disk caching.

When the plugin is first activated the recommended settings will already be in place.

How to Configure the plugin for best performance on a shared hosting plan

This article will go through all the steps of setting up the plugin to get the best performance gains on a shared host. If your on a VPS or private server you will have a lot more features to work with like using a PHP opcode cache and caching database queries in memory.

Page Cache Settings

Check all the options for page cache

Cache Preload

Turn this on and set the update interval at what ever is appropriate for your site. This will rebuild the page cache at the given interval.

Minify Settings

Select Rewrite url structure and if your going to use the CDN check the auto upload so newly minified files will automatically get uploaded to the CDN.

Minify HTML Settings

Enable and check remove line breaks, inline js and css minification. If your using adsense or another service that uses comment stems enter them here to avoid having them minified.

CSS and Javascript Minify Settings

In the file management choose your theme and add any css files you want combined and minified. There is also a help wizard that will search all your templates and add the suggested files for you.

Using The Help Wizard

W3 Total includes a tool that goes through your theme templates and finds Javascript and CSS files that are used and provides recommended settings. First try theses settings and if problems are encountered go back and modify as needed. Any files highlighted in red are files you have already included to be minified.

The minify settings give you the option of placing the minified files in different locations. After <head>, after <body> and before </body>. It is best to put as many as you can before </body>. If any plugins add inline js you won’t be able to use before </body> for jquery or the plugins js because it will need to load before any inline <script> tags. You can include any combinations of files in each location and for each template. For instance you can set your comment-reply.js to only load on single.php

Browser Cache Settings

This is the most important one to get right. If you properly cache your static content in your users browsers you can drastically reduce page load times and reduce bandwidth usage.

General

Check everything. Make sure and check “do not process 404 errors for static objects”. browser cache settings is a big win for shared hosting because invoking PHP and returning 404 pages to bots etc is a big drain on resources and this feature prevents that.

CSS and Javascript Browser Cache Settings

Check everything and set expires header lifetime to far future. 31536000 seconds is 1 year and what yslow recommends. If you make changes to your css or javascript you have to change the file names to prevent users from using the old version. If your using minify you won’t have to worry about serving outdated content because W3 takes care of changing the name of the minified file for you.

Set your cache Control policy to cache with max age.

There are two more browser cache setting sections. HTMl and Images. For Images use the same settings as CSS and JS.

For HTML don’t set expires unless your site is mainly static. You can use short lifetimes if you want (180 seconds) but I wouldn’t go higher. Enable gzip and you can check “set W3 Headers” so you can check the response headers to make sure they are working.

CDN Settings

CDN is one of the largest performance wins for any hosting scenario even if self-hosted. W3 Total has built in support for popular origin pull and origin push CDN’s and a robust self hosted option that requires you to set up subdomains and cnames. Note: Do not check force override unless new files are being overwritten. Force override will constantly re-upload files even if they already exist. This wastes bandwidth and resources.

Self hosted CDN will let you take advantage of pipelining. Browsers can only download a few files at once, only 4 in some cases. Pipelining is a technique whereby aliases (subdomains for example) of your server are used to allow your browser to increase the practical limit of files that can be downloaded in parallel. Doing so maximizes the throughput of the your internet connection and allows the browser to render a page faster. W3TC takes care of managing these files transparently once DNS CNAMEs (aliases) and subdomains are properly configured.

Support

W3 Total Cache is one of the best supported plugins on the WordPress.org plugin repository. The author responds to all questions tagged w3-total-cache and a support tab is also included in the plugin to use for reporting bugs.

Testing

You should always test your results and tweak your settings accordingly. I like to use WebPageTest.org. To compare my results and identify any potential problems.

How much can you increase your performance using W3 Total Cache on WordPress with shared hosting?

I recently helped a client reduce his page load times from almost 10 seconds to 3 seconds by implementing these settings on his WordPress blog.

Before:

As you can see by the waterfall image he was loading javascript before css which causes a blocking condition. Blocking is when the loading of a script or file makes all other requests wait until it is fully downloaded. He also had 50 external file requests and some 404 errors.

After installing and configuring W3 Total Cache

These results are not perfect but they are a dramatic improvement over what they were. We reduced the total time to load the page from 10 seconds to 3 seconds. By combining and removing the javascript to the bottom we reduced the Start Render time from 3.5 seconds to .45 seconds. The start render time is very important because it indicates when the page starts becoming viewable in the browser. This progressive rendering effect gives the illusion of instant page loads because the user doesn’t notice there are still files being loaded in the background below the fold.

Conclusion

W3 Total Cache is the best choice for a caching plugin because it has so many more features than just caching. What has your experience been with W3 Total Cache or other web performance solutions? I would love to hear some of your best practice tips lets discuss this further in the comments.

Other Performance Resources

Optimizing WordPress for Performance, my WordCamp Houston presentation.
How to add a re tweet button in an Iframe after the page loads for better performance
The Quest for Speed   by Frederick Townes

Your just finished reading Reduce Page Loading Time by 300% With W3 Total Cache. For more resources like this go to C3M DIGITAL.

One of the topics discussed in my WordCamp Houston Presentation, Optimizing For Performance, was putting social media share buttons in an iframe to improve page rendering. I thought it would be helpful to describe in more detail how to accomplish this.

Since Facebook already does a pretty good job of putting their widget code in an iframe we will use the TweetMeMe Re-Tweet button for this example. If you were to just put the code directly in an iframe it wouldn’t help much because Javascript embedded in an iframe will block the rest of the page from loading until it was complete.

To accomplish our goal of progressive page rendering we will need to start with a div placeholder for our iframe code and write a short Javascript function to add the iframe code to our placeholder div once the page has completely loaded. This is the same method Fredrick Townes, creator of the W3-Total Cache plugin and CTO of Mashable.com, uses to place the buttons on Mashable.

First we need to add our div placeholder to our template files where we want the Tweetmeme button to appear. In this case we will use div id=”tm_box” then close the div.

Next we will need to build our iframe src variable.

1. Start with the button.js url that Tweetmeme provides in their embed code:

http://api.tweetmeme.com/button.js

2. Add

?url= 

followed by the page url (for now we will add URL as a placeholder because we will want the url to be whatever page the button is placed on).
3. Add &style= followed by what button style you will want to use. Either normal or compact.
4. Add &source= followed by your Twitter username.
5. Add &service= followed by a URL shortening service for ease of use we will use the bit.ly service see the Tweetmeme api reference on how to add other services.

Your completed src variable will look something like this:

http://api.tweetmeme.com/button.js?url=URL&style=normal&source=Chris_Olbekson&service=bit.ly

Now we will set the width and height attributes:

For the normal style button: width="50" height="61"
For the compact style button width="90" height="20"

Now that we have all our variable our iframe code will look something like this:

<iframe src="http://api.tweetmeme.com/button.js?url=URL&style=normal&source=Chris_Olbekson&service=bit.ly" scrolling="no" frameborder="0" width="50" height="61" ></iframe>

Now to convert your iframe code from html to JavaScript you can use this simple online HTML to JavaScript Converter

Next we need a JavaScript function get the current page url. We will use the escape() function just like TweetMeme uses in its button.js and we will add window.onload = tweetMemeButton which will fire the code after the page is completely loaded.

Here is our completed JavaScript which we can save as an external file and call it in header.php or footer.php (It won’t matter where we call it because it won’t fire till the page is loaded).

function tweetMemeButton() {
	if (document.getElementById("tm_box")) {
		var iframeCode= "";
iframeCode += "<iframe src="http://api.tweetmeme.com/button.js?url=" + escape(document.URL) + "&style=normal&source=chris_olbekson &service=bit.ly" scrolling="no" frameborder="0" width="50" height="61" >";

		document.getElementById("tm_box").innerHTML = iframeCode;
	}
}

window.onload = tweetMemeButton;

This code is used to add the TweetMeMe Re-Tweet button at the end of this post.

**Update: 08/12/2020
Twitter just announced the release of their new tweet button. I will be evaluating the performance over the next few days.

Your just finished reading Add a Re-Tweet Button in an Iframe for Faster Page Loads. For more resources like this go to C3M DIGITAL.