Hi all,
I was wondering as to the current state of play with Moodle and PHP 6. I've got a test environment set up for development that runs many different versions of many different things, and I was hoping to run Moodle on PHP 6.0-dev so I can be ahead of the game.
However, when I try to switch one of my existing installations to PHP 6, I get one or more Strict Standards errors appearing on the page, and nothing else. (All error reporting is turned on, as it's a development environment.) This is my first time using PHP 6, but I'm assuming the standards errors are causing PHP execution to halt. I couldn't find a flag to turn them off in php.ini - perhaps I missed it.
Also, I can't get FreeTDS to load, as I get a startup error saying the API my PHP 6.x version of php_dblib.dll was compiled with is out of date, though I guess that will be fixed in time when Frank Kromann moves to the newer API.
Does anyone have Moodle running on PHP 6? Any tips? They would be much appreciated.
As an aside, I have to say, I'm looking forward to Moodle 2, when PHP 4 support goes out the window altogether. That will be a very happy moment for me. Fond as I am of v4, it's far too out of date, and it was with much smiling that I spotted Moodle on the list over at GoPHP5.
GP,
Strict mode is not a PHP setting, it is a MySQL setting. See http://moodle.org/mod/forum/discuss.php?d=70388#p317823
RLE
Strict mode is not a PHP setting, it is a MySQL setting. See http://moodle.org/mod/forum/discuss.php?d=70388#p317823
RLE
Greg - I vaguely remember taking a quick look at the changes for PHP6 which have to do with how variables get passed. I suspect (although I could be wrong since I only take a cursory glance) Moodle is not yet ready for PHP6 in the strictest sense but my impression was that it should not be too much work to get it ready. I believe that the changes from PHP4 to PHP5 were much more significant and as I understand things the changes from PHP5 to PHP6 will be to encourage cleaner, more consistent coding. As a result, you will probably see PHP errors like:
Strict Standards: Assigning the return value of new by reference is deprecated
Is there a way in the php.ini to turn off of the strict standards? Ideally we will want to identify these but to help you with testing, playing, and development you may find that helpful. Peace - Anthony
p.s. - I found the following from bitfilm.net which is worthy of note. You can also look at: http://bitfilm.net/2007/12/09/unofficial-php-6-changelog/
Strict Standards: Assigning the return value of new by reference is deprecated
Is there a way in the php.ini to turn off of the strict standards? Ideally we will want to identify these but to help you with testing, playing, and development you may find that helpful. Peace - Anthony
p.s. - I found the following from bitfilm.net which is worthy of note. You can also look at: http://bitfilm.net/2007/12/09/unofficial-php-6-changelog/
If you want to make use of PHP 6 when it comes, you're going to have to write your new scripts so they are compatible, and possibly change some of your existing scripts. To start making your scripts PHP 6 compatible, I've compiled a list of tips to follow when scripting:
- Don't use register_globals. In PHP 6, support for register_globals will be no more. There will be no option to turn it on or off - it will not exist. This change should not affect you, as you shouldn't really use register_globals anyway. If you don't already know, register_globals puts $_REQUEST into the global scope, so you can access the variables just like any other variable. Instead, you should access inputed data like this:
$_GET['input'];
$_POST['input'];
$_REQUEST['input'];
- Stop using magic_quotes. In my opinion, this tip should be applied whether you are using PHP 3, 4 or 5. Thankfully, in PHP 6, the magic_quotes feature is going to dissapear with register_globals. For those who don't know, magic_quotes automically escapes single quotes, double quotes, backslashes, and NULL characters.
- Don't Register Long Arrays. If you access user inputted data using $HTTP_POST_VARS or $HTTP_GET_VAR, you better stop now. Instead, you should use the superglobals - $_SERVER, $_COOKIE, $_GET, $_POST, $_FILES…
- preg instead or ereg. If you're using ereg functions for regular expression tasks, then you should start using the preg functions instead. ereg will not be available in the PHP core as of version 6.
- Don't initiate objects with the reference operator. If you're initiating objects using the reference operator, you should stop now. It will generate an E_STRICT error.
$a = & new object(); // Do not do
$a = new object(); // Do this as of PHP 6
Looking at these, the one that I think will likely take the most time is #5. I wonder if it would be helpful to avoid using & for AND so that it would be easier to search for areas where a reference operator may have been previously used. Peace - Anthony
5. is trivial to fix, if there are any instances of it, which I doubt.
We are using ereg in some places (point 6), but not in post. Changing to prag should not be a big deal.
We are using ereg in some places (point 6), but not in post. Changing to prag should not be a big deal.
AB,
Pardon me for, once again, putting both feet in my mouth up to just above the knees. In my total ignorance of PHP 6, I assumed GP meant strict mode, as you undoubtedly guessed.
As for #5, maybe a search for "= & new"? Or maybe a reg. expr. search for
= *& *new
just in case. Perhaps something like that is what TH had in mind.
RLE
Pardon me for, once again, putting both feet in my mouth up to just above the knees. In my total ignorance of PHP 6, I assumed GP meant strict mode, as you undoubtedly guessed.
As for #5, maybe a search for "= & new"? Or maybe a reg. expr. search for
= *& *new
just in case. Perhaps something like that is what TH had in mind.
RLE
Richard - No problem, it is easy to get lost in some of the similar syntax. It sounds like the developers have the PHP6 issue on the radar and under control. Peace - Anthony
I wonder if it would be helpful to avoid using & for AND so that it would be easier to search for areas where a reference operator may have been previously used
It is worth noting that && and and [heh] have different precedents, and aren't necessarily interchangable.
To quote one of the examples from the php manual comments:
// "&&" has a greater precedence than "and"
$g = true && false; // $g will be assigned to (true && false) which is false
$h = true and false; // $h will be assigned to true
var_dump($g, $h);
http://uk2.php.net/manual/en/language.operators.logical.php
Agreed - && and 'and' are both useful. Wouldn't want to go without them 
Nothing in the list above sounds like a problem to me. We don't use '& new' anywhere, and it's easy to grep for that if we want to. eregs have been known for a while to be bad for your mental health anyway, whereas knowing perl-style regular expressions makes you sexy and able to save the world (see http://xkcd.com/208/ ). What's not to like?
Nothing in the list above sounds like a problem to me. We don't use '& new' anywhere, and it's easy to grep for that if we want to. eregs have been known for a while to be bad for your mental health anyway, whereas knowing perl-style regular expressions makes you sexy and able to save the world (see http://xkcd.com/208/ ). What's not to like?
Hello,
the PHP strictness of our code will be fixed in 2.0, we should definitely aim for compatibility with PHP6 too.
skodak
the PHP strictness of our code will be fixed in 2.0, we should definitely aim for compatibility with PHP6 too.
skodak
Wow, thanks for all the replies guys. So it's basically a progressive thing, I guess. I'll be patient for now. 