Before we start, Joomla template overrides are a very good tool for site integrators to adapt the core to their needs. But it is a pain for extension developers like us. Why? We will tell you, read on.
What are template overrides?
Template overrides do require some basic PHP, HTML and CSS knowledge. So it is not a tool for everybody who uses Joomla. It allows site integrators to override the output of any extension in a template. It helps when you have a special requirement which can't be controlled by an option or when you need to change the HTML markup. Basically you can copy the view file (mostly default.php) from the extension view folder to your template html folder. The Joomla view renderer will then automatically pick the one form your template instead of the one from the component. It works for core and 3rd party components, modules, plugins and layouts. More documentation can be found on the web or in the official Joomla docs.
What is the problem?
As the view file is a copy of the original file, the problem comes on upgrades. When the original file has changed after an extension is upgraded. For example when new code is added, then the override doesn't get adapted. This can lead to errors or missing features. This is not a problem only for extension developers, also the core is affected. As we introduced custom fields, some templates had an override for the front end article editing form from an old version which was not able to display custom fieldsets in the form. But this are not regular cases in core as new features get added on a much slower pace.
For extension devs it becomes a real problem as we ship new features more often. For example in the release of DPCalendar 6.2, we replaced some javascript libraries with new ones and added the defer attribute to load them faster. All of this happens in the template files (eg. default.php). If you have an override in place, then it still tries to load the old files and can crash your site.
Is it then not a BC break?
You can argue that it is a BC (backwards compatibility) break. But it is hard to expand BC in layout files, otherwise they will become bloated. It would then also mean that every new feature would require a new major version which would be insane.
Is there a solution?
Don't do overrides! Wait, really? It is not that dramatically. But you should really consider if an override is needed or if the changes can be done trough CSS as well. We have many customers who want to do overrides, but then we figure out that it is possible to make the changes with CSS commands too. Or we have already an option which does the job. Yes we have a lot of options, so you can control a lot within DPCalendar.
Joomla has a very minimalistic override management UI which doesn't help here much. So what we did, for Google Summer of Code 2018, added a proposal to spice up the override management. Basically you need a diff viewer and an override detector when an extension or the core is upgraded and inform the site owner that layout files have changed where an override exists in the template.
We hope to shed some light into the biggest issue of Joomla overrides.