Update: Tried
adminlib.php,v 1.124.2.1 2007/02/15 09:45:37but still have just white screens if I try to access any admin scripts directly and no blocks in the front page.....
Help??
Can someone tell me the quickest way to determine what version of adminlib.php was packaged with Build 2007021520 so that I can pull it from the CVS? My 1.8.2 installation had its file written over, back up is corrupted and students are getting very restless...
Update: Tried
Help??
Update: Tried
Help??
Looking at adminlib.php, it looks like it is parsing all the plugins....
Will a change in the files under moodle/lib/editor cause this to fail, producing my problem? Has running the 1.9 file potentially corrupted locks now?
At this point am I best off to try and simply upgrade to 1.9 and hope that the upgrade resolves any issues?
Will a change in the files under moodle/lib/editor cause this to fail, producing my problem? Has running the 1.9 file potentially corrupted locks now?
At this point am I best off to try and simply upgrade to 1.9 and hope that the upgrade resolves any issues?
In reply to Marc Grober
Resolved: Urgent need for /lib/adminlib.php for Build 2007021520
by Marc Grober -
I can now confirm that 1.8.2 users should be wary of allowing a 1.9 build adminlib.php near their installation. I can confirm that that this version http://cvs.moodle.org/moodle/lib/adminlib.php?revision=1.124.2.10 will work with 1.8.2 and will magically restore blocks and eliminate admin white screens where patching with a more recent version creates such problems.
In reply to Marc Grober
Re: Resolved: Urgent need for /lib/adminlib.php for Build 2007021520
by Anthony Borrow -
Marc - Thanks for sharing your experience here. It is important that users be aware of how to upgrade and how to properly apply patches. No files, especially lib files which are used by multiple aspects of Moodle, should be used from a different version (i.e. 1.6, 1.7, 1.8, 1.9, etc.) as they may well cause problems as things mature and develop. The 1.9 files are written only to work with other 1.9 files. Users you might be confused about how versions work in Moodle may find it helpful to read:
http://docs.moodle.org/en/CVS_(developer)#Working_with_branches
As you discovered, it is important to understand how versioning works. In general, I recommend that when adding a patch or contributed (3rd party) plugin that users upgrade to the latest stable release of the version they have before applying the patch or adding the module (unless the instructions for that patch indicate otherwise). It is important that site administrators who want to take advantage of a patch make sure that it works with their installation by testing on a test server first. Patches are deviations from Moodle core and are likely to be less reliable and not as thoroughly tested. This really does place an additional burden of testing on the one installling the patch. I might even go as far as to say that any patch should be treated as beta quality.
Especially with patches that overwrite or modify core code, it is worth reiterating the warning found at:
http://docs.moodle.org/en/Installing_contributed_modules_or_plugins
Warning: Please be aware that some contributed modules and plugins have not been reviewed, and the quality and/or suitability for your Moodle site has not been checked. The modules and plugins may have security problems, data-loss problems, interface problems or just plain not work. Please think carefully about maintenance before relying on contributed code in your production site, as some of this code may not work with future versions of Moodle.
Moodle admins wishing to use patches or contributed code should be comfortable debugging code and troubleshooting issues. In short, patches are not for the faint of heart.
Peace - Anthony
http://docs.moodle.org/en/CVS_(developer)#Working_with_branches
As you discovered, it is important to understand how versioning works. In general, I recommend that when adding a patch or contributed (3rd party) plugin that users upgrade to the latest stable release of the version they have before applying the patch or adding the module (unless the instructions for that patch indicate otherwise). It is important that site administrators who want to take advantage of a patch make sure that it works with their installation by testing on a test server first. Patches are deviations from Moodle core and are likely to be less reliable and not as thoroughly tested. This really does place an additional burden of testing on the one installling the patch. I might even go as far as to say that any patch should be treated as beta quality.
Especially with patches that overwrite or modify core code, it is worth reiterating the warning found at:
http://docs.moodle.org/en/Installing_contributed_modules_or_plugins
Warning: Please be aware that some contributed modules and plugins have not been reviewed, and the quality and/or suitability for your Moodle site has not been checked. The modules and plugins may have security problems, data-loss problems, interface problems or just plain not work. Please think carefully about maintenance before relying on contributed code in your production site, as some of this code may not work with future versions of Moodle.
Moodle admins wishing to use patches or contributed code should be comfortable debugging code and troubleshooting issues. In short, patches are not for the faint of heart.
Peace - Anthony
In reply to Marc Grober
Re: Urgent need for /lib/adminlib.php for Build 2007021520
by Martin Dougiamas -
You should never update individual core files - there are all kinds of dependencies.
I would suggest just upgrading everything to the latest 1.8 weekly build (if you are sticking to 1.8).
cvs -q update -dP -r MOODLE_18_WEEKLY
I would suggest just upgrading everything to the latest 1.8 weekly build (if you are sticking to 1.8).
cvs -q update -dP -r MOODLE_18_WEEKLY
In reply to Martin Dougiamas
Re: Urgent need for /lib/adminlib.php for Build 2007021520
by Marc Grober -
As you can see this was resolved quite some time ago and the experience led to the Finding thread John Isner posted.
I had no intention of upgrading the core at the time, but that is another issue altogether. I was simply upgrading dragmath (or so I thought) only to discover that the claim that the files would work with 1.8 and 1.9 was overbroad because the zip contained a major rewrite of adminlib.php.
What is confusing is the suggestion that any 1.8 file will work with any 1.8 install while the claim is that one should never upgrade core files (within 1.8).
Nor would I do a core upgrade on a system in production the last weeks of a quarter (and while I appreciate that the multitude of postings about upgrade issues probably reflect a small minority of installations, they are still frightening as things do go bump, no matter the prep.
I simply needed to grab a copy of the original file, which was the quickest safest and most appropriate thing to do.....
I had no intention of upgrading the core at the time, but that is another issue altogether. I was simply upgrading dragmath (or so I thought) only to discover that the claim that the files would work with 1.8 and 1.9 was overbroad because the zip contained a major rewrite of adminlib.php.
What is confusing is the suggestion that any 1.8 file will work with any 1.8 install while the claim is that one should never upgrade core files (within 1.8).
Nor would I do a core upgrade on a system in production the last weeks of a quarter (and while I appreciate that the multitude of postings about upgrade issues probably reflect a small minority of installations, they are still frightening as things do go bump, no matter the prep.
I simply needed to grab a copy of the original file, which was the quickest safest and most appropriate thing to do.....