$ svn switch http://core.svn.wordpress.org/tags/3.0

And navigate to the Admin pages of the blog. Done — WordPress upgraded to the latest and the greatest within seconds. Would be faster if something like git is used instead of subversion (which I found slower and slower than git or hg), but certainly no complain here.

As of WordPress 3.0 — not much changed on the surface. I am pretty sure Matt and gang have done the heart transplant under the bonnet, but these days I am so out of touch with the latest WordPress development I seriously have no idea what has been changed. It does chew up a bit more memory, which can be a problem if you are running tiny virtual servers.

So far so good.

WordPress 2.8 “Baker” is now live to the world! http://bit.ly/wordpress28 (spread the good word)

Yup. It is here, and you can read more about the new features here. To upgrade to the latest version using subversion while Automattic haven’t tagged the 2.8 –

1. Go into your previously checked-out WordPress directory
2. Run svn switch -r 11549 http://svn.automattic.com/wordpress/trunk/
3. Navigate to http://yourblob/wp-admin/upgrade.php

Done! You are running WordPress 2.8! Of course some plugins and themes might not work but who cares. You are now using the latest and greatest :) Most new features are admin panel related, but the one that interests me the most is:

• Support timezones and automatic daylight savings time adjustment

Yes — it’s about time!

• Write a short 140-character micro-blog-post, and then assign it to a special category.
• It then pings all microblogging servers with my followers on it to update their message queue.
• WordPress can also take incoming requests and then populate my message queue with those whom I follow.

I guess things like Twitter-API emulation, XMPP integration, etc can all come later, so I just need one single WordPress installation to do both my regular blogging and my micro-blogging. Or maybe such plugin already exists?

