Tim Hunt

One of my colleagues just pointed this out to me:

Almost everywhere else in Moodle where students can upload files, there is a way for the teacher to set a maximum allowed file size. This is not possible for Essay questions. (As far as I can see from checking the code, it just uses the site-wide file upload limit - $CFG->maxbytes.)

Presumably it would be sensible to add an option on the form for creating essay question?

Yesterday I hit a tricky situation with profiling, and I just wanted to write it up where other people might see what I learned.

The situation was that since we upgraded our development environment to Moodle 3.8.2 (from 3.7.x) some of our Behat tests were failing because of hitting the PHP 30-second time-limit, and this was happening in in the minfiy library. We realised that this was it minifiying the CSS for our theme.

Profiling theme/styles.php

So, I wanted to profile (as in https://docs.moodle.org/dev/Profiling_PHP) theme/styles.php. However, that did not work, because that script sets ABORT_AFTER_CONFIG for performance reasons.

This caused Mark Johnson to tell me about $CFG->earlyprofilingenabled = true; which is worth knowing about. (The link there goes to where it is documented in config-dist.php.) However, that did no good. It still does not let you profile ABORT_AFTER_CONFIG scripts.

Then, thanks to a hint from Andrew Nicols, I just hacked the code in theme/styles.php to remove the ABORT_AFTER_CONFIG. It is not quite as simple as that, because the script uses functions like min_clean_param, so I then needed to add a manual require_once of lib/configonlylib.php, and also, lower down the script where it goes in to define('ABORT_AFTER_CONFIG_CANCEL', true);. I had to comment out that bit to prevent errors.

However, with those things done I got the profiling done, and found that almost all of the 40-second execution time (when it was re-building the CSS after the theme cache had been cleared) was due to calls from the minify library to preg_match and preg_replace.

Finding the issue in minify

So, then the question was, which preg calls in minify were causing the bad performance? The only way I could think of to do this was to add some debug code in the library, to count and time the preg_calls with different regexes. That lead to the first half of this patch. For each regex match, we write the number of times it is used, and the total time taken to a comment at the top of the minified PHP.

Then, for using that, it was a major pain that Moodle agressively caches the mified CSS. So I went through the relevant code relentlessly hacking if statements so that it never used the caches and always did the minifying. This meant that I could open the direct URL to the CSS in my browser, and just keep pressing F5 to reload as I changed things. That is the second part of the patch.

(As an aside, it is often worth putting in a little bit of extra effort in code like this whch you will later throw away, to make the feedback cycle as short as possible while you are working on the code changes that you want to keep.)

So, anyway, it then became really obvious which the problem regex was, and I was able to fix it. For the rest of the story (which is not finished yet), see https://github.com/matthiasmullie/minify/issues/317 and MDL-68191

Hope this is at least vaguely useful/interesting to someone.

I was not sure whether to post in Testing forum or here. Anyway, if you write Behat tests for your plugin, you might want to read https://moodle.org/mod/forum/discuss.php?d=395721. Thanks.

Not sure if I have posted about this before, but I thought it would not hurt to post again. In Moodle 3.8.1, 3.7.4 and 3.6.?, we have three new ways that plugins can hook into Behat, to make it easier and more efficient to write Behat tests for your plugin:

1. Plugins can now hook into Moodle’s And the following “blah” exist: step.
   
   Probably easiest to work out how to do this by looking at an example. Here is one from the quiz:
   
   To make this
       Given the following "mod_quiz > group overrides" exist:
         | quiz           | group | attempts |
         | Test quiz name | G1    | 2        |
   work, well, first you need code in class mod_quiz_generator extends testing_module_generator to create that sort of thing. Then you need a new class like class behat_mod_quiz_generator extends behat_generator_base which says how to map from the data in the Behat step to a call to the generator.
   
   General documentation for how to do this is in the class comment on  behat_generator_base: https://github.com/moodle/moodle/blob/265296a26e0400faa733b3f849029191c0d45ed0/lib/behat/classes/behat_generator_base.php#L32 
   
   Of course, you could always make completely custom steps to generate set-up for your tests, but hopefully being able to hook into the standard Moodle method lets you do with less code and more standardisation.

2. Similarly, plugins can how hook into ‘Named selectors’, which are what makes the steps like And I click on "Add" "button" in the "Competency picker" "dialogue" work. In that step, ‘button’ and ‘dialogue’ are selectors, and now you can define ones specific to your plugin. E.g. we could define a selector like “mod_forumng > Post”.
   
   To do this, you basically have to say how to convert from the selector info in the Behat step into an XPath. Here is an example from Moodle core. This time the extra code you would need to write goes in the class like behat_mod_forumng that probably already exists. You need to override an extra method get_partial_named_selectors.
   
   Again, the best docs are in the PHP docs.

3. Finally, there are two new steps:
   
   When I am on the "Quiz 1" "mod_quiz > View" page
   When I am on the "Quiz 1" "mod_quiz > View" page logged in as "student"
   
   The point of the first step is to let you start on the page you want to test, without having to navigate through a bunch of irrelevant pages (which takes time, and which might break if they every change parts of Moodle outside your plugin). The point of the second step is that if you use the old When I log in as "student" step, that takes you to the Moodle ‘Dashboard’ page which is really slow to load, and so logging in and going straight to the page you want to test is faster.
   
   To make both steps work, you just have add an override for one method to the existing behat_mod_forumng class. Example here: https://github.com/moodle/moodle/blob/87252eae2cb8edacc2e31f518ff4491c122be141/mod/quiz/tests/behat/behat_mod_quiz.php#L60 and docs here: https://github.com/moodle/moodle/blob/MOODLE_37_STABLE/lib/behat/behat_base.php#L1083.

I expect that most people won’t have time to update most old Behat tests to use these tings, but we should probably start using them for new tests.

I guess this is the place to find helpful usability people who might like a challenge.

It seems that, for a significant minority of users, it is not obvious how to do step 2 of the following:

1. They already have 20 questions in the question bank.
2. They want to create a quiz that give 10 different questions picked at random for each student.