@Yisrael (Wix) @Aleksander Denga @Brett Haralson (Wix) I think it's an outright dangerous idea to suggest that people use eval() who are novices or even experienced devs who do not know how to use it safely, and how dangerous it can be to use it. At the very least, the tutorial needs a bright red security warning. Even without theoretical access to the DOM, I think it should be proven that eval cannot be evil in Wix before recommending people use it. https://www.wix.com/corvid/example/javascript-playground

@givemeawhisky @Heath H-M @Salman Farizy I've created a small utility to display tags/hashtags in a single text element. It's: Easy to use Stylable Clickable Hrefable Fully accessible Minimally tested No text-wrapping in this Alpha version so please keep your tags on one line. Feel free to post any issues here or on Github. **I have a sneaking suspicion that the click action might have issues with Safari since Safari is essentially a dumpster fire with a fancy dbrand skin, but I can't bring myself to use it because I value my dignity so please let me know.

@Yisrael (Wix) @Aleksander Denga @givemeawhisky @Heath H-M For the record, I'd much rather have selectors that don't duplicate themselves as opposed to hashtags. Could just be me, but anyone feel free to chime in.

@Aleksander Denga You can see it in action here: https://mirokiiski.com/copy-of-home If you scroll down to the Wall of Honour, you'll see that the fourth item wraps onto a new row, though it could easily fit in the second. It does follow alignment (right now it's set to justify, if you set it to center the third image remains left aligned and the fourth is centered, making for a very weird aesthetic). If you have any suggestions, I'm open to them. Thanks

Please send emails out based on unique email address, and not instances of packages installed :) My poor little inbox was bombarded by duplicate emails...

I think some new areas of the member profile area are missing an overflow:hidden; CSS property...looks messy.

#WixTurbo I've seen many people posting about code breaking randomly though it was previously working over the past couple of weeks, and now it has happened to me. In my case, it broke some animations on items where I was using a hybrid GUI and code approach, but I was able to quickly fix that by making it all code. However, the other thing it broke was simple html formatting on text and styling on boxes... The code hasn't been altered, and this stuff is so basic there's no way it was my doing. Code on other pages has also been broken that's more complex and I might update it once I figure out what's going on, but this has got to be a bug on Wix's side. @Yisrael (Wix) @Yoav (Wix) @Ohad Laufer @Alexander Jdanov @Chaim Kram Could you please inquire about this/inform us on progress? UPDATE 4/4: 1. Fix for failing #wixLocation links: Instead of : const itemLink = itemData.link; wixLocation.to(itemLink) Use this, which is far better practice anyway: const itemText = itemData.text; const itemLink = itemData.link; $w('#text').html = `<span><a href ="/missingUrlString+${itemLink}">${itemText}</a></span>`; 2. Fix for #wixData connections: ???/Super inconsistent. 3. Fix for broken animations: Use code only. Link to API. 4. Fix for hidden/collapsed elements not being triggered: ???/f*ck around with your design and code until something works. I tried a whole bunch of other stuff but this was the only thing that worked in the end. 5. Fix for iFrames: As @tabraham found, they're not refreshing consistently on dynamic page load. So use postMessage without waiting for onMessage, or else try this to refresh the iFrame: if (wixWindow.rendering.env === "browser") { var iframe = $w('#html1'); iframe.src = iframe.src; await iframe.src; setTimeout(function() {$w("#html1").postMessage("yourmessage");}, 50); } If you don't have the time to parse through all this, feel free to contact me. UPDATE 4/1: 1.#Wixlocation seems to be buggy because there is flat-out no canonical url, which can result in some weird behavior highly dependent on where you are pointing your links. It's also affecting buttons without code in some cases. 2.#WixData connections are still failing on a page loaded with a url query. 3. I've corrected all animations, and it's no longer an issue for me. 4. HTML formatting is fine, just be careful with template literals using wixLocation for reason above. 5. This is the most annoying. I've tried everything I can while maintaining my desired style choices, but no go. Code once working for triggering multiple collapsed/hidden elements has just sh*t the bed. 6.#WixVideo seems to be fully functional again. 7.#iFrames I've been putting off on fixing, but I'm pinning what appears to be @tabraham 's very helpful answer from down below. Will update once I've tested: 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 (something similar is perhaps going on for the rest of the issues). So the fix is to directly call postMessage without waiting for an onMessage event as was the recommended practice. UPDATE 3/29: More things are broken now. Here's what I've seen on my end: 1. #Wixlocation.to seems to be breaking on some sites because urls have changed, but the API is still going by the old urls. This can be fixed by comparing the url you're being directed to vs the working url and manually correcting. 2. #WixData connections are breaking sporadically if you've connected through the GUI, while connections through the code seem to be much more reliable. 3. Animations are breaking if you have a combination of GUI and code on the same element. Easily fixed by making them code only. 4. The HTML/style formatting broke for a day before fixing itself. 5. Still having problems with triggering collapsed/hidden elements with onClick, not sure what the problem is there yet. 6. #WixVideo elements aren't playing when dynamically connected through the GUI or through code. This was tested with uploaded media and Wix stock media. 7. #iFrames on dynamic pages are not working currently. I'm all for faster load speeds, but Wix needs to say something about this. Customers can't be hung out to dry, especially if they don't know how to fix these sorts of things on their own.

