wp-login.php is in need of attention, I think, and will get it through REST eventually.

But it's also entangled with the last bastion of one of WP's most underrated/underdiscussed features: pluggable authentication.

If you mean the appearance of the code: it's not to my taste! But it's actually really heavily governed by code standards (including the Yoda conditions stuff).

WP itself will never be an MVC system, but then MVC is really at odds with the hooks-filters-and-actions API approach WP uses, which again you don't have to like but is crucial to its success.

You can make tiny, targeted changes to the way a WP page renders -- with a single hook function -- that would be hard to replicate in MVC without vastly more effort. Magento tries to achieve this, and does it well, but at the cost of needing dependency injection, XML layout files, etc. etc.; it's enormously more complex.

I personally think MVC is the right thing for app development but wholly the wrong thing for the rendering front end of a CMS site, but I acknowledge this is a contentious opinion.

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.