You could have avoided all of these problems by having a developer set up a staging environment, version the site in Git and disallow file editing on the site.
But would you also agree it's a totally insane capability, let alone default, for a CMS to offer a web interface to edit its own running application code? With no VCS integrated or rollback mechanism...
I was too naive to know I should look for a thing like that to disallow.
IMO WordPress' big flaw (and key asset) is its commitment to backwards compatibility. The upside of this is that it was very easy for people to pick up and deploy it on PHP hosting in the 2000s, leading to its massive growth. The downside is that, as a WordPress developer, you're saddled with sticking to decisions made years ago.
It's definitely not your fault that this is unclear, the WP.org documentation does a poor job of explaining the pitfalls. After 5-10 years of working with it you come to understand the weird kinks...
But would you also agree it's a totally insane capability, let alone default, for a CMS to offer a web interface to edit its own running application code? With no VCS integrated or rollback mechanism...
I was too naive to know I should look for a thing like that to disallow.