Staticize Reloaded

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

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.