Storing the widget callback parameters in the database was most probably\na bad idea, since they may be different from user to user, at least in theory.<\/p>","1.1.1":"
Asynchorous Widgets has been updated to be compatible with WordPress 3.3.1<\/p>"},"ratings":{"1":0,"2":0,"3":0,"4":0,"5":"3"},"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0","1.1.0","1.1.1"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":"1566889","resolution":"1","location":"plugin"}},"screenshots":{"1":"The plugin settings page in the admin section. This is pretty much the only visible\neffect of this plugin."},"jetpack_post_was_ever_published":false},"plugin_section":[],"plugin_tags":[221,8858,241],"plugin_category":[43,59],"plugin_contributors":[92610],"plugin_business_model":[],"class_list":["post-8266","plugin","type-plugin","status-closed","hentry","plugin_tags-ajax","plugin_tags-asynchronous","plugin_tags-widgets","plugin_category-customization","plugin_category-utilities-and-tools","plugin_contributors-dafutt","plugin_committers-dafutt"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/asynchronous-widgets.svg","icon_2x":false,"generated":true},"screenshots":[{"src":"https:\/\/ps.w.org\/asynchronous-widgets\/trunk\/screenshot-1.png?rev=1566889","caption":"The plugin settings page in the admin section. This is pretty much the only visible\neffect of this plugin."}],"raw_content":"\n
Asynchronous Widgets allows you to have any registered widget on your WordPress.org-powered\nsite be loaded asynchronously via an AJAX call. It is configured via the admin panel. No further integration is required.<\/p>\n\n
\/wp-content\/plugins<\/code>;<\/li>\n- Activate the plugin through the 'Plugins' menu in the administration section;<\/li>\n
- Configure the plugin via its settings page;<\/li>\n
- That's all.<\/li>\n<\/ol>\n\n\n
\n- How does it work?<\/dt>\n
The plugin replaces the callback a widget has registered with the WordPress.org engine\nwith one of its own. When that callback is invoked, instead of outputting the widget content,\nit outputs a customized chunk of HTML. That chunk contains information that will be parsed\non the client side, after the page is loaded, by a short bit of JavaScript this plugin also\ninjects on the page. This will result in an AJAX call to the server delivering the actual\nwidget content (one call for each widget).\nThe HTML also contains a <noscript><\/code> block with some information, in case JavaScript\nshouldn't be enabled.<\/p>\n\nThis mechanism is set to run on the wp_head<\/code> action hook, at priority 2^17.<\/p><\/dd>\n- What's it good for?<\/dt>\n
Good question. I don't know. It seemed like a froody idea.<\/p>\n\n
More seriously though, the main motivation for writing this was an instance where I wanted\nthe contents of a specific widget NOT appear to search engine crawlers. Since with this\nplugin, the widget content won't be visible unless JavaScript is enabled, this seemed\nthe perfect way to achieve that goal.<\/p>\n\n
I'm anxious to see whether it can have any other uses, though.\nI am also aware that the purpose stated above isn't entirely uncontroversial.<\/p>\n\n
In terms of performance, this plugin will most definitely increase your pages' \ndelivery speed (in proportion to how many and how \"heavy\" widgets you have), and \nprobably not<\/em> increase your server's load average significantly.<\/p><\/dd>\n- Is it compatible with custom widgets and\/or other plugins?<\/dt>\n
Yet another good question. I'm not sure, but I'm trusting you to help me find out.<\/p>\n\n
I've tested it successfully with a very few custom widgets. But there might be problems,\ndue to one significant change this plugin introduces. Namely, the fact that it detaches\nthe widget display callback from the rest of the WordPress loop (the widget callback is\ninvoked asynchronously, thus outside of the loop). If a custom widget makes some\nnon-persistent changes somewhere in the loop AND relies on those changes in its\ndisplay callback, there MAY be compatibility problems<\/strong>.<\/p>\n\nOne specific instance I've encountered was with the WP Widget Cache plugin\n(http:\/\/wordpress.org\/extend\/plugins\/wp-widget-cache\/) (which doesn't work with WordPress\n2.9, anyway). I had to integrate a little hack (essentially, making the changes WidgetCache\nperforms persistent) to ensure compatibility with it.<\/p>\n\n