Changes

• A new option has been introduced to hide the license and attribution information in the footer.
• Bug fix: Config hash file was never initialized
• Bug fix: Enabling “cacheable” option resulted in fatal PHP errors in some cases
• Bug fix: Preview option did not work when “cacheable” option was enabled
• Bug fix: “All Rights Reseved” licenses had no URLs

In addition, WP Flickr Background is no longer compatible with WordPress version 2.8 or older.

Links: Direct download WP Flickr Background (30) | Wordpress Plugin Directory

Related posts:

1. WP Flickr Background version 1.0.2 (Beta) available
2. WP Flickr Background
3. WP Flickr Background in Alpha testing

My biggest concern is that a fraudster will simply replace the account information to one he owns him or herself. Because it is such a hot topic on Twitter at the moment, this altered message would make its rounds quickly.

I was able to trace the original message back to @CruzRojainforma, the Chilean Red Cross. So far the retweeted message hasn’t been altered – other than being translated into English. But I’ve urged people to stop retweeting the account details and visit the official Red Cross website at www.redcross.org instead. There’s a link right on their main page that explains how you can donate time or money to the Chilean earthquake efforts.

On a final note, Twitter is also used to find missing persons. And with positive results I may add, as this article explains. Google also has a Person Finder database running, which it had done for te Haiiti earthquake as well. But please ensure that you do not give out too much personal details about the person you’re looking for, because it becomes a (nearly) permanent part of the Internet.

Again, the intentions are good, but there are too many people out there waiting to take advantage of every possible situation so be careful!

Fuerza Chile!

Related posts:

1. Hawaii Tsunami, Sprecks image gallery

While the actual waves were thankfully less high than expected, you do notice two distinct surges in the images. The view here is of the Sprecks towards the West Maui mountains.

Here’s a video which will give a better idea of what it looked like on the ground:

I have another set (with a smoother timeline) from a different location as well, which may add soon as well. A few images from that set stood out and I will share this one with you here:

Apparently this person wasn’t aware that there was a tsunami warning in effect and that you shouldn’t be on the beach, especially not making any phone calls.

Related posts:

1. Lifestream for March 1st
2. Red Cross’ Citibank details on Twitter could be false.

Satisfied with this, I’ve now made version 1.0.2 available as a Beta product. That means you can now use it for your own purposes, however I do not recommend using this in a production environment just yet (although nothing is stopping you from doing so – use at your own risk!).

The likely issues that I’m expecting are with the installation, plugin usage and the back-end (administration). But hopefully those will only be a few. In meantime, I will start the registration procedure with Wordpress.org so that the code will be available in the SVN, and the plugin available for download / upgrade within Wordpress itself. Hopefully this will be a matter of just a few days.

If you are running in any kind of issue, how small it may seem, I’d really like to know about it so I can improve the plugin. You can use the contact form, or leave a comment below and I will make note of it.

The static page for WP Flickr Background is http://www.myatus.co.uk/wp-flickr-background, and it will be updated with the latest version as it becomes available. You can also click on Downloads at the top.

Enjoy!

P.S.: A small update, WP Flickr Background is also available through the Flickr App Garden.

P.P.S.: Quicker than expected, Wordpress has accepted the plugin into the Plugin Directory. If you wish to use the development version (provided you know what you are doing!), see the SVN.

Related posts:

1. WP Flickr Background version 1.0.3 (Beta) available
2. WP Flickr Background
3. WP Flickr Background in Alpha testing

All you need to do is create one or more galleries within the plugin’s settings, each containing a collection of photos from Flickr that you have chosen, and WP Flickr will randomly select a photo from the active gallery to display as the theme background.

You can also customise a gallery by adding CSS styling code that will be loaded along with the photo, allowing you to color match the Wordpress theme to the particular photo displayed or for other use.

Links: Direct download: WP Flickr Background (30) | Wordpress Plugin Directory

If you have an idea for WP Flickr Background or wish to report a bug, click the feedback tab shown on your left or visit UserVoice.

Related posts:

1. WP Flickr Background version 1.0.2 (Beta) available
2. WP Flickr Background version 1.0.3 (Beta) available
3. WP Flickr Background in Alpha testing

I had taken down the website to make some changes to the web server, which quickly became a major overhaul. I figured that since it was already down, I might as well do the things I had long planned.

A good portion of it is implemented now, but I’m not completely done. I’ll give it my best effort to ensure there will be little to no downtime. Once again, my apologies!

No related posts.

If you’re new to this website, you probably haven’t noticed. But the background you’re seeing is actually something new. And random. And streamed from Flickr. It’s a new plugin that I am developing for WordPress called ‘WP Flickr Background’.

