You need to change the following file /components/com_sef/sef_ext/com_k2.php.

The following getItemTitle function in the SefExt_com_k2 class needs to be replaced with this function:

    function getItemTitle($id){

        $database =& JFactory::getDBO();

	if(preg_match('!:!', $id)) {

	    $idExplode = explode(':', $id);

	    $id = intval($id[0]);

	};

        $database->setQuery("SELECT `title`, `alias`, `catid` FROM `#__k2_items` WHERE `id` = $id");

        $item = $database->loadObject();

		$cat = $this->getCategoryTitle($item->catid);

		$name = $item->alias;

		array_push($cat, $name);

		return $cat;

    }

Nginx WordPress Mu FastCgi_Cache Conf Rewrites are an interesting thing to get set up because of the cookie situation. You also don’t want to have wp-admin php files cached either.

One of the problems with mu supercache is it doesn’t have very good support for Nginx. By default I think the latest version turns off the supercache portion if it cannot detect the apache mod_rewrite module or htaccess file. This means supercache is automatically turned off for nginx servers.

The Nginx fastcgi_cache is blistering fast and makes supercache redundant for Nginx users.

Usually Nginx caches a response depending on whether you have added “X-Accel-Expires: 0″ in the response with the cookie. Then you include the cookie in your key. This seemed unnecessarily complicated to set up on the wordpress side. It did require a bit of lateral thinking to get something quick n dirty up and working that avoided the above approach.

Really the only content you want nginx fastcgi cached is any permalink running off /index.php the wordpress controller for all published page requests. I couldn’t get try_files working so I just flagged the rest. This set up is for cache to expire after one day for successful 302 and 200 requests.

Step One:

The first step is in the root folder of your Mu WordPress folder make a copy of your index.php file which is the wordpress controller and call it second_index.php.

example:

/home/mu/public_html/index.php
/home/mu/public_html/second_index.php

Of course in your root wordpress folder there will be all the standard other wordpress files and folders.

Step Two:

In the main http { } area of your nginx create an area where the cached files are to be stored:

http {

fastcgi_cache_path  /var/nginx_cache levels=1:2 keys_zone=one:100m inactive=7d max_size=4g;

...
...
...
}

The above configuration sets the path to where the cache will be stored. Level’s is the number of folders to use for the cache.

keys_zone is the name of the zone which you will specify in your fast_cgi parameters and 100m means that nginx will use up to 100m for to store the key values.

Inactive is the time that the cache file will stay in the cache inactive before its deleted. I’ve set this to a long time because I’d like to have static files cached for up to 7 days.

max_size is the size of the maximum cache size. I’ve set 4 gigabytes.

The cached files are stored as binary files. The key of the file is written in the binary file before the headers and the content. The file name of the cached fastcgi request is an md5 of the url. For example ‘bookmarks.honewatson.com/2009/09/02/nginx-wordpress-mu-fastcgi_cache-conf-rewrites/’ filename is 119a34a0e9e5817140836ffb44883df1. Using this knowledge I suppose a plugin could be written to grep through and delete the cache file if it is edited or comments are added.

Step Three:

Create a configuration that will direct all non-logged in cookie users to a location where requests are cached. For all other php files, do not cache. You don’t want to fastcgi_cache files of logged in users. No php files in wp-admin are cached. Any requests of logged in users are sent to second_index.php which is not cached. They can see regularly updated comments. You could also set it up so the cache time is much lower for logged in users. Maybe 5 minutes. I’ll include a second configuration down the bottom for this.

This means you get far greater control than you would with supercache.

So here is something that is working for me:

location / {
            	root   /home/mu/public_html;
            	index index.php;
		if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
			error_page       404 = /second_index.php?q=$uri;

		}
	    	error_page       404 = /index.php?q=$uri;
}

