Redirection Proposal

Ideas

As many people have heard now, blogs that were previously hosted at weblogs.com are now needing to find new homes. Dave is going to be sending people their backup files but it looks like a lot of links may be broken, and some people proposed keeping a list of the old and new URIs.

Why not go one step better? I apologize if this is not technically feasible for whatever reason, but here’s my idea. DNS is very flexible, Dave can have specific A records for subdomains of sites that are going to stay under weblogs.com, and then set up a wildcard * A record to point to a different IP. This IP could be anyone running a service that would allow people to redirect their old domains to their new ones. Technically this would be pretty simple, no more than a few hours of hacking. The machine serving the redirects could have a wildcard virtualhost entry in Apache and a simple PHP script (or Python script, or RewriteMap) to serve 301 Moved Permanently headers depending on the hostname.

It could redirect to whatever the site owner wanted. The hosting overhead would be minimal. I’m willing to personally commit to writing the code and hosting it for at least 2 years.

Staticize Reloaded

Uncategorized

The caching plugin I pointed to the other day was very well-executed but it didn’t meet my needs for several reasons, mainly that it cached every bit of output, which wouldn’t be appropiate for things like my random photo. (Or my non-rotating photo formerly known as the random photo in the header. It’s on break right now.) My site is a pretty neat system of PHP includes, and I want to preserve that because it makes my life easy and doesn’t slow anything down any perceptable amount.

So I took the Staticize plugin and added support for dynamic non-cached sections, cleaned up the code a bit, fixed a weird problem where it would just show a blank page if it couldn’t write the file, fixed the problem with edit links and the comment form, and made it fit with the WordPress code a little smoother. Full instructions are included with the plugin, but to install just make sure your wp-content folder is writable (you may have already done that when setting up WP) and activate the plugin, and it will start working immediately.

I have a couple more improvements in mind for it already, but it’s fully functional and I’m running it right now.

Download Staticize Reloaded 2.0.

Mosquito Bites

Uncategorized

So it wasn’t even the first day of the bug tracker’s existence when bug notes got rowdy and prompted Shelley to write a post lamenting WordPress developer communication and more. I started to write a reply in the comments, but it got pretty long so I decided to post it here.

Shelley: Different people particpate with the development process at different levels. While I appreciate the point you were trying to communicate, it seems like an inappropiate place to role play a clueless user. (Particularly posting under your own account.) Ryan and I fully realize that the reply would mean very little to someone who didn’t know PHP or diff, but it was a dialogue between you—Shelley Powers the bug reporter who has written several advanced hacks and plugins for WordPress—and a developer who wants to address the problem. Someone else probably would have been treated differently. In the past you have been very indignant when someone assumed you didn’t know something and addressed you at a level you deemed patronizing. In that situation, how is anybunny supposed to respond?

It’s silly for it to come up in the first place. Communication is much more than 50% of successful application, it’s 100% essential because without it the code doesn’t really matter. The project falls in the forest without making any sound. However the bug tracker doesn’t seem like the best place to make this point. If you really feel strongly about this, why not write some guidelines or best practices in the wiki and send a note to the documentation list.

There a thread on the forums which addresses some of this.