Posted on 23/03/2023 10:40:27
I can explain the decontextualized.
When you are on a page in the backend and edit i.e. a page or a pragraph, it knows what website you are on. A website uses a design - i.e. Swift. So based on that information when you need to select a template, Dynamicweb can figure out that you might want to use a template from the Swift design.
When you are setting up things under settings - i.e. a shipping method or payment method - you do not edit those in the context of a website. So we have no clue if you will use a template from Swift or from another design from another website. So there is no "design context" when choosing the template there.
So you have to choose a template that is "out of context" - which means from /Files/Templates/eCom7/Checkout/* or similar.
Then when that payment method is used - on a checkout setup on a paragraph which is on a page which is on a website that uses the Swift design, it will first check if a template with the same name exists in the context of the design - /Files/Templates/designs/swift/eCom7/Checkout/* - and use that if it exist or fallback to the one you chose.
Not super simple - I agree - but how it works.
So all kinds of templates you can choose from places that are not in a website context, and hence not in a design context, needs templates in these locations.
All of this complexity stems from the fact that designs and layout is a relatively new implementation model - about 13 years old - and we still have support for the implementation models before that. Because as we discussed earlier - we always want and need to update all customers 4eva...