Glossary auto-linking breaks stack q type

[MaskwaSam]

I was hitting my head against the wall trying to get stack Q type to work, updated to the newest version, self hosted server and newest stack q type on Moodle. I found that when I disable glossary auto linking, the questions would work again! In my organization the glossary autolinking helps with incorporating a second language in my courses so it is inconvenient to lose this feature by disabling the vanilla filter. Thank you for all the work you do!

[aharjula]

Just to confirm that we don't have a new issue here, by "trying to get to work", are you talking about having the output not getting mangled/broken, or did it have other issues blocking any output?

Unfortunately, STACK has very limited means available to it when dealing with filters applied to the output of STACK by the VLE around us. We have the need to output equations, and we do that in LaTeX, which is then handled by outside filters. And if someone touches that LaTeX before it reaches those filters or even after they have worked with it, then those parts may break.

Among the traditional examples of this, we have:

• having multiple (La)TeX filters active, fighting each other
• some emoticon filter turning notation to emoticons
• various auto-linking filters targeting names of LaTeX macros like cos or sqrt, LaTeX presentation rarely survives having raw HTML, like a link, inside it
• localisation filters not liking LaTeX filters or emoticon filters... Typically, the guideline for localisation is to do it as the first filter.

In some cases, where filters fight simply being sane and not having multiple (La)TeX filters active at the same time works, and sometimes ordering of the filters may solve issues, but we cannot work with filters that do not understand context well enough to leave LaTeX bits alone and as far as I am aware there is no marker notation in the Moodle filter system to mark regions of output as something that should be left unfiltered by one type of filter but still filtered by another.

In reality, the closest one can get with STACK + those filters co-existing on a course is to have them active in the course but not in the quizzes where STACK is active. Luckily, one can tune filters at the quiz level, but obviously, that will be something people will forget, and there will be issues if parts of the quiz would really benefit from those filters.

In theory, STACK could find some way to completely disable some hard-coded filters inside STACK questions, which might cause some extra confusion for the maintainers of said filters. As long as the filters assume that what they filter is just HTML (although most of them do not even understand that, just for fun, try adding spanor div to whatever listing the auto-linker uses as its keywords), they will break LaTeX and will also cause issues elsewhere on the course and one would assume that if you need STACK you might also have equations elsewhere...

[sangwinc]

Yes I agree with @aharjula here completely. If you can provide us with more details, e.g. exactly which filters you have and in what order and much more specific details of the problems then we can look into this. No promises we can do everything: some filters may be just simply incompatible, and @timhunt may have encountered examples here. What we can do is document known problems, any solutions (filter order is often effective) and possibly change some things in STACK to widen the range of supported combinations.

I don't use glossary so haven't encountered this issue.

[MaskwaSam]

Holy moly! Thank you for your response! I will try to give details and I will make sure to tell my team this limitation.

Here is what I get when the filter is on.

Here is glossary auto-linking filter off.

Definitely something I am happy to have figured out, as STACK is great for my use case. I did not think to turn off the filters and did not know that the filter could do such an effect.

Here is my filter list.

[sangwinc]

Thanks @MaskwaSam that's helpful to know. That error is coming from STACK (renderer.php). We'll take a look.

[aharjula]

Well, the "error" comes from the placeholders, which mark the bits that need special extra filtering, and they're going missing. Basically, [[input:ans1]], [[validation:ans1]] and [[feedback:prt1]] style things and the reason why they traditionally went missing was localisation filters either losing them entirely or leaving multiple copies due to multiple languages being displayed at the same time.

I guess that in this case, the glossary might have terms like "input", "validation" or "feedback", and that is the reason it would impact the placeholders.

The problem is that we need to have placeholders, and if they end up matching some arbitrary filter, we will break. However, in this particular case, the logic could be adjusted, and we could change those placeholders at that phase of processing to be something less likely to match common words. I am sure that in the modern world, we could mix some Unicode letters from some almost dead languages to generate some interesting combinations that would not match names or words in any glossary, dictionary or course activity name. That should work as long as the filters do not include any logic that destroys such Unicode.

In any case, that last screenshot has the filter ordering, and I would really recommend talking to your Moodle admin about that "Multi-language content" filter's position in that list. The ordering is a system-level setting and needs an admin to tune it. And in this case, that should be at the very top of the list. For two reasons:

1. That particular filter is sensitive of <span> -tags matching and, at the same time, unaware of the possibility of nested tags. And in your filter list, there are filters that generate <span> tags, which may confuse that filter.
2. A language filter, like that, essentially cuts down the content by dropping parts that are not in the desired language, and if you do that early, no other filter needs to work on the parts that will be dropped. Thus, having it first saves memory and CPU cycles and thus the world by saving energy.

[sangwinc]

Minimal way to reproduce this error.

1. Turn on glossary auto linking at the site level.
2. Add a glossary to the course
3. Add a glossary entry "input" and activate the autolink.

This is, admittedly, a bit of an edge case but salting the word "input" and "feedback" before processing the question text with moodle's "format" command should fix this.

[aharjula]

@sangwinc , any reason why you did not also do that for validation it is after all being replaced at the very same phase of processing, in the same loop as those input ones? In any case, we can never be sure that someone does not filter out some key part of the document syntax, but this should cover some more likely situations. Hopefully, no one adds ans1 to their glossary or has a term like prt1 in there (both of those are terms in genome databases, and surely elsewhere as well).

As a cautionary tale, all auto-linking filters are dangerous. Back in the day we had a case where someone lazily named quizzes as something like "1.1" and so on. Then they had questions with random numerical data... LaTeX matrices don't like when numerical values inside them turn to links. That was hard to track as it triggered only when random parameters matched the activity names, after that we have kept the "Activity names auto-linking" filter off, if we need to link to parts of the course we recommend doing that by hand instead. And in any case, does one need to link between singular courses activities so much that a filter is required?