location ~ /index\.php.*$ {
	fastcgi_cache_key $host$request_uri;
	fastcgi_cache_valid 200 302 1d;
	fastcgi_cache_valid 301 7d;
	fastcgi_cache_valid any 5m;
	fastcgi_cache_use_stale off;
	fastcgi_cache one;
	fastcgi_ignore_headers  Cache-Control  Expires;
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

location ~ \.php$ {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

Second configuration:

1. Cache any 200 or 302 published content requests from anonymous users for 1 day.
2. Cache any 200 or 302 published content requests for logged in users for 5 minutes.
3. Don’t cache any other php files.

location / {
            	root   /home/mu/public_html;
            	index index.php;
		if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
			error_page       404 = /second_index.php?q=$uri;

		}
	    	error_page       404 = /index.php?q=$uri;
}

location ~ /index\.php.*$ {
	fastcgi_cache_key $host$request_uri;
	fastcgi_cache_valid 200 302 1d;
	fastcgi_cache_valid 301 7d;
	fastcgi_cache_valid any 5m;
	fastcgi_cache_use_stale off;
	fastcgi_cache one;
	fastcgi_ignore_headers  Cache-Control  Expires;
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

location ~ /second_index\.php.*$ {
	fastcgi_cache_key $host$request_uri;
	fastcgi_cache_valid 200 302 5m;
	fastcgi_cache_valid 301 1d;
	fastcgi_cache_valid any 5m;
	fastcgi_cache_use_stale off;
	fastcgi_cache one;
	fastcgi_ignore_headers  Cache-Control  Expires;
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

location ~ \.php$ {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

Third configuration:

1. Cache uploaded files for 7 days – slip this extra configuration in before the all other php files location.

location ~ /wp-content/blogs\.php.*$ {
access_log  /nginx_logs/muimagesphp_cache.access.log small_php;
fastcgi_read_timeout 10;
fastcgi_cache_key $host$request_uri;
	fastcgi_cache_valid 200 302 7d;
	fastcgi_cache_valid 301 7d;
       fastcgi_cache_valid 504 1s;
	fastcgi_cache_valid any 5m;
	fastcgi_cache_use_stale off;
	fastcgi_cache one;
	fastcgi_ignore_headers  Cache-Control  Expires;
	fastcgi_pass   127.0.0.1:8084;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME /home/mu/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

location ~ \.php$ {
...
... etc

}

apt-get install trac
apt-get install python-mysqldb

Now once I’ll assume you’ve set up an svn repostitory in /home/svn/myproject.

trac-admin /home/trac/myproject initenv #fill in details here assume project name is myproject
htdigest -c /home/trac/myproject.passwd myproject.com my_username
trac-admin /home/trac/myproject permission add my_username TRAC_ADMIN
chown -R www-data /home/trac/myproject
sudo -u www-data tracd -d -p 3110 --auth=myproject,/home/trac/myproject.passwd,myproject.com /home/trac/myproject

Now you have a tracd server daemonized.

Now add an nginx conf file in your nginx conf directory:

 upstream live_trachosts_com {
          server  127.0.0.1:3110;
  }

  server {
          listen          80;
          server_name     myproject.com;
          location / {
                rewrite ^/$ /myproject last;
                  proxy_pass      http://live_trachosts_com;
          }

  }

Now restart/reload Nginx.

Let’s say you have mounted the new volume on /dev/sdh at the mount point /vol on an xfs partition. Note you need to have the new volume mounted already.

Type into your terminal:


xfs_growfs -d /vol


The above will expand space out to the maximum available. Also if you cannot umount your old elastic block volume so you can detach and attach your new volume try the following:


umount -l /vol
umount -f /vol


You can use the php-fpm init.d script below. You need to change the variables at the start for your bin, conf, and pid to suit your set up.  PHP-FPM works great with Nginx.

Not sure if WordPress will format this script right so you can get as a text file here:

http://images.honewatson.com/random_files/php-fpm.txt

#! /bin/sh

esac

Saturated fat isn’t bad but wild game had much lower fat and a higher omega 3 content with a lower saturated fat in the profile.

svn import /home/myfiles/source file:///home/svn/myrepository -m “initial import”

The first directory after ‘import’ are where all your code are. file:/// is where the repository will be located.

Here is a handy tutorial.

Starting an svnserve daemon:

svnserve -d –listen-port=xxxx -r /home/svn/repository

Now test it out with a list:

svn ls svn://yy.yyy.yy.yy:xxxx
(where yy is your ip address xx is your port.)

Nassim Taleb will talk at an upcoming seminar.