Why, lookit that:
XML::Parser::Lite::Tree::XPath
It works!
So I let the author know about the mods, if he wants them. But in looking at the code to do this, I think I’d be happier with a “Lite” version. Don’t get me wrong, this is a lovely plugin if you want all of its features. I simply don’t: not the MSN smilies, and not the java stuff. I had to disable it to keep it from slowing my system down. Plus, in the course of modifying the code, I discovered it makes three passes over the content of the entry. Why? I think again cos of the javascripts, but now I want to look at this and see if I can make it a bit leaner and meaner…

And, no, I don’t mean the trendy kind of mashup that’s all the rage in 2.0. I’m talking about when plugins collide. Particularly plugins that run through the_content of a WP blog entry. I have two such at the moment: one that inserts smilies into the text such as this and I have another that renders code within <code> elements as completely unprocessed elements. The two together give rather unfortunate results for:

<code>XML:: Parser::Lite::Tree:: XPath</code>

(notice the strategically placed spaces before Parser and XPath…) as something like:

XML:<img src=’http://www.digitalramble.com/wordpress/smilies/yahoo_tongue.gif’ alt=’&#58;&#80;’ class=’wp-smiley’ width=’18′ height=’18′ title=’&#58;&#80;’ />arser::Lite::Tree:<img src=’http://www.digitalramble.com/wordpress/smilies/yahoo_love.gif’ alt=’&#58;&#88;’ class=’wp-smiley’ width=’18′ height=’18′ title=’&#58;&#88;’ />Path

Ahem.

Now clearly, it isn’t always possible to avoid plugin collisions. Some are just inherently incompatible with one another. But I have to wonder about the notion of indiscriminately putting smilies in where one might not want them to appear, such as in code elements.

There are probably some alternatives. For example, I could use Simple Code to generate unrendered code samples that view properly. But the same reason that this plugin would not collide with the Smilies one is the reason I don’t care to use it: it provides an option under the Write admin panel to cut and paste the code in, and the protected result out. This means that when I’m writing up a post, I have to save it, go to the SimpleCode option, paste the code i want, copy the results, then go back to editing. If I navigate away and neglect to save, I’ll lose what I was writing. Given that I tend to go back and forth with snippets of code, and given that this is a technical blog with lots of code, that’s not convenient (although, I must say it came in handy for massaging the above example, which will go away otherwise when I fix this collision). However if the output from SimpleCode contains anything the Smilies might match, I’m still stuck with potential Smilies appearing even in this.

I could drop the Smilies plugin but just as I’m geeky enough to want the code feature, I’m geeky enough to want the Smilies in the right place.

Hmmm…I foresee some modifications to this plugin.

The Tuneup Plugin has been updated several times and is up to 0.4, so if you’re behind, you probably want to grab the latest version and reinstall. Log out of your admin panel (this step is important, as I found from personal experience…ahem…), drop in the latest version, and log back in.

I’ll echo Mark’s call for people to install this WP upgrade plus the plugin fix. I think I pointed out in my previous post the NONCE implementation that’s introduced. That makes it a key security upgrade, actually. Which is why I went ahead and upgraded despite the various minor bugs it introduced (ah, the joys and ironies of software development…)

Did some light housecleaning today. First of all, I pulled in this plugin called delicious-integrator and so far I’m very pleased with it. I chose to put the bookmarks on their own page partly cos I didn’t want to slow down the sidebar any more and partly because I’ve been taking a little extra effort to include useful commentary on digitalramble’s delicious page so I figured I wanted to show off a little more than just five short ones on the side .

Note to other Dreamhost residents and others with allow_fopen_url disabled at their sites: the current incarnation of delicious-integrator will not work out of the box. You have to go into the file delicious-integrator/delicious.php, find the line containing

