One for the programmers.. WAT (via, RT by SimoRoth)
WAT
Aside
1
Tag Archives: Javascript
Destroy web pages with the simple bookma…
Aside
Destroy web pages with the simple bookmarklet from this page. Clicking the button on that page will launch a small Asteroids-like ship you can fly around a web pages shooting at the page elements and blowing them up. Fun.
HOWTO: Make WordPress plugins work with WP Super Cache
Thaya Kareeson has written an excellent article for plugin developers. It goes through how to make plugins work with WP Super Cache by using dynamic AJAX calls.
WP Super Cache can make static html copies of pages served by WordPress which is great for performance. Unfortunately that means some plugins don’t work because they rely on executing PHP on each request. The plugins need to be rewritten to use AJAX calls by the visitor’s browser. There’s a FAQ in the readme.txt all about it!
I previously wrote about adding AJAX to WordPress plugins but Thaya has worked through a simple example that will work perfectly with WP Super Cache. It’s a good foundation for plugin developers start from.
He also has versions of WP Postviews and Popularity Contest that have been rewritten to support static caching. I haven’t tried either plugin so leave a comment on his blog if you need help!
If you depend on a large portion of your content being dynamic this isn’t the solution for you as it will affect what search engines see. Those bots don’t speak Javascript, but for interactive purposes (ratings, stats etc) it’s the job.
Further reading:
- AJAX in Plugins is a must-read starting point for developers.
- wp_enqueue_script() is the command WordPress uses to load Javascript files. That page links to a couple of good pages too including this best practices post. As of this writing, Thaya’s example don’t use wp_enqueue_script() but it’s simple to use.
The vast majority of plugins work just fine with WP Super Cache, but some of the ones that don’t are quite popular. If your favourite plugin doesn’t work, why don’t you help the author out and fix it? You have all the source code after all and you’ll be helping everyone else who uses the plugin!
Dump Javascript at the end of your page
You’ve seen it plenty of times before. A website loads but only the sidebar appears. The loading graphic in your browser is still spinning and there’s that “contacting …” or “loading …” message at the bottom of your window. Why?
The most common cause of this is because the site uses a chunk of Javascript loaded from a remote site. Think of those fancy chat widgets, Snap.com popups and even hit counters. If those sites are slow to load, they could make your site slow too. The best place to put that code is right at the bottom of the page, after all the content, if you can and it’s appropriate.
I just noticed this happening on Pro Blogger a few minutes ago. Darren’s c2.gostats.com stats are loaded just below the sidebar and because that site was responding slowly the main content part of his blog didn’t display immediately. This may be a storm in a teacup because the next time I refreshed it loaded fine but remember, first impressions count. You don’t want to keep a new visitor to your site waiting.
The ever pervasive Snap.com seems to suffer this sort of problem on a regular basis so be extra careful when you use their Javascript applet. If it takes a while to load, so will your blog.
To further confuse matters, there’s also a bug in Firefox that makes the “Transferring data from …” message appear longer than it should. The guys at Sphere noticed this after complaints their Javascript was loading slowly. It’s all a bit of a mess really!
