-
Bug
-
Resolution: Fixed
-
Minor
-
4.2.7, 4.3.4
-
MOODLE_402_STABLE, MOODLE_403_STABLE
-
MOODLE_402_STABLE, MOODLE_403_STABLE
-
This is not something that is used by core qtype_multichoice itself, but it was a hook that was added to enable derivative question types (initially qtype_oumultiresponse, but more recently qtype_answersselect) more nuanced control of what feedback is visible.
The general way this sort of thing is controlled in the question system is through a class called question_display_options (which is often stored in a variable called $options is related code), which helps glue the various parts of the system (quiz or whatever, core_question, qbehaviour_, qtype_) together.
The specific problem we have here is that $options->feedback is not fine-grained enough on its own. ->feedback in general controlls "Specific feedback - that is feedback that depends on the particular answer the student gave." The problem is that qtype_multichoice has two sorts of feedback that fits in this category, and some derived qtypes want to control them independently (for good educational reasons).
For over 10 years this has worked by setting an un-declared property ->suppresschoicefeedback - but in PHP 8.2 that causes "Deprecated: Creation of dynamic property question_display_options::$suppresschoicefeedback is deprecated in ...".
I now realise that a better variant of this hack is to instead have a special value of $options->feedback that is neither question_display_options::HIDDEN nor question_display_options::VISIBLE (1). qtype_multichoice can have qtype_multichoice::COMBINED_BUT_NOT_CHOICE_FEEDBACK. (And, this hack would then be similar to the special values like qbehaviour_interactive::TRY_AGAIN_VISIBLE which that question behaviour users to do subtle things.
Can this be implemented in a backards-compatible way? I will find out..