I might actually sit down and look at how easy it is to implement something like this — if I have the time (i.e. no I don’t have time to do it). Going to Microsoft Tech.Ed 2008 for the next 3 days to be brain-washed by the evil empire because somehow work signed me up for it. Really excited… Not! That means I’ll also miss out CityBibleForum tomorrow :(

… do not click on “upgrade automatically”. Let me repeat, Do Not Click on Upgrade Automatically. Because if you do, you will not be upgraded to Permalink Redirect 1.0, but rather a completely different plugin will be installed.

Over the past week I have been notified by a few people about a strange behaviour after they have let the WordPress Automatic Plugin Upgrade to upgrade their Permalink Redirect plugin for them. Instead of getting an upgrade, another plugin of the same name, Permalink Redirect by Joost de Valk, has been installed instead. It has been asked on WordPress support forum, and it turns out that Joost’s plugin has registered the slug “permalink-redirect” on WP’s plugin directory which I assume is where the version number is checked. So when Joost bumped the version number to 1.0 a few days ago, suddenly everyone with Permalink Redirect installed gets that automatic upgrade option…

Here is what I have posted on WordPress.org regarding this issue, and so far there is no response.

Hi. This is an issue recently raised by users of one of my WordPress plugin.

I wrote Permalink Redirect back in 2005 to solve the issue of canonical permalink URL, and it has been downloaded many times and installed on many WordPress sites. Its core functionality has been integrated into WordPress 2.5 although it is now doing a bit more that just fixing the permalink. Currently the version in my own Subversion repository is 0.8.5 and is compatible with WP 2/2.5/2.6.

Then one of my users notified me that when he visited the plugin management page, the Permalink Redirect plugin has been marked that a new version is now available. User has been given the option to download or upgrade it automatically. To his horror, after the upgrade my plugin now ceases to be installed, and a complete different plugin with the same name but different author is now installed and activated.

Doh.

Now my question is, how can two totally independent plugins with different author and different plugin URL be allowed to be replaced by one another? Moreover, I would like to know whether there’s any solution in this situation.

Cheers,
Scott

Being able to replace someone else’s WordPress plugin almost-automatically by registering the same name on WordPress.org — this is a serious issue. While the code is hosted on WordPress.org, but I do not thing the code is audited by Automattic/WordPress developers. There is one scenario — what if offending code that automatically insert spammy links to all your posts get automatically pushed to the end user? And I won’t even talk about worse or more evil scenarios.

I do not think two independent plugins sharing the same name is an issue (although I do suggest that you do a Google search before start writing a new one). It is also partly my fault for not registering mine with WordPress.org (but why should it be centrally organised?) Anyway. Make sure you check very carefully before clicking on “upgrade automatically”, or disable the automatic upgrade all together.

And the reason for Permalink Redirect 2.0? So it will be greater than 1.0 and you won’t be bothered by WordPress’ “kind reminder” that you need to “upgrade”. Until Joost releases his next upgrade as Permalink Redirect 2008…

Download Permalink Redirect 2.0 (5.0kb ZIP)

Installation should be straight forward if you have installed it before. Unzip it, and then copy the PHP file ylsy_permalink_redirect.php to your WordPress’ plugin directory. Activate it from your Plugin Manager page. Done!

So what is new in Permalink Redirect 2.0?

Only one new bug fix — rewrite of the old permalink structure redirect handling.

Redirecting from the old permalink structure has been added quite a few ago, but having it working is a bit of hit and miss. How it worked was appending the extra rewrite rules generated from the old structure to a list of existing rules to be checked during WordPress’ request parsing process, similar to Dean Lee’s Permalinks Migration plugin. It is elegant, but does not always work.

It was ineffective due to the way WordPress processes through those rewrite rules. Some permalink structures are more aggressive than the others, as their regular expressions pretty much match everything (for example /%postname%/). Therefore some rules never get executed, and those old permalinks will never get detected and redirected.

So here is my less-elegant (or maybe call it hack’ish) solution. We will manually run through those old rules again after the main request parsing but before checking for redirection, only if a 404 Not Found is detected. It involves creating some of the main WP objects again and run them through alternate rewrite rules generated from old permalink structures. It will then try to redirect to the canonical URL if one of the old rules returns positive result, otherwise it will continue to process 404 Not Found.

It’s quite a hack which exposes some of not so poetry code inside WordPress. At least it works (for me). It has been tested under WordPress 2.0.11, 2.5.1 and 2.6, but no guarantee that it will work for other future or past versions of WordPress. You ought to upgrade to the latest if you are using 2.1-2.3 anyway, or else… As it does a bit of work only when 404 occurs, it should not affect normal page viewing but 404 page handling will be a tad slower.

So, please download it and test whether it is working for you if you have a strange redirect issue with old permalink structures.

Now, why 2.0, especially when there has never been a 1.0? I will leave that to my next post — WordPress plugins — check before you upgrade automatically.

Permalink Redirect 0.8.4

I have updated Permalink Redirect plugin to 0.8.4. The main functionality of this plugin has been replaced by WordPress’ redirect_canonical() function since WP 2.3, but somehow some people are still using this plugin for its remaining functions (permalink structure changes, arbitrary path redirect, etc). 0.8.4 fixes an issue with arbitrary path redirect when the old path is now producing 404. It has also overwritten the wp_redirect function (taken from WP 2.5) so 301 redirect works properly on Lighty/Nginx setups.

ESVPopup 1.4

Don’t you love browser incompatibility?! While everyone is trying to crack Acid3, I am still trying to figure out why event.clientX on Safari is different from all the other browsers.

Anyway. ESVPopup 1.4 should work with Safari 3.0.x now.

Btw, this blog has also been upgraded to WordPress 2.5. Nice new dashboard and so far everything works. Finger crossed.

Yes. Please call all your friends who have a self-hosted WordPress blogs and get them to upgrade to the very latest version.

To see what has been changed from WordPress 2.3.2 to 2.3.3, you can use the following Subversion commands:

$ svn diff --old=http://svn.automattic.com/wordpress/tags/2.3.2 \
           --new=http://svn.automattic.com/wordpress/tags/2.3.3

Which includes the diff of the five files that have been changed. The biggest change came from xmlrpc.php, in change set 6715, where Ryan tries to fix this security issue (yes the ticket was opened in November last year and only managed to get fixed yesterday, 3 months later). Basically, capability checking is done before determining whether the operation is editing a post — if post type is “post”. So any account can edit posts and pages via XML-RPC by faking post type as “page”. For more detail on this exploit, see The Seeker Blog, and it appears to be “going wild” at the moment.

The fix also only comes in 2.3 flavour, whereas the concept of “page” has been there in WordPress since 2.0. That also means, all you 2.0/2.1/2.2 users are still vulnerable. You have to upgrade to the latest stable branch, although not all existing plugins and themes work with 2.3…

I think I am starting to agree with Mark…

So what we have got here?

Gravatar Cache 0.2

On July 20 I have uploaded an updated version of Gravatar Cache. Something has been added, and something has been removed:

• Add MySQL backend support for handling negative responses

  Personally I found that SQLite-based backend is just not scalable. It is perfectly fine for small websites, but when you have a site with thousands of page views a day, each page view generates multiple Gravatar requests, and majority of requests yield negative result — you’ll probably see lots of SQLite locking errors in your log files.

  Porting negative cache to a new backend is easy. Now Gravatar Cache can use MySQL as backend so hopefully cache misses can be better handled.

• Remove fopen_url based HTTP request method

  That means we will never use fopen to grab Gravatar from gravatar.com, as fopen automatically follows 301/302 redirects. Gravatar cache can still download gravatars using either cURL or raw socket.

It has been running quite stably on one of my Drupal site doing 30,000+ gravatars per day.

Permalink Redirect 0.8.1

Also on July 20 I have released an updated version of Permalink Redirect WordPress plugin. There has been quite a few changes since 0.7.0:

• Add FeedBurner branding support

  Thanks to Mesoconcepts for sponsoring this enhancement. Since Google purchased FeedBurner, FeedBurner has released this Pro feature for free. Now you can edit your hostname as well as the pathname to redirect the visitors to.

• Add static page redirect

  Thanks to Sergey Menshikov for supplying the patch. You can now edit a list of [from] [to] and let WordPress to handle the redirection. Again, it is probably a feature best left for the web server to do. It is nice to have it in the plugin as well, for those who do not wish to touch their web server configuration files.

• Fix front page as static page issue in WordPress 2.2

  Somehow is_home() is ambiguous in different versions of WordPress. Anyway, it is fixed now.

• Fix 301 redirect issue with Lighttpd/Nginx + PHP FastCGI

  Permalink Redirect 0.8+ uses WordPress’ wp_redirect function, which refuses to send back 301 when PHP is running as FastCGI. Now we are making an exception in the code so it by-pass wp_redirect if we are running FastCGI behind Lighttpd and Nginx.

Permalink Redirect and Beyond

There has been words that WordPress is going to integrate the functionality of Permalink Redirect into its core, and looks like it is going to be available in WP 2.3 (currently SVN trunk).

The function redirect_canonical does pretty much the same thing as Permalink Redirect plugin so I guess the question is — what is happening to Permalink Redirect beyond WordPress 2.3?

Not much I guess. The primary goal for Permalink Redirect is redirecting visitors to the canonical URL for search engine’s sake, and I think WP 2.3 has achieved that right inside the core. While there are lots of other functionality in Permalink Redirect that are not ported to WP 2.3 (Feedburner feeds, configurable rules, old to new permalink structure, etc), but honestly even I do not use these features much myself.

It is still possible to create a lite version of Permalink Redirect to hook these extra functionality into WordPress 2.3, and I might start working on that when WP 2.3 turns beta. Meanwhile, excuse my absence here as I have my “other life” to sort out. Don’t bother with the bbPress support forum (it is down anyway). If you need any quick solutions, email me directly. You can find my email address in the contact page.

So what do we have?

• WordPress Widgets — Never going to use it as I don’t even have a sidebar here.
• Full Atom support — time to fix up my old code to support Atom publishing?
• New Blogger importer — again not very useful to me.
• Infinite comment stream — not useful, especially when Akismet is working.
• Speed optimizations — now we are talking. Any benchmark?

A bit more interesting for the developers. jQuery is now standard, which is pretty good. I am using jQuery for some of my other projects, and it is probably one of the most useful Javascript library out there. Hard-coding WP URL is also going to be useful to me, especially when you do staging with your WP installations.

I guess the question for now is — upgrade or not? It is bloody easy to upgrade a batch of sites, but not sure whether 2.2′s added complexity gives true usefulness to some of my fellow bloggers at FOCUSer.net.

While I thoroughly enjoyed my position being the Number 1 resource-wasting WordPress plugin, I also agree with Alister — why code it in PHP when your web server can do it faster for you? But hang on?! That hack requires access to .htaccess file which not everyone has access to. For example,

1. Hosting companies do not allow you to override options in .htaccess.
2. Alternative web server is used like Lighttpd, Nginx or (heaven forbids) IIS.

Then you should obviously change your hosting company. Maybe not Media Temple, whose (gs) product is causing grief wherever I read about it. This blog is currently hosted on NearlyFreeSpeech.NET (which I reviewed here) — maybe you may want to consider it.

Actually, there are indeed equivalent rewrite rules available for lighty and Nginx. Here is one for lighty (a bit flaky because lighty lacks file-exists condition):

server.modules += ("mod_redirect")

$HTTP["host"] == "example.com" {
  url.redirect = ("^/([^.]*[^/])$" => "http://example.com/$1/")
  server.error-handler-404 = "/index.php"
}

$HTTP["host"] == "www.example.com" {
  url.redirect = ("^/(.*)$" => "http://example.com/$1")
}

Nginx? No problem either.

server {
  server_name www.example.com;
  rewrite ^/(.*) http://example.com/$1 permanent;
}

server {
  server_name example.com;
  if (!-e $request_filename) {
    rewrite ^/([^.]*[^/])$ http://example.com/$1/ last;
    rewrite ^.*$ /index.php last;
  }
}

The idea is — if all you need to do is ensuring a trailing forward slash in URL, then doing it as a plugin inside WordPress might not be a good idea if you wish to get the maximum performance from your WordPress site. Instead, your web-server can send back a redirect response much faster without a single line of PHP gets executed. This is especially true when Permalink Redirect is only tested after some SQL queries have been executed. So if someone linked your site to Digg without the trailing slash, got pushed to the front-page, and 10,000 visitors followed that URL in within an hour — your blog post will be loaded from MySQL at least 20,000 times if you have Permalink Redirect installed.

And the co-habitants on your $5 per month shared hosting will absolutely hate you.

So if you do not want to be hated by your hosting company whenever you got dugg, then you probably don’t need and shouldn’t use my Permalink Redirect plugin.

Unless you are like me, who will never get dugg no matter how hard I’ve tried, don’t care what the hosting company says, have no desire to touch the .htaccess file, and sometimes use permalink structure without a trailing slash, then you are free to stick to my resource-wasting plugin :)

