Template engine changes to allow for structure flexibility

[MichaelC]

As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.

Also, this does allow for proper restructuring of files beyond the obvious moving component x out of a file into it's own file or renaming things to put them or putting them in directories between different styles which using hardcoded template names doesn't.

Also, it provides a very obvious fix to using different file extensions instead of having to do ugly work with trying both .html and .html.twig

[Marshalrusty]

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.

I agree. At the moment, the new style is not in a place where we can guarantee its arrival in time for 3.2. As such, prosilver will remain the default front-end all the way through 3.2 development. How and when we decide to deprecate/discontinue it doesn't change that fact.

As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.

I think we have to resign ourselves to the fact that BC will take a hit at least in 3.2 and 3.3. All extensions will need to be updated to work with the new style anyway, and it seems to me that changes to the layout of the templates do not increase the degree to which BC is broken, unless you're suggesting leaving everything exactly the same as it currently is.

[PayBas]

Another thing to think about if we don't want to use a template abstraction layer, is how far we want to go in conforming prosilver to the desired new template structure. I agree that reorganizing the prosilver templates could be done, but whether we want to split it up in components as well would determine how much work it is.

For instance, this is a list of all the hard-coded templates in the core (excluding all the UCP/MCP modules):

Code: Select all

{
	"faq_body.html" : "faq.html.twig",
	"index_body.html" : "index.html.twig",
	"report_body.html" : "report.html.twig",
	"search_body.html" : "search_form.html.twig",
	"search_results.html" : "search_results.html.twig",
	"viewforum_body.html": "viewforum.html.twig",
	"viewonline_body.html" : "viewonline.html.twig",
	"viewonline_whois.html" : "___.html.twig",
	"viewtopic_body.html" : "viewtopic.html.twig",
	"viewtopic_print.html" : "___.html.twig",

	"memberlist_body.html" : "members.html.twig",
	"memberlist_im.html" : "___.html.twig",
	"memberlist_team.html" : "team.html.twig",
	"memberlist_view.html" : "viewprofile.html.twig",
	"memberlist_email.html" : "___.html.twig",

	"mcp_front.html" : "mcp/index.html.twig",
	"mcp_move.html" : "___.html.twig",
	"mcp_approve.html" : "___.html.twig",

	"ucp_main_front.html" : "ucp/index.html.twig",
	"ucp_agreement.html" : "___.html.twig",
	"ucp_avatar_options_gravatar.html" : "___.html.twig",
	"ucp_avatar_options_local.html" : "___.html.twig",
	"ucp_avatar_options_remote.html" : "___.html.twig",
	"ucp_avatar_options_upload.html" : "___.html.twig",

	"confirm_body.html" : "___.html.twig",
	"confirm_delete_body.html" : "___.html.twig",
	"login_body.html" : "___.html.twig",
	"login_forum.html" : "___.html.twig",
	"message_body.html" : "___.html.twig",

	"posting_body.html" : "posting.html.twig",
	"bbcode.html" : "includes/bbcode.html.twig",
	"attachment.html" : "___.html.twig",
	"posting_smilies.html" : "___.html.twig",
	"posting_progress_bar.html" : "___.html.twig",

	"captcha_default.html" : "___.html.twig",
	"captcha_qa.html" : "___.html.twig",
	"captcha_recaptcha.html" : "___.html.twig",

	"auth_provider_ldap.html" : "___.html.twig",
	"auth_provider_oauth.html" : "___.html.twig",
	"login_body_oauth.html" : "___.html.twig",
	"ucp_auth_link_oauth.html" : "___.html.twig"
}

These files could indeed just be renamed in prosilver (and put in the appropriate subdirs), without necessarily being split up in components. But this would inevitably create a disparity between the prosilver structure and any new style.

[MichaelC]

As previously stated this introduces a really powerful template inheritance system which no other option does give us. Furthermore, breaking BC such a huge amount between 2.0 and 3.0, and 3.0 and 3.1 is no reason that we should (unnessisarily) break BC hugely between 3.1 and 3.2. If anything, we should break it as little as possible given the shorter release cycle.

I think we have to resign ourselves to the fact that BC will take a hit at least in 3.2 and 3.3. All extensions will need to be updated to work with the new style anyway, and it seems to me that changes to the layout of the templates do not increase the degree to which BC is broken, unless you're suggesting leaving everything exactly the same as it currently is.

With a template abstraction layer we could do just that, leave templates where they are in prosilver and not break BC for prosilver-based styles, hugely simplifying the updating process for styles authors and hopefully therefore meaning we have lots more 3.2 styles than we would otherwise.

[nickvergessen]

They still need to be updated with all the fixes and "breaking" it, just makes it more obvious that the style needs to be updated.
Also if you create such a huge list, it is just a nightmare when creating patches that need a new template file and requires a rebase when another PR added a file at a similar position of the list, which is why I'd prefer BC break over over-complicating things here.

[hanakin]

The only real advantages I think here are

• Multiple Inheritance - if you use inheritance
• Custom Folder structure per style for advanced styles - if you do not use inheritance.

everything else seems moot to me. If their is a better way to allow for this than lets look into that other wise this works?

[nickvergessen]

The question is, do we even want multi-inheritance, from my dev perspective I'd say no. If you inherit from a stlye that does something odd, just overwrite it again. There is no need for having 2 inheritance parents.
And as for custom structure, just make a good default one? You can structure your files like you want, if you just add a file with the original name and do a <!-- INCLUDE fancy/* -->

Both do not make up the negative impact from having the huge list, for me

[developer11]

Why would you want to do that?

I think you are completely misunderstanding. Not each and everytime. I want to rename them from what they are now for the FF files. Also as a theme/extension authour I wish to break things out by objects and as you add new objects you will need new files for those objects.

I think that its you - hanakin - who do not understand what you are saying......

its absurd especially for those whose forums are hosted with very limited disk quota/s....... new object = new file will quickly make their quotas used in 100%...... makes no sense to me.

Instead of transforming well-wrtten piece of code into sth crappy, you'd better do other way round - transform crappy permission unit into well-written one.....

[PayBas]

I think that its you - hanakin - who do not understand what you are saying......

its absurd especially for those whose forums are hosted with very limited disk quota/s....... new object = new file will quickly make their quotas used in 100%...... makes no sense to me.

Instead of transforming well-wrtten piece of code into sth crappy, you'd better do other way round - transform crappy permission unit into well-written one.....

Sorry, but this is completely irrelevant and off-topic.

[developer11]

PayBas: just the opposite - veryt much relevant and very much on topic.....