So I was reading about PHP namespaces, and I realized that in versions earlier than 5.3, if you write
namespace MyNamespace
you get a parse error.
Is there any way to avoid this i.e. make namespaces backwards-compatible, so the code doesn't simply crash?
Short Answer: No.
Longer Answer: (added to capture useful information from other deleted answers). The new Syntax will cause parse errors in PHP, so you can't use a customer error handler to catch errors generated in versions < 5.3. In theory you could write a pre-processor the scans and/or does a lex/parse on the source and then write something back out that would be PHP 5.2 compatible, but that creates more problems than it solves.
Perhaps you could query the version of PHP being used and call eval if it's high enough. I don't know if that will work though.
Actually, I think it's possible, but I don't believe it's worth it. The idea would be to create a custom default stream wrapper, which will parse PHP files according to the new grammar and make the appropriate changes to the syntax so that it will be valid PHP < 5.3.
The wrapper would have to replace class names such as Foo\Bar\Baz with Foo_Bar_Baz. Currently I'm not sure if there's something that would render this impossible.
Anyway, I don't believe it's worth the effort. Upgrade to PHP 5.3.
Oh, that means that the wrapper code should be compatible with PHP < 5.3.
I know this is a very old question, but I needed to make a couple of instructions with namespaces backward compatible with a very old PHP installation (5.2).
What I finally did to avoid parse errors was:
if(version_compare(PHP_VERSION, '5.3.0') >= 0) {
include("file_with_namespaces_code.php");
}
else{
echo("put php 5.2 code here");
}
Related
I have scripts that must be run with PHP 5.1.0 or higher (because using PDO class, for instance).
If not, they bring parse errors.
I'm talking of scripts that anonymous visitors are invited to download, install on their server (on which I can't have any information) and run to demonstrate how easy php scripts can communicate with a system of ours.
Of course, running any of these scripts and getting a "parse error at line xxx" won't really give a good image of the solution...
I tried echoing a neat "you need PHP 5.1.0 or higher to run this script" error message, using if (version_compare(PHP_VERSION, '5.1.0') < 0) { die(...); } but, of course, this doesn't work, as PHP first parses the whole script before starting executing it and having a chance to die on this test.
So my question is:
Is there a way in PHP to do some tests on php version BEFORE actually parsing?
I mean something like C/C++ #if or #ifdef PRE-processor directives.
Or any other type of workaround?
One constraint beeing: the solution to the issue should not make the whole scripts look unreadable or complex to understand (like massive calling of eval() which breaks syntax coloration) nor uncomprehensibly contrived (like having each script conditionaly included in a "container script"), because the global purpose is to demonstrate how SIMPLE it is to communicate with our system...
All solutions found googling around were about maintaining compatibility, using arrays of alternative functions to call depending on php version, comined with eval everywhere where something could go wrong for php parser... I would need something really simpler like "if php version not ok, don't parse"...
I've done little web using namespaces. I have it in my computer and i'm about to moving it to free hosting that uses php 5.2. Syntax highlighter for php 5.2 interprets them as errors.
Are namespaces supported by php 5.2?
If not is there any way how to use them with little changes to existing code?
Namespaces are not supported prior to 5.3. There isn't really a way to adapt for them into 5.2 unfortunately.
Namespaces are only available as of 5.3
At least in the case of classes, you can use the class_exists function to check if a class has already been defined with a like name within the global namespace. Coupled with the __autoload() function, you can create one universal alias and have the system check for both classes named by the original name as well as the name with some kind of extra identifier prepended. I'll use "ns" as an example.
function __autoload($class){
try{
require_once('ns'.$class.'.php');
}catch(Exception $e){
echo 'The class is unavailable in pseudo-namespace as well as global';
}
}
Just make sure the require path points to wherever you keep your models. You could use a different folder instead of the alias as well.
This way, any duplicate classes can be put into files separate from the main execution that are only included if they don't exists in the global. Though this doesn't strictly fix the problem of having to physically rename the classes, it will allow you to put your definitions in different directories for versioning purposes etc.
Namespaces are available in PHP as of
PHP 5.3.0.
Source: http://www.php.net/manual/en/language.namespaces.rationale.php
http://www.php.net/manual/en/language.namespaces.rationale.php
Namespaces are available in PHP as of PHP 5.3.0.
Ive just come across this problem, ive developed an image upload script myself and added some third party code to aid image processing (cropping) but they use namespaces, works fine on my develoment machine, but when i uploaded to the live server i get a Parse error.
Luckily my host supports php 5.3 and 5.4, so ive asked them to change it to 5.3 for me, im hoping that will solve the problems im having, simply removing the namespaces made the script fail :(
Paul
Im trying to compile phpurple. Im doing everything according to the documentation:
hxxp://phurple.php.belsky.info/ch02.html
but "make" gives me an error:
/myhomedir/phpurple/purple.c: In function ‘call_custom_method’:
/myhomedir/phpurple/purple.c:1370: error: ‘zend_fcall_info’ has no member named ‘object_pp’
/myhomedir/phpurple/purple.c:1408: error: ‘zend_fcall_info_cache’ has no member named ‘object_pp’
I`ve found other people with the same problem:
hxxp://www.mail-archive.com/monetdb-bugs#lists.sourceforge.net/msg05515.html
hxxp://belsky.info/archives/23-Phurple-per-se-PHPurple.html
but nobody gives any information about successful php 5.3 build and the message
PROJECT IS CLOSED if you want
commercial support for php 5.3, let me
know ... )
does not help at all.
does anyone have any idea how to compile it or any clue how to fix the problem ?
P.S. Sorry about the links, some strange StackOverflow limitation
According to phpurple requirements:
Please let me know, if you've successfully compiled on
earlier versions. Actually the extension is being developed
on the php v5.2.6 with the option to be upcomming php v5.3
compatible.
The authors will need to update their source. However, since you have the source you could update it yourself because you noted that the project is CLOSED. You could also fork the code and create your own gitHub project with php 5.3 support.
Good luck.
What you are seeing is PHP's shifty interface (ahem, hold your down votes, I said s h i f t y). By that, I mean function prototypes are subject to change from version to version. Take this meta example:
int foo_call_bar(const char *foobar, size_t len);
And in a later version of something, the function calculates the length dynamically, thus eliminating the second variable in the prototype:
int foo_call_bar(const char *foobar);
Some projects strive to always maintain backwards compatibility to alleviate this headache, which could be accomplished with pre-processor directives that prototype the new implementation with the len variable, but just don't do anything with it. If PHP did that, the code base would succumb to even more madness.
Unfortunately, you'll have to modify phpurple to present the correct arguments to the correct PHP functions, and ensure that they are of the appropriate type. That would be a bit of an undertaking, but probably wouldn't be as difficult as it seems.
The Linux kernel's VFS interface is the same way, and I'm often tasked with porting older experimental file systems to work on modern kernels.
look at that man
http://sourceforge.net/news/?group_id=235197&id=296063
A little late, but here is the latest library that works with PHP 5.3:
The new project page is: http://sourceforge.net/projects/phurple
The blog post: http://belski.net/archives/23-Phurple-per-se-PHPurple.html
I have ran into a problem after I have complied it and added the extension to PHP.ini configuration:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/phurple.so' - /usr/lib/php/modules/phurple.so: undefined symbol: ZVAL_ADDREF in Unknown on line 0
To fix this, change the line containing ZVAL_ADDREF in client.c from
ZVAL_ADDREF(PHURPLE_G(phurple_client_obj));
to
Z_ADDREF_P(PHURPLE_G(phurple_client_obj));
Well, the new URL seems to be a persistent repo with fixes to PHP-5.3 and above. Maybe that should be mentioned, but that won't help with checking it out anyway. For me it worked fine, so I would say it is worth a try.
You can check the new sources shortly posted on https://github.com/weltling/phurple
When i want to use xml libraries in php i get this error
Fatal error: Call to undefined function domxml_new_doc() in C:\AppServ\www\direction\db2xml.php on line 5
how can i solve it ?
The domxml_new_doc() function is from the PHP4 DOM extension. It has been moved to the PECL repository and is no longer bundled with PHP as of PHP 5.0.0. PHP5 introduced a number of improved extensions to work with XML:
It will, however, never be released with PHP 5, and will only be distributed with PHP 4. If you need DOM XML support with PHP 5 you can use the DOM extension. This domxml extension is not compatible with the DOM extension.
See my answers to
Best XML Parser for PHP
PHP what is the best approach to using XML? Need to create and parse XML responses
If you are working with older code from PHP4 and wish to migrate the code to work on a php5 server with minimal effort, check out the following:
http://www.silicon-vision.com/wp/quickpost-php4-domxml-to-php5/
Simply drop in the include file and reference it at the start of the file that is failing, and it will simply just work like it used to. Not much else to it really. Used it on several older sites after migrating them to a new VPS earlier this year and was quite pleased at solving the issue without having to sit there and rewrite someones spaghetti code :)
Update 2015: I no longer maintain the old blog linked to above, however you can find the domxml tool here: https://alexandre.alapetite.fr/doc-alex/domxml-php4-php5/index.en.html
Check that you have the module enabled and also that you have all required libraries.
May be you have forget to uncomment or add
extension=php_domxml.dll
in your php.ini file?
Is it possible to check syntax of php-code (without running),
similar to the
php-cli -l
when running php the "ordinary" way (as a module)?
There are also some PECL extensions which parse PHP code for various reasons. First there is BCompiler, which can compile a PHP into byte code. Since this step requires parsing the PHP code, I would expect errors if it isn't lint. Parsekit allwos you to compile PHP code to OP codes, which is basically what you desire. However, the extension did not have a release since late 2009, so it might be outdated. Parse_Tree is sadly unmaintained since 2007, but its purpose is to parse a PHP file into an AST. Maybe you can get to something with this one, after some polishing.
PHP_Parser is a PEAR package, which does not rely on special PHP extensions and attempts to parse PHP code from within PHP. Its marked alpha and unmaintained, but it might give you a basis to experiment with.
You can try to run a tool like PHP Depend on the sources, which attempts to parse the given PHP files into an abstract syntax tree. While this might not catch all PHP parser errors, it will already catch quite a lot of them.
You get nice software metrics as an additional goodie, if the code is valid. :)
Is it possible to check syntax of php-code (without running), similar to the php-cli -l
when running php the "ordinary" way (as a module)?
I think the question everyone missed is that there is no difference in PHP syntax whether you run it as a module, or simply execute the binary from a shell: the PHP syntax is the same on both occasions. So, you might as well just use php -l filename.php, as that has the exact same result as using the tools listed above.
For getting the same result as php-cli -l, use the function: php_check_syntax