Continued from How Apple Enriches My Life…
So no less than 24 hours later, I’m called by the Apple Store, Regent Street, and informed that the replacement optical drive has arrived and is awaiting my return to have it put in. I was told that if I didn’t think I could make it in the requisite 7 days I could just call and tell them when I could and they’d hold the part.
Read the rest of this entry »
WP Super Cache 0.91
Bad Behaviour
Not a conflict, as such, but if you have Super Cache 0.91 and Bad Behaviour running simultaneously, you’ll want to go here and grab the code for wp-content/plugins/wp-super-cache/plugins/badbehaviour.php
and replace the contents of that file. The shipped contents cause Super Cache to look for a directory called wp-content/plugins/Bad-Behaviour
which won’t exist (that’s the old install directory); wp-content/plugins/bad-behaviour
is the current plugin install.
The only down side to this not working properly (I think) is that BB needs static HTML files to work. You can switch Super Cache to support BB, however, you’ll only have Half-On legacy WP-Cache. I suppose this is fine, although, if that’s the case then you really don’t need Super Cache installed at all. I can’t find a decent explanation for any of this so I might be wrong as to the why. I could also find no explanation as to what level of armageddon will ensue if you disable the BB support option in Super Cache and allow it to serve dynamic pages. My guess is BB will simply either not catch any bad behaviour or it won’t work quite right and maybe false positives (?). However, upon looking at the foot of the page source, it’s stating that Super Cache had served it up dynamically. Frankly, I don’t know what’s going on here.
I don’t know which is the worse trade-off: pages loading slower and blocking spam bots, or pages loading quickly but serving them up to any spam bots that come knocking.
Note: I would have assumed that the plugin would do it for me, but I reloaded a page which I think was probably previously cached as compressed and the browser told me the page was compressed with some unknown compression. I cleared the Super Cache cache and reloaded and it was fine…for a while. Now it sporadically does it. I’ve reverted back to the previous options for now.
Typogrify 1.6
Wordpress 2.7.1
The Typogrify plugin seems to wipe out the content of some single post pages when the widow prevention option is activated. I don’t have the patience right now to troubleshoot it, but the wp-Hyphenate plugin mentioned on the Typogrify home page also handles widows and also deals with quite a few other typography concerns. It seems Typogrify and wp-Hypenate will be merged at some point.
Note: if you decide to install wp-Hyphenate, don’t download it from the website and then try to directly install it from the Zip file using WordPress’ plugin installer (i.e. “Add New” in 2.7). The Zip file is a wrapper which encloses the actual plugin code in a superfluous directory and causes WordPress to be unable to find the plugin. If you accidentally do this, you’ll have to log into your WordPress install, go to wp-content/plugins/wp-Hyphenate_1_07_beta
(or whatever the current wrapper version is) and move the enclosed wp-Hyphenate directory a level up into wp-content/plugins
. Also, this plugin doesn’t seem to be available yet on the WordPress plugin directory.
Inquisitor 1.0.2
Inquisitor 1.0.2 is a pretty little add-on that spruces up your Firefox Search Box (similar to Glims for Safari). It’s fairly quick. However, it’s being developed by Yahoo! and even though it gives you the option to use Google as the default search engine it doesn’t respect that choice in the context menu. If you select a word or phrase and right-click, it will show you “Search for ____” but ultimately will bring you to Yahoo! search page. This seems like a bug. At the very least, it’s inconsiderate and possibly offensive to the very sensitive user who actually expects their preferences to be honoured.
The Search Box behaviour seems fine.
Google Analytics for WordPress 2.7
I’ve only seen this happen on one post so it’s kind of hard to analyze. The Google Analytics for WordPress plugin would do a kind of gag-choke thing:

The things you don’t see here are:
- the Adblock link had a “);” appended to it.
- the second link to Pipes has the Adblock URL assigned to it.
The actual code in the posting shows nothing of any interest:
[sourcecode language=’html’]Pipes suffers quite a bit if you don’t disable the Adblock Firefox add-on for pipes.yahoo.com.[/sourcecode]
…except the malformed URLs for Pipes (which, of course, is a problem – but it shouldn’t be the plugin’s problem). When the “http://” was added the plugin behaved properly. However, even though it’s an error in the HTML I don’t think the plugin should lose its marbles. The regex that parses out the URL should maybe grab whatever is in the quotes, perhaps do something with it (perhaps not) but it shouldn’t behave unexpectedly.
Also, the administrative Options panel for the plugin shows this:
