The Model View Controller (MVC) pattern is a software design pattern for implementing user interfaces on computers. Traditionally used for desktop graphical user interfaces (GUIs) the original purpose of a MVC application was about the ability to open up multiple views all connected to the same model. When data in the model is changed all the other views are updated simultaneously and instantly. This is the MVC pattern in action.
MVC in a PHP related context is impossible. When a browser has loaded a web page, the connection to the server is closed and it's impossible for the webserver to contact the browser in order to update the view because some data in the model has been changed.
The main purpose of the MVC pattern is to inform all open views about changes to the model data which is why MVC in a PHP related discussion is completely impossible.
Another problem is that in a PHP context the view cannot render anything. The view is residing on the stateless web server and as such it cannot be stateful of its representation. Once data has been changed the view can't do anything about it, which makes the whole point of the MVC pattern in a PHP context fail miserably.
Lets face it! MVC and PHP really don't match!
Why then do most PHP frameworks promote themselves as MVC frameworks?
Unfortunately a lot of the PHP community is driven by "hype" and "modern" approaches without any regard for understanding the underlying technology. The MVC pattern in its original implementation also dealt with separation of layers and as such perhaps somebody misunderstood something yet managed to start a new trend in the community.
Every PHP framework that claims they are using the "MVC" pattern are using different implementations, none of which has anything to do with true MVC.
What most people actually think of when they mention the MVC pattern is Separation Of Concerns (SoC).
In computer science, separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. The main reason for doing that is to achieve better maintainability.
When an application uses the SoC design principle it is called a modular program. When concerns are separated, individual sections can be both reused and replaced more easily.
SoC is great, but there is no one right way of implementing SoC. Rather than religiously trying to jam you web application into specific patterns that doesn't really fit anyway, you should instead be focusing on how you can design your application in a pragmatic and reasonable way. Often this depends solely on what kind of application you're developing, how big it's going to be, how many people are going to be involved, what kind of architecture it's going to run on, and whether it's ever going to need to be able to scale easily.
In my humble opinion all these "patterns" and "concepts" that dominates the programming communities in general, and the PHP community specifically, are absurd! The original intent was good, but the result is a kind of madness where everyone is trying their utmost to fulfill someone else's interpretation of the requirements of some stupid pattern or concept.
In the mean time the most popular PHP frameworks has become even more complex, almost impossible to scale, ridiculous contradictory to the underlying web architecture, and notoriously inefficient.
If you have any comments or corrections feel free to email them to me.