da.futt

APC look tricky. Might take me some time.

Okay. Thanks.

Even if you fully clear the cache? I’ve had the same problem.

The thing is that this plugin stores the widget’s parameters whenthe page is loaded, and restores them it the AJAX call.

Since with the Super Cache plugin, the widget is not loaded, and hence the plugin’s hook not executed, we can’t store the values, and then the AJAX call fails.
To alleviate this, the code checks whether the Super Cache plugin is enabled, and if so, stores the widget paramaters directly to the database (and gets them from there in the AJAX call). But for that to work, it has to go through the “normal” loop at least once — before Super Cacha has a chance to do its magic.

Hi liangzai,

Thanks for your feedback.

You are right: it’s not Widget Cache that causes the problem you describe, but rather Super Cache. I’ve updated the code and I think I’ve got it to work now. Would you mind grabbing the development version (trunk) and trying it out?
I haven’t tried the other caches you’re talking about, though.

You’re also perfectly right about the inline JavaScript. I’ve moved that to a separate file.

As for the <noscript /> stuff, how wouldyou propose this should be handled?

df.

Don’t know if we ran into the same issue, but as for me, it wasn’t so much jQuery that stopped working altogether with the out-of-the-box 2.9 install, it was the “$” function that wasn’t defined.
In other words, the regular pages (as opposed to the admin) had been turned into a “no-conflict” zone.
Calling jQuery(... explicitly (instead of $(...) solved it.