code that used to work fine is no longer working using the html-component.
this:
window.parent.postMessage(“LoadOk”, “*”);
is no longer picked up on the Wix side with:
$w(“#html1”).onMessage((event) => {
I can see in browser console that you are working on the html-component, for new messages appear, like “iframe loaded”, which weren´t there a couple of days ago and are NOT mine.
UPDATE: deleted remarks about console.log not showing. The onMessage is simply never triggered, as stated above.
Hey
My site https://www.aroundme.ai/map uses the html component and post backs to the Wix Code and it is working as it should.
I have this in my html component:
window.parent.postMessage(data.id, "*");
And that works perfect on my site. I also have this in the html component.
window.onmessage = function(event){
if (event.data) {
console.log("This message from html component inside Wix Code.");
}
};
And in Wix Code I have this within my onReady function.
$w("#map").onMessage( (event) => {
let receivedData = event.data;
console.log("Clicked Events id: " + receivedData);
});
And when I send to the html component I have this:
$w("#map").postMessage(mapLocations);
Everything works. I do have my onReady in Wix as async but that wouldn’t make it work or crash I guess.
But I did have to make some changes some weeks ago, so I have to send from html component when page is loaded and done and then after I got that signal in Wix Code then I send the data to the html component. It seem that the iframe was not loaded when I sent the code first. I think this might have to do with server side rendering and the html component is not loaded when server side Wix Code is executed.
I am pulling my hair. Even the below code doesn´t work: I receive the 2 console.log´s from the html, but the “in w:onMessage” is never displayed. Can somebody run this code and see if it works at your end?
I do see something strange in the console.window: I first see my messages from the html and a LOT later a Wix debug message saying “iframe loaded”.
$w.onReady(function () {
//TODO: write your page related code here…
$w(“#html1”).onMessage( (event) => {
console.log(“in w:onMessage”);
});
});
with the following html in the html-component:
<!doctype html>
Oops, I got that one: the /script
Shit happens, does it work now?
No Andreas, it´s driving me up the wall. I now use this version:
<!doctype html>
Maybe 1 out of 10 times (F5) I receive the
console.log(“in w:onMessage”);
from the Wix side. The other 9 times nothing, but I do get “slow network detected” messages in between.
I am so stuck here.
Weird, maybe ask a Wix Code team member for help?
Andreas, before I do: could you do me a favour and copy that piece of wix code to a dummy page, put a html-component in it called html1, copy the html-code above (latest) in it and see if it runs at your end?
I have several sites using this, even on frej.ai/frej-kartan I use the html component and send in records to a map and it works. Do you want all that code? I have no time to test this today, sitting with prio client.
Hi Giri,
Can you please share a link to your editor so we can have a closer look?
Roi.
[Early warning: long read]
]
Roi, thank you for responding, you´re about the only one. I think I have got the problem solved, but for you and maybe others that run into the same problem, I will explain what I suspect was/is going on.
My problem was that, in earlier stages of the html-component (HC), $w was processed before/during (async) the loading of the HC. So when from within $w you sent a postMessage, the HC ignored it, because it was not loaded yet. So I made a workaround, starting the conversation from the HC in the html body onLoad (function) by sending a heart beat to $w, whereupon that side would send a message with data to display. Many people had the same problem, I emailed my solution to many and eventually put it onto my blog. One of you wanted to put me up for the Nobel Prize for this. That would be hugely overrated, but at least I offered a solution to a problem.
I was working on a alternative date picker for Wix (another natural language), a job way over my pay grade. I finally got it working on a Friday. Next Monday I press F5 and all goes boom.
I wrote all kind of posts on this forum, but I was not even taken seriously, better still, I am shunned. Yes, I was very p&//%ed off: working code just broke in front of my very eyes.
Now, I am perfectly aware that Wix Code is still in beta and things do change. What worries me is that Wix updates components significantly without an early warning to its user, thereby stating what has changed and offering a sandboxed environment where we can test the new component before deploying. If not, Wix runs the risk of having the same dreaded problems like WordPress on a shared environment: a component/plugin/addon (whatever you call it) is updated, and if your site still runs is up for grabs. It worries me because I see no effort to address this problem during beta, with the possible risk that this continues when finally released.
It worries me because this is not an exception, but rather a rule: I have had it with the dropdown component, with .save(), with the keyword “sleep” and now with the HC. A conservative estimate is that I have lost one month during one project because of this.
In short: we know this can happen during beta, but I see no provisions to solve this when released. That worries me a lot.
Back to the HT: in earlier versions, as I said, $w was processed before/during the loading of the component. This is no longer so. I see a constant opposite behaviour: the HC is loaded first, then $w.
I assumed you had done some major updating on the HC. No answer. But when I looked at the documentation, I found all kind of new things: full screen, ready to run inside the Repeater, etc. So you did a major upgrade. And this update changed the order of loading $w and HC, I suppose.
In my simple code example (see above), the following now happens:
I later called this behaviour erratic because in some browsers (Opera) $w would receive it, once or twice, but not constantly (I did not notice this on FireFox or Chrome). function html_onMessage () was ALWAYS received.
My solution is now: don´t even wait for the heart beat in $w, it is unreliable, just do postMessage, the HC is loaded in every case that I could test and ready to receive.
It would have saved us all a lot of aggravation and frustration if Wix would just document their changes better AND offer a Sandbox for testing/deploying. I THINK the above is what´s going on, but you are so tight lipped that I do not know this for sure.
I hope you take this the way it is meant: yes, critical, but pointing out real problems.
Hey Giri
I know the feeling and I am sad you feel this about Wix Code, this does not happen to Wix components at all. Since 2012 me and my wife have worked with Wix and we have not a single thing that have breaked in the middle of something with any of the Wix Apps from the team at Wix.
But, Wix Code is in beta as you and I also knows and I also have Wix Code projects that are in production, even that I know it is a risk I took and that risk costs me hours every month. But, using Wix Code have saved me more hours that it has cost me re doing things because things change.
There is also another thing we must take in consideration about Wix Code, this group of users is also new to Wix, even though they have developers that are rocket scientists in my opinion they have not had a product targeted to developers before. So all this is new to you and me but also to Wix teams.
There are more and more demand for a clearer roadmap, a bug list & report forum and also some heads up on things that will change or have changed. I believe that an open forum that lists known bugs would be great so you don’t invest days on your own thinking you did something wrong and then discover there was a change or a bug causing the issue.
So I agree with you on a lot and I still say this, Wix Code is beta and you can’t use it in production projects without knowing you take a risk that you have to redo stuff later on.
I work a lot in a software called Xamarin that was aquired by Microsoft and we all thought that this would make the product more stable and that the road map would be in more detail than before. It is the other way around, they update things suddenly with no warning so my apps break. Last year I invested more than 200 hours in fixing things that was changed and I had to redo it all.
I believe that we as developers need to have this in mind when coding, things change fast, new versions of PHP, iOS, Android and not to mention new browsers and functions that totally crash our work.
There is a reason why there is still large systems built in MS DOS and they are still running, because they are no stable nothing can break. But you have to make a choice somewhere, I want to be in the front end of things or I want to start using things when they are stable in version 1.0.
I hope you will continue here because I appreciate your thought and your challenges, you are a resource for this forum and I would miss you.
I will send to Wix teams and wish for a Upcoming changes & Bug Reports forums. I believe that Wix could give the more senior developers access to write new posts in the Bug Reports forum to make is solid and only be about bugs. I also believe Wix Code team would benefit from this new forums.
Andreas, don´t worry, I am not going anywhere. I like Wix as much as you do, but in my book that does not mean that you cannot be critical of some developments. I agree with you totally about the road map. For new customers, a production release would be a re-assurance, together with a statement that Wix , whatever happens, is going to support Wix Code at least n years.
I am, in general, very pleased with support: the oddest hours, the fact that the original developers did support first and are still looking over the new echelon´s shoulder is an indication of love for your product, something no suit, no manager can install.
What worries me is that Wix is generating its own support by updating components without prior notice. Support is a difficult and expensive department to run: constant training of new people (nobody want to shovel shit for the rest of their lives). Any company´s bottom line is defined by sales minus costs, and upping your profit can only be done by boosting sales or reducing costs.
Now, Wix has, with Wix Code, chosen a huge, but difficult part of the market: a small business owner who has outgrown his static web site. For them, Wix Code is a step up. In its current incarnation, Wix is never going to lure developers away in droves from WordPress/PHP/MySql. It would be a step down.
You see it in the forum. How many of these messages don´t start with “I am not a coder, but…”. This means these people try to get something running, copy and paste as much as they can and when it runs, go back to their business. When suddenly their site no longer runs, they are not going to debug, try, test and look for workarounds. They are going to put in a support request. It will also give wix code a bad rap (“It suddenly stopped working again”). So Wix Code will always be expensive to support. And eventually someone is going to do the numbers.
If you then, by whatever means, can reduce support costs, you can offer a more stable and less costly product. Every company, after a couple of versions, sees their support cost rising dramatically and eventually we all do the same: bring out a version that is not driven by cramming in more features, but stabilizes and reduces support.
If the problems I ran into are symptomatic, Wix could for instance contemplate different versions of the same component, like Microsoft once introduced to solve “dll-hell” with “side by side installations”. So you would not have one html-component, but several versions. If a customer designs his site with component version 2.3, then 2.3 will always be used, unless, in edit mode, you decide to upgrade (e.g. after a notification).
That way, you do not generate your own support, customers are happy and if you give Marketing a nice acronym (like Dora, Design Once, Run Always), they are happy, the boss is happy (support costs are going down) and, here it comes, we are happy too: now you and I don´t run the risk of having to rewrite all you Wix Code in some other environment. That is my point: Wix can still pull Wix Code from beta and not release it, or at any other moment. And the bottom line, the money, is usually the trigger.
That is what worries me in a nutshell: the market they have chosen and the lack of some important features that this very specific market calls for.
So you see, I am not at all negative, on the contrary: you are probably correct in pointing out that it is new for them too, and I am willing to help them in any way I can. But if I see a blunder, I will call it one. I have never sugar coated my opinions and am too old to start now. And when I am p%$·&ed off: well, that always ebbs away after a very short wile and I do not think of it ever again.
I believe you carry some weight with Wix, so maybe you could warm them up to this view and the points above mentioned.
Thanks for your time, all the best, let´s keep in touch.
Hey Giri,
I am facing similar issue and did not understand the solution completely. Is it possible for you to share the sample code on HTML component side and also the page code.
Have you read the July 2018 update on my article after the above mayhem? https://girizano.wixsite.com/codecorner/home/html-component-not-running-in-publish-mode-google-sheets-example