500: Server Error when editing templates

I’ve just updated to v5.2.19 and I’m getting 500: Server Error every time I try to modify a template.
Invoices and other things seems to save ok.
I have checked allow_url_fopen and it is enabled.
I have also disable modsecurity via .htaccess on the subdomain
Error logs show no error. PHP 7.4

[2021-08-19 00:00:03] production.INFO: latest version = 5.2.19
[2021-08-19 00:00:06] production.INFO: updating currencies
[2021-08-19 00:00:09] production.INFO: latest version = 5.2.19
[2021-08-19 00:30:02] production.INFO: Performing Autobilling 2021-08-19 12:30:02

I wish I never updated to V5, it has been nothing but issues ever since I updated…

@david any thoughts to debug this?

the 500’s should be writing the errors to the files. Perhaps your permissions on your files have changed?

Which files should I be checking for permission changes and what should their permissions be set to?

All the files and directory recursively should be owned by the webuser.

Its very strange that when I try to change templates now it works with no issues.
Same thing happened with emails when they weren’t working, they just started to work the following day. Could this be a shared hosting issue not updating things right away?

On my previous post I asked about password issue but I think you may have missed it.
Another issue; when I create a new client and leave the password field empty, it generates a password but doesnt send the password with the email. So there is no knowing what the password is.
Previously I use to make the password the clients mobile number, but now that doesnt work as it wont let the password start with 0. I found that a mobile number was the easiest way for a client to remember their password.
Also in the settings, it says if I dont set a password the client can set it themselves, but when I follow the link it just gives an email and password field, no option to create a password.

We’ve changed the implementation. In v4 we included the password in the email but this is considered a bad security practice, in v5 your client is able to set a password when they first visit the client portal.


Some shared hosts do limit CPU cycles sometimes which can cause weird 5xx HTTP errors.

If nothing else has changed and the app has suddenly started working again, this could explain it.