Template engine changes to allow for structure flexibility

[hanakin]

And how does mapping help you with that? It is still a simple rename. You can break it into object with current naming or after mapping - it won't make any difference.

The mapping is more for the twig issues, also the organization into subfolders i think <- @PayBas

[Arty]

And why that can't be done with simple renaming? Why do you need to add extra bloat?

[naderman]

I think you have to realize there are two distinct issues being discussed here.

(1) The current organization and naming of files in prosilver
(2) Adding a layer to allow any style to use arbitrary structure and file names

We all agree that (1) needs to be changed. So let's just reorganize and rename all the templates, and let's just do that the same way for prosilver, but there does not appear to be a need to have every style have their own structure, so (2) seems like an unnecessary complication as per Arty.

[MichaelC]

The enhancements to inheritance are demonstrated in https://gist.github.com/michaelcullum/6 ... 4676ea2563 - this means it allows usage of more than one parent (instead we are moving more to a standard dependencies model where you could even have two styles requiring each other) and explicit declarations of which style to use for different maps. It also allows overriding of maps used in parent templates should you only wish to change certain parts.

I don't think every style will suddenly have it's own wildly different, drastic structure and I think the styles validation process and simple lack of need will prevent this. I also think it will still be obvious what files are called as people won't call them random names and the styles validation process again will help mitigate this potential issue, not to mention if it happens to be that it really is not clear, it's as simple as looking it up in a file. overall_header.html and overall_footer.html are easily renameable (as far as i know they are only referenced in templates) but they are rarely (I don't think I've ever seen it) renamed.

With regards to the reorganisation of files, I think this needs to happen but disagree with doing it in prosilver as I don't think that making really horrible style diffs for prosilver is a good move to make (splitting components out of styles, renaming styles and standards edits to them) either when we want to promote people to update/convert styles to new versions, especially with x.y releases annually now. In addition to this, the naming and splitting up of components/includes in future styles is unlikely to be identical to that of prosilver and they will likely have different purposes.

Also, as Bas mentioned, this also provides an easy way to allow for sub-directories and varying file extensions which would need doing anyway.

Do you mean ability to point to template from another style? If its already part of style tree then template inheritance already takes care of it, therefore template name mapping is pointless. If its not part of style tree then there should be mechanism to make sure required template exists, adding extra layer of complexity to styles management, which requires a lot of development and testing for feature that I doubt anyone would ever use.

Checking the style dependencies (and relevant versions) will be handled by composer (the getting/installing of deps, the dependency resolution etc.) in 3.2 with extensions, language packs etc. anyway but that's a different debate. If you mean checking the existence of individual templates then we have that already.

Something that as far as I'm aware no style author ever wanted or needed to do.

Well, I believe that's what happening right now?

I think another core thing we need to keep in mind is that this is not just about changing the names of templates for files called from the core controllers but template files called from within templates whether they be in the default style of phpBB or whether they are random new files (with special components etc.) added by style authors.

[Arty]

The enhancements to inheritance are demonstrated in https://gist.github.com/michaelcullum/6 ... 4676ea2563 - this means it allows usage of more than one parent (instead we are moving more to a standard dependencies model where you could even have two styles requiring each other) and explicit declarations of which style to use for different maps. It also allows overriding of maps used in parent templates should you only wish to change certain parts.

I like that! If its implemented with support for adding dependencies to template.json, then I'm all for it.

[MichaelC]

The enhancements to inheritance are demonstrated in https://gist.github.com/michaelcullum/6 ... 4676ea2563 - this means it allows usage of more than one parent (instead we are moving more to a standard dependencies model where you could even have two styles requiring each other) and explicit declarations of which style to use for different maps. It also allows overriding of maps used in parent templates should you only wish to change certain parts.

I like that! If its implemented with support for adding dependencies to template.json, then I'm all for it.

It will be, although the required styles dependencies will be in composer.json (which will replace style.cfg).

[PayBas]

Yeah, so basically everything MichaelC said .

My main gripe is still with the backwards-compatibility part.

Indeed we want to change the template file structure. Not just a bit, I mean completely. I think most people would agree with this (since the current template structure is seriously outdated).

Updating the backend to reflect these changes... and updating prosilver for this would be an absolute nightmare. Especially since this would basically break every single available style that inherits from prosilver (requiring style updates that would probably be even bigger than 3.0.12>3.1.0).

It also would require extensive testing for prosilver (which nobody wants to do at this point), as well as creating a disparity between future styles which use components, and a patched-up prosilver. Again, I don't think anyone wants to put in the time to conform prosilver to the same component-structured template design.

So while I agree that creating an abstraction/mapping layer is not ideal, and should be avoided if possible... I think it's a necessary evil.

To give some example of what I mean (this is just an early WIP, please don't look into it too much), just imagine having to refactor prosilver to something like this:

1.png (54.09 KiB) Viewed 326 times

[nickvergessen]

I think you have to realize there are two distinct issues being discussed here.

(1) The current organization and naming of files in prosilver
(2) Adding a layer to allow any style to use arbitrary structure and file names

We all agree that (1) needs to be changed. So let's just reorganize and rename all the templates, and let's just do that the same way for prosilver, but there does not appear to be a need to have every style have their own structure, so (2) seems like an unnecessary complication as per Arty.

Quoted for agreement.

Regarding backwards compatibility. If we mostly rename files and reorder them into different folders, that should really not be a too big problem.
From 2.0 to 3.0 we had worse changes and also 3.0 to 3.1 was really a hard BC break (with removing imagesets).

and updating prosilver for this would be an absolute nightmare. Especially since this would basically break every single available style that inherits from prosilver

And as for "porting prosilver", we always need a sample style for authors, so they can see how it works. However, I would really strongly vote against having two styles again. It's really a pain for developers (you do not want to count the PRs where subsilver2 was forgotten and fixed later, or even not fixed at all). I'm happy we finally removed it from 3.2 and don't think we should go back to that again, even if it's the same style in different structures. we can only test one (or have a lot of overhead).

[PayBas]

I'm not sure how easily we can drop prosilver for 3.2. I think we've indicated in various places that 3.1 is the last supported version for subsilver, and 3.2 would be the last version for prosilver.

In any case. If we decide to not use a template abstraction layer, but decide to hard-code the new template names and directories in the back-end, then we will kill all 3.1 styles again. This might not be a huge problem, but the fact will remain that prosilver will probably not get much real improvements for 3.2 (besides restructuring the files).

This effectively means that all styles that currently inherit from prosilver will have to invest significant time to make their styles compatible... without any real benefit (other than "it works again").

Another solution is to add .html.twig files with new names to prosilver that has only one line: include directive to include file with old name. It will not affect child styles because styles tree works for included templates and there won't be need for template mapping, therefore won't break backwards compatibility and won't add extra php code.

Possible too. But that will also create some confusion, as it will probably double the number of template files.

[Arty]

But that will also create some confusion, as it will probably double the number of template files.

Only in parent style: prosilver. Third party styles will only modify old templates like overall_header.html