Dionysopoulos.me

In Joomla 3 the naming convention was ComponentTypeName where

This conventions held true in both the front- and backend parts of your component. For example, both the frontend and the backend would have a class named ExampleControllerItem and they could not extend from each other. This led to a lot of code duplication. Code duplication is the natural enemy of DRY (Don't Repeat Yourself) code and a source of the most egregious bugs. That's why this practice is mockingly called WET: Write Everything Twice. When you put it like that it sounds exactly as ridiculous as it is practicing it.

As for file naming, things were pretty clear for Controllers, Models and Tables. The name of the file was the Name part of your class name, but in all lowercase. For example, the class ExampleControllerItem was placed in a file called item.php.

Views were... a bit more complicated. A view has a view type which corresponds to the format URL parameter, the default (if not specified) being html. However, if all view classes of the com_example component for the view name item are called ExampleViewItem how does Joomla figure out which one to load for the html, json, raw, feed etc view types? The trick was in the file name. Regardless of the name of the view class, the file name the class was stored in was following the naming convention view.view_type.php where the view_type is the view type in all lowercase (corresponds to the URL format parameter). The HTML view class would be stored in a file called view.html.php. This was maddening because a. the file name does not include even a hint to the class name and b. view classes cannot extend from each other. Another case of WET.

With such complicated class and file naming — not to mention one not always being related to the other — it was impossible to write anything that remotely resembled a working autoloader for component classes. This resulted in Joomla using some ugly static calls in its base controller, model, view and table classes to get the MVC object you wanted. Whether that worked or not depended on whether they were called from within the same component or if you had used other badly documented static calls to tell these base classes where to look for component classes. If you wanted to mix front- and backend classes… let's just say the result was not pretty.

Basically, the Joomla 1.5 to 3.10 MVC class and file naming was a rolling Dumpster fire in the sixth ring of Hell. Yet, it was still better than nothing, i.e. what WordPress plugin developers have to contend with even to this day. It's funny how literally anything is better than nothing and how attached people got to what is objectively a bad solution which was rushed out of the door.

A bit of history: The MVC in Joomla 1.5 to 3.10 was never considered “finished” by its lead developer, Johan Janssens. He was aware of its shortcomings but ran out of time improving it in 2006. Janssens left the project shortly after Joomla 1.5 was released. The MVC architecture wasn't updated significantly in subsequent versions. Features were still added to it, e.g. Forms support in Joomla 1.6, but the class and file naming remained untouched until the release of Joomla 4 in 2020.