Posts Tagged ‘Wordpress’

Talk: Introduction to WordPress Plugins

Wednesday, August 5th, 2009

Last night I gave my first pukka pecha kucha talk at the monthly PHPNW. The talk is a lightning talk with 20 slides with 20 seconds a slide. I.e. 6 minutes 40 seconds in total. Since I hadn’t even decided I was going to talk until last Friday and I had no talk prepared I was still preparing the slides on the train to Manchester where the meetings are held.

I didn’t have a VGA adapter for my MacBook and had to borrow one to connect it to the project. I think I need to buy one. I bought a DVI adapter when I bought the machine but not the VGA one as I thought who needs them with modern monitors. But of course most projectors have VGA only connections so such adapters are a necessary component of the presenter’s toolkit.

The talk seemed to go well and was appreciated by the audience and plugins seemed to be my topic of conversation for the rest of the evening. There was some interest in my WordPress Coppermine Widget plugin and techniques I had used in the Javascript for it. I think this will become the subject of another blog post.

I went a little awry with my mental arithmetic and ran over by about a minute. When Lornajane gave her talk she had the slides change automatically after 20 seconds so you know when the talking time for a slide is up. I will steal this idea!

My slides are available as a PDF download.

WordPress Automatic Update Bug – Follow Up

Thursday, July 16th, 2009

The bug I raised on WordPress yesterday as documented in this blog post has been closed as a ‘duplicate’.

Looking through the bugs about a month ago someone else raised a very similar bug report and proposed a very similar solution. That bug report was closed with ‘wontfix’. The basic comment is that (a) they know about it; (b) they think changing the behaviour will break shared hosting; (c) group write support is not supported in WordPress anyway.

The comments in the bug do confirm something I spotted yesterday when looking at the latest release revision of wp-admin/includes/file.php which is that you can completely over-ride the write checking mechanism in WordPress 2.8 and above if you define the constant FS_METHOD to be ‘direct’. A bit hacky but useful. It means I can use decent permissions and still use auto-update. Time to upgrade to 2.8.1 I think.

WordPress Automatic Update Bug

Wednesday, July 15th, 2009

LornaJane wrote an article on her blog about WordPress automatic update asking for FTP. As I’ve been having problems with the automatic update too and since I also don’t want to install FTP I changed permissions as she suggested. Unfortunately, even with ‘other’ (world) write permissions, I was still being asked for FTP details. After some discussion on IRC it turns out that not only do you need the right permissions but you need the files with the right owner i.e. the Apache process. This didn’t seem right. Why an earth do you need the right ownership if you can write anyway. Also if you have to have the files owned by the Apache process any scripting running on the server can access and change the files. Its a security risk. So I decided to dig deeper.

Grepping the WordPress source for the text line ‘There was an error connecting to the server, Please verify the settings are correct.’ showed me the relevant code is in wp-admin/includes/file.php. The function that requests the FTP details is request_filesystem_credentials(). This function is called if get_filesystem_method() returns a method other than ‘direct’. It seemed that get_filesystem_method() was at fault. The relevant code snippet is below.

        $method = false;
        if( function_exists('getmyuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( getmyuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        }

Examining the function it seems that it tries to creates temporary file (typically in wp-content) and if successful compares the ownership of that file with the process. If equivalent it decides that it can use ‘direct’ mode. The problem is it uses getmyuid() which according to the documentation returns the owner of the file that called the function and not the owner of the process running the code. I.e. the owner of wp-admin/includes/file.php. It doesn’t matter who the owner of the apache process is. There is another function
posix_getuid() which returns the process owner. So I have modified the get_filesystem_method() function as follows:

        $method = false;
        if( function_exists('posix_getuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( posix_getuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        } else if( function_exists('getmyuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( getmyuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        }

I.e it checks to see if posix_getuid() is supported and if it is it uses that instead. This allows me to have my WordPress files owned by a different owner than the apache process. I have set the wp-content to a member of a group containing the apache process owner and made them group writeable. As long as apache can write the temp file WordPress can use automatic update. This is still some what insecure but better than having all the WordPress files either owner by the apache process or world writeable.

Note that I am currently running WordPress 2.7.1. Looking at WordPress 2.8.1 the get_filesystem_method() function has changed but not significantly. I am raising a bug.

Coppermine WordPress Widget

Sunday, March 29th, 2009

I’ve not been well this weekend. Its the remnants of a fluey cold exacerbated by getting too cold in the wind and rain when using public transportation on Thursday and Friday. However every cloud has a silver lining and sitting in bed, in between snoozes, has given me the chance to get on and develop a WordPress plugin and widget that integrates with, and displays images from a Coppermine gallery.

This is the first plugin and widget for WordPress I have developed and its been a bit of a learning exercise. Its no way completed but the basics are there and you can download the plug-in here. (Edit: The plug-in is now supported officially on the WordPress site. You can get the latest one from here). Currently the only known bug is that you add the widget to a sidebar before you have configured the default Coppermine database settings.

Currently the widget just displays a fixed number of random images from the whole gallery. You can see it in action in the left side bar. Clicking an image takes you to that image’s album in the gallery. Imminent additions I will make are a configurable number of images and columns; selectable queries e.g. the latest additions to the gallery, random from an album or albums, and so on; and pop-ups on mouse-over showing a larger version of the image together with image title and description.

First post

Friday, September 26th, 2008

I'm not slacking off, my code's compiling!

It about sums it up really (from the great xkcd web comic). I’m sitting here waiting for a big build to get to the place where I want it to purposefully break, so that I can extract some files, and so I decided to finally get my blog back in to use again. So here’s the first post. What’s the purpose of the blog? Well mainly general ramblings; a way that my family and friends can keep up with my activities as I jet around the world; and talk about private projects.

So there you are!