Widget Voodoo Release 1.0.3
The new Widget Voodoo release, 1.0.3, fixes a small (but annoying) misbehavior with the Tag Cloud widget.
Please update to the newest version to avoid future (bad) surprises.
What’s the snag?
Some widgets are ill-formed in that their contents (that is, anything but their title) are a just a mixture of text and a bunch of HTML elements, not grouped under a clasping “body” tag. Alas, such a tag is needed to collapse the widget contents without deforming their layout. For that reason, Widget Voodoo automatically wrapps ill-formed contents in such a “body” tag.
Unfortunately, the jQuery operation normally used for wrapping does not always behave as expected. Worse, it behaves differently with different versions of jQuery.
Therefore, I re-implemented the wrapping algorithm in a more robust way. This release is the result.
- Widget Voodoo PlugIn Released
- Widget Voodoo 1.0.2 Release
- Widget Voodoo Release 1.0.3
- Widget Voodoo Release 1.0.4 Supports Variable Title Styling
- Widget Voodoo 1.0.5 With WPMU Compatibility
- Widget Voodoo 1.0.6
Hi (and happy Easter!)
(this post is about the delay of colapsing on page loads)
I read the link you sent me to and the tweeking manual, but I don’t see there mentions of why there’s no “start closed” as opposed to “auto-colapse”. But yes, I understand that there’s a problem if your css is executed too far down the line, leaving the auto-colaps elements visible a bit at the begining.
Also I was wrong: 1.0.2 showed the same behaviour, it’s just that I noticed it after the upgrade. It’s understandable that on a local server it gets done really fast. But for example, on your site, a page refresh gives a noticeable delay on the colapsing of the archives list (I have a 5Mbit link).
I have to say I have quite a few widgets on my site… but I’ll play with my theme a bit see if I can hide them from the start.
Hi Charles,
happy Easter to you, too.
I moved your comment from where you posted it to this post, as it belongs to this discussion. Please stick to discussion threads to keep confusion for other readers low.
The thing is, there is no WordPress mechanism (action or filter) to adjust widgets at page generation time. Instead, the morphing takes place with JavaScript, after the page was loaded. It has nothing to do with CSS “execution”. That’s also why “auto-close” is possible, but “start-closed” not.
I think it’s possible to tweak the theme to achieve better perceived performance, but not in a generic way usable in all context, or all themes. Unfortunately, since widget code is by no means bound to any rules regarding its output, tweaking the theme may not do it all.
Hi, I don’t know, it seems my previous comment disapeared. Anyways, thanks for the quick modif! However as I said I can’t test it since I already made modifs to my theme. There’s one side effect thought. The “start closed” items actually start open and quickly close after the whole page is loaded. An interesting point is that the sliding notes are ok (I have one on top “Veuillez noter”).
Hi Charles,
actually, the changes that I made only affect cases with ill-formed widget bodies, so there should be no difference in perceived performance to the prior version. (There are no “start closed” items, only “auto-collapse” items. I’ve elaborated on the Why’s in the Theme Tweaking Manual.)
The effect you describe was there before, and it’s “visibility” depends on what other JavaScript code is executed else (Analytics, Ads, Membership Logos etc.) Perceived performance also depends on whether you have moved JS to the footer (by means of the Footer JavaScript plugin, for ex.) or not, and how many widgets are processed/collapsed in total. For ex., on my local test server, without ads and analytics, the time between loading the page initially and collapsing the selected widgets is so short I don’t ever see it.
However, if there is a difference on your site, I’d appreciate it if you could re-install the prior version (as you have already changed the tag cloud widget), so I can have a closer look at what might be causing it (at my site there’s no difference to before).
Thanks.