Moodle 3.1.1.
Was upgrading various plugins and after the last one was uploaded to the server, I went back to the plugin check/upgrade page in my web browser and now get stuck on a blank screen with the header plugins check. I've not encountered this problem before. I haven't been able to find some specific ways to address this. Help would be much appreciated!
Thanks for the reply Ken. The even the landing page now is completely blank. I tried the purgecache.php but it was also just blank. The plugins.php also is simply blank. I had 4 plugins in to do but wasn't expecting this type of outcome from rather mundane maintanence. Since nothing seems to be direclty accessible, I'm not sure what to do other than restore yesterday's directory backup.
If in a pinich, then yes, restore yesterday's backup ... which I hope includes a restore of yesterday's DB dump.
If you didn't start the process of 'upgrading' with a backup of code and a backup (sql dump) of the DB, then you might have to restore an older set of backups.
Was this an update (within a series ... like 2.9.3 to 2.9.highest) or an upgrade (up a series ... like 2.9.x to 3.1.1 highest just released)?
How did you do the update or upgrade?
Did you follow any docs ... like https://docs.moodle.org/31/en/Upgrading
Other suggestions ... check ownerhips/permissions on all folders/files if upgrading. If you did that as root user, for example, all of the files/folders might belong now to root and not a user that web service is using.
Turn on debugging ... by taking the debugging lines from config-dist.php and inserting them into the bottom of the active config.php file just above the following lines in config.php:
require_once(dirname(__FILE__) . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!
Those debug lines are:
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
Remove the '//' in front of lines 2,3,4, and 5 above.
No need to restart anything, just try to navigate the site. Hopefully, Moodle will report something.
'spirit of sharing', Ken
Yes, it has the database dumps from yesterday. I've already been working with our host to inititate the back up restore since this is going to be the easiest option.
I just had to free up some space on the server to do the restore so it's a waiting game at the moment.
I wasn't upgrading Moodle, I was only upgrading plugins (Poodll and Buttons Course format) which is what makes this all so very strange to me. I was preparing for the release of 3.1.2 and intended to upgrade Moodle this week and was simply doing plugins first (did a few on Saturday, and then there were a couple of new updates I saw this morning).
I'll let you know how the restore goes- I'm just waiting.
Ken,
We restored a back up from yesterday and as soon as I logged in, it immediately reverted to this half blank plugins check. The main URL also will not load. This, of course, shouldn't be happening though. This is before any of the updates that I did today. I am at a total loss. I was able to temporarily access the purgecache.php and initiate that, but now I can no longer access that page, or the plugins one. This is unfortunately beyond my knowledge base and am not sure what else to do.
Im uploading a backup from Thursday which is before the work I did on Saturday (that was completely fine) and might restore this though I am afraid it will result in the same problem for some reason.
Unfortunately, one has to research plugin compatibility, prior to pulling the trigger on updating or upgrading. So one suggestion is to check compatibility. Normally, a plugin what was compatible with say a 2.9.6 should be compatible with 2.9.highest. Doesn't mean, however, if one upgrades to say 3.1.highest (skipping 3.0.highest) the plugin will continue to be compatible.
If purging caches via Moodle UI doesn't work, time to get nasty with it. With whatever you have browse files, navigate to the moodledata directory and manually remove the *contents* of cache and localcache directories.
Those should rebuild as you click around.
Would also manually remove all sessions files in moodledata/sessions/
Then, in browser, remove cookies and history for the site.
You've mentioned remotely hosted and 'had to free up space' .... so two more thoughts ... is cron job running often enough? Cron job now has task to do things like moving unlinked files from moodledata/filedir/ to moodledata/trashdir and then, eventually, erasing the files.
Remotely hosted moodles are normally in a virtualized environment and could be under limits of some sort (space being one). Sounds like it's managed ... ie, service provider does stuff for ya. So is your hosting arrangement such that it has enough space, can use extra memory (needed for not only backups and restores of courses, but things like updates and upgrades).
If you can view server logs, check out apache error log to see if there isn't a clue or two in there.
'spirit of sharing', Ken
Ken,
All good diagnostic questions. I can't tell you what the problem was that caused all of this but the first attempt to restore didn't restore the contents of the public_html directory, which, well, was where those plugins were (or not really resetting anything).
I don't know why this was an issue in the first place as they are all compatible (and the Poodll ones were minor updates to the official Poodll 3 release which was installed on Saturday and those were fine.
With the second restore, everything was back to normal. Just installed the 4 plugins from this morning without any problems. Everything is running as it should. Well, normally I'm not at the office at 10pm on a Monday. On a national holiday.
Normally the server is running around 40% capacity and I offload daily backups to a work computer so they don't built up on the server (and in case anything burns down on their end). Cron job runs at night for the trash clean up, etc. I'm grateful for backups and hosting support though.
I'm off to an hour train ride home and to bed! As always, thanks so much for the advice and help Ken. I really hope one day I'll amass the type of knowledge you share with the community here.
When this first happens to you it's quite scarey because there is no longer anything you can do from the user interface.
But it happens from time to time when you install plugins.
Most commonly in my experience it's a plugin bug or its incorrect permissions on files.
Kens suggestion of turning on debugging from the config file is the first thing you should do.
Any error information you get will probably point you in the direction of the problem.
You should also check your web server error logs. There is bound to be information about the error in there too.
Justin,
It's the first time I have experienced so to say that I had (and still don't) no idea of what to do is an understatement. My goal is to try get our installation running on my MAMP installation at the moment so I can non-destructively play with it. I'm only a front end developer/course designer so while I generally understand the concepts of how stuff works, developer/debugging mode doesn't help me too much as its all Greek! I am trying to get that info and get in touch with one of the Moodle Support services (e.g. Catalyst IT) to help figure it out.
William,
When it comes to debugging no one is expecting you to know what it says ... and not necessarily what to do about it. But one could copy what it says ... come back here, and post a response with 'heres what debugging showed'!
Think Justin is the author of one of those plugins ... now when was the last time you got to talk to any programmer for Google, or Bing, or Windows, or Apple, etc..
That's what open source is about. Moodle is open sourced software and even though releases of versions have the word 'stable' in them doesn't mean it's 100% bug free. Moodle HQ releases code/updates to existing supported versions all the time ... at least once a week.
Now let's put that into some terms in your area ... Course Designer. Let's say you discover a 'better way'. Those folks for whom you have designed a course, might need your help in setting up this 'better way'. They also might have a hard time with the concepts and understanding 'why it's better'.
So take this little bump as just that ... a bump ... In a journey into expanding what you do ... a course designer with a + in troubleshooting issues + fixing them (even if you don't program) actually might lead you to expansion into other areas ... apache web services ... DB server admin. Those are things that are in the background but very important in making it go. A course designer with that sort of background has to be worth more than one without, right?
Kinda like Bachelors, Masters, and Doctorates degrees, huh?
The 'ride' can be frustrating at times ... but all the bumps and ups/downs in emotions will make you a better course designer in the long run.
Testing things out on a laptop version of Moodle is a good approach to start ... if that blows up, no biggy ... you are then forewarned and might be better prepared for the production server then.
'spirit of sharing', Ken
PS .. we 'old folks' really aren't any smarter ... we just have had more experience - good as well as bad. We're just able to recognize a mistake when we make them again ... cause we've made 'em before! ;)
Ken,
For sure, this is what debugging shows! Justin is definitely the author of Poodll and a very nice guy!
Warning: include(): Failed opening '/home/gnucr/public_html/courses/admin/tool/qeupgradehelper/version.php' for inclusion (include_path='/home/gnucr/public_html/courses/lib/pear:.:/usr/lib/php:/usr/local/lib/php') in/home/gnucr/public_html/courses/lib/classes/plugin_manager.php on line 318
There's also a line on top I couldn't quite get to copy but its sort of visible in the screenshot. Unsurprisingly its related to the upgrade process.
Interesting - what that implies to me is that there is a problem with part of your core Moodle install. Is this a new installation? Can you tell us what plugins you were upgrading? Normally I would suggest pulling a new version of Moodle code down and upgrading/replacing your moodle install but not sure what stage you are at with this site ...
The site has been around for a while and predates me. At least 5-6 years? I took over this position maintaining it just under a year ago.
I was upgrading Poodll plugins, and a couple of others. The irony is, after the site was restored, I had no trouble upgrading them.
A couple days later I ran into problems upgrading core moodle and restored back to a previous version.
Justin was really really kind today and helped me sort out Poodll - he had no issues upgrading the plugins which absolutely blew my mind since I had such difficulty and don't really want to touch anything now. I have to wait until we are out of session.
I just download a site back up and am going to work on getting into my MAMP set up and try to run a full update there and see what I can do.
Thank you! Now folks can help! ;)
The 'qeupgradehelper' was an admin tool in versions 2.6 and below to assist with upgrading the quiz engine. If you re-call it was a link in the Site Admin menu at the very bottom.
In your 3.1 code - courses/admin/tool/ there is a "qeupgradehelper" that doesn't belong there. That tool no longer available for your version.
Suggest using whatever you have for managing files/directories and "move" the "qeupgradehelper" directory found in courses/admin/tool/ out to some location of your file space *outside* of courses (the moodle code).
Let's see if doing that will get you by.
However, Emma is right ... might have been due to the method used to upgrade your Moodle. It is never recommended to over write moodle code directory for issues like you are facing now ... a directory that should be removed, remains. A fresh code directory, with the config.php file of the old code directory is generally the way to upgrade.
Let's not assume the worst and start over yet .... just move that directory out.
Let's hope that's the only item that's out-of-place.
'spirit of sharing', Ken
Ken, Emma,
I confirmed that there was in fact a qeupgrader folder in both the directory and in the admin tool list of plugins. I uninstalled it - and went back to turn on the debugging output.
No output. Nothing. I had to make sure I actually hit save. Normal and All reasonable PHP displayed zero output. I'm positing this is a good thing. I'm off to bed at the moment but I appreciate everyone's help today.
Under All Moodle Developer Notices, I did get the following however:
If I'm following you ... no more errors about qeupgradehelper any more. Good. One step forward.
The errors now all relate to poodll and since you have the maker of Poodll engaged already, am sure Justin will have some suggestions.
Close to resolution me thinks.
'spirit of sharing', Ken
Ken,
You are following 100% correctly . I did also start loading a copy in my MAMP set up last night - I was able to get the Moodle files in place, the moodle data files in place, and direct the config file to both. I have yet to get it connected to the sql database though. There's only so much time in the day.
If your Mac isn't a true server ... and you are using MAMP, the mysql daemon (service) is started by clicking the MAMP icon ... which launches a little panel where one can start the DB service as well as the Apache provided by MAMP (not the Apache that your Mac already has).
On your true server (probably linux) that's handled differently (shouldn't have to launch Apache NOR Mysql all the time as those are services which should be running all the time and start up on boot up).
The config.php file of either, does have lines for DB server settings. Never use the config.php file for MAMP on your production Linux server.
Also, the poodl errors ... unless I am wrong, poodl is really a set of addons - more than one.
See: https://moodle.org/plugins/browse.php?list=set&id=13
The one you are missing appears to be this one:
https://moodle.org/plugins/assignfeedback_poodll
Install that one, and those errors should go away.
'spirit of sharing', Ken
Ken,
Yep it's all separate- I just have to get the sql files in the right place of the directory (which I haven't looked at yet).
As for Poodll, yes it is a set of plugins and we aren't missing the assignment_feedback plugin-it's definitely there on the server and available for use in Moodle (I don't think any of our faculty use it though-I'm more sure of their use of written feedback).
Justin will have to correct me as I might be totally wrong (probably am) on this, but I swear I read somewhere on a Poodll thread that there was an issue with certain string data. He provided a potential work around that involved some work. That may or may NOT be related to this. I'm off to bed at the moment but I'll see tomorrow about locating that thread.
Enjoy the day Ken!
Now I know you haven't looked into it yet, but .... how about a hint at this part:
get the sql files in the right place of the directory (which I haven't looked at yet)
The code directory and moodledata directory/folder are fliles that need placing in proper places. An sql file is really the database in a format that can be imported into another MySQL DB server.
And the official docs that talk about that part:
https://docs.moodle.org/29/en/Moodle_migration#Restore_the_database_backup_to_the_new_server
While the version in the link says 29 what it shows is applicable to all versions.
You're gaining on it! ;)
'spirit of sharing', Ken
Ken,
I was trying to do HW tonight instead of Moodle stuff but I eventually distracted myself!
I got some help to get the DB connected. A little bit more involved than I was anticipating but it's set up and running .
In the MAMP installation I removed the qeupgrade tool as I did the other day on the live site. Updated all of the plugins (this took some time-my internet at home is slow).
Checked the debugging output-as expected none. The most recent Poodll update that Justin pushed out seems to have fixed those string related issues that came out under Extra Moodle Dev notices. (He pushed out one the day after he helped me out).
Upgraded to 3.1.2+.
No issues in MAMP.
Everything looks good. I can't thank you enough for all of the assistance (and motivation). At some point I have to do this on the actual server though. I hope it goes equally smooth then, but it won't be for
Congrats! You've made one giant leap from 'course designer' to course designer **with experience**. ;)
Now when it comes to production .... plan your work ... work your plan. ;)
'spirit of sharing', Ken
Ken,
It has definitely been an experience . Plan in the works!
I did enable debugging mode prior to trying to upgrade a plugin. When the page times out and results in just a blank white screen, I get :
Fatal error: Maximum execution time of 30 seconds exceeded in C:\MAMP\htdocs\courses\lib\classes\plugin_manager.php on line 2188
I did search through the file for this line but I was unable to find any line of code related to execution time. That might just be me though. When it doesn't "time out", I just get the half rendered page.
I've tried deleting cache, local cache, and .htaccess but the results are the same. Ironically I did this on my home computer MAMP set up yesterday and had no issues!
I can live with this if I know how to fix it, but, I don't! What are your thoughts? That is the only output I get.
As for 2188 in the php file, I find:
public function is_directory_removable($fullpath) {
if (!is_writable($fullpath)) { //this is line 2188 here//
return false;
}
How about that!!! Guess I forgot they make/made a MAMP for Windows!
Errr ... not a Windows person:
https://documentation-3.mamp.info/en/documentation/mamp-windows/
But the error one needs to troubleshoot is really this one:
"Maximum execution time of 30 seconds exceeded" for MAMP
On a Mac, I would have told you to do this:
Kens-MacBook-Pro:MAMP ktask$ find ./ -name php.ini
.//bin/php/php5.6.2/conf/php.ini
.//conf/php5.6.2/php.ini
in the php.ini file that you would edit with a text editor (like nano on a Mac):
max_execution_time = 60
max_input_time = 120
memory_limit = 128M
Save the file.
Default for first is normally 30, second is 60, and third is 256M (I think).
TIA! (try it again).
I have MAMP on a Mac and the settings you see above are on the Mac. Curious they aren't the same on Windows. Oh, that's right ... they aren't the same OS1! ;)
'spirit of sharing', Ken
Ken,
I burst out laughing when I saw the first lines of your reply! I am a Mac user through and through, and sadly I am tortured at work with a Windows machine. (All kidding aside, it's alright, but, not my cup of tea)
Yes, it just seems like it gets lost in this time-out purgatory. I will explore this tomorrow when I am at work! As you would expect, I can reset the MAMP (WAMP in this case?) server, log back in to moodle, but it triggers the need to upgrade the database and then just times out.
My goal for the future is to perform the upgrades locally and then just migrate that to the server. It's inefficient, I know, but at least it avoids problems. Doing the SQL import and connection in the config file is relatively easy now that I have done it several times lol.
On a side note, I discovered today that Firefox 49.1 has problems playing back mp3 files through Poodll on Windows XP! Who knew! (48.0.2, totally fine). Please don't ask why we are running XP still because I really don't know (government, bureaucracy, cheap, apathy, cheap, did I mention cheap?).