Installing and upgrading help

Hi Jasper,

Thanks for jumping in, but I think you mis-understand the purpose of this section of code.

This section is in the ajax_check_captured_output() function, whose purpose is to check for any potential errors, or other unexpected output. It is always called after we have called ajax_capture_output() and we expect there to be no output at this stage.

Prior to the introduction of this code, any time that an AJAX query included a plugin file which has unexpected whitespace or content, this caused issues when the browser tried to decode what it expected to be a JSON request. If you take the example of a plugin which used echo to output a problem or debugging info, then this would be output before the expected JSON output, leading to output which may look like:

Couldn't find course 1{"id":"1","somecontent":["foo","bar","baz"]}

The browser is unable to correctly parse this and throws an error which is meaningless to the user and does not help to track the issue down at all. As a result, during AJAX scripts, we now look for and capture any unexpected output. The above block of code then decides what to do with that output. If the $output variable (where that unexpected output was captured to) is not empty (as in the if (!empty($output)) section you highlight in particular), then we log this to the web server's error log. If the site is additionally in the relevant debug mode, then we instead throw an exception which is caught by the JavaScript endpoint and displayed to the user.

Since we don't expect production sites to run with debugdeveloper, this should mean that production sites function as normal with the errors being logged to the web server log; whilst developer sites have information displayed to the user.

So, in summary, this is correct. There are a few changes I'd like to make (moving error_log to above the throw for example), but the code you highlight is spot-on.

Andrew

Same problem with our moodle test site (2.7).

susana