I'm building a new development server and would like to know what version of PHP is required for Moodle 2. One place says 5.2.4 and another says 5.2.8. I know that it will likely change, and that I should always have the latest version available, but I'm working with campus tech so don't have total control of the situation ;) If anyone can tell me what the minimum version is that would be great. Right now their stock setup is 5.1.6!
Thanks,
Nate Baxley
Hi Nate,
AFAIK 5.2.8 is only for Moodle 2 which is likely to be released mid-2009.
We current use 5.2.5 on our production boxes running Moodle 1.9.2 (soon to upgrade to 1.9.3) and have no problems.
With regards to minimum version, I think the moodle team aim for compatibility with PHP v4.3 for all moodle 1.x versions - although some functionality in the latest moodle versions (such as search modules which use new Zend technologies) won't work.
Hope this helps,
Ian
AFAIK 5.2.8 is only for Moodle 2 which is likely to be released mid-2009.
We current use 5.2.5 on our production boxes running Moodle 1.9.2 (soon to upgrade to 1.9.3) and have no problems.
With regards to minimum version, I think the moodle team aim for compatibility with PHP v4.3 for all moodle 1.x versions - although some functionality in the latest moodle versions (such as search modules which use new Zend technologies) won't work.
Hope this helps,
Ian
Moodle 2 isn't finished yet, so I imagine this is still subject to change. Also, of course, more PHP bugs are discovered all the time...
If you're asking them to upgrade anyway, why not ask for the latest stable version? Which appears to be 5.2.8. Or, if they have a constraint, ie they want to only use a version that's available as part of red hat whatever, then find out what that is and ask again?
--sam
If you're asking them to upgrade anyway, why not ask for the latest stable version? Which appears to be 5.2.8. Or, if they have a constraint, ie they want to only use a version that's available as part of red hat whatever, then find out what that is and ask again?
--sam
I guess to ask the question more generally. I know that PHP 4 is out for Moodle 2.0. What's the new minimum? 5.1.0? 5.2.0? 5.3? It seems to keep changing and be whatever the latest version of PHP is. I'm wanting to nail down a new floor. 
Currently we think Moodle 2.0 will require PHP 5.2.8. The latest (quite) increase in required version number was because of bugs in the built in zip libraries. Petr struggled to find a workaround and failed before increasing the required version. We did not really want to increase the required version any more. Hopefully it won't have to change again.
Thanks for the reply Tim. Sounds like a reasonable reason for the increase. Hopefully it will stick here. Maybe I can get our guys to move by the time we're ready to start real testing.
Unfortunately, the upcoming Debian release will be shipping PHP 5.2.6 
http://packages.debian.org/lenny/php5
http://packages.debian.org/lenny/php5
Well that's OK, because Debian fans will be running Moodle 1.8.2 anyway (released 8 July 2007) 
http://packages.debian.org/lenny/moodle
They can still use Lenny to run Moodle 2.0 but on 64 bit machines they might have to forgo using zip .... MDL-15928
http://packages.debian.org/lenny/moodle
They can still use Lenny to run Moodle 2.0 but on 64 bit machines they might have to forgo using zip .... MDL-15928
And Ubuntu 8.04 LTS will only be on 5.2.4 http://packages.ubuntu.com/hardy/web/php5 
and even 8.10 is only at 5.2.6
Does this mean no Ubuntu servers will be able to run Moodle 2 without compiling PHP manually???
and even 8.10 is only at 5.2.6 Does this mean no Ubuntu servers will be able to run Moodle 2 without compiling PHP manually???
Ubuntu 09.04 will be out before Moodle 2.0, so upgrading to that will help the Ubuntu servers.
Even 9.04 is still only listed as shipping with PHP 5.2.6 - http://packages.ubuntu.com/jaunty/php5. I appreciate that this might change before final release in April though, however we would loose the benefit of suing the LTS version even if Ubuntu do move the PHP version up to 5.2.8!
So which distros will be shipping with PHP 5.2.8???
So which distros will be shipping with PHP 5.2.8???
I agree - this is a decision made by developers (with some good reasons) - but has potentially huge impacts for server admins.
We use Ubuntu, and I know many servers running Moodle use Ubuntu / Debian.
If Moodle 2.0 is going to require a version of PHP that is not standard in a common distribution (and not yet planned to be, although it might) does this suggest the developers are pushing this aspect a little further than the user base are ready for?
Stuart
We use Ubuntu, and I know many servers running Moodle use Ubuntu / Debian.
If Moodle 2.0 is going to require a version of PHP that is not standard in a common distribution (and not yet planned to be, although it might) does this suggest the developers are pushing this aspect a little further than the user base are ready for?
Stuart
It might be more relevant to look at what is in Ubuntu 9.10
No one wants to release requiring a PHP version that is not in common distros. We know that would cause major pain.
But bitching about it is not going to do any good. We need a proposal for what we should do instead if we are going to avoid this situation. (The tracker issue is MDL-15928, although it is a bit light on information.)
(Actually, our current plan seems to be to continually increase the scope of 2.0 so the release date keeps getting further and further away
)
No one wants to release requiring a PHP version that is not in common distros. We know that would cause major pain.
But bitching about it is not going to do any good. We need a proposal for what we should do instead if we are going to avoid this situation. (The tracker issue is MDL-15928, although it is a bit light on information.)
(Actually, our current plan seems to be to continually increase the scope of 2.0 so the release date keeps getting further and further away
In any case, it is safe to assume that when Moodle 2.0 is tagged PHP 5.2.8 or better will be widely available in backports.org and EPEL.
Looking at the bug, I am curious though. This PHP "zip" extension, does it work with a fixed memory buffer, or does it allocate memory "as needed"?
If it's the second case, it may be fine for cli scripts, but it will be a complete disaster for Moodle, specially if we end up losing the option of using the external binaries.
In other words, the php 'zip' extension may exist and work bug-free, but depending on its internal implementation, it may still be a fundamentally bad idea to use it in mod_php living inside apache.
Looking at the bug, I am curious though. This PHP "zip" extension, does it work with a fixed memory buffer, or does it allocate memory "as needed"?
If it's the second case, it may be fine for cli scripts, but it will be a complete disaster for Moodle, specially if we end up losing the option of using the external binaries.
In other words, the php 'zip' extension may exist and work bug-free, but depending on its internal implementation, it may still be a fundamentally bad idea to use it in mod_php living inside apache.
I did try changing it to "5.2.6" instead of "5.2.8" but when I refreshed the install.php page it did not recognize the change and gave me the same error (which was probably user error or it did not change instantly after I uploaded). So, I just edited the config.php file and it worked -- perhaps the "5.2.6" change was in affect then and maybe that's why it worked! Anyways, I got it to work! And yes, this is a total testing site! : ) Thanks for the respsonses.
We are using the ZipArchive class http://au.php.net/manual/en/book.zip.ph, which is based on zlib, which is probably as good as it gets. (Code is in lib/packer in Moodle.)
Well, from what I could read in a brief googling, that code is what used to be the PECL-hosted zip extension library.
And that is not good news -- the code we are talking about is memory bound. I have no doubt it is much better than the pure php implementation of zip we had before, but it is seriously inferior to using the external zip binary.
Can we keep support for /usr/bin/zip? Otherwise, this will bring down servers left and right when users ask for the backup of their courses, and the courses have large media files
And that is not good news -- the code we are talking about is memory bound. I have no doubt it is much better than the pure php implementation of zip we had before, but it is seriously inferior to using the external zip binary.
Can we keep support for /usr/bin/zip? Otherwise, this will bring down servers left and right when users ask for the backup of their courses, and the courses have large media files
With Ubuntu's PHP 5.2.6 32-bits, and comparing /usr/bin/zip with a quick adaptation of the sample script (as per php.net site)...
The src file is a 658MB file, both zips brought it down to 244MB. More good news: PHP script took a stable amount of memory - it was quite a bit more memory than /usr/bin/zip (~6MB vs 400KB) but I think we can blame 4MB on the PHP interpreter.
The somewhat bad news are around performance:
$ time php testzip.php
numfiles: 3
status:0
real 9m47.265s
user 9m38.688s
sys 0m2.572s
$ time zip test_bin.zip xo-703/os703.usb
adding: xo-703/os703.usb (deflated 63%)
real 1m49.080s
user 1m45.839s
sys 0m1.964s
So it's not a cause for major worry. It won't hog memory like I feared, is just very slow. Maybe newer versions are faster?
The src file is a 658MB file, both zips brought it down to 244MB. More good news: PHP script took a stable amount of memory - it was quite a bit more memory than /usr/bin/zip (~6MB vs 400KB) but I think we can blame 4MB on the PHP interpreter.
The somewhat bad news are around performance:
$ time php testzip.php
numfiles: 3
status:0
real 9m47.265s
user 9m38.688s
sys 0m2.572s
$ time zip test_bin.zip xo-703/os703.usb
adding: xo-703/os703.usb (deflated 63%)
real 1m49.080s
user 1m45.839s
sys 0m1.964s
So it's not a cause for major worry. It won't hog memory like I feared, is just very slow. Maybe newer versions are faster?
Isn't the 5.2.8 requirement because of zipping? I see you tested with 5.2.6 - maybe there's a performance difference there.
I don't have a 5.2.8 to test with and I don't much feel like using a non-packaged version , maybe Petr can weigh in.
I don't have a 5.2.8 to test with and I don't much feel like using a non-packaged version , maybe Petr can weigh in.
Useful experimentation.
The other issue is Unicode file names. When Petr was looking at the options, all command-line zippers mangled them. I think that may just have changed, and there may now be a command line program that works.
The other issue is Unicode file names. When Petr was looking at the options, all command-line zippers mangled them. I think that may just have changed, and there may now be a command line program that works.
"When Petr was looking at the options, all command-line zippers mangled them"
Very odd. The cli zip/unzip on linux has worked well with unicode for literally ages. You have to set the right env variables before you call it.
Here is a quick test that works well on my machine (and has done so for a couple of years)...
export LANG=en_NZ.UTF-8
mkdir src
mkdir dest
cd src
mkdir foo
echo hey > foo/martín
zip -r file_with_unicode.zip foo
cd ../dest
unzip ../src/foo
(BTW: markdown format is broken!)
OK, so it works on properly configured linux servers. What about on shared hosting? What about Windows servers?
Not that I actually know what I am talking about. I have just read Development:File_API#Unicode_support_in_zip_format, and vaguely remember some developer chats where Petr was thinking about this.
Not that I actually know what I am talking about. I have just read Development:File_API#Unicode_support_in_zip_format, and vaguely remember some developer chats where Petr was thinking about this.
Linux or OSX hosts, you just set the environment variable before the exec() -- this works on single-user hosts, on shared hosting servers, anywhere. Windows has had unicode filesystems for a long time too. I am sure relatively modern zip utils do the right thing if you set the right environment vars.
What I am trying to say is: it takes a little bit of setup (for us programmers) before exec'ing /usr/bin/zip or zip.exe . But I am fairly sure it works.
[Edit: a quick google reveals that I can be stupidly optimistic. That this has worked for years on Linux and OSX does not mean much... zip programs on the legacy OS from Redmond seem to be a bit behind the curve... sad state of affairs...]
What I am trying to say is: it takes a little bit of setup (for us programmers) before exec'ing /usr/bin/zip or zip.exe . But I am fairly sure it works.
[Edit: a quick google reveals that I can be stupidly optimistic. That this has worked for years on Linux and OSX does not mean much... zip programs on the legacy OS from Redmond seem to be a bit behind the curve... sad state of affairs...]
I did very extensive testing about a year ago, there was no thing better than PHP zip extrension for us at that time. The binary info-zip was useless for Windows clients. The level of support for unicode zips varies in client programs used too: windows zipping, 7zip, Total Commander, WinZIp - they all worked in a different way. The most broken is of course internal windows zipping/unzipping
Well, nothing is as bad as it looks, info-zip has a new version that should partially support unicode, 3rd party windows zipping utils were improved too, unfortunately the windows built in zipping is still a mess
I suppose later this month I could test everything once more again and see if there are any new alternatives to PHP zip extension. The major problem here is that the PHP zip extension does not produce correct unicode enabled zips, it just accidentally worked with buggy windows clients at the time when I was testing it. We do not need "correct" zip encodings we do need something that our friends with windows can extract...
It will take some time before linux distros start shipping zip 3.0 and unzip 6.0 (still in beta) binaries, seems like installing zip binary would be easier than new PHP version any way.
In anycase supporting two different zipping methods would create more problems because they will never be 100% compatible
Well, nothing is as bad as it looks, info-zip has a new version that should partially support unicode, 3rd party windows zipping utils were improved too, unfortunately the windows built in zipping is still a mess
I suppose later this month I could test everything once more again and see if there are any new alternatives to PHP zip extension. The major problem here is that the PHP zip extension does not produce correct unicode enabled zips, it just accidentally worked with buggy windows clients at the time when I was testing it. We do not need "correct" zip encodings we do need something that our friends with windows can extract...
It will take some time before linux distros start shipping zip 3.0 and unzip 6.0 (still in beta) binaries, seems like installing zip binary would be easier than new PHP version any way.
In anycase supporting two different zipping methods would create more problems because they will never be 100% compatible
Is there really a problem here?
If you want to (or need to) stick with standard packages on these distributions then do the same for Moodle as well. For Debian that is Moodle 1.8.2.
If you are comfortable downloading and installing versions of software that are not "standard" for the distro (and let's face it this is pretty easy these days!) AND you want to run the most modern Moodle 2.0 then you might need to upgrade Moodle 2.0's dependencies.
If you want to have Moodle 2.0 running on old PHP etc then we can do it, but it'll mean delaying Moodle 2.0 even longer, because it's a lot of work ... (and by then the distributions will catch up anyway!)
If you want to (or need to) stick with standard packages on these distributions then do the same for Moodle as well. For Debian that is Moodle 1.8.2.
If you are comfortable downloading and installing versions of software that are not "standard" for the distro (and let's face it this is pretty easy these days!) AND you want to run the most modern Moodle 2.0 then you might need to upgrade Moodle 2.0's dependencies.
If you want to have Moodle 2.0 running on old PHP etc then we can do it, but it'll mean delaying Moodle 2.0 even longer, because it's a lot of work ... (and by then the distributions will catch up anyway!)
My 0.02 € on this,
Let's face it, using a non-distribution-packaged version of Moodle is really easy: just download the .tar.gz and unpack it in the right directory.
Compiling PHP on the other hand is not that straightforward. Lots of devel libraries needed, etc[1]. And then you need to keep on top of new releases fixing security bugs and so on.
Maybe Ubuntu would upgrade PHP on their LTS releases during the 5 years lifespan, but it's not guaranteed. And Debian, well I guess you know what their policies are on this subject
The only option I see in the sort term is persuading the people at backports.org to maintain a 5.2.8 (or later) version of PHP for Debian Lenny/Ubuntu Hardy.
I wonder what the latest RHEL is shipping...
Btw, just in case someone thinks I'm advocating lowering the requirements just to make the above trouble go away, I'm not. If 5.2.8 is what's required to make Moodle 2.0 avoid critical PHP bugs without hacky/fragile workarounds, I'm all for it
Saludos. Iñaki.
[1] I've done it in the past to develop the LDAP Paged Results patch and to compile oci8 support in Debian's PHP and it's a bit of a hassle.
I know you can update them The question is: is your RHEL still supported by RH if you upgrade to 5.2.8 from a non-official repository and the stock version for your RHEL server is 5.2.6? (actual version numbers are irrelevant to the discussion).
Saludos. Iñaki.
Would all of you quite your wining and snivling! Man! compile PHP from source, its more secure and you have more control over what you include and what you do not include. I moved away from binary distribution packages because of 'dependency purgatory'.. Perhaps you should to?
There is of course Im aware of a support issue with some enterprise linux vendors that claim you are unsupported if you compile from source. I learned this after 5 years of never having to call support but our institution was paying for it the whole time. When I did call I suggested compiling in a security fix for SSL from source and they said "Oh, no, we dont support that.", to which I explained the happenings of the past 5 years and their response was "Oh sorry, you're out of support then." - not impressed.
Of course when suggesting such a drastic change in order that my comments not be written off and labeled rhetoric here are some helpful links for compiling PHP:
http://www.php.net/manual/en/install.unix.apache2.php
http://www.securityfocus.com/infocus/1706 - Be carefull of this one, PHP safe mode does work but you need a fair bit of privileges to make it go, furthermore I have not fully tested with the basic set of mod_security rules, I will be doing this with our 2.0 pilot team. I tried to put in all the core rules for our most recent AMP stack but had to pull out last minute due to some pains with the gradebook and some file uploads.
Hope this helps some of you out there. Unfortunatly Im sure there will be a big push on the part of ISPs to move their PHP installations forward but 5.2 shouldnt be that far of a cry seeing as PHP4 is EOL.
"Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release. "
There is of course Im aware of a support issue with some enterprise linux vendors that claim you are unsupported if you compile from source. I learned this after 5 years of never having to call support but our institution was paying for it the whole time. When I did call I suggested compiling in a security fix for SSL from source and they said "Oh, no, we dont support that.", to which I explained the happenings of the past 5 years and their response was "Oh sorry, you're out of support then." - not impressed.
Of course when suggesting such a drastic change in order that my comments not be written off and labeled rhetoric here are some helpful links for compiling PHP:
http://www.php.net/manual/en/install.unix.apache2.php
http://www.securityfocus.com/infocus/1706 - Be carefull of this one, PHP safe mode does work but you need a fair bit of privileges to make it go, furthermore I have not fully tested with the basic set of mod_security rules, I will be doing this with our 2.0 pilot team. I tried to put in all the core rules for our most recent AMP stack but had to pull out last minute due to some pains with the gradebook and some file uploads.
Hope this helps some of you out there. Unfortunatly Im sure there will be a big push on the part of ISPs to move their PHP installations forward but 5.2 shouldnt be that far of a cry seeing as PHP4 is EOL.
"Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release. "
http://distrowatch.com/table.php?distribution=redhat suggests that it's currently 5.1.6 in RHEL5, and 4.3.9 in RHEL4 (which is what we're running here, I believe).
We are actually running a much newer PHP version (will be 5.2.8 soon). I think our server team built it manually. Obviously they would have preferred to use the standard version for reasons of support etc. but in practice it hasn't caused too much trouble - er, that I'm aware of.
--sam
We are actually running a much newer PHP version (will be 5.2.8 soon). I think our server team built it manually. Obviously they would have preferred to use the standard version for reasons of support etc. but in practice it hasn't caused too much trouble - er, that I'm aware of.
--sam
I have been looking around and you can add PHP 5.2.8 into Ubuntu 8.10 by adding the following to your apt/sources.list:
deb http://ppa.launchpad.net/tarkus/ubuntu intrepid main
deb-src http://ppa.launchpad.net/tarkus/ubuntu intrepid main
This is from https://bugs.launchpad.net/ubuntu/+source/php5/+bug/305393
Works on my test box at home. I will do some tests before applying it to any boxes at work!
deb http://ppa.launchpad.net/tarkus/ubuntu intrepid main
deb-src http://ppa.launchpad.net/tarkus/ubuntu intrepid main
This is from https://bugs.launchpad.net/ubuntu/+source/php5/+bug/305393
Works on my test box at home. I will do some tests before applying it to any boxes at work!
Thanks very much Jon!
I''ll try this on one of our test servers as well
Cheers, Stuart.
I''ll try this on one of our test servers as well
Cheers, Stuart.
I am installing Moodle on my host which uses PHP version 5.2.6. I downloaded the latest Moodle 2.0 dev version and I got the error: "version 5.2.8 is required and you are running 5.2.6". Since I can not install the correct version of PHP what can I do to get the latest Modle Dev version up and running on my host?
I searched on Moodle Tracker and found: http://tracker.moodle.org/browse/MDL-18073 but I am not familar with how it works. It says the issue is closed, so is there a fix? Where is it and how do I implement it? (sorry if it's easy to find, I searched a lot before I asked - I promise! )
Thanks.
I searched on Moodle Tracker and found: http://tracker.moodle.org/browse/MDL-18073 but I am not familar with how it works. It says the issue is closed, so is there a fix? Where is it and how do I implement it? (sorry if it's easy to find, I searched a lot before I asked - I promise!
Thanks.
As long as you prepared for some features to not work, then you could get it to install by editing admin/environment.xml and changing this line to 5.2.6:
<PHP version="5.2.8" level="required">
Or just install it on a local desktop or notebook instead ... I assume you realise that is an incomplete version for developers and not suitable for production use!
<PHP version="5.2.8" level="required">
Or just install it on a local desktop or notebook instead ... I assume you realise that is an incomplete version for developers and not suitable for production use!
Hi
Is this (simple and useful) workaround no longer possible?
On a test server I edit the admin/environment.xml and replace the required version.
But no matter what version is used I get the following error:
Even if these two lines are removed completely I get the same error:
<PHP version="5.2.8" level="required">
</PHP>
Is the PHP version being checked somewhere else other than admin/environment.xml ?
Or another possible explanation... any ideas?
Thanks, Stu
Is this (simple and useful) workaround no longer possible?
On a test server I edit the admin/environment.xml and replace the required version.
But no matter what version is used I get the following error:
- PHP version
- version 5.2.8 is required and you are running 5.2.6-3ubuntu4.1
<PHP version="5.2.8" level="required">
</PHP>
Is the PHP version being checked somewhere else other than admin/environment.xml ?
Or another possible explanation... any ideas?
Thanks, Stu
In you are using the install.php script, rather than just creating config.php by hand, then you need to change it in install.php too.
Thanks Tim - will look at that
There is no 'fix'. Moodle 2.0 requires PHP 5.2.8 to function correctly. However, it is only file zipping and unzipping that breaks on 5.2.6, so if you just want to try things out, find the file admin/environment.php, go to about line 230 of that file, and change <PHP version="5.2.8" level="required"> to say 5.2.6. Then it will install, and you can try things out.
Thanks a lot for this "workaround" .
5.2.4 seems to be fine for translation work
5.2.4 seems to be fine for translation work
Tim... maybe you were talking about environment.xml?
Just upgrade your current PHP version on whichever Ubuntu you're using via apt-get. No need to compile.
Today (Jan. 30th) just did a CVS update of my moodle 2.0 local installation to Build: 20090130. When I run the update, notifications tell me : PHP version 5.2.8 is required and you are running 5.2.5.
On the same (Windows XP) machine where I installed XAMP I also have moodle 1.8 and 1.9 running (plus a couple of other PHP/mySql software).
What should I do to gracefully upgrade my PHP from 5.2.5 to 5.2.8? Is there an XAMP package in the Moodle downloads containing PHP 5.2.8? If not, where can I get that PHP version from ? I do want to be able to continue updating my moodle 2.0 regularly to the latest version available but I do not want to botch my other versions (nor my other PHP software) in the process. I'd be grateful if someone could provide a step-by-step, non destructive procedure for a Windows machine.
Thanks,
Joseph
http://tracker.moodle.org/browse/MDL-18073
Interesting that the earlier MDL http://tracker.moodle.org/browse/MDL-15410 with regard to setting the php version for Moodle was closed, and this opened.
It is experimental and 5.2.8 is the current version, but that is quite a curve ball....
Sorry no help to offer.....
Interesting that the earlier MDL http://tracker.moodle.org/browse/MDL-15410 with regard to setting the php version for Moodle was closed, and this opened.
It is experimental and 5.2.8 is the current version, but that is quite a curve ball....
Sorry no help to offer.....
Hi Joseph,
since some days ago, the Windows Packages, available in http://download.moodle.org/windows are using the latest XAMPP 1.7.0, that comes with PHP 5.2.8. So I guess you can use them.
Hope this helps, ciao
PS: Marc, both Moodle Tracker reports are resolved as fixed. The old one was about to jump to PHP 5.2.4 and the newer to PHP 5.2.8 (I hope we won't *need* to perform more jumps).
since some days ago, the Windows Packages, available in http://download.moodle.org/windows are using the latest XAMPP 1.7.0, that comes with PHP 5.2.8. So I guess you can use them.
Hope this helps, ciao
PS: Marc, both Moodle Tracker reports are resolved as fixed. The old one was about to jump to PHP 5.2.4 and the newer to PHP 5.2.8 (I hope we won't *need* to perform more jumps).
Thanks Eloy,
I installed the latest XAMP package and everything is OK.
Joseph
I installed the latest XAMP package and everything is OK.
Joseph