Matt

We use the member ID in the URLs to ensure that the link goes to the correct place. There are some occasions where the 'friendly' part of the URL may not be unique. UTF8 allows for a wide range of characters, some not visible so it would be possible to use specific UTF8 sequences which would be stripped during the FURL process, which could mean that without the URL there is the possibility of it pointing to the wrong person.
It also means that permalinks stored externally still work even when the user has changed their name.

I've replied to FZ in the ticket, but a few things to mention here that we'll improve on:
1) The sidebar widget will only show if you are not subscribed to your own site via Hive. You (the admin) are subscribed automatically during set up, so when you drag in the Hive widget, it won't show for you - but it will show for others. It's a bit confusing but if you log out (or use a private browser tab) you'll see the widget in all its glory. We're looking at ways to improve this so you get some kind of message if you are subscribed.
2) We're working on onboarding to reduce confusion. The site was added and it is pulling in data. I've left a recommendation for FZ on how to log back in.

We love updating things because Elon got bored. 

It's probably caused by the opt-in/essential cookies additions in .11. We're getting a .1 release ready to fix the outstanding issues reported.

I've taken a look at this issue, and it's caused by new javascript code in Invision Community taking full advantage of the ES (2020) syntax, specifically the chaining operator, like so:
ips.getSetting?.('baseURL')?.replace This is only supported from iOS 13.4 onwards (https://caniuse.com/?search=optional chaining operator)
We can remove the chaining operator from this line of code which will fix the issue, but moving forwards we are more likely to use it again - especially for Invision Community v5.

Hi there,
I've taken a look at your account, and you are right, there has been no ticket created. I'm not sure why, but I do apologise.
I've created a ticket from your other topic and I will investigate it now for you.
I'm sorry that there seems to have been some kind of mix-up with this issue, and it falls short of our normal support standards.

To be clear, data is not transferred from EU to US servers to troubleshoot issues on your community.
People geographically located in the US may troubleshoot issues via the AdminCP, but we do not move data from EU to US servers to do this.

I can't think of a reason we'd need to transfer PII out of EU and into US servers, even if we need to repair data or tables, etc.
The article is a little confusing when it says: “Support access for persons in a third country to data in data centres in the EU also constitutes a third country transfer.”

I think this means that someone in the US who needs to copy the data to a local data centre to work on it would fall foul of GDPR, but we do not operate like that.

It has been restored for 4.7.8 in Pages (March release). 🎉

Just as a note to future readers of this topic, the issue looks to be by the Elastisearch provider not allowing access to the task and update by query APIs.
If you get any odd issues with multiple entries where there shouldn't be in streams, it's almost always update by query not working or being blocked by the host.

Don't say it.
 
 
Don't say it.
 
 
 
Don't say it.
 
 
 
Don't say it.
 
 
 
Don't say it.
 

This is fixed and will be in the next 4.7.0 release.

Excellent sleuthing @Andy928!
A fix is now in review and may just make it for the June release.

Cheers J, all sorted.

Cheers. I can clean up the schema, but it's totally harmless. Just a silent error during the upgrade process.

Thanks for letting us know. This should be fixed in the June release.

PR 6963 added, should be in June's release.

PR 6968 opened. This should be in the June release pending review.

I believe the sharing links only show in forums that are accessible by guests. If you need to log in to see a forum, the share links won't be visible (as most services will just return a 404).

This has now been fixed, and the button should work correctly.

I understand what you mean.
You're saying your site is my-site.com, and you have created a directory 'forums' and put the forums in there, so the JSON should report the site as 'my-site.com' but it's reporting 'my-site.com/forums'. I'll open an issue.

We believe we have a fix for April's release.

Ok, I've run recovery mode, cleared your caches and switched the chatbox back online. Your site is now operating normally.

@Cobar The issue is caused by GitHub being down right now. The build process pulls from the latest tagged release, and as GitHub is currently experiencing issues, it's failing there.

Once GitHub is back up, it will work fine.

https://www.githubstatus.com

I've added the ability to upload maskable icons, and this should be in our March release (4.6.11)

Sadly the W3C validator complains about a lot of things we have to do in the real world.

The markup you are seeing is a well known workaround for limitations in how iOS manages start up images across its wide range of screen sizes and devices.

https://appsco.pe/developer/splash-screens
https://www.simicart.com/blog/pwa-splash-screen/

To change device-width to just width breaks this.

It's not something we can fix.