I made some additions to the site over the last few days. The first one I’d like to mention is the Archives page.
This page uses the Extended Live Archives Plugin. It’s uses ajax to let the user browse through an entire archive of posts without needing to reload the page. Of course, since I only have a handful of entries, this is of little significance. However, for blogs with hundreds (or thousands) of posts, this is a really nice tool to have for improving usability.
The beauty of this plugin is that it essentially comes pre-configured with the k2 theme. This makes things really easy for me; I don’t have to worry about the code.
Unfortunately, when things go wrong, I do need to worry about the code. Moreover, it is not easy to debug someone else’s code.
Thus, I had a slight problem with the Live Archives plugin in Safari. When I activated the plugin, it caused each page to ‘flicker’ on loading. This didn’t happen in Firefox. Additionally, pages took longer to load with the plugin activated.
One issue going on here is how WordPress works with plugins. WordPress processes all the code for each active plugin, even on pages where those plugins aren’t used. The Live Archive plugin is only used on the Archives page, so it would be nice if WordPress somehow knew not to process any of its code unless the user was viewing the Archives page.
To implement this, I modified the plugin code in the af-extended-live-archive.php file. I wrapped an if statement around the content of each function that checks what page the user is viewing.
Example:
function af_ela_function_name() {
if (is_page('archives')) {
// function code here
}
}
If the user is viewing the Archives page, then all of the Live Archive’s plugin code will be processed. If not, the code is merely skipped over.
This eliminates the Safari ‘flicker’ problem on all pages except for the Archives page. It also prevents a degrade in site performance, enabling faster browsing between pages.
A quick analysis on what’s causing the Safari ‘flicker’: My first thought was that it’s a css-related issue, but after a couple tests, it looks like it’s a javascript issue. Rather than waste time trying to fix a silly bug, I settled for the work-around above (which I feel is a better solution anyway since it keeps page loads faster).
{ 5 } Comments
thanks for this. I’m one of the sites with lots of posts who love this plugin, but for whom it causes probs. My server is a lot happier now.
Ich erklare meinen Freunden uber diese Seite. Interessieren!
Was kann ich sagen? Wirklich gute Arbeit erledigt mit dem Aufstellungsort…
Ich erklare meinen Freunden uber diese Seite. Interessieren!
Wow, this is exactly what i was looking for. My wordpress install was getting super bloated when it would load scripts for plugins on every page. Thanks a bunch.
{ 3 } Trackbacks
[...] Photos « Site Addition Part 1: Archives Page [...]
[...] WordPress Optimisation: Control When Plugins Are Loaded Although, I love the Extended Live Archives plugin and the Archives page it creates, it’s very resource hungry and even though my server is getting better by the day thanks to Matt, it’s still a big drain. I did a quick search on Google and I found this tip for reducing it’s impact on my page speeds, which should work with many other plugins. [...]
[...] Although, I love the Extended Live Archives plugin and the Archives page it creates, it’s very resource hungry and even though my server is getting better by the day thanks to Matt, it’s still a big drain. I did a quick search on Google and I found this tip for reducing it’s impact on my page speeds, which should work with many other plugins. [...]
Post a Comment