When you cross people’s money making business, expect back fires. So the designers strike back with their own perspective. After all, there are many starving artists that need the dole, and what right does Matt/WordPress.org have preventing them getting wages from their work?

Then Matt posted a new article Plugin Authors Get No Love, arguing WordPress plugins are no less useful, equally sophisticated to create, but rarely have sponsored links bundled. The title was a bit misleading I think, as many interpreted “love” as getting monetary rewards.

But anyway. One week later, I think I am going to write a bit of my point of view on this matter.

I Have Been On Both Sides

I just need to declare that I have actually been on both sides of the fence. I am a coder at heart, and I have developed and released a few WordPress plugins, including the popular Permalink Redirect plugin, which frequent many people’s top 10 WP plugin lists, especially amongst the SEOs. All my WP plugins are released under GNU General Public License. Some of my other work are released under even more liberal Public Domain, i.e. no license term at all!

However back in 2003 I actually started a theme/style site for Movable Type, when free themes/styles were not readily available. Due to other commitments I asked someone to take over the site — I literally just gave that site away with more than one year of domain rego left! Come to think of it, what was I thinking that I gave away a PR6 site with 160+ inbound links for FREE! I must have been crazy! The same guy who took over the domain have done nothing over the last two years, and yet it is still a PR6 site.

