1. WordPress changed the way they bind the save event in the widgets.php form to use the jQuery().live(‘click’,…) call

   This subsequently caused my plugin to not be able to selectively unbind and rebind just the save button click event of the about me widget. Instead we had to unbind all the widget save button click events – due to a quirk in how jquery live() and die() methods work, and then bind a custom click event to all the widget save button click events, and then check the source widget that raised the event, so if it is the about me widget it then triggers an mce save and then calls the functions from the original save button click event.

2. The version of tinyMCE shipped in WordPress 3.1 has an updated triggerSave() function that forces the form postback when called.

   This has the annoying sideaffect of breaking the ajax widget save event. So I changed the click event of the widget save button to call tinyMCE(editor).save() instead, which doesn’t force a form postback but does cause the rich text from the editor to be saved in the textarea.

So without further ado, I give you the latest version of about me widget, v2.2, compatible with WordPress 3.1.

Same disclaimer as for the last time I fixed the widget to work with WordPress v2.9.x.

Since I use this plugin on my blog I will actually be taking a look at it in the coming days/weeks/months depending on how busy my regular day job keeps me. First appearance seem to indicate yet another change in the way the ajax save button works on the widgets page causing borkage in the ugliness I had to use to get the widget to save correctly last time.

We might end up being locked in this duel with the WordPress widget page author’s for eternity methinks

Update: I’ve identified the cause, and to fix it will require yet another save click hack that I am reluctant to apply just yet. Have posted to wp-hackers to see if there are any alternatives to geting this fixed.

Source: Flikr

I was having a water cooler conversation that turned into a debate with someone at work yesterday. We were talking about approaches to styling WordPress blogs using themes.

I’ll take this opportunity to digress before diving into the detail and tell you about a particular ethos at Gruden. This is obviously the preach part of the post.

So at Gruden we believe strongly in web standards and accessibility, but at the same time, we believe just as strongly in usability, user engagement and simplicity in design. In fact we believe you can and should have all of these in everything you do on the web, it’s the kind of thing we take a lot of pride in doing for our clients. But as anyone who’s tried to do any reasonably non-trivial interactive, accessible and standards compliant stuff on the web can tell you, it’s not always the easiest thing in the world to do. And it’s not something you’d normally want to invest time in when you get home from work, especially for something as pre-canned as a blog.

Well actually, for people like us at Gruden, it is.

So back to the debate… So Peter was telling me that it would be trivial to knock up a customisation on a WordPress theme in 4 or so lines of php code and thought that that was the best way to style a blog. I was busy extolling the virtues of K2 and insisting that it was the best approach. Having spent many a year as Development Manager in the online space, one thing I’ve learned is that the less actual programming languages you need to work in, the better… And we all need to know css right?

My argument behind K2 was this; I refuse to invest any time in any component that is more likely to have someone as passionate about this stuff as me with more available time to tweak it than I ever will. Hence my preference to buy before I build. I want a theme that has the best of the standards and usability world (i.e. AJAX enabled etc.) and I want to be able to style it with css alone.

For a long time, K2 has been that for me. I didn’t want to touch a single line of php code to style my blog. I was more than happy to modify a stylesheet (I can still wrangle css like a semi-pro these days), but I wasn’t going to make application changes that touched the main-loop.

Peter’s argument was that he’d much rather be as close to the rails of the core system, for the sake of being up-to-date with updates than use yet another link in the chain of infrastructure from db to content being served to the client.

Interestingly enough, we were both arguing the same point, just from slightly different perspectives. Peter thought that a few php lines of code were easily maintainable, and my point was that merely updating a css file was far more maintainable (think future proofing against WordPress upgrades). Along the way through this debate, I had to concede to Peter that in fact K2 is no longer that well fitting a solution to my needs, since it hasn’t been updated with WordPress for a while, and the markup isn’t the nicest in the world.

So I throw out a random comment, “I’m sure someone is bound to take the Html 5 boiler plate stuff and wrap it round a nice functional WordPress theme, I’d even be willing to do that to twenty ten eventually.”

Enter thematic and wordpress child themes with HTML 5 boiler plate pre-rolled.

This is a wordpress theme engine, that makes it easy to put together a minimalistically plumbed (i.e. just the css thanks folks) theme using WordPress child themes and gives you all the bells and whistles expected in today’s web. And to top it off it seems to be maintained and updated pretty much in synch with WordPress updates. Have I mentioned lately how I love the fact that if I need to do something with WordPress these days someone’s already done it as a plugin?

Anyhow, I look to move my theme style across to thematic with HTML 5 boiler plate at some stage in the near future (the practise part).

As mentioned in I’ve updated the about-me-widget to be compatible with WordPress 2.9 changes. The changes I made should be backwards compatible to 2.8x too.

Download the latest version of the about-me-widget now.

Technically, I’m not particular proud of the things I had to do to get the plugin to work, it’s not the cleanest solution. But I even checked in with wp-hackers and the consensus there seemed to be that the work arounds are the most practical solution for now. Regardless, the plugin still works perfectly for end users, so download away.

Just a quick update to let you all know that I just updated the about me widget over at codex to be compatible with the new WordPress Widget API. I decided to contact Sam and get access to the repository on codex, rather than host the download on my blog locally. Feel free to discuss installation or other issues in here.

