Re: Strange problem with prices displayed at final stage of checkout
Quote:
Originally Posted by
mc12345678
While this may have prevented the problem seen, it still doesn't look like the right solution or perhaps the problem is caused by something else.
The tpl_ files are expected to be in the global space. That means any variable referenced within them is expected to be in the global space. The $currencies variable when needed is routinely loaded either in the associated header_php.php file for the page or its main_template_vars like file. Having to declare $currencies as a global indicates that this template file is being loaded/run within some other code section like a function or class method. If that is the case, the function/class method really should ensure that the variable is brought into the current space rather than the file that is being called. Meaning, where global $currencies has been added, it should be within the out-of-scope code section that is calling this template file.
I do see what you're saying and I agree, to a point.
However, doesn't this mean that the function (or the page) including a template must predict all of the global variables a custom override might require and declare all of them in the function? It has no idea what code is in the overriding template, what it is doing and which globals it needs in order to do it.
Re: Strange problem with prices displayed at final stage of checkout
As you say, though, perhaps the problem is caused by something else and the template shouldn't be included in a context that isn't truly global.
Re: Strange problem with prices displayed at final stage of checkout
Quote:
Originally Posted by
BillJ
I do see what you're saying and I agree, to a point.
However, doesn't this mean that the function (or the page) including a template must predict all of the global variables a custom override might require and declare all of them in the function? It has no idea what code is in the overriding template, what it is doing and which globals it needs in order to do it.
If this were the style of design to consider the possibility of any template file to be so used, then every variable within every template should be declared as global and used as such; however, can see two parts to this, why would there be the design to include a normally expected global file in a non-global context and *not* know what it needs to support operation? Design by design, right? So, that leads to...
Quote:
Originally Posted by
BillJ
As you say, though, perhaps the problem is caused by something else and the template shouldn't be included in a context that isn't truly global.
There are multiple ways to activate or prepare a template file to be displayed/loaded in the global space. Of course, one question is why would/do ZC template files contain executable code rather than "reference" or fill-in-the-blank variables (obvious answer is that it was inherited and isn't actually in the way of operation)? If/when the template system gets so or similarly revised, it would be possible to set/modify the associated variable(s) to contain the information necessary though that wouldn't fix the template file within the limited scope function (as compared to an init_include, module, or other on-demand global scoped template file).
Yes, there may be a "reason" to load that template file within a function instead of some other way, inquiring minds certainly would like to hear. Good discussion, I think.
