Jim M

Means you have an error in the template (syntax or otherwise) or you have mod_security or something on your server blocking the save action.

While I get the response ID is not really human legible, it is an always valid identification of the response. The "action" you are suggesting the change to, could change over time and seeing a response in the log that could be varying could get confusing and could hinder troubleshooting. Afterall too, we use it in the configuration screen as well, so it makes sense to relate it back that way. I wouldn't be opposed to the response ID and action taken being shown here. As that way the evergreen ID is shown, and the historical action is logged.

Yeah, as Terabyte mentioned, the only way would be to surgically add all the table rows and references back in, ensuring none are missing (if any are missing, you will get errors). Note: we do not support this kind of custom restore and any issues which result from it would be outside of scope as well. The easiest and cost-effective way to do this would be just to restore a full backup.

I see that there is a hook interfering there. You'll want to disable all third party applications/plugins and then test again.

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.

I have answered your support ticket and resolved this for you. In the future, you can run the upgrade at /admin/upgrade

Glad to hear it's working fine. It may still be worthwhile contacting your hosting provider to ensure permissions are correct and that you know how to check in the future.

That is understood. We are attempting to assist you here. If the software is having issues writing to your server, this is the first troubleshooting step to take.

You would need to contact your hosting provider if you are unsure how to check folder/file permissions and ownership. It is different per server and based on your configuration.

While that may be, doesn't mean something could be off and caching was simply hiding that.

Make sure your uploads directory (and all sub-directories) is writable and owned by the correct user/group.

Glad things are working for you now.

The constant is in the constants.php file on your server. Once you remove that constant, you can simply rename the admin folder or re-upload from the Client Area.

You may wish to ensure the user’s device is up to date. The device controls what emojis are represented visually so it would be up to the device display it.