Mark H

There is no way to abort an upgrade once it has started, unfortunately. You would have to restore the backup you made before the upgrade. If that is not possible then you'll have to wait for your host to fix the issue with Sucuri.

Please check our documentation for Zapier:

You do not have an active self-hosted license, and your expired self-hosted license is associated to a domain that does not resolve. Please clarify how you are "self-hosting", and at what URL.

Thanks for alerting us, that's been adjusted.

If this is Shared hosting, it's unlikely that the mod_security settings can be overridden on a per-account basis in an .htaccess file, but that's something only your Host would be able to tell you. I'd first ask them if mod_security is actually in use and, if it is, can it be turned off completely, even briefly for testing.

In that case you would need to speak to your host. Only they will be able to determine what is causing those errors, as the one you pasted doesn't have enough info for us to tell that, unfortunately.

The errors are being reported by your server, but the error you pasted doesn't have enough info to say what is the cause. Is that the full error entry for one instance of the errors?

That is also something your Host needs to investigate and correct. Our software does not set the time, the server controls that and only your Host will be able to correct it.

Your server needs to be able to resolve, and make Outbound connections to, remoteservices.invisionpower.com on Port 443 But that error you're seeing means your server cannot do that, for whatever reason. You need to contact your Host and give them this information so they can configure the server to allow it.

You're welcome, glad to see all is well now. 🙂

Please visit your upgrade URL directly (https://domain.com/admin/upgrade/) then login and complete the upgrade which is pending. If you encounter errors when doing performing the upgrade, please reply here to let us know.

You're welcome, we're glad you got the issue resolved. 🙂

Yes, please monitor the Topic which Richard linked.

You are using a Free Trial, but do not have a licensed cloud or self-hosted purchase in the account you used to post this Topic. As well, a Trial packages should not show that error... where are you seeing it?

Terabyte is correct. While it may be working for you now, in the future you will very likely hit that error again, and possibly at the most inconvenient time (e.g. in the middle of an upgrade).

Glad to hear the problem is resolved now. 🙂

Each innodb table within the database would need that setting changed, there's no function to change them all at once. This process is something you would need to ask your host to assist in doing, since the DYNAMIC option is not appearing to you.

This was not fixed in 4.7.5 but will be addressed in a future release.

You're welcome, glad to hear the issue is resolved. 🙂

You're welcome, thanks for confirming. 🙂

Randy is correct on both points, but don't optimize that table. Your host needs to see it in that condition. Contact your host and tell them something like "automated cleanup of deleted table data doesn't appear to be working, please check that and correct it if so?". You can show them that screenshot, or they can check via phpMyAdmin as well. Either way, and assuming you're on a managed server, they are the only ones who can fix this.

Do you have access to phpMyAdmin at your host? If you do, examine that core_log table with it. Check the table's "Size" and "Overhead" values: "Size" is the current actual size of the table. If your shows 9.7 GB then that error you see is valid (though pruning should clean that up). "Overhead" should be zero or "-" as above. If your core_log table shows 9.x GB of Overhead, then your server is not performing the cleanup of the deleted data, which should happen periodically. This is something your host would need to address. Does that resolve the issue? If not please reply with more details as to where you "only see 40 or so entries".

Yes, your host needs to make that change to PHP 7.4. Once they do you should be able to get up and running again, or at least to the point that recovery mode will work. (Also please remember that the current version of IPS Community, v4.7.4, requires PHP 8.x so you should also ask your host if that can be made the default, when you upgrade from 4.6.9 to 4.7.4)

Apologies, it isn't clear what you mean by that. Can you please clarify?

Your screenshot indicates you are using pirated plugins/apps. Note the filenames containing the word "webflake", a known pirate site. Remove those items from your install, or purchase them from an authorized source. Once you have done so there shouldn't be any errors, but if there are you need to contact the plugin's author.