CoffeeCake

Devices instead of IP addresses would be better. I think I've seen a plugin/application that does this.

You might want to log a support request to find out for certain, yet highly recommend you make it a non-issue by only conducting your migrations with copies as part of your plan to actually perform your go-live upgrade. This way, should things not go as expected, you can rest assured that your existing community is unaffected until you can resolve everything. This is how we handled our very large VB->IPS migration.

To be safe, and to follow best practices, you'll want to do all of your testing with a copy of your production site, not touching your live VB5 site or using the live server in any way. Make a complete copy of your VB5 installation (database and files) and do your test migration with a copy, on a completely different server. You'll want to make sure you made a copy of your VB5 database and that the credentials used to access the copy of your VB5 database are different from your production database, just to make sure there's no way possible your tests will impact your live site. Good luck!

How has the update worked on your test copy of your production site?

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

There is insufficient limitation to prevent the viewing of details of a member and give them access within the ACP. We operate on the principle of least privilege, so knowing a member's name, e-mail address, etc. is not necessary to moderate the forums. And, there isn't the "disable for XXX days" type option we have for other actions, such as moderation, banning, etc.

You definitely want to handle this externally from IPS. Look at either setting up a firewall or using a CDN in front of your install that prevents this from happening.

Yes, you can disable it via ACP if you are an administrator, yet the request I made was to make it an available option when a moderator issues a warning and for a period of time. The option in the ACP is in effect until an administrator reenables manually. That functionality still does not exist.

Putty is free and will get the job done.

When self-hosting, there are skill sets that you will need to have and develop. IPS offers cloud-based packages for those customers that want a fully managed experience, and alternatively you can develop those skills yourself or contract with a provider to help with these sorts of things. For smaller databases, this isn't an issue, yet you get the warning you saw when tables exceed certain sizes that may time out. It seems that your install has some larger tables, so brushing up on how to handle this yourself would be well advised. The alternative is that the upgrader doesn't warn you, it times out, and you end up with issues due to the timeout. These issues vary greatly depending on what MySQL is doing in the background.

The 200 error code, in IPS land, is likely coming from your image manipulation software (imagemagik, gd). While @Jimi Wikman is right that a 200 response code for HTTP requests means "success," that's not what you're seeing here.

The reason IPS is asking you to run these on the SQL server itself is because PHP-based queries may time out depending on the configuration of your web server, PHP, and MySQL instance. Long story short: do not use phpMyAdmin to do this. Just like IPS, it runs through your web server and PHP. There is no difference between phpMyAdmin and the upgrader. You should instead connect directly to your MySQL instance via command line to run these queries. Typically, this will involve the mysql command while connected to SSH in a Linux environment. https://dev.mysql.com/doc/refman/8.0/en/mysql.html Read that carefully. It does not say phpMyAdmin.

Not so sure I'd characterize it so broadly. It sounds like your DevOps process was faulty and did not integrate with IPS via its API. Instead you were writing changes directly to the filesystem without updating internal metadata. The particulars about the release notes being less than wonderful are valid and remain an opportunity for improvement. The method you were using to change things within your install is some pretty important information about the particulars of your environment when it comes to troubleshooting the issue, and it's understandable that IPS support would be looking at other areas first. For anyone else wanting to update downloads powered by IPS, they should work on that integration via the API, documented here: https://invisioncommunity.com/developers/rest-api?endpoint=downloads/files/POSTindex

This is most likely a need for a developer that works with Zapier and not so much an IPS. The limitation is on the integration published via Zapier and not in your self-hosted community. Provide a Zapier developer documentation for the IPS API and you'll probably be able to tackle this. Question is, will Zapier allow one-off integrations like that. Edit: Good news, they do https://platform.zapier.com/docs/start

Almost. It's XXX-XXX-XXX-TESTINSTALL. This is what we do.

Fixed your typo. 1. Have a test copy of your production environment. What does that mean? Same version of OS, same version of PHP, same version of web server, same version of MySQL, same extensions, same configurations, different hostname, behind a firewall or otherwise secured. Not "kind of the same," or "almost the same," or "completely different." Same plugins, extensions, themes, languages, configuration for IPS Ensure things that interact with the outside world (payments processors, e-mail configurations, APIs, etc.) are pointed to corresponding test environments as well. You don't want real payments being processed or real e-mails being sent out from your test environment that affect your members. 2. Make changes in your test environment and document your changes carefully, noting the exact steps you took. 3. Test! 4. Have an issue in test? Investigate and open a ticket. 5. No issues, follow the same steps you documented in step 2 in your production environment. If you're doing it any other way, you're gonna have a bad time.

That misses the point of a test environment. You want to ensure things are working exactly as you will have them configured in production. That way, when you make a change in test and breaks something in production, you know not to make the same change in production (and the flip side, if you make a change in test that doesn't break something, you can be reasonably confident that things won't break in production either).

Try it on your test install first and verify it won't be an issue before doing it in production. If you don't have a test install, set one up. This will help you find other bugs that may be new to you or issues you'll need to address without affecting your community.

Google Drive would not be an appropriate file storage method, however Google Cloud Platform does have Cloud Storage that may be an option to investigate. It is interoperable in some ways with Amazon S3, though we've not explored it: https://cloud.google.com/storage/docs/migrating

It's a bit concerning to see security issues not addressed for 4.5, and forcing an upgrade to 4.6. While we are in the process of testing, things aren't at a state yet here in the community where third-party developers have released compatible updates to their extensions. Why isn't there a 4.5 patch? See: Some guidance and communication on when a branch will become end of life would be appreciated.

We have multiple providers, yet for IPS, we use sendgrid with the built in sendgrid integration.