I have a dynamic page that retrieves multiple data items from a remote database (based on an input identifier from user) and then sends it across to different html components to display as charts.
Well it used to work but now it has stopped working on the published site ( but still works in editor preview mode ).
Not sure if this has anything to do with the Wix Turbo rollout #wixTurbo – but everything was working until yesterday and suddenly stopped working sometime earlier today. Wix Support was not able to resolve why it works on editor preview site but not on live site.
The code block is roughly like:
$w.onReady(function () {
$w("#dynamicDataset").onReady(() => {
let currentItem = $w("#dynamicDataset").getCurrentItem();
itemID = currentItem.itemID;
let indicatorArray = ['id1', 'id2', 'id3'];
remotedb_getData(itemID, indicatorArray)
.then((dataPntArray) => {
$w("#arrayChartHtml").onMessage((event) => {
console.log(event.data.type);
if (event.data.type === 'ready') {
$w("#arrayChartHtml").postMessage(JSON.stringify(dataPntArray));
}
});
})
.catch((error) => {
console.log(error.message);
});
});
});
Everything in code above works the first time the dynamic page is loaded but when the user submits the next user input, the postMessage call in the inside if loop never gets called.
Hope the Wix Code forum can resolve this. Thanks in advance for your help
So I have a fix for the above (could be temporary/permanent) – depending on whether it is considered a bug/feature by Wix.
Previously, the recommended practice was to wait for a onReady message from a iFrame HTML component before doing a postMessage to send data from the page code to the HTML component.
But now, it looks like Wix is no longer reloading iFrame Html Components on Dynamic Pages – as such the onMessage event is not triggered except for the first load of the Dynamc Page.
So changing the code above to the following fixes the problem:
$w.onReady(function () {
$w("#dynamicDataset").onReady(() => {
let currentItem = $w("#dynamicDataset").getCurrentItem();
itemID = currentItem.itemID;
let indicatorArray = ['id1', 'id2', 'id3'];
remotedb_getData(itemID, indicatorArray)
.then((dataPntArray) => {
//Since wix is no longer reloading HTML component (and it appears as if
//it is already present we can directly do a postMessage to the component.
$w("#arrayChartHtml").postMessage(JSON.stringify(dataPntArray));
//Strictly speaking the onMessage block is not needed (at least as of now)
//on the published website, but you may choose to retain it because
//otherwise the iFrame is not rendered in the Editor Preview mode.
$w("#arrayChartHtml").onMessage((event) => {
console.log(event.data.type);
if (event.data.type === 'ready') {
$w("#arrayChartHtml").postMessage(JSON.stringify(dataPntArray));
}
});
})
.catch((error) => {
console.log(error.message);
});
});
});
1 Like
Hi @tabraham , please post your site so we can take a closer look at what is going on. Thanks.
Hi @chaim-kram , thanks for reaching out. The actual live site is a password protected site. But here is a site that I setup to illustrate the problem:
https://tabraha7811.wixsite.com/website
As mentioned the dynamic page behavior is different between live and editor mode (where it works perfectly).
when you go to
https://tabraha7811.wixsite.com/website/testData/Tom
you will see the message gets refreshed.
But when you enter Harry in the input box, the message does not get refreshed (with ‘Hi Harry’) in the live site (but the message does get refreshed in the editor preview mode).
Look forward to inputs on what the final approach is going to be from wix regarding Dynamic Pages (as mentioned I have a temporary fix which I have detailed above in my second post).
Thanks again.
Hi @tabraham , this does appear to be a bug, because before Turbo this worked but with Turbo the behavior changed. I am checking this with a product manager. Sorry for the trouble and I’m glad you found a workaround!
Wonder if this is a bug: it used to work this way before Turbo as I have described here : https://girizano.wixsite.com/codecorner/home/html-component-not-running-in-publish-mode-google-sheets-example more in particular:
"Update 02/07/2018
Huge problems developing the alternative Date Picker, using the html-component (HC). Suddenly, instead of the HC loading AFTER the Wix page ($w), it consistently loaded BEFORE. That meant that the “heart beat” was never received, because $w had not loaded yet."
Basically, there are (were?) 2 possibilities: component is loaded before page or after page. Second scenario works with “waiting” for it before you do a postMessage. First one (component loads first , or IS ALREADY LOADED) will fail, because the postMessage is sent from the component while the page is not ready to receive it.
The solution I came up with is exactly the one that you came up with too: “trow it twice”.
1 Like
@chaim-kram thanks - any idea when the problem would be resolved.
Also, it would be great if the Wix Support team could be informed about this - because I was told earlier by them that there was likely something wrong with my custom code.
Hi @giri-zano , it does sound like a very similar problem and I have seen a Wix Chart example taking the same approach of posting the message twice though it seems inefficient and also am not sure how it is possible for the HTML Component to be loaded prior to the Wix Page in which it is embedded.
According to the FAQ section (see second question) at this link , the HTML Component is supposed to be loaded a little bit after the page on which it is embedded has finished loading.
1 Like
@tabraham , unfortunately we don’t know when changes will be made or bugs will be fixed. We always want it to be “sooner” but…
Wix Support will know about the problem now (if they’re diligent) because there is now a trouble ticket that they can find with a simple search.
Thanks for alerting me to this!
@tabraham About the order of loading of components: I had a discussion about this with, from the top of my mind, a Wix Code person called Roy Bennet (or something similar). It´s still somewhere here on this forum. According to him, in most cases, the component is loaded after the page, but due to infrastructural issues, there is a slight chance that it may be the reverse.
About the inefficiency: yes, you are right, although the data sent (and then, worse case, are lost in cyber space because 1 part is not listening yet) are so small (maybe a couple of hundred bytes), the lag is almost non-existent in my experience.
But I agree, if Wix could guarantee consistent loading of the component AFTER the page, we wouldn´t have to throw it twice.
EDIT: forgot something, about “how it is possible” that component is loaded before the page. Html-component is loaded from a different domain, see my article about Google reCaptcha´s
@giri-zano thanks and agree makes sense - now hoping Wix resolves these outstanding issues soon. cheers!
@chaim-kram thanks - any info back from your discussion with the product manager. Thanks.
Btw, what is the best way to effect change with how Wix is currently responding to issues and rolling out solutions – lot of sites struggling and feeling helpless with the lack of PR/response and visibiiity on when to expect fixes from Wix. Thanks again for your help.
Good news: The bug is fixed! Please take a look and let us know if you’re still having trouble. Thanks.
@chaim-kram Hi Chaim
I have the same problem. I wrote some code for a customer form that when the customer chooses the state in the drop down box in the form that they are in, the information in the vending drop down box changes to the specific information for that state. It works in preview mode but does bot on the live site. Building this Site for a client so I need some answer asap.
Thank you sooooo much, that worked 