Jon

"Nice fix! Sorry you had to hack around our problem. If it's any consolation I think this is fixed for others as of today by replacing window.location = '#idc-container'; with window.location.hash = '#idc-container'; Which should already by live. If you'd prefer not to poll to check when IntenseDebate loads, we offer some JavaScript hooks to detect that via our plugin system. There's more info here: http://www.intensedebate.com/docs...... but the basic idea is that you can register a JS function that we will fire on certain events (including IntenseDebate loading). Might be a slightly nicer solution if you're interested in poking around. Again, sorry for the trouble, but nice job working around it!" - Jon

"I'm not convinced that that would be the most likely case. Blogger, as far as I can tell, is generally pretty relaxed about free speech and I don't think that the Bum's blog could be considered 'hatred' except by the most thin-skinned of complainants and similar responding Blogger employees. I may be wrong (but I sincerely hope I'm not). It might (and I'm not entirely convinced that this is the case) have been something to do with the recent (IMO overblown and confused) betwixt the Bum and Heather over at Why Don't You, but I can't see him dumping his entire blog over that. Saying that, he closed it down previously for no reason that I could see, and then resurrected it. Maybe it's just one of those "ah, fuck this blogging malarky" things... *shrug*" - Jon

"The update should appear on your WP plugins page now. If for some reason it's not, you can always download it from here: http://wordpress.org/extend..." - Jon

"Yes this is true. My main concern with 3rd party scripts is that the end of the first script might not be the end of the necessary JS. Often remote scripts will then load multiple other objects/scripts that may be necessary for the code to function properly. And since it's a remote script, even if this isn't the case today, it could be tomorrow ;-) It's a safe bet if it's your own JS though that you know when the last bit of JS you need is and can insert it there. You can even include it as a conditional paramater in the script request if you don't want it to load all the time. Like: http://mydomain.com/js... Or something similar, which can then be setup to only include the function call when that parameter is set." - Jon

"Interesting technique. I've not seen this queuing method before, but I have seen another method of dealing w/ this problem that is very similar. Basically, the idea is that when you load the javascript links initially you give them dummy functions that queue the function call, but then replace the href once the javascript is loaded (and execute the queue). It avoids the wrapper but at a rather expensive replacement of the links. I think your idea of a wrapper function is a bit cleaner, but generally eval is pretty bad with large functions/bodies of code in my experience, so the other technique may work better if it's any more complicated than a straight function call. One thing you might consider to get a slight bit of extra performance is adding the dequeue_actions(); call to the end of the javascript you're loading (assuming you control the script and it's not loaded from a third party). This will allow the js to execute as soon as the necessary javascript is loaded instead of..." - Jon

"This is a personal blog, not an IntenseDebate support channel. I'm sorry if you're support concerns have not been addressed, but your comments are unrelated to the post the comments have been posted on and that's why the comments were deleted. If you'd like to follow up with one of us you can email us at jon@intensedebate.com, michael@intensedebate.com, and/or support@intensedebate.com. Thanks for understanding." - Jon

"Give IntenseDebate a try!" - Jon

"Very exciting" - Jon

"test sdafdsf" - Jon

"test 5" - Jon

"test asdfsdasdf" - Jon

"test 9" - Jon

"test 8" - Jon

"test 2" - Jon

"test 10" - Jon

"test 2" - Jon

"test 7" - Jon

"test 6" - Jon

"test 3" - Jon

"test 10" - Jon

"test" - Jon