Bugfix/NGO-951/Preload Assets

[PeterBooker]

Adds preload for both the JS and the form schema request.

DOES NOT WORK

For the form schema preload to work, the request needs to be made in the the exact same way (request headers, URL, etc). For us the cache busting URL params make this impossible. Looping through the content also does not catch everything which could be included via FSE these days (patterns/etc).

PERFORMANCE ISSUE

We can only add the preload for the form schema by looping through post content in the header. This means that the site needs to loop through the content twice to render the post, which will have a negative performance impact.

IDEAS

I am not sure how to rescue this, but I have a few thoughts.

1. Only preload the main JS script. Minor improvement.
2. We could update post meta with a list of Form IDs updated on save, instead of looping through content. Not sure if we could make this fully compatible with FSE?

[pierre-dekode]

@PeterBooker a few thoughts, sorry if these are crazy ideas 😅 :

1. we could have the plugin fetch the Fundy JS assets file and extract the window.FundyFormsVersion = 1776331155734; value at the top, and store it in a transient.
2. or, if this is not maintainable, have the forms build command generate a .txt or .json file that contains the value of that version timestamp, and have this file live publicly somewhere. Then, the plugin would fetch and store this value.

Thinking about your 2nd point above, we could hook into save_post to generate the "definitive" list of schema URLs when the post is saved, coupled with a transient to fetch the window.FundyFormsVersion on a regular basis (maybe once a day or something?). It would indeed be more efficient than doing the calculation on every page uncached render.

[PeterBooker]

@pierre-dekode Interesting ideas!

That would allow us to add the preload, as if something went wrong and we did not have the FundyFormsVersion then we could avoid adding the preload for the schema in.

I would like to explore the save_post hook but I am not familiar enough to be confident I could find all the forms used in this age of FSE. Looping post content is fine, but I am not sure how to check patterns or whether it is possible to store content anywhere else- do you have any experience with this?

[pierre-dekode]

@PeterBooker No, my experience with patterns (outside the ones registered in a theme/template) is limited. I would say that looping through the current $post->post_content blocks and fetching the form IDs from it (as you currently do in this PR) would cover 95% of our cases. The key thing would be to add a filter/hook somewhere for the project developer to possibly inject IDs on the fly, if they decide to make use of Fundy forms outside the post content (like hardcoded in a template or something), with proper documentation for it.

[PeterBooker]

@pierre-dekode That is a great idea, thanks. I will update this PR and make it usable!