My professional website, created and developed since I idealistically invested in the earliest betas of Elements has picked up seemingly intractable bugs over the years’ updates that are driving me crazy. I tried moving everything to a new host today and the bugs persist, confirming for me that it’s not the hosting config/edge rules/etc.
Character encoding seems stuck in Western (which was the default in Elements betas). Even though it’s now all set to UTF-8 in all Elements’ settings and the body HTML in there’s still something that’s causing Western encoding to appear only once published (via Elements ftp) on desktop and mobile browsers:
The project takes between 8 and 12 seconds to preview even the smallest changes in any browser. This is a huge issue for me as it makes even minor trouble-shooting incredibly time consuming even with a M4 Max.
Dark mode is not working on any browser even though it’s set correctly.
Google has, since I built the site, told me the site map is unreadable, even though I can see sitemap.xml sitting in the same directory as index.html. So I’ve lost a search ranking that took me years to build up.
I sent Elements Support the project on 2 September; I’ve subsequently emailed them three more times to ask if they can at least quickly check the project on their own machines no less than 4 times, receiving nothing more than an auto-reply directing me to the forum, which is incredibly frustrating. So here I am.
I really regret ever outlaying many £ to Elements for almost no support when I’m desperate. It’s literally ruining my business: people can’t even read my bloody name on the top of the website (which may also explain why I’ve disappeared from search!!)
Yet I’m here now and it’s a big and complex website that I don’t have time to rebuild elsewhere.
Perhaps someone else in the community has encountered and fixed some of these problems? Thanks in advance – you’re my last hope before I give up and reactivate my Squarespace site…
There may be more going on than you think. If your site is adamsebire.info, when I attempt to go there I get a security notice, meaning something isn’t hooked up right for https, and that would definitely impact your search results. It’s also unclear exactly where your problems are given your descriptions (other than the International characters bit).
The thing that makes me pause is your comment about long preview times. My first question would be are you making your own (or using others’) devpacks (as opposed to items built into Elements or on sale at the store)?
As for sitemap: “unreadable” is different than “not there.” Google is telling you that something in the sitemap is not in the form it expects. So one thing you can do is copy what’s in that file and show it here. It might give us hints about some of your problems.
Finally, just so we’re all on the same page, when you have problems it helps if you identify which macOS and Elements versions you’re using.
Character Encoding - This seems fine on my end, I’ve tested both Safari and Chrome. Both are showing UTF-8, and your home page text looks to be displaying correctly. I’m not seeing what you are seeing in your attached screenshot.
Google Sitemap - Your sitemap looks fine. Are there any other messages in Google Search Console showing you why it can’t fetch the sitemap? Usually you’d see some errors or warnings that give you a hint on what might be wrong.
Dark Mode - This looks like it’s related to the Google Analytics tag you are placing in the global template head section. Something is causing that javascript to get malformed on preview and publish. This in turn is messing up the page source which has a top down effect of causing dark mode not to work. If I revert your global template to default, then dark mode works fine. This seems to be something we’ll need to look into, and I’ve reported that to the team.
Regarding the site previewing slowly, this seems to be caused by one of your custom HTML components. I deleted all of them and the site preview returned to normal speeds. Unfortunately due to the amount of custom HTML components you have created (42), I couldn’t test one by one as that would be terribly time consuming and testing custom components is beyond the scope of our support, however that would be a place to start looking. I’m wondering if all those custom components are necessary. Are they all doing something that our built-in components cannot do? And are you having AI write those custom components?
The site has been wonky over the weekend as I ironed out SSLs and the transition to a new host that’s 100% green-energy powered. Now that it’s up it it’s been confirmation for me that the issues weren’t host-related. I’m on v3.0.18 and OSX 15.8.
First: the progress. In a fit of desperation last night I used an external tool to create a sitemap www.adamsebire.info/sitemap-copy.xml and uploaded it to Google Search Console. Just now … hooray … for the first time in 18 months my website is back to around page 2 in key searches (previously Google knew of my site but the last sitemap it’d been able to read was pre-Elements). Comparing that XML to the one Elements generates, it’s something to do with Elements’ pretty URLs which probably originates from the way I set up the site in the first betas. I am no website expert, as you will have gathered, and I was trying to keep URL consistency whilst moving over from Squarespace. Hopefully I will work out a way to fix this within Elements – without buggering up all my URLs up again – but for now an externally generated sitemap is the solution to GSC saying Elements’ one couldn’t be read.
So yes @thominator, it was those missing forward slashes that’d upset GSC for the last 18 months. And your question about DevPacks: hmmm, I have only created my own to port across certain parts of the “Artist” template from the store. But I’ve no idea how to unpick my pickled packs so I’ll try Dan’s idea first.
Thanks Markus for pinging @differentdan, and to Dan for the response.
Character encoding : my site only looks readable if I manually add a line to my .htaccess (under the previous host I’d spent ages diving into Edge Rule hell)! Without AddDefaultCharset UTF-8 the site goes wonky on every publish. If I was using an FTP client I would guess that I’d used the wrong protocol but this is creeping in during SFTP publication from Elements. For now it’s under control but I do worry about downstream implications for search as my name and most of my work is done in countries that use ø é and even ᑕᕐᕆᔮᒃᓴᓂᒃ My (perhaps unfounded) hunch is that something crept in when I set up the site under an early beta bug which defaulted to Western even when I chose UTF-8, and whatever gremlin it is refuses to go away.
Sitemap: as above, my wonky workaround is (for now) holding. I think I need to take a deep breath and try to work out where I’m missing forward slashes then hope it doesn’t further enrage the machine.
Thanks for looking further into the dark mode problem. Actually I just now noticed that it is kind of working on some bits (eg. the bottom of my contact page) but not on the top of the same page. Yet the WYSIWYG preview in Elements itself shows the top working also.
Re: the 8-14 second previews. This is the biggie as it’s driving me completely balmy. It’s extremely helpful to know you’re seeing it too: this was the main thing I wanted Support to tell me. My endless wrangling with it to date had assumed problems with firewalls, browsers, etc. (Hours because every small adjustment takes around 12secs to preview!)
The reason I have those 42 components is because I’m a filmmaker and most of my videos are remotely hosted so I had to build components (until the Video component came along, but that only handles some videos). No, I’ve never used AI to write them; they’re HTML snippets pasted from my various video hosts. So at least now I know where I must look – thank you Dan. I shall convert as many as possible to the Video component. But as the whole point of coming to Elements was to move away from American companies such as Vimeo and YouTube I will still need quite a few components for the videos I’ve moved to PeerTube instances and European CDNs.
Thanks for sending the project over, it’s really helpful. I’ve found the problem with the Google Analytics script in your global template. Some unicode characters were tripping up the export tidier. I’ve fixed that, and it’ll be in the next build.
The dark mode issues look like they were caused by the same script, so they should be sorted by that fix too. Let me know if anything’s still off once you’ve updated.
I’ve also replicated the slowness and will try to have a look at that too, I’m intrigued to see what’s in those custom components.
If you do isolate which component or what code is tripping every preview up please let me know, as it’s extremely slow work for me to try to iterate (due to the delayed preview – catch22).
And as much as I would like to replace all the HTML snippets with Elements’ video component, the problem is that the component has never (in my experience) been able to handle non-horitzontal Vimeo videos, so I can’t.
If you visit this URL, I have left the problem in place. The top left uses Elements’ component to show a vertical video; it shrinks as soon as you click it. The one below is Vimeo’s embed code as a HTML component. TALL doesn’t work and nor does CUSTOM RATIO with 9:16. (The online version at the time of writing is the the Video component set to TALL/COVER/CENTRE).
I haven’t tested square/circular videos since upgrading to v3.1.0 but from memory they suffered similar problems, if you want to test one also, while debugging: AnthropoScenes (teaser)
I can see your css workaround is in the page code but something else is going on … and I’ve used 45mins getting nowhere (because of the slow previews problem). I will go back to HTML snippets for now since I at least know they work.
(which may also explain why I’ve disappeared from search!!)
able to resurrect old music videos and many old creations….
