Asynchronous Widgets

FAQ

How does it work?

The plugin replaces the callback a widget has registered with the WordPress.org engine
with one of its own. When that callback is invoked, instead of outputting the widget content,
it outputs a customized chunk of HTML. That chunk contains information that will be parsed
on the client side, after the page is loaded, by a short bit of JavaScript this plugin also
injects on the page. This will result in an AJAX call to the server delivering the actual
widget content (one call for each widget).
The HTML also contains a <noscript> block with some information, in case JavaScript
shouldn’t be enabled.

This mechanism is set to run on the wp_head action hook, at priority 2^17.

What’s it good for?

Good question. I don’t know. It seemed like a froody idea.

More seriously though, the main motivation for writing this was an instance where I wanted
the contents of a specific widget NOT appear to search engine crawlers. Since with this
plugin, the widget content won’t be visible unless JavaScript is enabled, this seemed
the perfect way to achieve that goal.

I’m anxious to see whether it can have any other uses, though.
I am also aware that the purpose stated above isn’t entirely uncontroversial.

In terms of performance, this plugin will most definitely increase your pages’
delivery speed (in proportion to how many and how “heavy” widgets you have), and
probably not increase your server’s load average significantly.

Is it compatible with custom widgets and/or other plugins?

Yet another good question. I’m not sure, but I’m trusting you to help me find out.

I’ve tested it successfully with a very few custom widgets. But there might be problems,
due to one significant change this plugin introduces. Namely, the fact that it detaches
the widget display callback from the rest of the WordPress loop (the widget callback is
invoked asynchronously, thus outside of the loop). If a custom widget makes some
non-persistent changes somewhere in the loop AND relies on those changes in its
display callback, there MAY be compatibility problems.

One specific instance I’ve encountered was with the WP Widget Cache plugin
(https://wordpress.org/extend/plugins/wp-widget-cache/) (which doesn’t work with WordPress
2.9, anyway). I had to integrate a little hack (essentially, making the changes WidgetCache
performs persistent) to ensure compatibility with it.

Other such conficts might arise. If you encounter one, please provide some feedback.

Which PHP version does it use?

This plugin has been developped with PHP version 5.3.1.

Can I get hooked?

• You can hook on the action that outputs the proxy HMTL code: async_widgets_output_proxy_html.
• You can filter on the action that outputs the proxy HTML code: async_widgets_output_proxy_html_filter.

Each of these take one argument: the “widget settings” array as would normally be passed
to the widget display callback (they’ll be invoked once for each widget).

If using the filter, you MUST return that value, lest you want to supress the widget’s output.

Can I donate?

No. Go buy yourself something nice.