[sangwinc]

Thanks @aharjula, yes I should add in the validation tags. I also agree these autolinking plugins are essentially an insoluble problem. This commit is a sticking plaster, not a sound solution.

@timhunt is there any way we can disable particular filters at this point?
https://github.com/maths/moodle-qtype_stack/blob/master/question.php#L2332

If we can blacklist certain filters within this particular plugin, that's probably a logically much more sound way to proceed.

[aharjula]

The real solution would not be to blacklist anything. If we knew enough about the capabilities and roles of all the filters and had secure placeholders provided by the filter system, we could support almost* all filters.

The first thing that we would need is some metadata from the filter system to help us in choosing how to deal with a particular filter. If we knew that a particular filter is a (La)TeX-filter of some kind, we could, in theory, preprocess (we would hide sensitive things behind placeholders) our content so that other filters would see everything else, and that filter would see the TeX filter bits (after all, we already have logic that knows, or can be used to check, which bits of our output are LaTeX). It would be handy if filters had such declared types; otherwise, we would need to keep a list in our code base, and anyone building their own new filter could not directly use the default STACK, as the hard-coded listing would not contain their own custom filter.

But we could not even do that safely unless the filter system also provides some method to have a universally safe placeholder format (or better yet, a generator providing such placeholders) that no filter ever modifies (although a lang filter might drop the whole thing if it is inside a lang block and so on). Otherwise, we can only hope that whatever sequence of symbols we generate as a placeholder for content being hidden from a particular type of filter is not being mangled by some filter.

If we had those two features in the filter system, we could then execute all non-LaTeX filters in their normal sequence and target the LaTeX filter on the LaTeX bits we secured behind placeholders. And naturally, like in the plaster in this issue, we would also use safe placeholders for our own placeholders during that filtering.

Both of those requirements would require some large changes in the Moodle-filter system, and that would only be Moodle; the same thing would need to apply to other VLEs as well. Seems somewhat unlikely, but on the other hand, we are not the only plugin that needs to handle input sanitisation and separation from the normal filter chain, nor the only one that outputs LaTeX or other syntax sensitive to filters. So maybe those features could make sense to actually have. Otherwise, plugin creators will always need to juggle between being good people who allow filters to do their thing, or just don't allow them at all, or just some of them.

(*) The "almost all" at the start, is due to filters that might move content out of the normal stream (onto JS side and so on) and with those, we might lose access to the content and could not replace the placeholders in them.

[timhunt]

Let me start with where this thread started: "In my organization the glossary autolinking helps with incorporating a second language in my courses so it is inconvenient to lose this feature". These filters may be annoying for developers, but they exist for a good reason: they provide good features for teaching.

Anyway, ther code we have currently is purely defensive: it detects whether the filters have messed up things STACK cares about, but it does not try to prevent that. Other question types take a more active approach, e.g. https://github.com/moodle/moodle/blob/992949915d22d2a2d3bee19e19ab5888350a3ae4/question/type/multianswer/renderer.php#L50

That replaces the signgificant syntax in this question type (in STACK that would be the [[input:ans1]] etc) with almost certainly intert 'tokens' that look like <span class="nolink">qtypemultianswer12marker</span>, then calls format_text, then replaces the tokens with the real content (which has been collected in a $subquestions array here).

And, that is basically what was suggested above. There is no 100% perfect theoretically safe placeholder, but in practice, there are ones that are good enough. In Moodle <span class="nolink"> is the way to tell filters not to mess with that bit. (But, does that work given STACK's insistance on using Markdown rather than HTML? Probably yes.)

[aharjula]

Tim, what insistence on Markdown? Since CASText2 the whole content has been converted back to HTML before it ever reaches the filters? No matter what formatting the question definition used originally. Well, that does not matter.

You are basically saying that we need to use placeholders, and there are no universally safe ones. Can we "mine" for them, i.e., push some candidates through the current full filter chain and see which ones stay clean with the current filters? Or would that cause unwanted side effects? Basically, if some of the candidates trigger some filter that might cause JS-side effects or trigger loading something extra to the $PAGE, is there any method we could use to block such side effects if they exist?

And then the issue of protecting content from one class of filters but not some other one. Basically, if we want to protect LaTeX from all non-LaTeX filters, but still execute the LaTeX filter (there should only be one active, but it is not necessary always MathJax) on it. We need to dig out the list of active filters and detect the LaTeX filter from that, and then apply that separately on the protected bits.

[aharjula]

... In Moodle <span class="nolink"> is the way to tell filters not to mess with that bit. ...

Ok. So tracing that back (in 5.1.3) the filters that use filter_phrases() in their logic respect those tags (Activity, Database and Glossary auto-linking and H5P) should be fine if we use that wrapping. The Emoticon-filter and URL-to-link also have their own logic for respecting those tags. Other core filters do not seem to have such logic. Also multiple filters add that wrapping on the parts they affect to protect those results from other filters, including MathJax so if one places MathJax above filters respecting those tags then one won't suffer auto-links or emoticons in equations.

So if our placeholder key includes that wrapping it would be safe from the core auto-linkers and emoticons. That should lessen the risk of the placeholder getting mangled.

Bit worried on the extra </span> we would generate that early in the process affecting the multilang-filter (when people use the <span lang="xx" class="multilang"> syntax) but we cannot avoid all issues and people should really use something else in STACK.

[sangwinc]

Thanks @timhunt I really didn't know about nolink and something like <span class="nolink">qtypemultianswer12marker</span> is a great place to start.