prevent nested templatePlugin from overwriting parent instance

[themightychris]

@Seldaek I know dwoo1 is end-of-life, but dwoo2 isn't suitable for me yet. I expect you won't want to merge any more pull requests but if you could comment on this a bit it would be very helpful as I wasn't able to discern the original intention behind appending templatePlugin function names with _$uuid

Scenario

test.tpl:

{load_templates test.sub1.tpl}
<h1>sub1 test</h1>
{sub1 "input1"}

{load_templates test.sub2.tpl}
<h1>sub2 test</h1>
{sub2 "input2"}

test.sub1.tpl:

{template sub1 input}
    <strong>sub1({$input})</strong>
{/template}

test.sub2.tpl:

{load_templates test.sub1.tpl}

{template sub2 input}
    <p>sub2({$input}) -> {sub1 $input}</p>
{/template}

Problem

The above example fails on test.tpl's call to {sub1} with Fatal error: Call to undefined function Dwoo_Plugin_sub1_535188f29fcdb() because {load_templates test.sub2.tpl} copies an instance of {sub1} with a different UUID from the cloned compiler back to the original compiler, causing the function written to the compiled template to use the UUID generated within test.sub2.tpl

Solution

The best solution I could find was to remove the _$uuid suffix from generated templatePlugin functions and prevent Compiler->addTemplatePlugin from overwriting an existing templatePlugin entry with one with a new UUID. Indexing template plugins by only their name in the templatePlugins array implies the names should be globally unique, so I couldn't make sense of why the function name needed to have the UUID appended. I kept the UUID logic in place for generating the scope though.

Unanswered Question

• Why were template plugin function names appended during compilation in the first place and can you think of anything removing it would break?
• Is there a better way to approach this conflict?

[Seldaek]

IIRC the UUID is to make sure that two templates defined in two different places get different names even though they can be declared using the same name. Your patch might fix this but could break the case where you have test.sub1.tpl and test.sub1bis.tpl both defining a sub1 template. Not sure if that was working at all though. I haven't touched this code in many years so this is not guaranteed to be accurate :)