Stuart Silvester

You should have a renewal invoice waiting for you now.

You shouldn't be seeing that get logged anyway, it sounds like you may have the DEBUG_LOG constant enabled. If you have, this will cause a huge amount of things to be logged.
If it isn't enabled, it could be the plugin you have that is extending your registration process logging the response.

I don't think we've said anywhere that we're removing it, it's even documented: 
 

Security through obscurity isn't the best idea. We recommend using the built in tools instead such as requiring multi-factor authentication for AdminCP access.
We also often see that customers that have done this still forget to rename the folder when upgrading manually and they end up with two admin folders, one that redirects to the other completely ruling out any obscurity advantage.

Security through obscurity isn't the best idea. We recommend using the built in tools instead such as requiring multi-factor authentication for AdminCP access.
We also often see that customers that have done this still forget to rename the folder when upgrading manually and they end up with two admin folders, one that redirects to the other completely ruling out any obscurity advantage.

Security through obscurity isn't the best idea. We recommend using the built in tools instead such as requiring multi-factor authentication for AdminCP access.
We also often see that customers that have done this still forget to rename the folder when upgrading manually and they end up with two admin folders, one that redirects to the other completely ruling out any obscurity advantage.

It's a background task without progress, so that's going to be a bug.

I'm not really sure what would cause that, a first thing to check would be to re-upload all Invision Community files to your server again to make sure they're all correct.

I'm not really sure what would cause that, a first thing to check would be to re-upload all Invision Community files to your server again to make sure they're all correct.

Note in your stack trace that you're seeing code load for the frontend (See Dispatcher\_Front) - 
#6 /usr/home/xxx/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\_Front->init()  
It looks like when you're going to /admin/upgrade it isn't actually loading the upgrader, but redirecting the request to the front end. It could be a mod_rewrite rule that's doing this.

Note in your stack trace that you're seeing code load for the frontend (See Dispatcher\_Front) - 
#6 /usr/home/xxx/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\_Front->init()  
It looks like when you're going to /admin/upgrade it isn't actually loading the upgrader, but redirecting the request to the front end. It could be a mod_rewrite rule that's doing this.

Note in your stack trace that you're seeing code load for the frontend (See Dispatcher\_Front) - 
#6 /usr/home/xxx/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\_Front->init()  
It looks like when you're going to /admin/upgrade it isn't actually loading the upgrader, but redirecting the request to the front end. It could be a mod_rewrite rule that's doing this.

Note in your stack trace that you're seeing code load for the frontend (See Dispatcher\_Front) - 
#6 /usr/home/xxx/system/Dispatcher/Dispatcher.php(109): IPS\Dispatcher\_Front->init()  
It looks like when you're going to /admin/upgrade it isn't actually loading the upgrader, but redirecting the request to the front end. It could be a mod_rewrite rule that's doing this.

You might want to enable the 'DEBUG_TEMPLATES' constant in that case, it'll avoid the use of eval for debugging.

No, I have re-sent you the renewal invoice 🙂 

No, I have re-sent you the renewal invoice 🙂 

Typically this can happen when GD runs out of memory processing an image -- It doesn't have to be a huge image, but it might be a complex one. You can (if available) switch to ImageMagick for image processing or temporarily increase your PHP memory limit.

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.