I recently updated to 1.8.2. A classrooms using a wiki to write term papers (individual wiki's) is experiencing these problems. 3 students and growing can't access there previous work. They click on the wiki, it spins and spins then pops up with a blank page with this in the url but no data displayed: http://moodle.mpls.k12.mn.us/classroom/mod/wiki/view.php?id=1238
It is happening on 2 separate wikis in the same course.
Any help trouble shooting this would be great.
hello matt,
my students habe the same problem. could you solve it.
thanx for help
fred
Hi Fred. I ended up requesting a third party to look at it and I will post the response I got from them. I have been monitoring the wiki forums and it seems like there are many issues in 1.8 with the wiki, especially when we do did our upgrade in late august. i have considered upgrading altogether. Here is the feedback i got.:
Matt, since you filed the ticket, we've had some success in troubleshooting the problem you mentioned here. We have seen some other customers notice the same symptoms you are describing, however, solving the problem is very delicate. Let me begin by explaining what is happening. The problem is not actually the wiki, the wiki works fine, it is the HTML editor which is used in Moodle which can easily hang, go blank or deliver the unresponsive script error in Firefox. Each browser handles the condition differently. It's not that the script has become unresponsive, it is because the browser has gotten impatient waiting while the HTML editor saves the data back to Moodle. The more data in the page, the longer it takes for the information to save, or depending on database load, network conditions it can take a variable amount of time for the information to save back to the database which when this error or symptoms appear, it exceeds the browser's wait time. It's also important to note that once the browser displays the unresponsive script error or similar symptoms, we highly recommend closing out the browser, as it will no longer respond normally, and will usually 'eat' anything further put in to it until the browser restarts. Based on what we've learned so far, we have three strategies to dealing with this behavior depending upon how often or how much it is impacting your environment. All steps are not necessary, but options and recommend exercising them on a case by case basis. 1) Ensure your users are vigorously using the Clean Word HTML button in the editor before clicking save. This greatly reduces the amount of clutter in the document and makes it easier for Moodle to save. This also works great when pasting from other programs as well; so don't let the 'Word' in Clean Word HTML fool you. Make it a good habit after saving any changes to use it anyway to make sure the changes are not bringing any unneeded clutter to the document. 2) The next step we propose is increasing the patience of the browser to wait for the document to save. This fix is applicable to users running Firefox. Were still looking at how to extend this other browsers. 1. Type about:config in Firefox's address bar. 2. Filter down to the value for dom.max_script_run_time. 3. Change (double click) the value to 60 3) Turn off the HTML editor. Users can choose not to use the HTML editor from the profiles under the 'when editing text'. When editing text will only appear after clicking on Show Advanced on the profile screen. Using the simple web forms will eliminate this problem since the html editor will be turned off.
Matt, since you filed the ticket, we've had some success in troubleshooting the problem you mentioned here. We have seen some other customers notice the same symptoms you are describing, however, solving the problem is very delicate. Let me begin by explaining what is happening. The problem is not actually the wiki, the wiki works fine, it is the HTML editor which is used in Moodle which can easily hang, go blank or deliver the unresponsive script error in Firefox. Each browser handles the condition differently. It's not that the script has become unresponsive, it is because the browser has gotten impatient waiting while the HTML editor saves the data back to Moodle. The more data in the page, the longer it takes for the information to save, or depending on database load, network conditions it can take a variable amount of time for the information to save back to the database which when this error or symptoms appear, it exceeds the browser's wait time. It's also important to note that once the browser displays the unresponsive script error or similar symptoms, we highly recommend closing out the browser, as it will no longer respond normally, and will usually 'eat' anything further put in to it until the browser restarts. Based on what we've learned so far, we have three strategies to dealing with this behavior depending upon how often or how much it is impacting your environment. All steps are not necessary, but options and recommend exercising them on a case by case basis. 1) Ensure your users are vigorously using the Clean Word HTML button in the editor before clicking save. This greatly reduces the amount of clutter in the document and makes it easier for Moodle to save. This also works great when pasting from other programs as well; so don't let the 'Word' in Clean Word HTML fool you. Make it a good habit after saving any changes to use it anyway to make sure the changes are not bringing any unneeded clutter to the document. 2) The next step we propose is increasing the patience of the browser to wait for the document to save. This fix is applicable to users running Firefox. Were still looking at how to extend this other browsers. 1. Type about:config in Firefox's address bar. 2. Filter down to the value for dom.max_script_run_time. 3. Change (double click) the value to 60 3) Turn off the HTML editor. Users can choose not to use the HTML editor from the profiles under the 'when editing text'. When editing text will only appear after clicking on Show Advanced on the profile screen. Using the simple web forms will eliminate this problem since the html editor will be turned off.
Hi Matt. Thank you for your message.
fred