$contents = @file_get_contents('http://' . $wpdi_username . ':' . $wpdi_password . @del.icio.us/api/posts/all');

(there is only one file_get, fortunately. Replace it with (or comment it out and add):

/* curl wrapper: */
$ch = curl_init();
$timeout = 5; // set to zero for no timeout
curl_setopt ($ch, CURLOPT_URL, 'http://' . $wpdi_username . ':' . $wpdi_password . '@del.icio.us/api/posts/all');
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$contents = curl_ e x e c($ch);
curl_close($ch);

Take out the spaces in the middle of curl_ e x e c above! (I can’t post it intact here.) That should do it. The options/delicious page you get with this plugin has a somewhat puzzling pair of templates, but what these are used for is to control how the sidebar or page layout goes. You can choose the ordering of items/tags in the page, for example. I put the items first — who wants to scroll through fifty tags before seeing any interesting bookmarks?

Anyway, I’m very pleased with this one, and getting it to work. The fella is aware of the curl substitution, but of course his problem is that some of his clientele do not have the curl library available! I would think that the php function_exists utility would be very useful here.

I upgraded WP, as I described earlier. That went more smoothly than I thought. I certainly hope 2.1 doesn’t require a hasty fix-it plugin by the next day though!

I cleaned up a bit of http/error.log mystery: it seems that the im_smileys plugin does an odd bit of jiggery in putting up what seems to be a smiley popup (eg if you can’t remember which smiley is which) upon clicking on a smiley. For some bizarre reason, it links in the php file itself as the javascript file. I can’t decide if this is some kind of bizarr-o hack where the php file degenerates (via comment trickery) into just a javascript program when src’d as one, or if some other really weird thing is occuring. In any case, it doesn’t work, whether because of the WP version, or what, but what I did was disable the javascript pop up (there’s a setting in the control panels, although I did it by hand into the file since I was poking around thinking maybe it was something being dropkicked to the curb by allow_fopen_url’s settings). So now the error file is free of the “client denied by server” messages for this plugin.

One last plugin left to cleanup! The codesnippet plugin appears to call on a css file within the plugin directory, which causes more “client denied by server” complaints. I’ll try symlinking to that file from another spot and seeing how that works.

In this vein, I must mention I find the statistics available to the Dreamhost resident on their management panel a good way of finding bad links. In this case, they provided a clue about why the error messages were occuring. Basically, you can’t look into the plugins directory via the url. This has to do with my htaccess settings. So that’s kind of interesting. But anyway, pay attention to stats that tell you which files are most often accessed, and which files are not successful on query. Those really help in tracking weird problems down.

I have some further tweaking to do. I’d like a category cloud, without the overhead of the tag warrior. Something very simple that does just that. I’ll probably scale the notables back which are slowing down the page load on front. If that doesn’t work, then I’ll ditch them for simpler just delicious and just technorati links.

The favicon/image through the rss/atom feeds seem to be working. So I’m considering putting together a plugin that allows WP users to control favicons. It would have a control panel that would allow the user to specify an image/icon for the feed, and one for the current theme. Something along those lines. This way I can play around with how to put together a plugin that adds items to the panel.

I’ve also seen theme switcher plugins but it would be nice to have a css switcher one. I’ve seen one for pre 2.0, but not post. Maybe I’ll play with that and see if I get it working. I was thinking in terms of having a font size switch in just css (no need for an entire theme switch for that level of switcheroo). A friend of mind requested something like that (very nice bloke, he’s a florist tho I must say his clientele is kind of odd) for his blog.

There’s additional bling, such as a live comment plugin that would show (my legions, my hordes) of commenters their post as they typed it in. That would be fun. There’s an “email this” plugin I want to use, but I think it ran afoul of the allow_fopen block first time I tried it, so I’ll look at it again now that I’ve got a better handle on that.

There’s just about every kind of plugin out there. There’s a netflix one of all things…they provided an API to get at your queue, I guess. Wow. I suppose I should be thankful no one plugs in their ipod playing lists for me to get an earful when I go visiting…

Well, I’m still hard at work revising the entry page for SCLRR. I have a number of variations, here, here, here, and here. Of course there’s the usual stuff in dealing with a committee of people and a plurality of decisions. We’ll get there. Also the switch over between a shell account with a redirect for the domain (sooo late nineties…) to an actual hosted domain has gone fairly smoothly, although I expect I shall shortly hear from a multitude of volunteers who had their computers memorize their passwords so that they’ve long since forgotten what they are…

The real story is in those drop down menus. I got the idea from A List Apart which has a gorgeous css only (well mostly) drop down menu styling. It seemed like this would be the perfect solution to so many links as on the old one.

Oh dear. That “mostly” contains a drama in of itself. Because it seems that most browsers do just fine with the css definitions which basically involve defining the display to none for the li containers in the ul list (really, really elegant) and then changing the display back to block on hover.

Except of course our dear old friend Internet Explorer 6 doesn’t do hover when it’s not a link. Pish. So there’s a little javascript hackery that rewrites the hover routines on the fly for IE6. All well and good, I snarfed the css file examples, integrated them into the css and js files and went about happily buffing and polishing the newindex page.

Of course, the astute reader will recall that not only do I use Firefox, but I also work on Linux (Ubuntu, and yes I’m ecstatic that Dapper Drake comes out tomorrow, though I’ve been using the Dapper Beta for the last month and titch) so he or she will spot the looming cliff that I am oblivious to. I am also dealing with a crew of very non tech people, so they are all using IE6 hands down.

And of course it turns out that the dropdowns aren’t working at all in IE6. Figuring a conflict between css elements from the original css file with the new stuff, I copied just the example over and sure enough that worked. So I slowly added in all the decorative elements: the background, border, table, finally the multiple column…and it all works!!

So why doesn’t it work on the index?? I start to add in the actual copy (bidding farewell to the trusty lorem ipsum) piece by piece and it finally dawns on me that the javascript for the slideshow is conflicting with the javascript for the hover rewrite. At first I thought it was due to some IE6 weirdness about mixing inline and external js (the slideshow has some elements that must be inline because the perl script generates the values on the fly) but that wasn’t the case. I finally tracked it down to a conflict over the onLoad in windows. Seems that IE6 doesn’t like two of them. When I combined the calls in a single function, it demonstrated its further fussiness by working only when the two were called in a certain order. (I tested this in IE7, by the way, and it worked without the javascript: hallelujia, praise the lord and pass the ammunition.)

So, it was very wrong of me to blame all the problems on the css. I’ve learned that lesson…