> 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.
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.