Stuart Silvester

This issue will be fixed in a future release. Specifically it's related to being prompted for a large database update when you're self-hosted. As Marc notes, a manual upgrade at this time is the best solution.

Make sure that you're creating the topic in the forum an not in the category.

The endpoint documentation contains a list of possible error codes and the reason for them: https://invisioncommunity.com/developers/rest-api?endpoint=forums/topics/POSTindex This one is that the authorized user does not have permission to create a topic in the forum.

OS's periodically update which Emoji/Unicode standard they support. You're using something older than Windows 10 21H2 so you won't see and cannot use any Emoji that was added in version 13 of the standard. Upgrading to the latest Windows 10 release will give you more emoji. 🪟🥷🏻🥸 It does look like we're missing a check to see if the emoji can be rendered in your browser, so we'll get that addressed and also take a look at the duplicate results.

Please don't do that, update the credentials in the client area instead.

It doesn't greatly matter, there's nothing stopping us changing it in the future. At least we know what we're getting with this specific version. We'll likely add Unicode 14 to the Emoji soon too, then they'll match up nicely. The solution is to upgrade I'm afraid. The last 3 releases have been more minor in nature due to the holidays so there aren't any huge changes. If there's a CDN available it's better to use that for this kind of thing, plusses are potentially more performance for your end-users if they use another community/site/Twitter that also use the same CDN and you're not having to store and serve an extra 3,660 images on your server.

This has been fixed in 4.7.6, StackPath is apparently not continuing the free CDN for OSS projects (such as Twitter Emoji). We've switched it over to a different CDN (JSDelivr).

This issue has been fixed, however since it was quite a central low level change it will be in the an upcoming feature release of Invision Community (Feb).

The upload will resize the image in the end-users browser before uploading it, I would also suspect this issue is coming from their computer. It's likely that the image doesn't need to be resized to fit within your attachment limitations, but it does to fit within the avatar size limitations.

From such an old version you'll need to upload the files, switch your server to PHP 8.0.x and run the upgrader from /admin/upgrade. Have a look at our guide here, specifically the 3.x section:

You'll likely have a hard time getting it to work on anything newer than MySQL 5.5. You don't however need to be able to load the AdminCP to perform an upgrade. You can upload the new v4 files and go directly to the upgrade process.

You would need to look at the $additionalHeaders parameter to get the Reply-To value (if it exists)

We've done this for a long time, it might be worth checking that your email service/server isn't stripping it for some reason. Here are the headers from a message I just tested: MIME-Version: 1.0 To: incoming@invision.local From: =?UTF-8?B?Q29udGFjdCBVcyBUZXN0?= <test@invision.local> Subject: =?UTF-8?B?QSB1c2VyIHNlbnQgYSBtZXNzYWdlIHZpYSB0aGUgY29udGFjdCBmb3Jt?= Date: Mon, 02 Jan 2023 11:21:41 +0000 Content-Type: multipart/alternative; boundary="--==_mimepart_13ae51f629e2f82a07451774723f2078"; charset=UTF-8 Content-Transfer-Encoding: 8bit Reply-To: =?UTF-8?B?Q29udGFjdCBVcyBUZXN0?= <contacteee@test.local>

It should also have rewrites in it to allow the friendly URLs to function. To get the right rules, go to AdminCP > System > Site Promotion > Search Engine Optimization. Click the download link in the description for the 'Rewrite URLs?' option.

Yes, that's the reason although it wasn't a forgotten temporary thing. For the majority of communities (even huge ones) they don't typically have enough members to get near the limit of MEDIUMINT and it wasn't worthwhile forcing a large number of database changes for those that wouldn't be affected. We've got an internal issue for this so we'll make it easier to change these columns when appropriate. For @David.. as a temporary work around, if you find the lines in the file @teraßyte mentioned ( /system/Application/Application.php on line 2846), temporarily delete the following and then go to the support page in the AdminCP. if ( isset( $differences['type'] ) and ( $differences['type']['is'] == 'MEDIUMINT' or $differences['type']['is'] == 'INT' ) and $differences['type']['shouldBe'] == 'BIGINT' ) { unset( $differences['type'] ); if ( isset( $differences['length'] ) ) { unset( $differences['length'] ); } if ( isset( $differences['unsigned'] ) and !$differences['unsigned']['is'] and $differences['unsigned']['shouldBe'] ) { unset( $differences['unsigned'] ); } } When you're done running the queries it presents, you can restore that file back to default. As always, it's a good idea to make sure you have a good database backup before making changes to the structure.

Yes, that'll be the issue. If you use PHP 7 with 4.7.4+ you will encounter errors as we use code that will only work with PHP 8

In 4.7.4 the required minimum PHP version was changed to 8.0.

Hi @Owlsonline Admin, I just wanted to let you know that I wasn't able to reproduce this on your Community with an S22 Ultra using the Samsung browser

Gift cards can be redeemed at /store/redeem where the value is added to the redeemers account credit.

HI @Dreadknux This bug report was investigated recently and some fixes have been implemented for a future release. Since we're in a bug fix only cycle over the holidays. With this fix being a little more involved, it will be included when we restart feature releases around February at the earliest.

Unfortunately, I'm not able to reproduce this on the same device. The rank should stay attached to the bottom of the view. I see, it's the client area. We've removed it from there.

Sorry for the delay! Can you share more about how are you are sending the request? Your post suggests that you're sending JSON to the API, whereas you need to send the values as POST parameters.

You'll want to keep your eye on (or follow) the vendors issue: https://github.com/ckeditor/ckeditor4/issues/2207. It's up to them when it gets fixed and released.

It's completely normal and part of the Progressive Web App. The service worker periodically downloads the offline page so it can be displayed if the device loses an internet connection or the community is unreachable.