Technocrank

Typogrify 1.6

Something’s a little loose in Typogrify’s pattern matching code.  There’s an option for it to

Add <span class="amp"> to ampersands.

…which does just that, but it doesn’t check the context of the ampersand’s placement.  It will grab an ampersand in the middle of an anchor tag, for instance say, in a title attribute and nuke it.  The results are this:

<a title="Bob <span class="amp">&amp;</span> Doug McKenzie" href="http://www.hoser.com">Take off, eh?</a>

…which leaves a broken link and HTML guts all over the page.  Like, you really don’t need that many double quotes in there, do you now.  The regex code in Typogrify works if instead of “amp” it used ‘amp’ with single quotes (unless your attribute is enclosed with single quotes).  At least it doesn’t break the HTML into tiny little pieces.  However, there’s a larger question as to whether or not you really need a span inside an title attribute – or even anywhere inside HTML code.  It’s more code to do a check that you’re not pattern matching inside HTML tags, but it’s been done.  Maybe this will be addressed in wp-Hyphenate when it gets rolled in.

All In One SEO Pack 1.4.7.3
WP Super Cache 0.9.1

WP Super Cache supports server-side compression which you’d think is a good thing.  It doesn’t seem to play nice with the All In One SEO Pack, though.  You’ll need to turn compression off and delete your cache to get the two to work together.  Funny trade-off, though: if you’ve installed the SEO pack then you obviously want to increase traffic to your site.  Assuming this works, it would be of benefit to have server-side compression working to reduce the load on your server.

As an aside, I like the second comment on this forum posting:

“Why are you using crap like Super Cache anyway? Get rid of it entirely. Get 1BlogCacher — it’s simple, it works without problems, and it’s very, very good in making your blog static. And yes, it works with all other plugins without trouble.”

I assume he’s referring to a different caching plugin.

wp-Hyphenate 1.07 beta
GigPress 1.4.5

I have a site that uses GigPress and in order to get it to embed its own code you need to insert a [gigpress_upcoming] (or similar) code into the page.  However, when wp-Hyphenate is activated it seems GigPress gets skipped and the string literal “[gigpress_upcoming]” gets regurgitated onto the page.

Update: It is indeed a known problem by the developer who quickly got in touch with me and informed me that it’s fixed in the upcoming release.  If this is actually bugging you and you need a quick fix you need to edit wp-content/plugins/wp-hyphenate/wp-hyphenate.php around line 94.  Change:

[sourcecode language=’php’]
add_filter(‘category_description’, ‘hyph_preProcess’, 10);
add_filter(‘comment_text’, ‘hyph_preProcess’, 10);
add_filter(‘the_content’, ‘hyph_preProcess’, 10);
add_filter(‘the_excerpt’, ‘hyph_preProcess’, 10);
add_filter(‘the_title’, ‘hyph_title’, 10);
[/sourcecode]

to

[sourcecode language=’php’]

add_filter(‘category_description’, ‘hyph_preProcess’, 9999);
add_filter(‘comment_text’, ‘hyph_preProcess’, 9999);
add_filter(‘the_content’, ‘hyph_preProcess’, 9999);
add_filter(‘the_excerpt’, ‘hyph_preProcess’, 9999);
add_filter(‘the_title’, ‘hyph_title’, 9999);

[/sourcecode]

Which forces wp-Hyphenate to do its duty last.

jQuery Lightbox (Balupton Edition) 1.3.5

jQuery Lightbox (Balupton Edition) WP plugin 0.5

There are a million lightbox implementations out there and almost as many corresponding WordPress plugins.  My favourite is the jQuery Lightbox (Balupton Edition) which, in my opinion, is one of the best looking ones out there.  A lot of them go for flashiness but end up looking tawdry or, in their attempt to be pretty end up suffering usability issues.   The jLB is simple and attractive.  I use it in conjunction with the Add Lightbox plugin.

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.