#responsive #resolution I've seen this question floating around often and have had to find solutions for it myself, so here's a quick guide for three ways to make your site work well with different resolutions. Presuming you are using the Wix Mobile feature for your mobile visitors, you can use these solutions for anyone viewing the desktop site. The following is tailored for dynamic pages, since it should be much easier to reverse engineer the code for static pages. import wixData from 'wix-data'; import wixWindow from 'wix-window'; import wixLocation from 'wix-location'; $w.onReady(()=>{ $w("dynamicDataset").onReady(()=>{ //first we need to get the fingerprint of the browser's current width wixWindow.getBoundingRect() .then( (windowSizeInfo) => { let windowWidth = windowSizeInfo.window.width; //if you need to change sizes for many things at once such as large images and wide repeaters, use this to redirect people to a copied narrow version of the same page that you can design manually let thisData = $w("dynamicDataset").getCurrentItem(); let wideUrl = thisData['link-wide-dynamic']; let narrowUrl = thisData['link-narrow-dynamic']; //if window width is greater than or equal to 1280 pixels on desktop site, direct here if ((windowWidth >= 1280) && (wixWindow.formFactor === "Desktop")) { wixLocation.to(wideUrl); } //or if window width is less than 1280 pixels on desktop site, direct here else if ((windowWidth < 1280) && (wixWindow.formFactor === "Desktop")) { wixLocation.to (narrowUrl); } } ); } ); } ); //or else if you need only minor tweaks you can choose to 1.show/expand and hide/collapse elements based on the windowWidth property and/or 2.alter the .html properties of text like so let textValue = $w("dynamicDataset").getCurrentItem().mytext; if ((windowWidth >= 1280) && (wixWindow.formFactor === "Desktop")) { $w('#textElement').html = `<span style ="font-size:20px">${textValue}</span>`; $w('#largeElement').expand(); } else if ((windowWidth < 1280) && (wixWindow.formFactor === "Desktop")) { $w('#textElement').html = `<span style ="font-size:14px">${textValue}</span>`; $w('#largeElement").collapse(); } //optimally you can modify solution 1 to link pages through code like this //we'll use a repeater on a static page with links to dynamic pages as an example $w('#repeaterDataset').onReady(() => { $w('#repeater').onItemReady( ($item, itemData, index) => { $item('#repeaterText').text = itemData.mytext; $item('#repeaterText').onClick(() => { //if the desktop window is greater than or equal to 1280 pixels wide or if you are on the mobile site, direct to the standard wide page (you don't need two different layouts on Mobile) if ((windowWidth >= 1280) && (wixWindow.formFactor === "Desktop") || (wixWindow.formFactor === "Mobile")) { wixLocation.to(itemData["link-wide-dynamic"]); } //if the desktop window is less than 1280 pixels wide and is not on Mobile, direct to the narrow layout page (the not equal to !== is just to show you can use different condition indicators if you need to) else if ((windowWidth < 1280) && (wixWindow.formFactor !== "Mobile")) { wixLocation.to(itemData["link-narrow-dynamic"]); } }); }); }); Hopefully this is easy enough to understand. The first code snippet requires two separate pages and is more flexible, the second only requires the one you already have but limits your options. The third option is the most ideal of the three, but requires you to link your elements using WixCode instead of the GUI. Because the first option is a redirect, it will load two different pages every time you travel to the narrow resolution page. The good news is with WixTurbo, this shouldn't take long. I would recommend testing on Firefox and some Webkit-based browser like Chrome because their default resolutions are often different. This should help you test what elements to change and how. Finally, in cases where you're working on a simple page with a couple strips or so and you only need some text to be responsive, check out this post by Johanna! Good Luck!

I have an Iframe used to embed media on dynamic pages. The code works perfectly on firefox every time, but works only the first time on Webkit browsers. After that, the iframe shows up completely empty. Initially it was sometimes failing to load at all, but I figured out that adding a timer to the dataset's .onReady got rid of that problem, so I assumed the issue is in how webkit loads the dataset. However, when I use developertools to see what's going on, refreshing the webpage while inspecting the iframe forces it to load just fine, which makes me think it's a communication error between the iframe and the browser... Anyone have any ideas as to why this could be happening? Would greatly appreciate a solution or workaround as I've been struggling with this for a while now. HTML Component code: <iframe id='videoFrame' scrolling="no" frameborder="0" border="0" src="#" width="560" height="315"> </iframe> <script> window.onmessage = (message) => { document.getElementById('videoFrame').src = message.data } </script> Page JS code: import wixLocation from 'wix-location'; import wixData from 'wix-data'; import wixWindow from "wix-window" let debounceTimer $w.onReady(function () { if (wixWindow.rendering.env === 'browser') { $w("#dynamicDataset").onReady(() => { if ($w('#embedURL').text.length > 0) { if (debounceTimer) { clearTimeout(debounceTimer); debounceTimer = undefined; } debounceTimer = setTimeout(() => { $w('#embedOne').postMessage($w('#dynamicDataset').getCurrentItem().mediaEmbed); $w('#mediaHolder').expand(); }, 200); } } ); } } ); Is it possible to get the browser type in WixCode? I've tried using standard JS but it didn't work and the feature isn't listed in the API. Also, would be great if anyone has tips on preventing the iframe's scrollbars as it's loading!

Hey Wix Team, Not sure why but the profile page in the code forum has no functionality, you can't click on any items. Also when I attempt to open my notifications in a separate tab, I'm taken to a 404 page. I haven't checked on any other browsers yet. Anyone else having these issues?