Troubleshooting

Unexpected Output while processing AJAX request

The following error can sometimes come up on the Site Administration menu (depending on your Moodle version):

Coding error detected, it must be fixed by a programmer:  
Unexpected output whilst processing AJAX request.  

This could be caused by trailing whitespace. Output received: ' '

What causes it is there is a new function in later versions of Moodle in lib/ajax/ajaxlib.php called ajax_check_captured_output.

This is a useful check for developers, and therefore when the site is in DEVELOPER debug mode it throws an exception. You can change the debug mode to something less than DEVELOPER and you shouldn’t get an exception (but note that there is still an underlying problem).

One catch is that if the site administration navigation is failing, you can’t actually get to Site administration > Development > Debugging.

An easy work around, visit https://your-moodle.com/admin/settings.php?section=debugging and adjust your debugging settings there.

Can’t create a new XMLDB file

The Moodle XMLDB plugin does some checks of the db/ folder in your plugin to ensure it has read/write access before allowing certain permissions (e.g. create and load). If it doesn’t find this, the text will appear but it won’t be a hyperlink.

Have a look in:

admin/tool/xmldb/actions/main_view/main_view.class.php

For example for the create button it will have:

 // The create button
                if ($dbdir->path_exists &&
                    !file_exists($key . '/install.xml') &&
                    is_writeable($key)) {

So the db directory needs to exist and be writable by the user running the Moodle instance (e.g. if using apache the user that apache runs as).

NOTE: set this permission correctly for the relevant web server user rather than doing something like chmod 777 and giving every one read/write/execute access which is a big security hole.

Site Stuck at Upgrade

If you encounter the following:

!!! Site is being upgraded, please retry later. !!!

This indicates that an upgrade is happening. This is normal, and is deliberate to prevent changes while the site is being upgraded.

Behind the scenes an entry is added into the database in the mdl_config table:

Howeever, sometimes a site will get stuck on this message indefinitely if there is a error with the upgrade process. In such cases you need to clear the upgraderunning entry out of the mdl_config table manually. Be careful here and make sure that an upgrade really isn't running.

Don’t forget to clear your moodle cache if you do happen to clear out the upgraderunning flag.

Plugin is Defective or Outdated

When upgrading you might see an error like this:

Default exception handler: Plugin "{block name}" is defective or outdated, can not continue, sorry. Debug: Self test failed. 
Error code: detectedbrokenplugin
* line 833 of /lib/upgradelib.php: plugin_defective_exception thrown
* line 425 of /lib/upgradelib.php: call to upgrade_plugins_blocks()
* line 1639 of /lib/upgradelib.php: call to upgrade_plugins()
* line 465 of /admin/index.php: call to upgrade_noncore()

To see what self tests are occuring check the relevant class for the _self_test() function for example in blocks/moodleblock.class.php. The plugin needs to meet all the relevant criteria e.g. a title, appropriate content, applicable formats, preferred width etc.

Office 365 Email Settings

A few tips when configuring an Office 365 email account for your SMTP server settings in Moodle:

Site administration > Server > Email > Outgoing mail configuration
  1. You will need the port 587 as part of your SMTP host (as the port is not a separate setting).
smtp.office365.com:587

  1. SMTP security should be set to TLS

  2. SMTP Username will be the full email address of the Office 365 account.

  3. Your SMTP username and no-reply address need to be the same. You can configure the no reply address under No-reply and domain settings.

  4. Use the the test outgoing mail configuration option to test. You can also use messaging between users or the forgot password functionality.

SCSS Max Execution Time Reached

If you have a site where the theme is not displaying correctly and you have confirmed it is not related to problems loading CSS (e.g. not securely over https), then you might be seeing an error like this in the logs:

Maximum execution time of 12 seconds exceeded in lib/scssphp/Compiler.php on line 4248
[08-Jul-2020 11:04:25 Australia/Melbourne] PHP Stack trace:
[08-Jul-2020 11:04:25 Australia/Melbourne] PHP   1. {main}() /theme/styles.php:0

If that's the case, try the following. First in config.php you'll need to increase the execution time by adding the line towards the top. Note this is a good way to introduce any other PHP settings to Moodle.

ini_set('max_execution_time', 600);

Second, run the admin/cli/build_theme_css.php CLI tool. This will use the max_execution_time in config.php and eventually build the the theme CSS.

Note, it can take a long time so set this to a high enough value e.g. at least a few minutes. I used 300 (5 mins). Also this didn't work from the browser, only the CLI.

Make sure you remove the max execution time setting from config.php when you are done!

Collation is not valid for character set

If you get an error like this when saving data (e.g. creating a new user):

COLLATION 'utf8_bin' is not valid for CHARACTER SET 'utf8mb4'

It means you need to fix the collation on your database tables (MySQL/MariaDB). The easiest way is with the mysql_collation.php CLI script:

For example to change all tables back to utf8_bin to match this requirement:

php admin/cli/mysql_collation.php --collation=utf8_bin

Note if you are trying to move to utf8mb4 you need to adjust your database server collation settings accordingly.

The data source class does not exist

If you get the following during an upgrade, particularly from early Moodle 3.x versions to later, it means you need to first remove the cache and localcache folders in your data directory.

!!! Coding error detected, it must be fixed by a programmer: The data source class does not exist. !!!
!!
Error code: codingerror !!
!! Stack trace: * line 506 of /cache/classes/definition.php: coding_exception thrown
* line 534 of /cache/classes/helper.php: call to cache_definition::load()
* line 493 of /cache/classes/helper.php: call to cache_helper::purge_store()
* line 175 of /admin/cli/upgrade.php: call to cache_helper::purge_all()

Error opening language pack (incorrect string value)

If you get an error like this when opening the language pack, it is indicating that your database, database tables (particularly mdl_tool_customlang) or your config.php is not using an utf8mb4 collation. For example utf8mb4_general_ci.

Debug info: Incorrect string value: '\xF0\x9F\x91\x8B' for column 'original' at row 1
INSERT INTO mdl_tool_customlang 
(lang,componentid,stringid,original,master,timemodified,outdated,local,timecustomized) 
VALUES(?,?,?,?,?,?,?,?,?)
-- line 1408 of /lib/dml/mysqli_native_moodle_database.php: 
call to mysqli_native_moodle_database->insert_record_raw()
[array (
0 => 'en',
1 => '1',
2 => 'welcomeback',
3 => 'Welcome back, {$a->firstname}! 👋',
4 => 'Welcome back, {$a->firstname}! 👋',
5 => 1685932707,
6 => 0,
7 => NULL,
8 => NULL,
)]
Error code: dmlwriteexception

You can fix the database tables using the tool (e.g.):

admin/cli/ php admin/cli/mysql_collation.php --collation=utf8mb4_general_ci

Don't forget to also set your database to the correct collation.

Finally, you need to check what you have set in config.php as well e.g.

$CFG->dboptions = array (
  'dbpersist' => 0,
  'dbport' => '',
  'dbsocket' => '',
  'dbcollation' => 'utf8mb4_general_ci',
);

If the config.php file is still using something like utf8 you'll need to update it AND clear the cache. For this to take effect.

Illegal Mix of Collations

If you receive an error like this:

Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) 
for operation '='
INSERT INTO mdl_scorm_scoes_value (attemptid, scoid, elementid, value, timemodified)

