I think the lack of MVC and general "shaghetti-ness" of the code (why is form HTML rendering mixed in with business logic in the aforementioned file?) is a huge part of why WP has a terrible security track record.
> rendering front end of a CMS site
If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
MVC may be more difficult to grasp, yes - I went through that a decade ago when I moved from shitty PHP scripts similar to the code above (but hey I thought I was being smart by hashing passwords with SHA-512 instead of MD5!) to learning a proper framework like Laravel (and eventually moved off PHP altogether). However, I absolutely believe it's necessary otherwise you kill productivity, increase human errors and make code review much more difficult. If it raises the barrier to entry I'd say that's a good thing as it would prevent at least some terrible & vulnerable plugins from being made.
> If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
Right, but can you give me an example of a dynamic content management system that fully sandboxes its _plugins_? I can't think of one.
I tend towards telling people that adding a plugin or theme to their site is the same as adding its developer to their project. You have to decide where your risks are. But the flip side of this is that adding third party services to a static site generally involves significant GDPR exposure at this point. There is a choice to be made.
> MVC may be more difficult to grasp, yes
It's not that MVC is more difficult to grasp; I've been building PHP apps like that for 16 years (and before that Rails and Perl). I've never had any difficulty teaching it to other developers.
It's that MVC isn't actually appropriate for the generation of static CMS content at all. It ultimately locks you into a very specific pattern of layouts (with all sorts of ugly solutions to break out of the box).
It may not be a popular opinion but the hooks-and-actions approach to WP is a much, much more appropriate system for the generation of code for a content management system.
It gives you a "nudging the asteroid" approach to plugins, where hooking into one function at the right point in the page life cycle gets you what you want. That is more difficult with MVC -- you inevitably run into much greater design complexity. As I've said elsewhere, Magento has attempted this, and they have to offer several different methods (involving dependency injection, method rewriting etc.) that WordPress does not need, because its page rendering has a simpler functional flow.
> rendering front end of a CMS site
If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
MVC may be more difficult to grasp, yes - I went through that a decade ago when I moved from shitty PHP scripts similar to the code above (but hey I thought I was being smart by hashing passwords with SHA-512 instead of MD5!) to learning a proper framework like Laravel (and eventually moved off PHP altogether). However, I absolutely believe it's necessary otherwise you kill productivity, increase human errors and make code review much more difficult. If it raises the barrier to entry I'd say that's a good thing as it would prevent at least some terrible & vulnerable plugins from being made.