Drupal 6 node.save uses different methods for saving taxonomy for different taxonomy types.

For multiple select based taxonomy:

(php)

$nodeObj->taxonomy = array(2=>array(15,19));

(python)

nodeOb['taxonomy']['2'] = [15,19]

For tags based taxonomy:

(php)

$nodeObj->taxonomy = array(
  'tags' => array(
         2=>'military,navy'
   )
);

Nginx fastcgi cache with php-fpm can be a super fast of serving WordPress Mu.

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  /vol/nginx_logs/jollypeople_sphp_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 /vol/home/jollypeo/public_html$fastcgi_script_name;
	include        /usr/local/nginx/conf/fastcgi_params;
}

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

}

Assuming you’ve downloaded ./configure && make && make install the latest nginx and have mysql, svn already installed. More info on installing svn and setting up svn here.

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.

Magento is a steaming pile of turd.

I’ve developed for WordPress, Drupal, Magento, and Joomla so feel I can provide a reasonably educated opinion on opensource php cms.

Magento is good in theory but in action its bloatware.

Magento is unnecessarily complicated with far too many files, like Joomla. It’s even slower than Joomla. It’s pitifully slow despite claims that it has been optimized. For clients there is more hand holding. The learning curve is too much for your clients, like Joomla.

WordPress easily has the most elegant and practical code and its easy for clients to manage their content. Next is Drupal. After that there’s daylight and then there’s Magento and Joomla.

The WordPress object design, database structure, and database api are refined to a level of efficiency the others could only dream of at the moment. WordPress is a framework that can be used for the majority of content serving tasks. (With Facebook and Twitter API’s in-house social media modules are not so important)

Out of the mainstream Opensource PHP Carts I currently like Ubercart which is a Drupal module. But even that has its downsides. That’s why I’m going to build a cart which uses WordPress as the framework and makes no manipulations to the WordPress database table structure.

WordPress Classes and API’s are all there

If you look at WordPress carefully all the api’s and classes are mostly there to build a far more efficient cart. Despite this, no one has done it yet with a plugin. They haven’t looked at the code closely enough to realize that the way the database, and objects/classes work… well everything is already there for the core requirements to create an easy to use and install cart.

WordPress is Scalable

WordPress.com is a Mu WordPress install which is one of the top 20 biggest sites on the internet at the moment. WordPress.com, built on the core of WordPress servers visitors that any of the alternatives could only dream of. Why?

Because WordPress is efficient in both its code, it’s database structure, and it has the best built-in caching.

I bet there are a few frustrated designer/part-time coders that are already frustrated enough to be looking for an easy alternative to Magento. Plenty agree that Magento is bloatware.

I’ve bought a domain and I’m going to start work on Api Cart. The WordPress Cart plugin which is going to bring the smack down on all other PHP Opensource carts!

import email, getpass, imaplib, os

detach_dir = '.'

### directory where to save attachments (default: current)

m = imaplib.IMAP4_SSL('imap.gmail.com', 993)
m.login('username@gmail.com','password')
keywordsSearch = 'bananas oranges'
searchString = "(ALL SUBJECT '%s')" % keywordsSearch

### m.search(None, "(ALL SUBJECT 'bananas oranges')")
resp, items = m.search(None, searchString)
items = items[0].split()
for emailid in items:
    resp, data = m.fetch(emailid, "(RFC822)")
    email_body = data[0][1]
    mail = email.message_from_string(email_body)
    if mail.get_content_maintype() != 'multipart':
        continue
    print "["+mail["From"]+"] :" + mail["Subject"]
    for part in mail.walk():
        if part.get_content_maintype() == 'multipart':
            continue
        if part.get('Content-Disposition') is None:
            continue
        filename = part.get_filename()
        counter = 1
        if not filename:
            filename = 'part-%03d%s' % (counter, 'bin')
            counter += 1
        att_path = os.path.join(detach_dir, filename)
        if not os.path.isfile(att_path) :
            fp = open(att_path, 'wb')
            fp.write(part.get_payload(decode=True))
            fp.close()

There is an issue with Drupal 6 menu router rebuild which causes Drupal to time out with 404 pages or internal 500.

The following fix worked for me:

Install Drupal Tweaks, increase php memory, and mysql recommendations etc

http://drupal.org/project/drupal_tweaks

Download the following patches:

http://drupal.org/node/251792#comment-1831346

http://drupal.org/node/317775#comment-1491208

From command line copy patches to your root drupal directory.

cd to your root drupal directory and then apply the patches. Each time you will be asked where the file is for the patch and the actual path to the files to be patched will be provided in the command line. Just copy and paste each file path as presented into the prompt.


cp *.patch /home/drupal_directory/
cd /home/drupal_directory/
patch < no-router-blob-317775-56-D6.patch
patch < lock-251792-163-D6.patch

So in the above text you can see it gives you the path ‘includes/bootstrap.inc’. Just copy and paste that to where it says ‘File to patch:’. For each file it will provide you the correct path to the file assuming you are in the drupal root directory.

The final thing to do is to cp the lock.inc file which is created to includes/

Thematic is a pretty cool theme development framework for WordPress although I believe it can be improved.

One great thing about thematic is the ability to create css based on the template file.

For example, the single.php template will include the css class ’single’ in the body classes of the html:


<body class="... ... single ...">


The dog-page-template.php, a custom page template will include:


<body class="... ... dog-page-template ...">


So if you want to customize any links for those specific pages you simply place:


body.single a {}
body.dog-page-template a {}


The fix (change to whatever language or version of english you’re using eg en_GB):

apt-get install language-pack-en-base


export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
locale-gen en_US.UTF-8
dpkg-reconfigure locales


If you get the following warning below for apt-get or dpkg in ubuntu:

perl: warning: Please check that your locale settings ubuntu

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = “en_US.UTF-8″,
LC_ALL = “en_US.UTF-8″,
LANG = “en_US.UTF-8″
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

First install imagemagick.

sudo apt-get install imagemagick

Then cd to your folder with your jpg images and type the following:

mogrify -quality 75 *jpg

Image optimization quality is defined by the number after -quality. In this example 75%.

Sometimes wordpress plugins can interfere with the basic functionality of wordpress such as uploading files.

One plugins was preventing a jquery action occuring to reveal an image which had been uploaded with the wordpress image loader.  The file was there, but you couldn’t send it to the browser.