Greg Beaver wrote: > The solution I've found for pharring things has involved clever use of > str_replace(). I pharred up phpMyAdmin and it works just great using this > technique. This removes the need for an include_path hack.
phpMyAdmin is an interesting test case because every file access are relative to the current directory, and some global variables are used both for relative file access, and as HTTP URLs base directories. In such a case, prefixing every path with a stream wrapper prefix cannot work because, as a side effect, it generates some '<img src=phar://....' strings in the HTML pages. I just had a look to the way you 'pharred' phpMyAdmin. I wanted to know how you solved the problem of the $pmaThemeImage global variable, which is used as a base for HTTP URLs and for file access. From what I understand, you replace it with an 'http:' string, which forces every file access through the http wrapper (which assumes at least that url_fopen is allowed). Here, it is not just a couple of str_replace(), it is a real change in the software structure. And it is not the only one. I understand that it is a prototype but I must say that I am skeptic about generalizing such an approach, even if, with the current PHP engine, there seems to be no btter one : - With changes like this in the source code, you cannot guarantee that the software works the same. And I don't see who will support it when somebody finds a difference. - If the original developers decide to support the phar packages and to distribute this format, they will want to distribute their software, at least for a given time, in both formats. Which means that their source code must be compatible. And filtering the files through str_replace() won't help. - If you have to make such changes in the software code, it implies that you know the software structure very well. And the work has to be repeated for every new version. Just try to build a phar package from the current phpMyAdmin version (2.8.2) and you will see that your changes cannot work exactly as in your previous build. For these reasons, I still consider that any PHP packaging system, PHAR or another one, will be greatly handicapped as long as we don't find a solution to the 'current directory' and 'include path' problems. Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
