Script/Style Changes in WordPress themes

[zslabs]

Hi beezee,
First off, this is pretty damn awesome.

I collaborated with another developer on getting PJAX to work with the Roots Theme, Roots PJAX, but unfortunately never really took off. The problem we ran into was since WordPress not only can, but encourages conditionally loading scripts/styles on certain pages, making sure we hooked into anything set by wp_enqueue_scripts() (as a very top-level example, being loaded in the header, footer -- or as introduced in WP 3.3, within the body as well) were left out. Does using DJAX run any checks for these types of things? Thanks!

[beezee]

Thanks for the compliment @zslabs - this is an interesting thing to consider, and as of now djax doesn't run checks. If I were to implement this, I'd do it as a djax WP plugin, since it's probably too WP specific to warrant inclusion in the jQuery plugin.

My thinking if I were to implement this as a WP plugin that acknowledges additional script/style inclusions on different pages would be to set up an ajax listener that processes enqueued scripts/styles and outputs them as JSON, so the calling code could then process the results, either using $.getScript() or a secondary library like headjs, (not sure off the top of my head what async stylesheet application would look like, but a few min of Googling should provide insight).

At the end of the day, this is likely to be overengineering, since not only do you need to load those scripts when they are called for on the current page, you need to re-process actions in those scripts on subsequent page loads where they are also called for.

Being that you only load the page once, the end result is that alot of your JS will need to be aware of the djax environment you're running in, most likely by listening for the djaxLoad event on the $(window) object, since this is what signifies a new pageload via djax.

The other option would be to set your exceptions such that pages which include unique javascript/css files are loaded fully, as they would without djax, as documented here - http://beezee.github.com/djax.html#parameters/exceptions

I work with WP for my day job, so I'm pretty familiar with the platform and would love to take on the challenge you've brought up, so if you have any other thoughts on this I'll be happy to hear them.

Afterthought: a possible low tech solution (particularly if WP 3.3 let's you enqueue to the body) would be to enqueue those separate stylesheets/js files to a djaxable element, such that it would be part of the normal update djax runs on an internal link click. This might be overly optimistic, but if I were digging into this it'd be the first thing I'd look into.

[zslabs]

Hi @beezee - appreciate the response. Yup, what you're referring to was the exact reason Roots PJAX never got completed - due to the complexities of this. The main dev had written Crackle to tie in with the main js file (to help with these changes -- to my knowledge) and obviously had a different approach (towards specifying headers throughout the template).

This is definitely a bit of head-scratcher. While I'm not familiar with Rails, I'd assume you could conditionally load styles/scripts on pages as needed, and since PJAX was not exclusively, but hinted upon being used for Rails, it may have just been assumed your assets would all be loaded in one spot. And who knows, maybe conditionally loading scripts isn't necessarily all it's cracked up to be (I personally disagree with that), but I'd hate to take it as a, "this is how it is" statement.

Definitely up for any testing as you see you fit (written a number of plugins that throws JS/CSS files all over the place), so I'd be a good test candidate :) Thanks!