Stuart Silvester

Right here: https://invisioncommunity.com/clientarea/cards/

This can happen when you export a database with the wrong character set, i.e. if moving server etc. You would need to specify --default-character-set=utf8mb4 when running mysqldump.
It is irreversible, you cannot restore the now corrupt emoji data.

Yes, though @Stuart Silvester promises insane improvements. I'd need to see it myself first to believe it, that's how scarred I am from the experience. 😅
There is no support for partial conversions. You can't convert the first million posts and then go back and finish off the rest. Would this be nice? Yes. But... if they managed to get this down to a few hours of downtime, then great news for you. This means you have some choices in how to approach this.
Our approach was to develop modifications to vBulletin to essentially create a "read-only" mode, make a snapshot of the vBulletin database at that point that would be our source copy for conversion, and then run the conversion on that snapshot in a separate migration environment from production. We had separate migration specific MySQL instances that were tuned specifically to perform as efficiently as possible to the migration, and removing any and all external load from slowing things down.
We announced our planned migration window well in advance, had established a solid estimate for the length of time it would take, and kept members informed through a status page of our progress. Our production servers continued serving out vBulletin in read-only mode for the length of the migration, until we were ready for the switch over. Our cutover involved swapping out the underlying VMs, so after confirming everything was ready to go and all of our tests passed indicating as best as we could assume success, we redirected our IP traffic to the new IPS configured VMs and began serving out requests from our new production IPS environment.
This resulted in minimal downtime of our content, though had the unfortunate impact of having to be in a read-only mode for the duration. We could have left vBulletin in full operation, but all changes that would have been made after we took the migration snapshot of the database would have been lost, and we determined that this was not acceptable for our case.
I would not do this. I would only work with complete copies of your vBulletin database. Because of the layered approach the process takes, you can't be sure that things end up correctly until the end. If you want to create a sample of vBulletin data and then run migrations on that to just confirm a test to test conversion, that may be a good idea, yet I would early on start using copies of production. Every time we ran another test migration, we started with the exact process we'd use and take a fresh snapshot of prod.
This is exactly the process we used. Don't overrely on your members though, and encourage them to report anything that seems off. Many of the issues we found that our testing members did not find were things they assumed were supposed to change. Make sure you include members with long histories on the community and new members, and that you have representative samples from all of your usergroups if there are varying levels of permissions in your implementation.
And! Don't forget to test e-mails and make sure that test e-mails don't go to your members. We had a special process for redirecting all outbound e-mail from our test and migration environments into a viewer that allowed us to see the contents of those e-mails and make appropriate changes. There is a constants.php setting you can set to ensure that e-mails go to /dev/null until you're ready for that.

Now now, let's not hosting-shame.
This is something that could have tripped any of us up, regardless of whether the site were running on a repurposed Sega Genesis in the garage or had a full dedicated datacenter, as it involved multiple moving parts across multiple providers, and the SSL cert would not have been visible from the browser.
Being methodological in troubleshooting, not allowing confirmation biases to impede our attempts to identify the root source, and generally keeping our disordered personality traits in check go a long way to getting things resolved as quickly and calmly as possible.

The issue was that your SSL configuration on your server is broken, disabling SSL between Cloudflare and your server works around the issue. This is a workaround specifically, if you fix your SSL certificate, you can switch it back to full SSL mode.

The issue was that your SSL configuration on your server is broken, disabling SSL between Cloudflare and your server works around the issue. This is a workaround specifically, if you fix your SSL certificate, you can switch it back to full SSL mode.

This is because there are a lot of opinion based threads here. I don't think "Like" is a good reaction when you want to agree or support what has been said in a thread but currently the only agreeable reaction. 
Like is a broad (and at least for me) a very default way for people to respond/react to something that they simply think was a good read.
In some cases I would like to actually agree with what the member is saying or support it with a +1. To me agreeing versus liking something will give me a better way to show my appreciation to a members post.
An example a cute joke in the middle of an opinion thread would get a like or a 'haha' but something that brings up good points can get my 'agree'.

The issue was that your SSL configuration on your server is broken, disabling SSL between Cloudflare and your server works around the issue. This is a workaround specifically, if you fix your SSL certificate, you can switch it back to full SSL mode.

That shouldn't be the case, we'll have a look into this 🙂 thank you for letting us know.

'EX0' is an uncaught exception, essentially it's anything that is unexpected. On registration, it's typically caused by a third party plugin/application.

'EX0' is an uncaught exception, essentially it's anything that is unexpected. On registration, it's typically caused by a third party plugin/application.

We have made some optimizations for 4.6, mainly disabling Redis data being encrypted by default.

We have made some optimizations for 4.6, mainly disabling Redis data being encrypted by default.

We have made some optimizations for 4.6, mainly disabling Redis data being encrypted by default.

It's an extra attribute on the image tag, if a browser does not understand it, it will be ignored. It won't break anything.

A blank page would typically mean that PHP encountered a fatal error. Your server PHP error log should contain further information about the issue.

@Adriano Faria The issue with @Morrigan not being able to upgrade is because your new application has a lower (long) version number than your plugin did (despite this being a point in the guidelines for this exact reason). No one using your plugin will be able to upgrade to the newer version.

Yes, you would still need to configure the CORS headers. The main difference is that you will be sending requests as an authenticated user instead, so they'll only be able to see things that they're allowed to see and perform actions where allowed.

It's an extra attribute on the image tag, if a browser does not understand it, it will be ignored. It won't break anything.

The difference is that when you use an API key, you're interacting at a high level. These requests do not have extra permission checks on them to determine if the end user can see the content.
Even if you're specifically crafting a URL to fetch topics from a certain forum, your same API key could be used to fetch topics from a secret forum that you don't want anyone to see.
https://invisioncommunity.com/developers/rest-api

There was a reason we didn't add it to profile photos in the first place, it caused some issues due to how some of the profile photos can be loaded in content via AJAX.
We do ultimately want to move towards native lazyloading (which wasn't a thing when we designed this functionality) it would just be nice if Apple finally supported it on MacOS and iOS - https://caniuse.com/loading-lazy-attr

There was a reason we didn't add it to profile photos in the first place, it caused some issues due to how some of the profile photos can be loaded in content via AJAX.
We do ultimately want to move towards native lazyloading (which wasn't a thing when we designed this functionality) it would just be nice if Apple finally supported it on MacOS and iOS - https://caniuse.com/loading-lazy-attr