A few days ago I wrote about how to configure Wordpress to use Google’s cache proxy servers to serve images. After writing that entry I kept thinking to myself that there had to be a better/easier way to accomplish this other than changing Wordpress settings. Well I finally figured it out and got it working on my other blog DavidChiu.net. It involves using mod_rewrite and symbolic links. First you need to create a symbolic link to the Wordpress /uploads/ folder. For example:
ln -s wp-content/uploads/ images/cache
Then you just need to modify your .htaccess file:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^.*wp-content/uploads(.*) http://gmodules.com/ig/proxy?url=http://davidchiu.net/images/cache$1 [R,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
And voila! All images will now be served by Google’s proxy cache!
On my other blog One Man’s Wishlist, I’ve configured Wordpress to use Google’s ad proxy cache to serve my blog images. The setting to change is “Full URL path to files” under Settings->Miscellaneous:
The path needs to point to: http://gmodules.com/ig/proxy?url={path to your uploads folder}. The downside is that this setting will only apply to images inserted into new posts. Old images in posts will need to be changed using a search and replace plugin or manually.
As mentioned in my previous entry, I converted davidchiu.net from MT to WP. The migration was pretty easy and I just followed the instructions I found on Wordpress.org. The only thing is that I didn’t care for their solution for redirecting previous MovableType permalinks to new Wordpress pages. So I came up with my own solution: create a custom WP 404 page which redirects the user to a search results page. The effect would be this:
If a user comes from an old MT permalink such as http://davidchiu.net/2003/05/some_old_title.php that does not correspond to an existing Wordpress page, convert the filename to a title fragment (ie, some_old_title.php becomes “some old title”) and return a Wordpress search result.
This should take care of all old permalinks. The corresponding code is pretty simple. I just added the following code to the top of my custom 404 page:
<?php
$filename=basename($_SERVER['REQUEST_URI'],”.php”);
$filename=basename($filename,”.html”);
$title=ereg_replace(’_|-’,’ ‘,$filename);
header(”Location: http://”.$_SERVER['SERVER_NAME'].”/?s=\”".$title.”\”");
?>
The first two lines strip either the “.html” or “.php” extension from the original request URL. The ereg_replace() function converts any underscores or dashes to spaces. Finally, the header() function redirects the user to the Wordpress search result page for the title fragment.
In my initial tests it works great. Let me know if this code could be better.
I’ve finally converted my longest running blog - davidchiu.net from MovableType 4.1 to Wordpress 2.5.1. This wasn’t an easy decision since I’ve been using MovableType since 2003 but Wordpress now provides a compelling solution for blogging. One of the deciding factors was the template/styling implementation in Wordpress. If you do quick Google search for Wordpress Themes you will see the amount of support that Wordpress has - granted, most of the Wordpress themes out there are crap, but there is a huge community developing for Wordpress. The same is true for Wordpress plugins. Conversely, MovableType does not have the same amount of community development. The only thing I worry about Wordpress is performance. MovableType has the option to pre-render an entire site and publish static files to the file system, whereas Wordpress dynamically creates pages on the fly. MovableType has the obvious advantage here but there are caching strategies people are using through plugins to overcome this disadvantage. Ultimately, Wordpress is just easier and faster to use than MovableType and with web2.0/syndication plugins such as Wordbook and Twitter-Tools Wordpress is too attractive to pass up. Plus, migrating to Wordpress was painless.
I spent a couple hours trying to diagnose why I couldn’t log into one of my blogs that used the Tarski theme. Every time I tried to login Wordpress would just hang forever. At first I thought it might be due to the Wordpress 2.5.1 update so I reinstalled. Then I thought it might be a database corruption so I created a new database and imported all my entries. Then I thought maybe it’s the plugins so I removed all plugins. Nothing seemed to work. But then I noticed that there were “edit” links on my blog entries - indicating that I was successfully logged in. So I clicked on the “edit” link and discovered I was able to edit entries. I just couldn’t get to the Dashboard or Tarski Options. So I tried going to the Tarski theme website looking for a possible solution - only to find that their website was not responding. That gave me a clue to start looking through the Tarski theme files for callbacks to the Tarski theme website.
VOILA!
It’s the stupid Tarski theme version checking function that’s hanging because it’s not able to retrieve the atom feed from their website. So I just commented out the code and now my blog is back to normal. The problem lies in wp-content/themes/tarksi/library/classes/version.php. I chose to disable version checking completely by commenting the body of the tarski_update_notifier() function on line 196:
function tarski_update_notifier($location = 'dashboard') {/*
$tarski_version = new Version;
$tarski_version->current_version_number();
$current = $tarski_version->current;
$svn_link = 'http://tarskitheme.com/help/updates/svn/';
// Update checking only performed when remote files can be accessed
if(can_get_remote()) {
// Only performs the update check when notification is enabled
if(get_tarski_option('update_notification')) {
$tarski_version->latest_version_number();
$tarski_version->latest_version_link();
$tarski_version->version_status();
}
$latest = $tarski_version->latest;
$latest_link = $tarski_version->latest_link;
$status = $tarski_version->status;
if($location == 'options_page') {
include(TARSKIDISPLAY . '/admin/version_options.php');
} elseif(!detectWPMU() || detectWPMUadmin()) {
include(TARSKIDISPLAY . '/admin/version_dashboard.php');
}
}*/
}
But the problem really lies with the version_feed_data() function on line 66. They need to set the timeout option for CURL and use ini_set(’default_socket_timeout’, $seconds); before calling file_get_contents(’http://tarskitheme.com/version.atom’);
TO THE CREATORS OF TARSKI: FIND A BETTER HOST AND FIX YOUR CODE!!!
TO THEME CREATORS: LEARN FROM THIS LESSON!!!!!