IMPORTANT ANNOUNCEMENT

REPRODUCE
=========
Create a template accessing a global variable in some way, assigned some how (I can't see any special conditions to trigger that bug).

~~~ snip test.php ~~~
$tpl = new Opt_Class;
$tpl->allowArrays = true;
$tpl->allowObjects = true;
$tpl->register(Opt_Class::PHP_FUNCTION, 'dump', 'var_dump');
Opt_View::assignGlobal('foo', 'Hello World');
[...]
~~~ END snip test.php ~~~

~~~ snip test.tpl ~~~
[...]
{dump($global.foo)}
[...]
~~~ END snip test.tpl ~~~


RESULT
======
All global variables are read as null because the compiler thinks it's a normal assigned variable, not a global one.

~~~ snip webpage ~~~
null
~~~ END snip webpage ~~~

~~~ snip compiled template ~~~
[...]
<?php echo htmlspecialchars(var_dump($ctx->_data['global']['foo'])); ?>
[...]
~~~ END snip webpage ~~~


EXPECTED
========
If I hack the compiled template manually, $ctx->_global actually contains my desired variables, meaning the compiler should create the following.

~~~ snip compiled template ~~~
[...]
<?php echo htmlspecialchars(var_dump($ctx->_global['foo'])); ?>
[...]
~~~ END snip webpage ~~~


WORKAROUND
==========
A workaround, which doesn't actually cure the problem source, but make it work some how. Add a line as shown below in the file Opt/Class.php, in the class Opt_View, the function _parse.

~~~ snip Class.php ~~~
[...]
$ctx = new Opt_InternalContext;
$ctx->_data = &$this->_data;
$ctx->_global = &self::$_global;
$ctx->_vars = &self::$_vars;
$ctx->_procs = &self::$_procedures;
+ $ctx->_data['global'] = &self::$_global; // This is a workaround
[...]
~~~ END snip Class.php ~~~