I need a development branch bug fixed ASAP please!!! We're planning to train a number of OU developers on the Moodle code base and we can't install 1.6 dev (our target platform for our spring courses). An existing bug Bug #4249 was reported at the end of October. If someone with more expertise than I could take a look at it and post a fix, I would be eternally grateful.
Thanks!
Jason
How big is your maximum memory setting in php.ini? This sort of thing is more often than not caused by running out of memory. The blocks installation process is quite memory intensive. Try increasing it.
Failing that, make sure you have error logging switched on and check the end of the logs immediately after the error happens - it's likely you will see a PHP error of some sort, which will be a big clue.
Failing that, make sure you have error logging switched on and check the end of the logs immediately after the error happens - it's likely you will see a PHP error of some sort, which will be a big clue.
Hi Jason, just tried installing the the latest zip download on my laptop, went fine.
What OS and box are you using? Is it a fresh install of the OS?
Hi Michael,
We're trying to install on a fresh RHEL 4 box with PHP 5 custom compiled.
We're trying to install on a fresh RHEL 4 box with PHP 5 custom compiled.
Hmm, I would recommend going with PHP 4.4.1 if you need to get up and running soon, there were some problems in various .x of 5.
But then I am generally terrified of .0.x versions of any software and try to wait until they get their first .x (where x>1)
Hi Jason,
I don't know if this will be your problem but it seems that the "lams" code breaks the installation process (at least under my PHP 5.0.4) installation.
The "mod/lams/lib.php" includes the "lib/nusoap/nusoap.php" library and that library has some incompatibilities with PHP servers with SOAP enabled (due to some function names, if I'm not wrong). I remember I had to hack such library in my Google API block some time ago to work under PHP 5.
Perhaps you could try to delete the mod/lams dir to see if then you are able to install 1.6 successfully.
It could be the memory too, but I've installed everything (but the lams module) perfectly in my server with 8MB (I really think that this setting isn't important at install time in practically every server).
Hope it helps, ciao
I don't know if this will be your problem but it seems that the "lams" code breaks the installation process (at least under my PHP 5.0.4) installation.
The "mod/lams/lib.php" includes the "lib/nusoap/nusoap.php" library and that library has some incompatibilities with PHP servers with SOAP enabled (due to some function names, if I'm not wrong). I remember I had to hack such library in my Google API block some time ago to work under PHP 5.
Perhaps you could try to delete the mod/lams dir to see if then you are able to install 1.6 successfully.
It could be the memory too, but I've installed everything (but the lams module) perfectly in my server with 8MB (I really think that this setting isn't important at install time in practically every server).
Hope it helps, ciao
I compared the nusoap.php in moodle 1.6 and that in moodle 1.5 and found they are exactly the same. Since "lams" works in moodle 1.5, it shouldn't break moodle in 1.6 for that reason mentioned by Eloy.
I tried remove everything related to "lams" before I started installing moodle 1.6.
It ended up with the same serious error as with "lams" when setting up the site at the final step. The environment is Windows XP professional with SP2, Apache 2.0.55(Win32), PHP5.0.5, MySQL5.0
I tried remove everything related to "lams" before I started installing moodle 1.6.
It ended up with the same serious error as with "lams" when setting up the site at the final step. The environment is Windows XP professional with SP2, Apache 2.0.55(Win32), PHP5.0.5, MySQL5.0
Well,
as I said in my previous message, I'm not really sure if this is the same error that you are viewing or no. But I must insist that, having PHP 5 with SOAP enabled is incompatible with the nusoap library included in Moodle, both in Moodle 1.5 and 1.6dev (it's the same). And it breaks the install, just after installing the "mdl_lams" table (no Continue button). Exactly it happens when the "lib/nusoap/nusoap.php" is included by "mod/lams/lib.php".
The cause seems to be the soapclient() class that conflicts in PHP SOAP and nusoap. When I was developing the GoogleAPI block, using the nusoap library produced such problem so I included a slightly modified nusoap library (just with that class name changed to nusoapclient()) inside the block to be able to run without problems.
Ciao
as I said in my previous message, I'm not really sure if this is the same error that you are viewing or no. But I must insist that, having PHP 5 with SOAP enabled is incompatible with the nusoap library included in Moodle, both in Moodle 1.5 and 1.6dev (it's the same). And it breaks the install, just after installing the "mdl_lams" table (no Continue button). Exactly it happens when the "lib/nusoap/nusoap.php" is included by "mod/lams/lib.php".
The cause seems to be the soapclient() class that conflicts in PHP SOAP and nusoap. When I was developing the GoogleAPI block, using the nusoap library produced such problem so I included a slightly modified nusoap library (just with that class name changed to nusoapclient()) inside the block to be able to run without problems.
Ciao
If it's that case, I suggest we change lib/nusoap/nusoap.php that way, so that all the modules that need nusoap can benefit. There's no point including customised nusoap here and there. I found quiz also uses nusoap and it includes a seperated nusoap.php and it calls new soapclient(...) as well
100% agree to:
- Add latest nusoap library (1.2) to lib/nusoap/nusoap.php
- Patch it to work properly under PHP servers with their own SOAP extension enabled.
Although, perhaps it would be better, in the long term to:
- Add latest nusoap library (1.2) to lib/nusoap/nusoap.php
- Create a lib/nusoap.class.php that will be a wrapper to SOAP services under Moodle, using nusoap or PHP's SOAP ot whatever SOAP library we want to use in the future, isolating this changes in base libraries from developers. It shouldn't be too much difficult to change current SOAP code in Moodle (lams and quiz) to use that wrapper class.
Ciao
- Add latest nusoap library (1.2) to lib/nusoap/nusoap.php
- Patch it to work properly under PHP servers with their own SOAP extension enabled.
Although, perhaps it would be better, in the long term to:
- Add latest nusoap library (1.2) to lib/nusoap/nusoap.php
- Create a lib/nusoap.class.php that will be a wrapper to SOAP services under Moodle, using nusoap or PHP's SOAP ot whatever SOAP library we want to use in the future, isolating this changes in base libraries from developers. It shouldn't be too much difficult to change current SOAP code in Moodle (lams and quiz) to use that wrapper class.
Ciao
That's really good idea!
I will be trying to repro it (and fix it if possible/relevant) tomorrow. Can't repro on my laptop now. Fixing bugs could end up being part of the training
Moodle 1.6 (nightly cvs) no longer breaks, only on a German languange file, so I removed that language.
Before I had a demo in a scorm course format (International Security Risks: the course where you learn that Amsterdam is famous for making extasy), but this course says now:
Fatal error: Call to undefined function: scorm_get_toc() in C:\apachefriends\xampp\htdocs\moodle\course\format\scorm\format.php on line 96
German langfile fixed anyway