Stuart Silvester

Thank you, we'll make sure this is fixed in an upcoming release.

That would be something up to your ad network to implement. Google Ads support responsive ads, so I wouldn't think you need to set up mobile/desktop/tablet specific versions. The backend has no way to know what device the user is using or what size it is, CSS media queries work in the end users browser based on the viewport size and then hides or shows depending on the CSS classes defined. That does mean that the browser will still load those things, they may just not be visible. That's how CSS and web browsers work.

Thanks, I have opened an internal bug report to take a look at this.

I have opened an internal bug report so we can look further into this, it isn't a caching issue in the general sense.

Thanks for letting us know, we'll look to get this fixed in a future release.

If you don't use it, you can uninstall it in 3.1 before upgrading. You shouldn't run into the issue then.

We're still looking at this via the accounts ticket. As noted above, the problem is that your database has Pages/IP.Content installed but your license does not have that application included at this time. I have asked our accounts department a question about this and they'll reply as soon as they can.

With PayPal Subscriptions, PayPal are completely in control of when any payments are taken from the customer. We've seen them be late in the past sometimes up until the next cycle) but they've been generally reliable recently. You would need to contact them if they're taking too long to process a renewal.

Cloudflare is still blocking the request, we're seeing CF error code '1020'.

I'm afraid there isn't, you would need to use the Authorization Code flow to use MFA. You should see both, the table has a filter at the top to switch between the types. These will always be available on the /core/me endpoint, but they're not generally available in the member object anywhere else. -- These can be considered 'sensitive' because they are related to the anonymous sign in functionality, if they were to be available it could leak information about when the user was anonymously active.

The OAuth 2 spec does not have an MFA grant type, Auth0 however looks like it does have a custom one. We follow the standard OAuth 2.0 specification with our implementation. If you enable MFA in Invision Community, it will prompt the user during the login process. It logs the requests to AdminCP > Rest & OAuth > API logs. It can be useful for debugging and development. Secondary groups are a little special, members don't know which secondary groups they belong to and thus they're not made available via the REST API unless using an elevated permissions (API KEY) access. The /me endpoint is special too, the 'email' information within it is controlled by the 'email' scope that the user accepts when initially logging in. This is the only member object that will contain an email address when using OAuth. This does appear to be a bug, we'll get this addressed.

We don't currently have a method to do this. However it did come up internally very recently and it's something we want to solve in a future release. There are global compression/quality settings in AdminCP > Files > Image Settings.

Yes, we've recently been testing a fix for this. It'll be included in a future release.

By default we nofollow profile links and block them being indexed via robots.txt https://invisioncommunity.com/4guides/advanced-options/configuration-options/seo-robotstxt-r364/

You can truncate content in emails via a setting change. AdminCP > System > Email Settings > Truncate Content

They're response times. During the outage, customer URLs were still responding to requests but they weren't responding with the 'normal' page.

Activity Streams have always used Elasticsearch if it was enabled, but yes in 4.6.9 it's also used to generate the content for the Similar Content widget (and it's doing a pretty awesome job of suggesting similar content).

You purchased it here, go to https://invisioncommunity.com/clients/purchases/, you should see an option to renew it.

It should hide the next time it checks for new bulletins.

We designed the Post Before Register feature to streamline the ability for guests to post whilst also requiring them to register. You might want to give it a try... - more information: https://invisioncommunity.com/news/invision-community/44-increase-visitor-registrations-with-post-before-registering-r1106/

That wouldn't be post before registering (topics aren't visible before registration is completed and would have a valid member after registration) , it looks like the OP may have permissions set so that guests can post topics. Go to AdminCP > Members > Member Groups > Click the padlock icon next to 'guests'. Make sure that they don't have any permissions for posting replies or topics.

That's an old bulletin from 2019 that appears to be stuck in your system (we removed it a while ago), you can disregard it. Elasticsearch 7.2 and newer are currently supported.

Since you're using our Cloud service, we manage the SSL certificate for the site. It is set up correctly and working properly. As noted though, the issue is that OpenDNS are blocking your requests for some reason.

OpenDNS is blocking your request and that's also why you're seeing a certificate error (because they're using their own instead of the valid one). You will need to contact your network administrator that set up OpenDNS to find out why it's blocked or I suppose you could click the "Report an incorrect block" button.