It is indicating that you have tables with different collation types in your database e.g. utf8_unicode_ci vs utf8_general_ci

You'll need to change them all to the same type using the mysql_collation.php CLI tool:

e.g. change them all to utf8_unicode_ci.

php admin/cli/mysql_collation.php --collation=utf8_unicode_ci
Converted: 168, skipped: 1663, errors: 0

Moodle File Picker Upload Fails

When using the Moodle file picker, if the upload button just spins and won't upload a file, then there could be an issue with the Apache X-Frame settings.

If you turn on your web browser developer tools console, you might see the following errors:

Refused to display 'https://yourmoodle.com' in a frame because it set 'X-Frame-Options' to 'deny'.

Along with something like this:

yui_combo.php?rollup…dlesimple-min.js:28 Uncaught SecurityError: 
Failed to read a named property 'document' from 'Window': 
Blocked a frame with origin "https://yourmoodle.com" from accessing a cross-origin frame.

This indicates that you have your X-Frame-Options set to DENY instead of SAMEORIGIN in your Apache SSL configuration.

For example in Ubuntu, take a look at the file: /etc/apache2/conf-available/ssl-params.conf

If you see the following line:

 Header always set X-Frame-Options DENY

Change this to:

 Header always set X-Frame-Options SAMEORIGIN

An Apache restart (or graceful restart) will be required.