Item8723: Broken (?) Inclusion order of Skin Template Topics

I'm converting a TmWiki web over to Foswiki. That web has it's own skin, which slightly modified the Pattern skin. I implemented it entirely in Topics, and set SKIN = myskin,pattern in WebPreferences. All was well.

I've moved over to Foswiki 1.0.9 with the default TemplatePath. Something has changed. Here's a very short example which illustrates the problem.

I've created a topic TestSkinViewTemplate:

%TMPL:INCLUDE{"view"}%

%TMPL:DEF{"sidebar"}%%TMPL:END%

HELLO THERE, 1

and Set SKIN = test, pattern in WebPreferences. I expect that the page will be rendered without a sidebar and that HELLO THERE, 1 will appear somewhere on the page. Instead the sidebar is still there, and I see the text HELLO THERE, 1. That means that the topic is indeed being parsed, but that the %TMPL:DEF% command is being overridden.

To debug this, I added some code to Foswiki::Templates::_readTemplateFile to prefix each template line with the filename or topic from which it was read, and then printed out the final recursively generated template text. Here are the interesting results of that log, looking just for the definitions of sidebar:

TestWeb.TestSkinViewTemplate: %TMPL:DEF{"sidebar"}%%TMPL:END%
viewsidebar.pattern.tmpl: %TMPL:DEF{"sidebar"}%<div id="patternSideBar"><div id="patternClearHeaderLeft"></div>

What's obvious is that the definition from TestSkinViewTemplate is showing up first and is getting overridden. I expected it to show up last.

More debug output showing the order in which the templates are read:

Foswiki::readFile(externallinkplugin.tmpl)
Foswiki::readFile(view.pattern.tmpl)
retrieveTopic( Foswiki::Store=HASH(0xbab4f0), TestWeb, TestSkinViewTemplate )
Foswiki::readFile(viewtopicactionbuttons.tmpl)
Foswiki::readFile(viewtopbar.pattern.tmpl)
Foswiki::readFile(viewsidebar.pattern.tmpl)
Foswiki::readFile(view.tmpl)
Foswiki::readFile(foswiki.pattern.tmpl)
Foswiki::readFile(foswiki.tmpl)
Foswiki::readFile(viewbottombar.pattern.tmpl)
Foswiki::readFile(css.pattern.tmpl)
Foswiki::readFile(css.tmpl)

Here's what I think is happening. The first template file read is view.pattern.tmpl. It starts out like this:

%TMPL:INCLUDE{"view"}%
%TMPL:INCLUDE{"viewtopicactionbuttons"}%
%TMPL:INCLUDE{"viewtopbar"}%
%TMPL:INCLUDE{"viewsidebar"}%
[... lots of definitions ...]

The template inclusion code essentially replaces the %TMPL:INCLUDE{...}% with the contents of the templates. So, when the first INCLUDE is processed, it picks up TestWeb.TestSkinViewTemplate and inserts that before the inclusion of viewsidebar.pattern.tmpl. When viewsidebar.pattern.tmpl is eventually included it overrides the definition of sidebar from the topic.

I believe that the problem is that view.pattern.tmpl is being processed first. If the topic template was processed first, then I believe all would work as before.

Thanks, Diab

-- DiabJerius - 17 Mar 2010

This may mean nothing, but if I set VIEW_TEMPLATE to TestSkinView it works as expected.

-- DiabJerius - 18 Mar 2010

wow - that's actually a very interesting observation.

-- SvenDowideit - 30 Apr 2010

Any hope of reverting to the old behavior? Being able to create templates without having to muck about on the server is really really useful. It makes users happy, and it's so much easier to upgrade.

-- DiabJerius - 07 May 2010

I wasn't involved in the template path changes, so I'm not sure why that search order was chosen; I think maybe Kenneth and Arthur were? But what you describe certainly sounds like a bug.

-- CrawfordCurrie - 14 May 2010

I was not involved either.

-- ArthurClemens - 14 May 2010

Sven made the change http://trac.foswiki.org/changeset/1550 under the auspices of Item4463.

If you change it back, then don't forget to change the doc in SkinTemplates as well Item2558.

-- CrawfordCurrie - 07 Jun 2010

My feeling is that we are dammed no matter what we do.

This template order was also changed a few times in the old project.

There is always one use case where one order is the best and another usecase where another order is the best.

I doubt there is a path that can be defined as the ultimate right path.

I guess this is why the configure setting was introduced in the first place.

Maybe instead of keeping on changing it, configure help text should suggest 2 or 3 alternative paths for some typical use cases, and then let the current default stay what it is.

-- KennethLavrsen - 18 Jul 2010

I agree, though I think a page in Support web (and a link to that page in configure) is the appropriate action. And nothing is going to happen if we wait for Sven to provide feedback on this, so I'm moving it back to confirmed. Anyone can pick it up for action.

-- CrawfordCurrie - 22 Jul 2010

Done

-- CrawfordCurrie - 26 Jul 2010

Commenting is disabled while not logged in