I bumped the number up to 2.0 since it was a complete re-write to make it work in the new Widget API. The new API makes it incredibly easy to write regular widgets, but incredibly difficult to write plugins that require rich controls that use their own kind of ajax, tinyMCE being the candidate in this instance.

I had to do some very evil things to make the tinyMCE editor able to save it’s html into the textarea on the save button click event (since that triggers the ajax postback, not the form submit event that tinyMCE is watching for).

I also had to do some very bad things with respect to page loading and click event binding to get tinyMCE control to survive the ajax widget re-ording events. Apparently drag-and-drop destroys the underlying controls in the widget div which leaves the tinyMCE editor orphaned with no active window. The only way I was able to work around this issue was to bind the widget settings button (the down arrow) click event and literally remove the editor from the DOM, using jQuery().remove() and then re-init the editor and show it.

This is the only way i was able to get the tinyMCE editor able to both survive a sort event, and bind to the textarea. I don’t like because it means everyvtime you try to edit the about me widget you have destroy and re-create the tinyMCE editor and rebind it to the textarea. It works, it’s just not clean.

I suspect the WordPress dev’s will be changing the API to give it more hooks and mature it’s ajaxy-ness as time goes on.

Plugin link: http://wordpress.org/extend/plugins/about-me-widget/

Actually I’ve had the majority of the widget done, and simplified for more than half that time, but I’ve been struggling with one issue since; how to get the rich text from the tinyMCE instance into the textarea on form submit so it will be saved. And let me tell you… it’s been a tail of one annoying discovery after another.

First let me say that the new widget API is impressively simple and a breeze to work with, however in many ways it reminds me of the iPhone, fantastic so long as all you need to do is what the original engineers thought you would ever want to do. In other words it has some limitations, and they’re mainly around the wp-admin/widgets.php page itself instead of the api.

Where to start?

Each widget admin form is rendered in it’s own form, fantastic, but the form has no id or name, boo. It took me a ridiculous amount of time to figure out the correct jQuery foo to get the form encompassing the current widget so that I could try and add a submit hook. Which brings us to the next issue, try as I might I could not find a way to actually catch the form submit event and force the tinyMCE widget to copy the html to the textarea. I soon discovered that this was because the form is never action submited, in fact the widgets admin page wires the ajax request to the onclick event of the save button. That’s right, rather than adding an onsubmit event handler to catch the form and ajax-ify it, they use an onclick event. If they’d actually used the form submit event then the tinyMCE auto detection would have worked on it’s own.

So as it stands we have a whole bunch of html foms with no id’s or names, which are ajax-submitted by an onclick event of the button. Not the best way to do it, but workable. So the next step is to register an onclick event hook on the button using jQuery and just force the tinyMCE.triggerSave() call in there.

Nope. That won’t work either, since jQuery fires all the click event’s asynchronously and the generic form submission click event is bound before my custom event. There is no way in jQuery to reorder the event bindings, you can only unbind them and add your own. Dirty, dirty, dirty.

I’m going to digress now to talk about Anthem.Net, an ajax library that knew how to integrate on both the client and server. Anthem did ajax exactly as I’d expected it above, it caught the form submit event, built an asynch request, fired it off and then updated the page with the new content. This conversion of a .net form postback concept to an ajax mechanism was named a callback in Anthem terminology, and Anthem provided a way to catch the event on both the client and server. On the client side it provided another event called onprecallback (or similarly named), which would allow the developer to hook in any client side code that needed to be run before the form was submitted. I was sorely missing this feature while working on this widget.

So now to the widget, what I have to do is unbind the save button’s click event, bind my own event that does the tinyMCE.triggerSave() call and manually call whatever functions it was that the save button’s click event was meant to call.

Not a clean solution at all, but it works

I’m disappointed that this plugin uses yet another theme engine (Carrington as opposed to K2).

Let me know in the comments if your phone doesn’t render nicely or you experience other issues.

I still have to tweak some subtleties (text and link corlours as well as header sizes), but it’s still pretty indicative of what the intended design was to look like.

K2 made this job far more easier than I thought it would be, though I did have a few issues with it’s use of padding css. In my experience padding and cross-browser design just don’t go together. You better served to try and make the design work with margins.

Thanks to my friend Joe Smith, for the original inspiration for this site’s current look and feel

About Me widget working in WordPress 2.7

So I’ve been doing some spot cleaning in preparation for the new look and got side tracked making the rich text editor work in the about me widget on wordpress 2.7.

I thought I should share it with the rest of the world, so I guess I’ll add a zip file containing the widget to this post. The question is, do I go through all the effort of adding it to the wordpress plugin directory, and if so do I add it as a new plugin?

Download: About Me Widget for WordPress 2.7 (302)

Update: Make sure not to change the folder name in the plugins folder as there is a hard-coded reference to it as in this comment.

P.S. If you do download it, please leave a comment to let me know how it goes for you.

Final Update (20 Oct 09): I have updated this plugin to work in the new WordPress Widget API (as of 2.8.2). Rather than host the download here I have updated the plugin at the WordPress plugin repository. See this blog entry. For now, I’ve closed comments on this blog entry, please leave any comments in the new entry.