I'm trying to wrap a legacy application in the Zend2 MVC framework. Thanks to the Zend Skeleton Application and code samples (especially https://github.com/maglnet/MaglLegacyApplication), I've solved most of my issues.
The one big issue I haven't been able to solve is illustrated by the following "legacy" file:
<?php
$test = "test";
function echo_test(){
global $test;
echo "test = ";
var_dump($test); # Makes NULL explicit
}
echo_test();
In the Controller for a ZF2 module, I capture the output of the include using an output buffer and stick that into the response object:
...
chdir($filePath) # Fixes relative includes
ob_start();
include $filePathAndName;
$output = ob_get_clean();
$response->setContent($output);
return $response;
... and I get back test = NULL.
I've seen warnings that ZF2 namespaces can create issues for legacy files and done my legwork to try and clarify why. According to the PHP guide, "Without any namespace definition, all class and function definitions are placed into the global space". Indeed, my sample is only slightly more complicated than the one listed below this statement... but it doesn't seem to work.
I also see that "You can set a variable after declaring a namespace, but variables will always exist in the global scope. They are never bound to namespaces.".
I continued to research and have finally discovered that this approach "will import the contents of the include file into the method scope, not the class scope".
Is there any way to process the file outside the method scope?
This is nothing to do with PHP namespaces. If you're including a file from within a ZF controller action, it will execute within that function's variable scope. For your example to work you'd need to declare global $test; in the ZF action as well before including the file (which would be horrible).
Without knowing exactly what your legacy code looks like it's hard to suggest a good solution. If there are a set number of globals you need to work, you can global them at some point earlier in the ZF application (with the goal of removing that hack at a later date). If you don't know in advance what the globals are, or if there are a large number of them, you may need to edit the legacy code to try and refactor out the reliance on globals.