Mechanism of delta-loading
Please see: Transparency policy
Usually, you will have different CSS’s and scripts on the various pages.
Some CSS’s and scripts tags will be page-specific while others are common to all pages.
Simple delta-loading(from version 7.2.0) means that:
- CSS’s and scripts that are genuinely new to Ajaxify(across pages) will be loaded dynamically
- CSS’s and scripts that are known to Ajaxify will be ignored(nothing is done)
- all CSS’s and scripts with
data-class="always"are always loaded each time around - all CSS’s and scripts indicated in
alwayshintsare always loaded each time around, too
You have to specify, which files should be loaded each time around by one of the two following methods!
Using alwayshints (recommended)
With alwayshints, you can control files to be loaded every time around, even if you don’t control their inclusion on the server side
Multiple alwayshints have to be separated by comma + space
| alwayshints | Files loaded each time |
|---|---|
| ‘productsearch’ | All files with URL containing the string ‘productsearch’ are re-loaded each time around |
| ‘productsearch, showcart’ | All files with URL containing the string ‘productsearch’ OR ‘showcart’ are re-loaded each time around |
Using data-class="always"
<script src="https://somesite.com/productsearch.js" data-class="always" ></script>
Complex delta-loading(before 7.2.0) means that:
- CSS’s and scripts that are genuinely new to a page (page-specific) will be loaded dynamically
- CSS’s and scripts that are common to both pages will remain in memory
- CSS’s and scripts that are genuinely old to a page (page-specific) will be unloaded dynamically
- all CSS’s and scripts with
data-class="always"are always loaded
If you prefer the old, complex delta-loading please use version 7.1.0 (version 7.1.1 is buggy)
Inline scripts and style tags
…can be loaded smartly
async and defer attributes
…in external JS inclusions are supported
Preserving order of the DOM
The order of scripts in the DOM, whether inline or external is preserved, when delta-loading. That means you can steer the order of loading by interspersing inline and external scripts, which is probably, what you expected intuitively…
Initial load
…is performed without an extra GET! (analysing the DOM tree on DOMReady)
Delta-loading described at Wikipedia
see also: Delta-loading in HTTP at Wikipedia
Hi Arvind,
I’m continuing to try and get this working alongside Woocommerce again so have a quick question regarding the delta loading of the scripts.
Is there any way to instruct new scripts to be loaded after the body tag instead of the head?
Woocommerce is very picky with regards to placement of them and by default, a hard page load / refresh places them all after the body tag.
Thanks
Matt
Hi Matt,
Thanks for your perseverance and effort!
If you’re primarily talking about external JS scripts, there now is the possibility to label them with the “defer” attribute.
You could sneak preview the coming version…
Just an idea…
Thanks and
Regards,
Arvind
Hi again Arvind, Yeah.. still plugging away and determined to get it working. All the other Ajaxify scripts out there aren’t anywhere near as comprehensive as yours, hence my wanting to stick with it.
Thanks for the headsup and pointer towards the new version. I’ll certainly give it a go and would be good to keep up with the latest version. Is there any documentation to highlight what the latest features are?
Thanks in advance & keep up the good work!
Matt
Hi Matt,
Thanks for those kind words – exactly, what keeps an open-source author going 😉
The new features of the new version are not yet documented but I can name them here:
– “defer” attribute supported (are you in control of the scripts in question?)
– WP-Admin links no longer ajaxified (those e.g. in the “meta” section of a WP-site)
– some source code formatting and a small simplification of code – no functional difference
So, if you’re in control of the respective script inclusions, we might be in business!
Thanks,
Arvind
Hi again, Matt,
even if you don’t control those scripts, I would still have an idea how to enhance Ajaxify for your use-case…
Thanks,
Arvind
Hi again Arvind,
Have just downloaded the latest version and will try and get it integrated into my demo site over the next few days.
Would certainly value your input on a few things that I’d like to try and iron out. Generally though it’s looking promising so far and the pronto events will certainly help with page to page transitions.
Thanks
Matt
Hi Matt,
sure – I have time throughout the next days, will be off for the evenings.
We can try debugging from tomorrow on. If you wish, we can switch to eMails for more rapid development…
Whatever you prefer…
Thanks
Arvind
Hi,
Thanks for Great Plugin, I have working it and found little problem.
doesnt identify how to solve it.
Ajaxify is not working with bootstrap for special onload classes.
like i want to use selectpicker with ajaxify its doesnt work.
Please help me to do it.
Once Again Thanks
Amit
Hi Amit!
I would need further details or, if possible, a link to your site, to see what you mean?
Thanks!
Yes Please Lookat this link :
http://demo3.wp-coders.com/amf/
then click on Sign Up
Regards,
Amit
The sign-up process doesn’t seem to work. Is that the issue we’re talking about?
In here, you’ve set
formsto false – so the form should not get ajaxified…There is an error in the console, saying, that “font-awesome.css” is not getting loaded?
Yes I dont want to form ajaxify because i already handle it with ajax request.
problem is there is male female dropdown.. when I remove ajaxify from page.
its working fine.
but when use ajaxify then that dropdown not worked.
Amit
Could you try removing the
no-ajaxyclass? Just a quick idea.With
formsset tofalse, Ajaxify should not do anything, really, but we could try that…Hello
Removed no-ajaxy class..
look it once ..
then will remove ajaxify.js then will check it again.
Regards,
Amit
It said: “Your message was sent successfully.“, although I was not able to select the gender, leaving it as “male” – don’t know, whether Ajaxify was enabled or not
Gotcha, I understand that this is probably not necessary for many users.
I ended up just changing the if statement in the _freeOld function to this:
if (s[i][1] == 2 && s[i][0] && s[i][0].search("typekit") < 0) _removeScript(s[i][0], PK);I didn’t want to run the javascript again I just wanted to keep the
it created.This is maybe a bit of a hack but it’s working good for me so far.
Thanks for your help!
Hi Andrew,
so you derived your own version of Ajaxify – cool 🙂
Well done!
Best of luck!
Hi,
This plugin is awesome!
I’m having one problem. I’m trying to use Typekit which doesn’t allow you to link directly to the font, you have to use an embed script which attaches a style tag to the head that links to the font. Is there a way I can have Ajaxify leave that style tag alone instead of offloading it when a new page is loaded?
Hi Andrew,
please try:
style: falseThanks and good luck!
Yeah I should have mentioned I already tried that. I’ve also tried inline set to true and false and also put “Typekit” in inlinehints.
Above it says:
“CSS’s and scripts that are genuinely old to a page (page-specific) will be unloaded dynamically.”
Since the Typekit styles have been generated for the current page only it seems like they would be “page-specific” and unloaded.
I can see in web inspector that the style tag disappears when a new page is rendered.
Hi Andrew,
thanks for your detailled answer and thorough research!
Here some quick feedback:
–
inlinepertains to inline scripts only (i.e. inline JS)– you need to turn on style handling, in order to achieve, what you would like to do!
– the usual “delta-loading” does not apply to style tags – they are handled differently:
1) Fetch all style tags from the target page
2) Delete all style tags from the head
3) Append style tags from the target page to the head
You’re right – this means that style tags from older pages are lost!
What would you expect from a user’s point-of-view instead?
I’d be happy to overhaul the style handling for you and future users…
From what you’ve posted, I reckon, you would like the following to happen instead:
1) Fetch all style tags from the target page
2) Compare with the “history” of style tags
3) Append new style tags to the head
(keeping a “history” of style tags)
Just two more questions:
– Does everything work, when Ajaxify is disabled?
– What is the behaviour of “Typekit” then – does it generate the
styletags for all pages?Thanks very much again!
Hi,
Thanks a lot for the info and help!
I will answer your two questions first.
Everything works when I disable Ajaxify.
Yes Typekit generates style tags for each page. It works differently than some web fonts in that you don’t link directly to the stylesheet, you just include some javascript which does some feature detection and then attaches the link to the font. So yeah, I don’t actually have the link in the head on every page just the script.
Yeah I think your solution would be great!
My problem is specific to Typekit, but I imagine there would be times a user would want to leave a link alone especially if it involved making a request to a third party server.
Hi Andrew,
slept over this issue one more night. I think, I won’t implement the change, because in the current form, the algorithm reflects what probably most users would expect.
What came to my mind: Could you please make sure, that Typekit runs before Ajaxify kicks in?
If it’s the other way around, i.e. that Ajaxify runs first, the behaviour you reported is understandable…
You also mentioned, that it’s a piece of Javascript that creates the style tags. In that case you need both
style: trueandinline: trueor if that JS is the only one you’d like to trigger theninlinehintsset…Thanks!