A little over two weeks ago I changed my theme to Motion by 85ideas, and was intrigued by its effective use of transparencies and the background. And since I quickly get bored looking at the same thing, I thought ‘Why not make this background random’? Flickr provides millions of photos, many of them under a Creative Commons Attribution License, and this would be an excellent source for those random backgrounds. So I started coding…

Interestingly, it wasn’t as straight forward as one would expect. After all, you could simply use a dynamically generated CSS style sheet with a ‘background’ element pointing to a random Flickr photo. Right?

But small photos cascade and your website will look like a bad 1995 rendition of your first HTML page. And the large photos may be SO large, you end up staring at just a grain of sand instead of a beach.

CSS3, the brand-spanking new version of CSS style sheets, supports stretching of background images. Unfortunately, not a single browser I have tried supports it. So I reverted to good-old image hacking, basically injecting the background in a negative Z-indexed <div> block at a fixed position.

Yes, that last sentence is a great conversation breaker. But trust me, it is the injection portion that’s trickiest. For one, I do not like it when plugins require me to manually modify files, let alone modify files in the first place. So I assume there are other people out there who think alike. So how can I change a WordPress theme without actually modifying its files? Enter Javascript, jQuery to be specific, and we are on our way to great trickery!

So in the end, WP Flickr Background will use Javascript to add a new background image overlaid by the actual (original) contents. And it works! At least, it does so with Opera 10, Firefox 3, Google Chrome 3, MSIE 8 and Safari 4. Hence I am now putting the plugin through a public Alpha test, waiting for complaints to roll in: “Your website looks weird” and “I’m getting Javascript errors” are some of the things I am expecting to see during testing, but hopefully there will be none! You will let me know, right?

If I am satisfied that there are no major issues with the plugin, then I will make it available for download. In meantime, I will be re-arranging a few things on the website once again to make room for the new plugin and a few others I am thinking about writing. So please excuse construction going on in the next few days!

Related posts:

1. WP Flickr Background
2. WP Flickr Background version 1.0.2 (Beta) available
3. WP Flickr Background version 1.0.3 (Beta) available

So I have been keeping myself busy with a number of projects, some small, some big. One project has been updating my blog a bit, giving it a fresh coat of paint and tweaking a few bits and bytes. All this tweaking will give the articles some more room, because in my previous layout it seemed rather cramped. I still don’t have a logo though, so those three overlapping circles in the upper-left corner will have to do for now.

For another project, I’ve put the Amazon S3 Fuse driver on a back burner a bit and will focus a bit more on using another company, namely Diomede Storage. This is because the per-request fees at Amazon make it too expensive for the end user. Diomede Storage simply charges for storage and transfers only, and that’s it. As an added bonus, Diomede Storage makes multiple copies of your file(s); even at the minimum of 3 copies it’s less expensive that Amazon or other Cloud Storage providers like RackSpace. The only issue with Diomede Storage is the lack of a complete documentation and a broken REST API, but I’m sure this will be fixed soon.

There are plenty of other projects on my “To-Do” list, including one that involves data centres in the UK, Netherlands and Japan. And although they could potentially fill every hour that I am awake, I’d rather focus on something more important, which is finding a new career opportunity.

The credit crunch is nearing the end and companies are more confident, so now I feel is a good time for me to make the change and settle in with a company where I can remain until my age demands that I retire. Although I do see myself saying “Why the heck should I retire?” – Just so I can keep busy.

Well, whatever lies in my and your path, I hope it’s all well for 2010!

Related posts:

1. A little silence doesn’t hurt

As you may have read in one of my previous blog entries, specifically “NginX and Apache, but no memcached”, I prefer to use NginX as the front-end serving static files, and Apache as a back-end dealing with the dynamic pages. So it would be ideal if NginX could serve up static Wordpress files, which is exactly what I am doing now with the help of WP Super Cache.

WP Super Cache is a rather popular plugin and converts the output generated by Wordpress into a static HTML file. Installation is quick and painless, and automates a few tasks for you (or lets you know what needs to be changed on your website).

To make it work with a NginX front-end and Apache back-end, a few additional changes need to be made, primarily to the NginX configuration.

Wordpress / Apache Changes

Firstly, enable  WP Super Cache into the “full on” setting, meaning it generates a “cache” and a “super cache”. WP Super Cache will then ask you to change the .htaccess file, by adding a few Rewrite Rules. In this case, we do not need those entries and we can reduce it to just the following:

# BEGIN WPSuperCache

### WARNING: This is handled by NginX!

# END WPSuperCache

