Are you sure it's saved ? Last time i check : nothing seems saved on user settings.

Yes, that's what we are seeing

Yes, see the other mantis after (i think i already reported it :( )

Somehow there is a missmatch in between the core question theme and the names of the core question themes.
Ex: Short free text question theme is core and its name is shortfreetext. Usually core is used on the code, but on the data and the model the name is shortfreetext.

Question themes have a name, like 'arrays/array' or 'bootstrap_buttons'.
There are base (core) question themes and extended question themes (custom or included with Lime).

Some parts of Lime only handle the question themes by name, and treat the core themes as "core" (instead of by their name).

For example, when handling question attributes, it's usually done by question type and question theme name, and 'core' is used as theme name for the basic ones.
That also applies to the question type/theme selector.

The specific problem with this ticket is that question type/theme metadata for the selected question (to mark the selected question type/theme in the selector) is retrieved with QuestionTheme::findQuestionMetaData(), which returns the "real" question theme data, including the saved name.
Since the selector has a list of question type + theme pairs where the theme is 'core' for the basic ones, but the question metadata has the actual theme name ('arrays/array', 'longfreetext', etc), no question type/theme is marked as selected (defaulting to the first one.

It's temporarily solved in T656 by replacing the theme name after retrieving the metadata.

Alternative better approaches follow:

Alternative A) Make the replacement inside findQuestionMetadata(). Other parts of Lime using that function don't rely on the theme name, so it wouldn't have an impact. But, the function is public, so it may be used by third party code.

Alternative B) Make a clone of findQuestionMetadata() adapted for returning "core" sometimes.

Alternative C) Review the usage for findAllQuestionMetaDataForSelector() and make it match to findQuestionMetadata().

Thoughts? @ollehar

Alternative A) … … so it may be used by third party code.

Young code, out of any API : don't really care, no ?

If you think of « it may be used by third party code» : you don't create i10n function like this.

Somehow there is a missmatch in between the core question theme and the names of the core question themes.
Ex: Short free text question theme is core and its name is shortfreetext. Usually core is used on the code, but on the data and the model the name is shortfreetext.

Can you give some example where this happens? There might be a hack present, not sure.

There are three types of question themes:

• core - the basic core themes included in the github repo
• custom - question theme included in repo but which extends a core theme
• user - question theme NOT included in repo but which extends a core/custom theme (so installed by the user)

Whenever you see "core", the variable should probably be called $questionThemeType.

Just a NB about "findQuestionMetadata" - this function shouldn't exist. It should be $question->question_theme->config->metadata.

Questions have no metadata, only question themes do (and all other extensions like survey theme and plugins). There's some conceptual confusion here I want to sort out together with Patrick as soon as he's finished with encryption (again).

About "findAllQuestionMetaDataForSelector", not sure this should exist either. :) More like

array_map($questions, function($q) { return $q->question_theme->config->metadata; });

Much could fall into place if we add a new class Metadata and a method "getMetadata" to ExtensionConfig class.

About this line:

        $baseQuestion['settings'] = json_decode($baseQuestion['settings']);

This is a sign of lack of abstraction between view, logic and data. There should be a method "getSettings" that does the conversion. Actually, settings should not be part of metadata at all, because metadata should be identical between all extension types (plugins etc). Again some domain confusion.

This lack of separation is throughout the entire question theme system, sadly.

Possibly a new class QuestionThemeExtensionConfig extending ExtensionConfig could have method getSettings.

From Olle:
Maybe the question_theme column (#17350) to lime_questions table could be done before?
Then we could have proper ORM code like: $question->question_theme->config->metadata

Waiting for #17350 to be finished to reassess this