Crap. Am I stupid or not?

After all I am more than just a coder at heart. I am an open source coder deep down who believe artistic creation (code is poetry, remember?) should be shared to make collaborative improvement a reality. Ultimately I would like to see more Movable Type themes developed and added into the repository, although I did not have any time developing it. So I was thinking, “hey if I pass it onto someone else, he can continue all the work!” Places like Sitepoint Marketplace has never entered into my mind.

I guess it is what sets many plugin developers and theme developers apart. As I replied Matt’s post:

Plugin developers are programmers who understand the benefit and reason behind open source/free software. Theme developers are designers who do not necessary understand FOSS.

Not saying one is superior than the other, but just two different groups of people coming from two different backgrounds.

Okay. With that background in mind, let us look at some implications.

Designers Making Money From Themes? By All Means!

As much as I believe in open source, I also believe that credit should be given where credit is due. If you are a graphics designer who love to make beautiful themes for popular content management systems, and are making money from doing so — congratulation!

I have seen people argue that since WordPress is free, people should not ride on the bandwagon, create an economy around it and make some money from it. He/she has obviously misunderstood the definition of free in Free Software. There is no license restriction on making money from open source/free software product.

So the GNU guys do not mind people making money on free software, but the next question is, whether making money off free software is ethical? In my own opinion, there is no two different ethics between free and proprietary software. Instead, ethical or not should totally base on how the money is made.

Ethics in Monetising the Themes

There are several ways for designers to monetising themes that I can think of.

• Pay per design — many companies monetising in FOSS world by providing value-add services. There are also many high profile bloggers or company blogs out there that need more than just the default Kubrick theme. Many are willing to pay for high quality designs.

• Pay per download — you have created the most coveted and versatile WordPress theme in the world. Charge 10 bucks per download.

• Ask for donation — it is not too hard to put a PayPal donation button on the sidebar, is it?