This will keep the plugin’s setting page from complaining about the need to configure .htaccess.

I have also enabled the “Super Cache Compression” option, however this is not mandatory. I choose to do this to relieve NginX from a few CPU cycles (as the HTML is already compressed then).

NginX Changes

Next the NginX website configuration needs to be modified. And a few of these modifications will depend on your website or needs. In my case, I  am using a separate template for the iPhone, Android and other smart phones and do not wish to use the cache for these. So I have the following entry in my NginX that will detect mobile phones:

server {



... (snip!) ...



        # Check if it's a mobile phone

        set $mobile "";

        if ($http_user_agent ~* "(2\.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine\/3\.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA\/WX310K|LG\/U990|MIDP-2\.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP\.Browser|UP\.Link|webOS|Windows CE|WinWAP|YahooSeeker\/M1A1-R2D2|NF-Browser|iPhone|iPod|Android|BlackBerry9530|G-TU915 Obigo|LGE VX|webOS|Nokia5800)" ) {

                set $mobile "M";

        }



... (snip!) ...

This will set the variable $mobile to “M” if  the user-agent is from a mobile web browser. If you don’t need or want this, then you can simply leave it out of your NginX configuration.

We also need to modify the common location section. There are a number of ways to approach this, but I choose to use a number of “if” statements to build a variable $wpsc_flags. Depending on the list of “if” statements NginX will output the static cached file from WP Super Cache or continue to the Apache back-end (which will handle the rest).

Unfortunately NginX does not provide support for nested “if” statements or booleans, so this is a slightly dirty hack:

       location / {

                # If it's a POST request, send it directly backend:

                if ($request_method = POST) {

                        access_log      off;

                        proxy_pass      http://apache_backend;



                        break;

                }



                # Is it a mobile user?

                set $wpsc_flags "${mobile}";



                # Is the user logged in?

                if ($http_cookie ~* "(comment_author_|wordpress_logged_in_|wp-postpass_)" ) {

                        set $wpsc_flags "${wpsc_flags}C";

                }



                # Do we have query arguments?

                if ($is_args) {

                        set $wpsc_flags "${wpsc_flags}Q";

                }



                # Does the (gzip) Super Cache exist?

                if (-f $document_root/wp-content/cache/supercache/$host/$uri/index.html.gz) {

                        # The file exists in the WP Super Cache

                        set $wpsc_flags "${wpsc_flags}F";

                }



                # If the following flags are set (in this order) we use the cached version:

                if ($wpsc_flags = "F") {

                        expires         1h;

                        rewrite ^(.*)$ /wp-content/cache/supercache/$host/$uri/index.html.gz break;

                }



                # Or else it goes to the backend:

                access_log      off;

                proxy_pass      http://apache_backend;

        }

By reading the comments it should be clear what this does, but I’ll clarify further just in case.

A HTTP POST should not be cached, and so it will be sent directly to the Apache back-end server(s) and stops doing any other checking.

In the next step, it creates a $wpsc_flags variable based on the $mobile variable we created earlier. If you do not use the $mobile variable, then you can simply replace it as following:

set $wpsc_flags "";

Then it will add flags to $wpsc_flags depending on whether the current user is logged in, if the request contains arguments (ie.: “someurl.com?this=is&an=argument”). This will prevent an editor or commenter from being presented cached pages, which can be bothersome.

Now, as I had turned on the “Super Cache Compression” in the Wordpress plugin, I am looking for files that end with “.html.gz”. If you are not using the compression option, simply remove the “.gz” from the “if (-f” statement as well as the “rewrite” statement.

Also note that it will only display the cached data if, and only if, $wpcs_flags is set to “F”. If you were logged in, this variable would actually be “CF” (in this order!) and so it will continue to the portion where everything is sent to the Apache back-end.

Speed Improvements

A while ago I had posted a message on a forum that showed how a Wordpress cache could improve responsiveness. The (truncated) results of a simple “ab -n 1000 -c 50 http://<website>” (ApacheBench) showed the following back then:

Requests per second:    1753.08 [#/sec] (mean)

Time per request:       28.521 [ms] (mean)

Time per request:       0.570 [ms] (mean, across all concurrent requests)

The cached responses were generated by Hyper Cache at the Apache back-end, then forwarded to NginX to be delivered to the user (“ab” in this case).

With the new setup, where NginX is responsible for the delivery of a cached response opposed to Apache / Wordpress:

Requests per second:    4712.65 [#/sec] (mean)

Time per request:       10.610 [ms] (mean)

Time per request:       0.212 [ms] (mean, across all concurrent requests)

Although these are not conclusive, lab-certified benchmarks, the crude test does show a rather impressive improvement. The time for each request has been reduced by more than half. So it’s well worth the effort.

Photo “Ashley Force” by Ford Racing (CC)

Related posts:

1. NginX and Apache, but no memcached
2. Compiling NginX on Debian / Ubuntu
3. Myatu’s is mobile

You can customize your message and use [title] to replace it with the article’s actual title and [link] with a (shortened) URL to the article. So you could do something like “New blog entry ‘[title]‘ posted at [link]“ – Well, perhaps you’d want to keep it as short as possible though, but it’s to give you an idea.

So given that you can customize your message, you can also add one or two hashtags. But these are all done manually, for example “Blog [title] – [link] #blog” is what I was using myself.

But the #blog hashtag isn’t really something a lot of people will search for. So why not re-use the tags that I already have added to my article with Wordpress? Like this article for example, can’t I use its customization tag as the #customization hashtag in my Twitter update? Well, with some modifications to WordTwit, it’s possible. Here’s how.

The modification involves editing the file wordtwit.php, which can be found in your /wp-content/plugin/wordtwit/ directory. The first part is very minor and simply involves moving a line of code a little further up. You need to look for “$post_tags = get_the_tags();” near line 484 (in version 2.2.4 of WordTwit):

...(snip)...

        $can_tweet = true;



        // check tags

        if ( count( $wt_tags ) ) {



            // we have a tag or a category

            $new_taxonomy = array();



            $post_tags = get_the_tags();

            if ( $post_tags ) {

                foreach ( $post_tags as $some_tag ) {

                    $new_taxonomy[] = strtolower( $some_tag->name );

                }

            }

...(snip)...

Move the  “$post_tags = get_the_tags();” line up and place it under the “$can_tweet = true;” line. This is done to avoid calling the same function twice. Admittedly, it’s a minor speed hurdle, but if you get into this habit of doing this throughout code, it’ll eventually speed things up. So now the above code will look like this:

...(snip)...

        $can_tweet = true;

        $post_tags = get_the_tags(); // <-- The line was moved here



        // check tags

        if ( count( $wt_tags ) ) {



            // we have a tag or a category

            $new_taxonomy = array();                



            if ( $post_tags ) {

                foreach ( $post_tags as $some_tag ) {

                    $new_taxonomy[] = strtolower( $some_tag->name );

                }

            }

...(snip)...

Up for the next bit.  At around line 515 of the same file (wordtwit.php) you need to inject the code that will handle the Wordpress tags to Twitter hashtag conversion. The actual line number will depend on the version of WordTwit you’re using (in this example, version 2.2.4) so I have included a snippet of the existing code as a reference where to add it. The actual code will be commented accordingly:

...(snip)...

            $message = $settings['message'];

            $message = str_replace( '[title]', $post->post_title, $message );



            global $post;

            $message = str_replace( '[link]', wordtwit_make_tinyurl( get_permalink(), true, $post->ID ), $message );



// !!! Wordpress tag to Twitter hashtag conversion STARTS HERE >>>



            if ( $post_tags && strpos($message, '[tags]') !== false ) {

                $tags_to_add = '';



                // What's the message length without this tag?

                $message_len = strlen($message) - 6;



                foreach ( $post_tags as $some_tag ) {

                    $tag_len = strlen($some_tag->name) + 2;



                    // Can we add this tag within the 140 char constraint? (accounts for hashtag and spacer)

                    if ( $tag_len + $message_len <= 140 ) {

                        $tags_to_add .= '#'.$some_tag->name.' ';

                        $message_len += $tag_len;

                    } else {

                        // Nope, we're done

                        break;

                    }

                }



                $tags_to_add = rtrim($tags_to_add);

                $message = str_replace('[tags]', $tags_to_add, $message);

            }



// <<< Wordpress tag to Twitter hashtag conversion ENDS HERE !!!    



            $twit_username = $settings['username'];

            $twit_password = $settings['password'];



            twit_update_status( $twit_username, $twit_password, $message );

...(snip)...

Save the file and you’re done with the modification!

Now you can customize your WordTwit message with three replaceable  tags: [title], [link] and the new one [tags]. When you specify [tags] in your custom message, WordTwit will use the tags you’re using from Wordpress and convert them to a Twitter hashtag. It will try to fit in as many as possible, up to a limit of 140 characters. If you have 10 Wordpress tags but there’s only room for 3, then only the first 3 hashtags will appear in your Twitter status update. And obviously all 10 will appear if there’s room for them.

Related posts:

1. Faster WP Super Cache with NginX
2. WP Greet Box autohide feature
3. Fancy WordPress Translations