[#30083] - [4.0] Separate user/template provided overrides
- Closed
- 20 Jul 2020
- Medium
- Build: 4.0-dev
- # 30083
- Diff
- dgrammatiko:properlayouts
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
The problem
Let's do a simple case study:
Imagine that you're a dev/designer/admin/etc and you decided to use a 3rd PD template. To make this more realistic let's say that you want to use @C-Lodder https://github.com/C-Lodder/joomla4-backend-template
Few days later you decide that some changes in one of the overrides will fit better your use case. You ego ahead and do the changes. Couple days later Joomla says that the template has an update and you go ahead and apply the update.
Ooops your overrides have been overridden
Ok, apart from this case also the core itself provides overrides https://github.com/joomla/joomla-cms/tree/4.0-dev/administrator/templates/atum/html which CANNOT be overridden by the user. So, to cut the story sort here, there are 2 MAJOR problems here:
- User is not able to actually override everything (as the project is advertising)
- There is no way any template to provide safe, self owned overrides and also allow the user to use/create their own ones
The solution
Provide another html, I've named it base_html, lookalike folder in the template.
Summary of Changes
First and foremost the changes here are totally B/C.
The only changes for this to work are:
-
add the
base_htmlbased files as a lookup (2nd in order, html is always the winner if exists) in the MVC, modules and JLayouts -
Patch the override creation process so if a template provided override exists then this will be copied over to the HTML folder
Testing Instructions
Create some overrides, component, module, layout (use the Atum as your base as it's easier).
Edit each of the overridden file and add some simple text, so you can understand which file was used for the rendering of the page
Rename the html folder to base_html. You should be able to see the same texts
Create the same overrides you did before
The files inside the html folder should have the texts from the base_html files. Rename these texts. Now the rendering should display the last changes.
@ciar4n as a template provider can you give us some feedback here?
Documentation Changes Required
Yes, I guess
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_templates Language & Strings Libraries Front End Plugins |
| Labels |
Added:
?
?
?
|
||
| Category | Administration com_templates Language & Strings Libraries Front End Plugins | ⇒ | Administration com_templates Libraries Front End Plugins |
| Labels |
Removed:
?
|
||
| Category | Administration com_templates Libraries Front End Plugins | ⇒ | Administration com_templates Libraries |
| Title |
|
||||||
but it really needs its own master plan on what is looking to be changed and what the desired end result
@mbabker thanks for checking this! This PR basically solves my own needs which are only to keep consistency for the overrides but I guess someone (eg: me) could do the same additions on the lookups for css/js/images. That will leave out the root .php files (index.php, component.php, error.php, etc) but my feeling is that if you're going to touch these files then you're essentially forking the template and although wp had this option for ages I'm not so sure if Joomla wants to go that way as well.
So, the static assets can also be patched in a similar fashion (base_css/css, base_js/js, etc) without any B/C breaks but as you mentioned this leaves out the root entry files.
Also now that I'm thinking about the root php files someone could use JLayouts for the html part and thus have a working solution for those as well (although not sure if that qualifies as such)
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-07-20 17:44:10 |
| Closed_By | ⇒ | dgrammatiko | |
| Labels |
Removed:
?
|
||
You really need WordPress' theme inheritance mechanism here and all the intricacies that are involved with proper template hierarchy for all aspects of a template, not just code dealing with HTML overrides.
This doesn't address customizations to
index.php,component.php, orerror.phpin any way.This doesn't address if someone wants to make a change to a CSS or JavaScript file included into the template.
custom.cssis really only useful to people who can't or won't work with pre-compilers and even then only for a limited subset of CSS related changes before it starts becoming a performance burden on a website (for all you PageSpeed Driven Developers, that means lower scores) and there isn't a mechanism for custom JavaScript in templates at all without either touching PHP code in some way (ranging from adding a line toindex.phpfor simple changes to writing a plugin that will correctly load said JavaScript) or abuse of the custom HTML module (and the side effects that creates based on module rendering). For people who do work with pre-compilers you're left with a hard fork of the template to avoid a compiled asset being overwritten.So this might be a first step in making improvements to the templating experience, but it really needs its own master plan on what is looking to be changed and what the desired end result is so that it doesn't end up with monkey patching support for different capabilities in a haphazard and inconsistent way.