We’re introducing a breaking change that we recommend you migrate to. We’re now running custom HTML headers (both at the page level and at the app level) after other Bubble assets, which is a safer approach (so far, a syntax error in the HTML could break entirely the page). This should only impact apps where the custom HTML headers need to run before Bubble’s core code, which is highly not recommend, as we could introduce a change that breaks things without warning.
I think it basically means that what you stick in your page header will be loaded after everything else. That’s the field you see when you click on the page and the property window opens “Page HTML header” so for example, you might stick in a JavaScript link or maybe some JavaScript which will be loaded after bubbles core code that runs your app.
For non-developers, this has nothing to do with any sort of “header” you design on the page. If you’ve never added any code or any snippets in the “Page HTML Header” field, you can likely ignore this.
Yes it’s only for people that add custom JS to their pages. Also, the test when you upgrade is quite simple, if it doesn’t go well the entire page will likely break. So if you upgrade and can load the pages, you’re good to go.
with these in the header version 2 works great. with them on version 3, just a blank white page, with the date and time picker date only - no formatting no border. Also debugger is blank too. Take them out, page renders but charts do not.
This script needs to load first. Is the header still the place this script needs to go in order to allow me to continue to run d3.js code on my page? If not, then where should I put the code.
Fingers crossed on your answer. I really don’t want to have to figure out how to integrate D3 again. It took weeks to figure out and test the current setup (Big learning for me without examples to follow. Passing bubble data into the HTML window and then running that data in D3.js) and we are about to launch our app big time over the coming months.
HI Sam, I am not running this particular script but similar and if you are just referring to that src link then it should be fine! But, @emmanuel is right you have to test to see if it effects it and there are options. There are always options, even though they may not always be pretty.
The difficulty Bubble has is that they need to look after the core code to make sure our apps are running like a well tuned engine, and they just don’t have the resources to consider every possible script that may be used - there are literally thousands! Unless the script tells you that you must explicitly load this script into the browser before anything else, then you should be good to go!