• Sponsored link — now we are getting into the gray area! Google does not like it as it pollutes SERP. Personally I think taking sponsors and add a link into footer of your theme template is okay, as long as you make full disclosure, including appropriate license terms.

  For example on the download page, theme developer needs to say “This theme is sponsored by such and such, and a link is included in the footer of the page. As it is released under Creative Common Attribution license, please leave the copyright notice.”

  Then the person who is downloading and using theme is fully acknowledged the existence of the sponsored links, and what he/she can/cannot do with the template.

Again in my opinion a theme with sponsored links without disclosure is considered spammy and unethical, especially the ones with blackhat tricks like cloaking and invisible DIVs. If you can only get people downloading your themes without the disclosure, then maybe your theme is not good enough. Go back to your PhotoShop! :)

GNU GPL or Creative Commons?

One issue (or advantage from a different perspective) with Creative Commons (CC) licenses is — they are essentially copyright lite. Attribution is always required in CC, so there is no way to remove the usual copyright notice at the bottom of each theme, usually with a complimentary link back to the theme developer. Worse, there are themes with Attribution + NoDerivs license that forbids any derivative work based on licensed product. That simply means, if there are hard coded sponsored links in the template, you cannot touch them!

If it is how many themes are licensed, no wonder they are in deep conflict with WordPress, which is licensed under GNU General Public License (GPL). GPL gives the receiver of the end product every freedom except imposing restriction on others. From legal point of view, I can grab WordPress, rename it to something else, change source code here and there, shrink wrap it, and sell it for $5,000 a copy without acknowledging Matt and co, as long the source code is provided to my buyer, and they can do whatever they want with it (including selling it for $10,000). Maybe it is not ethical, as in a case I have looked at previously. But it does tell you what really matters to the open source/free software people — freedom for the developers to do whatever you want.

And I consider it was this freedom that made WordPress a more preferred blogging platform than its closest competitor back in May 2004, when Movable Type stopped being “free”. Mark Pilgrim’s post is the one article that I constantly referred back to.

Therefore licensing plugins or themes under any more restrictive licenses is against the central philosophy of WordPress, or any other free software. Duncan Riley didn’t get it — the fall of SixAprt started when the community were upset, but they were upset because people realised that this software is not really free.

(Just a side note — I have been looking for forum software to kick start a community site. However I am not touching SMF nor MyBB, as those so-called “free” forum software are not really free if you check their license terms. Still waiting for phpBB 3 to release…)

Removing Themes from Theme Gallery

Not only because sponsored theme confuses visitors, but also because of this philosophy difference, I completely agree with Matt that they should be removed from WordPress official sites.

Another reason, which I believe Matt would also agree, is that how difficult it was to come clean after being accused of spamming. For some they are tainted for life, and I am sure Matt would not put the WordPress brand in jeopardy again.

That does not mean sponsored themes will not continue. Designers from everywhere are still free to take sponsorships for themes they made. They just will not be listed under the WordPress brand, that’s all. Weblog Tools Collection is still happy to list them, as long as sponsorships are made known.

Other Thoughts?

Other random thought pieces on this matter that cannot be put logically anywhere, so I shall just append them here.

• Plugins IMO are actually easier to write because:

  1. I am a coder, not a graphics designer. I don’t even own a copy of PhotoShop.
  2. I write plugins because I have an itch to scratch, and somehow made it distributable along the way. Not true when you are developing a theme.
  3. Plugins can be short (less than 10 lines). No one will use a theme that contains less than 10 lines of CSS.
  4. Browser compatibility is rarely an issue with plugins.

  Then again theme developers rarely have to suffer answering support questions, make sure it works in a few popular versions of WP, different hosting platform, etc. Support question is a killer — I probably spent 5x more time answering emails and forum posts on my plugins, then actually writing the code.

• If your lively hood solely depends on making sponsored WordPress themes, then please go and find a real job.

That’s all folks!

• Old Permalink Structure Redirect. I figured this detailed instruction is way too complicated. So if you have done the wrong thing, chosen a bad permalink structure when your WordPress blog was launched, you can still redirect old permalinks to new without tinkering with Apache mod_rewrite. Just fill in old structure in the options page, and Permalink Redirect plugin will do the rest for you.

• Hostname Redirect. Is your blog accessible via multiple host names? If you are hosting on a Cpanel account (most popular shared hosting control panel), then the answer is probably yes! Visitors can get to your site via www.yourdomain.com and yourdomain.com, but from search engine point of view they are actually two different sites. With Permalink Redirect 0.7, you can turn on an option and it will automatically redirect to the hostname set by Blog Address in the General Options page.

Also a minor fix to the skip rules. Previously it will only check for the path part of an URI, but it will pass in the entire REQUEST_URI to verify skip rules.

Go to the project page and download the latest release now!