I just found this handy snippet out there in the ether, to get rid of the gamma and colour profile info from PNGs.

pngcrush -d outputdir -rem gAMA -rem cHRM -rem iCCP *.png

pngcrush also optimizes the file and reduces the size, which is nice. Handy little tool.

SSL: using SSL with Nginx is not as simple as just turning on the HTTPS section from the default/example config file and copying over the location directives from the port 80 section. You need to ensure that the PHP fastcgi knows that HTTPS is on, so add the directive:

fastcgi_param HTTPS on;

to your location ~ \.php$ section.

Queries: if you are using a forms plugin, or something else that sends GET requests, you may find that they don’t work. Change your default rewrite to:

try_files $uri $uri/ /index.php?$args;

Security: if you are using php5-fpm (you should be!) then it is quite possible to execute remote php files. We don’t want that! Add this line to your php section:

try_files $uri = 404;

Suhosin: you may want to use the Suhosin patch (I do), but this can cause problems with file uploads (and phpMyAdmin). Add the following to your php.ini:

suhosin.post.max_array_index_length = 256
suhosin.post.max_totalname_length = 65535
suhosin.post.max_vars = 1024
suhosin.request.max_array_index_length = 256
suhosin.request.max_totalname_length = 65535
suhosin.request.max_vars = 1024

I added this in /etc/php5/conf.d/suhosin.ini, but you may wish to add it elsewhere.

Nginx + php5-fpm + APC + memcache is a super speedy combination. I use it everywhere now. But it does take a bit of getting used to if you are accustomed to Apache.

Just as an afterthought, the docs for setting up WordPress on Nginx in the codex suggest that unless you use APC and a WordPress caching plugin, you will get no performance benefit over Apache. This is utter drivel. Yes I highly recommend APC – it’s great – but you can use it on Apache too. Nginx is fundamentally faster than Apache, even if you compare apples with apples and set up Apache with fastcgi instead of the more common mod_php. This is because Nginx uses an asynchronous, event driven architecture, thus using significantly less resources. It is all explained here.

1. You should never use inline styles.
2. WordPress normally leaves styling to the themes (as it should).
3. Even if you wanted this behaviour, padding would have been more appropriate.

So how do we fix it? Well I just spent a while searching and found a few ill thought out suggestions, like overriding the style with !important (doesn’t work on all browsers and could cause problems if you want to override it again in a specific class) or replacing the shortcode function, either directly in wp-includes/media.php (just plain crazy) or in your functions.php (better but doesn’t work too well and not very maintainable). This last idea did lead me to find a good solution though. The img_caption_shortcode function has a filter, which effectively overrides its own output. So here’s what I used (tested on WP 3.1):

add_filter( 'img_caption_shortcode', 'my_img_caption', 10, 3 );

function my_img_caption( $nowt, $attr, $content )
{
	extract( shortcode_atts( array(
		'id' => '',
		'align' => 'alignnone',
		'width' => '',
		'caption' => '',
	), $attr ) );

	if ( empty( $caption ) )
		return $content;

	if ( $id )
		$id = 'id="' . esc_attr( $id ) . '" ';

	return '<div ' . $id . 'class="wp-caption ' . esc_attr( $align ) .
		'">' . do_shortcode( $content ) . '<p class="wp-caption-text">' .
		$caption . '</p></div>';
}

Shove that in your theme’s functions.php and it will replace the core caption function, with the inline style removed. If you’re wondering what the $nowt variable is about, it is an unused blank string passed by the filter.

Sounds perfect? We shall see. I shall test it out soon. On this very blog…

./setup

You will be asked for your password, as the script requires sudo. Then plug in your printer. You may then need to add it manually via the printer configuration tool.

Anyway to fix the browsing issue type:
cupsctl BrowseProtocols='"cups dnssd"'
in your much neglected OSX terminal.

Job done.

I created a test page to check the Javascript method required: document.formname.submit() or document.forms['formID'].submit() (my Javascript is a little rusty because, I’m glad to say, I rarely use it). This worked fine, so I added the little bit of code to the real page. It promptly refused to work. No matter what I tried, it wouldn’t auto-submit, and the debug console said "document.formname.submit is not a function". How bizzare! No end of googling could find an answer. The code was right, according to all sources. I changed names of the form and added IDs galore, but no joy.

Then it hit me – the submit button in the form (I included one for those who might have no Javascript, or Javascript turned off) had the name attribute of "submit"! This meant that the submit button was the object: document.formname.submit , but I was trying to execute the method: document.formname.submit() . Javascript can’t cope with one object and a method of another object, having the same name. As soon as I changed the name of the submit button, all was well. It worked!

What a load of hassle for such a tiny error. So remember, when you give your form elements names or IDs, make sure they are different from the element tag. A good practice is to give the form a generic name, such as "mysite_signup" and then name its child elements with the formname as the prefix. So, an input field might be "mysite_signup_email_address", and the submit button might be "mysite_signup_submit". Unique naming baby – it’s the way forward.