See http://wordpress.org/support/topic/364929 and effectively the ‘patch’ on the Google Support forum thing which works fine (there are two bits of the plugin which need updating – whcih correlate to the two parts mentioned in the posting etc)

Bit annoyed that the fix is so easy – yet the plugin hasn’t been updated yet. Grr.

We persistently got the same error (e.g. Fatal error: SOAP-ERROR: Encoding: object hasn’t ‘SortResults’ property in ….) yet the generated WSDL file (when viewed through a web browser etc) no longer has SortResults in it.

We checked :

• Proxy settings,
• Apache configuration (and restarted Apache)
• svn reverted files
• DNS and more.

Then it turned out the SoapClient PHP object caches the WSDL file by default in e.g. /tmp/wsdl-blahblahblah. (Where blahblahblah looks very much like an md5). And it doesn’t make much of an effort to check it’s validity. Obviously the documentation does state this, but it does seem like the wrong default behaviour to me.

Solution: Add something to the automated tests to delete /tmp/wsdl-*. OR pass into the SoapClient constructor an array of options like :

$client = new SoapClient('http://somewhere/blah.php?wsdl", array(cache_wsdl => WSDL_CACHE_NONE)

Time wasted: Too much.

Anyway, yesterday I had a referral for someone who has two fairly busy websites (anorak.co.uk / whoateallthepies.tv) sat on a fairly beefy server (8 core, 16g of ram… oh in a few years that’ll be entry level… but I digress)… anyway, they were having performance difficulties with one site – a bit of investigation found the problem to be related to their migration from one server to another – rinetd was directing traffic from the old server, but had filled the filesystem up and was consuming all cpu time …… Easy enough to fix. Job done. Everything started working again.

After a bit more investigation I found that the two sites needed updates applying and plugins upgraded, and they had no backup job in place *doh* …. Clone the site, whizz through the wordpress upgrade routine on the clone, get the customer to OK it (he did) and then we did it on the live server…. and it looked like a success. Until an hour after I’d done the update and the customer realised part of his front page was missing….

Great. Just what I’d hoped to avoid – delving into wordpress’s code.

On opening up the theme’s index.php file it was easy to see where the content should be –  add in some debugging on the clone – and “Oh look – that ‘thing’ is empty.. it should contain ’stuff’….”

Turns out there’s a WP_Query class; and it seems Wordpress 2.9.x treats it’s query slightly differently to previous versions – ‘they’ used category_name=blah as a parameter – this no longer works, instead it needed changing to cat=1234 .. bingo, data returned; site fixed; customer happy.

I breathed a big sigh of relief. I was worried that they previous developers had made some weird customisation to wordpress core which I’d have to forward port and debug/fix.

Being the nice chap I am, I also installed xcache onto the server to help PHP out – I suspect they could cut their hardware ‘allocation’ by half and still have ample capacity to serve the sites. A few days with munin running and I’ll know for certain. Perhaps they’ll appreciate the cost saving?

Installed .deb from here

# wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin_2.3_all.deb/download

....

# dpkg -i postfixadmin_2.3_all.deb

... dpkg moans about missing dependencies

Selecting previously deselected package postfixadmin.(Reading database ... 38632 files and directories currently installed.)Unpacking postfixadmin (from postfixadmin_2.3_all.deb) ...dpkg: dependency problems prevent configuration of postfixadmin: postfixadmin depends on dbconfig-common; however:  Package dbconfig-common is not installed. postfixadmin depends on wwwconfig-common; however:  Package wwwconfig-common is not installed. postfixadmin depends on php5-imap; however:  Package php5-imap is not installed.dpkg: error processing postfixadmin (--install): dependency problems - leaving unconfiguredErrors were encountered while processing: postfixadmin

# apt-get -f install

(dependencies now get installed...)

…. Goes into the Postfixadmin .deb installer thing.

• Tell it to use Apache2 (in my case) as the webserver,
• Give it the ‘root’ user’s database password (if MySQL).
• Tell it to generate a password for the postfixadmin user…
• Tell it to use the package maintainers version of /etc/postfixadmin/config.inc.php (well I did).

I think something went wrong for me – as I needed to do this afterwards; perhaps you’ll have better luck.

# mv /etc/postfixadmin/config.inc.php.ucf-dist /etc/postfixadmin/config.inc.php

Next, goto http://yourserver/postfixadmin/setup.php – you should see lots of text saying how it’s updating the database to version xyz, xyz+1 etc.

Choose a password to protect the setup.php page; press submit, and you’ll be presented with a ‘hash’ – copy and paste this into the config.inc.php file – so you get something like this on line 32 :

$CONF['setup_password'] = ‘my long hash thingy goes in here’;

Next, create a super admin account, using the setup.php page – remembering to type in the setup password you used to create the hash above.

That’s it.

(Well, now you need to configure Postfix and/or courier and/or dovecot etc etc)

You might want to read my other article which covers this…