Category Archives: WordPress

The open source publishing platform I co-founded — development, releases, community, and the ecosystem.

Staticize 2.5

Version 2.5 of the Staticize Reloaded plugin is now available for download. Installation instructions are included in the archive. What does Staticize Reloaded do? It is a highly advanced caching engine that dynamically and automatically caches pages on your site that need to be cached, when they need to be cached. It also allows for some parts of a page to be cached and others not to be, so for example your menu could always be dynamically included from a single file while your main blog content was cached. With Staticize Reloaded you don’t have to worry about rebuilding, stale caches, slow posting times, or any of that. It works silently, efficiently, and trasparently to both the end user and the author.

This version adds the ability to have dynamic functions on a page in addition to dynamic includes. It also adds full support for etags and last modified headers, though you must turn it on in the plugin file. My one tip is that when you redesign or tweak your template temporarily deactivate the plugin. Staticize Reloaded is well-suited for sites on older servers or that receive more than twenty thousand visitors per day. WordPress is so fast anyway I find it’s not worth caching on lower-traffic sites.

Update: The zip archive had a slightly older version of the plugin than the final 2.5 release. Please re-download to get the latest and greatest and fastest.

NetNewsWire Subscription Favelet

NetNewsWire Subscription Favelet that uses Mark’s excellent feed finder. Seems like a good hybrid solution. I have been less than impressed with NNW’s autodiscovery performance. In a perfect world I could take my OPML file (which only contains site URIs, not feed URIs) and it would import and autodiscover every feed. Also there seems to be no WordPress setting for weblogs. I’m new to all this, so some of this may be things I’m missing.

Mac IE 5 Support Worth It?

In Joining the Dark Side -OR- Is Mac IE 5 Support Worth $1,500, Scott responds to Tantek’s calling out of the new Feedster’s lack of support for Mac IE. Personally I’m sympathetic to Feedster’s case because I’ve had to spend hours talking to someone with a Mac trying to debug Mac IE issues with this site and wordpress.org and ended up having to change my favorite list menu technique from using floats to display: inline, which meant changing all the other menu styles to compensate. It was a pain.

I know that when I’m tweaking and checking things in different browsers, the number of my audience who uses that browser isn’t always the most important thing. In the previous case the only Mac IE I had heard anything from since both of the sites started was Tantek, and that was important enough to spend a couple hours of my time on. Imagine if you’re doing a job and the client’s boss uses Netscape 4, (god help you and) suddenly that browser becomes much more important in your testing, and you should triple your rate.

However, is this something the Web Standards Project should be interested in the same way we have been All Music or Odeon? I don’t speak for anyone but myself, but in my opinion it’s not the same at all. Feedster’s pages are a few trivial mistakes away from valid XHTML 1.1 and valid CSS, which is no easy task. (MIME issues aside.) Of course they should fix those mistakes, but it is a matter of a few minutes rather than 1-1.5 days. They aren’t writing to one browser or propietary technologies, they’re writing to modern standards and excluding browsers that have serious flaws in that area. Is that so different from the browser upgrade campaign?

From a user experience point of view, excluding Mac IE users might be a good idea as well. If Feedster allowed Mac IE users to visit and they saw a messed up layout (or no layout at all), as Tantek has suggested, then their perception of the Feedster brand, reliability, and image would be negative. I bet Keith would have some great thoughts on this. If they’re given a message that the site doesn’t support Mac IE, (honestly) they’ve probably seen this before and will just switch to another browser for that site. In my experience Mac users tend to be total browser flirts, and have every browser you’ve ever heard of installed. I would rather they open up my site in Safari or Firefox.

If Tantek was here I imagine he would counter that those browser options are really only valid for users on OS X, and that ignores hundreds of iMacs and such in libraries and such. Of course the question that a site owner needs to ask himself then is that in terms of costs and benefits, does that half of a single percent audience in libraries on older computers overlap with the audience you’re targetting with your site? If I was doing an ecommerce selling something like BMW accessories, I wouldn’t even give it a second thought. This isn’t about the many innovations that Mac IE introduced or its excellent standards support for its time, the issue is where Mac IE stands today.

On the bright side, Feedster has characterized this as a business cost/benefit decision and said if anyone sends them Mac IE CSS they’ll use it, which seems like a good concession. Of course I think Feedster should support Mac IE, and a day and a half to add support seems a little high, but if they choose not to I can understand.