Avana

Thanks for the tip, I have identified where in the template CSS the issue lies. I will fix this and remove my hack at some point in the near future. Right now I am too busy trying to find a workaround for Squarespace's broken banner videos.

This is a terrible act of negligence on the part of Squarespace. I recently finished a site design which included several very expensive, purchased stock video clips, spent considerable time selecting, editing, color grading, etc, all with the intention of using these as a banner image on a new Squarespace site for my company. Without banner videos, this is all wasted, and the design falls flat—it was predicated on the captivating effect of a hero video. I've noticed this issue going on 3 weeks now and it still hasn't been fixed. What are you paying your developers for? This bug is probably ruining—quite literally—tens of thousands websites, and by extension, their ability to conduct business online. Come on, Squarespace. Get your act together.

Correct. It was based on Pacific, chosen before I took over development duties, and I turned on dev mode for all our sites and customized the templates. Since I can't wait until Squarespace support comes back on Monday morning, I have temporarily decided to cobble together a hacked solution as follows: $('#header-section img').each(function() { const img = $(this); $.get(img.attr('src'), function(data) { if (data) { img.removeAttr('data-load'); img.addClass('loaded'); } }); }); I looked at the Pacific template's scripts, and when an image is asynchronously loaded, the "data-load" attribute is removed, and a "loaded" class is added to the image. As such, I simply implemented the same behavior within the callback of a GET request that requests the image and then tests to make sure the data was successfully received. This has successfully resulted in our images becoming visible once again. However, I stress that this is only a temporary patch—I would like to get to the bottom of this bug.

Hi, I manage a constellation of sites on Squarespace: https://www.stackmethod.com https://www.pulsemethod.com https://www.visionmethod.com Each of these pages has several image blocks on them, but perhaps most notably, each has two image blocks in the hero section of each page, a large product logo image and a smaller, monochrome company logo above it (see image below). Today, however, my team realized that none of these image blocks were appearing on our live sites. I examined them in DevTools and saw that the images had in fact loaded and were present in the code, but that the reason they were not visible was that they each had their CSS opacity set to 0. Each of these images a fade-in animation that is applied by default by Squarespace—it's not something I added to the image (and in fact, each of the images says "No animation" still under the "Animation" options of the "Design" tab when I inspect the image in the Squarespace WYSIWYG editor, and editing this fixes nothing), but appears to be a default animation such that when the page loads, all images fade in automatically. Well, for some reason, this animation stopped functioning and now all of our images are stuck at 0 opacity and thus invisible on the page. I thought perhaps there may have been a javascript error issue, where some code was breaking javascript on the page and preventing an animation from running, but I observe no such errors in the console, and the rest of the javascript farther down the page is executing fine. So, the conclusion I'm left with is that this must be a major Squarespace bug. Is anyone else experiencing this problem? I am unable to contact Squarespace support because they are not available now until Monday morning. If there were a way to turn off this automatic animation behavior, I might be able to fix it, but I can't figure out what setting in Squarespace actually controls this behavior, perhaps it is baked into the template that my employer used to start the site before I revamped it? Looking at it in devtools again, I notice that the attribute "data-load" is set to "false" on these images. Setting "data-load" to "true" makes the CSS match a rule with opacity: 1, making the images visible. So perhaps there is a loading problem after all. Nothing has been changed from our end, though. Image Attachment #1: Should look like this. Currently looks like this (with my annotations, note the "opacity: 0" and "data-load" attribute in the CSS rule):