Trouble Overriding A Deeply Nested Template File
Permalink
I'm having a hard time overriding a template file located here:
packages/problog/blocks/problog_list/templates/simple/view.php
I put mine here:
packages/brp/blocks/problog_list/templates/simple/view.php
but it's not working. My overrides cache is off.
What am I doing wrong?
packages/problog/blocks/problog_list/templates/simple/view.php
I put mine here:
packages/brp/blocks/problog_list/templates/simple/view.php
but it's not working. My overrides cache is off.
What am I doing wrong?
Thanks!
That does work. But I was hoping to keep everything within my package. Is that not possible?
That does work. But I was hoping to keep everything within my package. Is that not possible?
Components of packages cannot be overridden by other packages. There was some talk about enabling that a while back, from what I seem to remember it wouldn't be a massive change to the core. The reason I remember hearing for not doing so is that it couldn't be arbitrated deterministically.
A way round it is for a package to copy the file to the root during its installation, always advising the site admin and ideally asking permission first. Doing stuff like that in a marketplace package gets it classified as black.
Is there a particular reason for overriding the template rather than create an alternate template and using that, perhaps even setting it as the default?
A way round it is for a package to copy the file to the root during its installation, always advising the site admin and ideally asking permission first. Doing stuff like that in a marketplace package gets it classified as black.
Is there a particular reason for overriding the template rather than create an alternate template and using that, perhaps even setting it as the default?
No particular reason to override vs. create a new custom template other than me defaulting to override rather than replace.
I'll try it with a new custom template.
concrete5 has been around long enough to have good reasons for it's designers' structural choices. But I could certainly make one case for allowing a package to override parts of another if there is a dependency between them. But then there'd be the need to roll in Composer, or some such package management tool, for that.
I'll try it with a new custom template.
concrete5 has been around long enough to have good reasons for it's designers' structural choices. But I could certainly make one case for allowing a package to override parts of another if there is a dependency between them. But then there'd be the need to roll in Composer, or some such package management tool, for that.
ChadStrat