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.
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:
<a href="pipes.yahoo.com">Pipes</a> suffers quite a bit if you don't disable the <a href="https://addons.mozilla.org/en-US/firefox/addon/1865">Adblock Firefox add-on</a> for <a href="pipes.yahoo.com">pipes.yahoo.com</a>.
…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:
Well, looks like I can retire WebKit for a little while. The Safari developers have released a beta of version 4. I had a bit of trouble starting it at first (Mac OSX 10.5.6). It was the Glims plugin which was crashing it. I removed it from /Library/Application Support and Safari started up nicely.
Update: Turns out Google Gears doesn’t work in this Safari 4 beta.
Update 2: The Glims developers have release a new version which doesn’t crash Safari, but is missing a chunk of functionality.
Update 3: Safari, even in the development WebKit nightlies exhibited an irritating “bug” with the WordPress 2.7 administrative interface. It would cause a modal overlay dialog to hang. The dialog appears when editing a post with the visual editor (e.g. add a link, upload images, etc.). This is still quite present in 4 beta.
Update 4: (June 11, 2009) The bug mentioned in Update 3 with the modal dialog has been fixed in Safari 4.
Firefox 3.1b2
Google Gears 0.5.4.2
You know what would be really faboo? If the devs for Google Gears figured out it was worthwhile looking at the non-compatibility issue with Firefox 3.1 and Google Gears. I know, I know, it’s free software and there are a million other things to get to. And they’ve said (unofficially) that by the time Firefox 3.1 gets out of beta they’ll be ready. The only reason I’m asking is this:
There are now a preponderance of sites out there now that are JavaScript heavy. All Google products, Facebook, MySpace, and yeah, WordPress – especially the admin backend which is now AJAX supercharged. So when you’re dealing with these sites a lot it really makes a big difference having a browser that can crank through the JS routines and render the damn page already. This is why I’m working with the beta version of Firefox 3.1 (actually, now the OSX optimized version, Shiretoko – there are Windows versions out there too) which has the Tracemonkey JavaScript engine enabled. It’s quite fast; incidentally I’m also testing WebKit, the Safari engine development version which is right up there too.
Anyway, FF 3.1 makes a big difference in shaving off my waiting time, especially here in WordPress-land. And incidentally, the kind folks at WordPress have incorporated Google Gears functionality to offload the download…load. Works great on WebKit/Safari, but since the Gears guys haven’t worked out the FF 3.1 compatibility yet, we’re still waiting.
Not a big rush, really…but it’s Valentine’s Day. Blow me a kiss, boys.
Spent a whole day on this. Thanks Hostgator.
PHP 5.2.8
Apache 2.2.11
Wordpress 2.5
Xinha4WP 1.2b
WPG2 3.0.2
A client’s WordPress install recently started giving them trouble. It’s installed alongside Gallery2 with the WPG2 and Xinha4WP plugins. They hadn’t touched their site in a while but now they found that when trying to invoke Xinha4WP’s Image Manager they would get a 404 page popping up instead. So it would have seemed that the path that’s either getting passed to the plugin or the way it’s being parsed had changed.
Disabled all the other plugins. That didn’t work. Upgraded WordPress to 2.6.5 (in case they’d made some changes that accounts for PHP quirks). No change. Contacted Hostgator and asked if anything would have changed in server settings that would affect the path (e.g. mod_rewrite, etc.). Nope. Reinstalled the Xinah4WP plugin in case Hostgator had somehow corrupted. Nothing.
Finally Googled (okay, now, this is after hours of Googling various things) “WordPress” and “hostgator” and it came back with the WordPress forums. Turns out, there was a recent modification to their Apache setup involving mod_security and suphp.
Contacted Hostgator, and oh yes. That was the problem. They did something on their end and it’s now fixed. &!^(#*@
