Moodle Bug: No Combined Fields With Formatting In Formulas

Hey everyone!

We've got a bug report here that's pretty interesting, and it has to do with how Moodle handles combined fields when you're formatting numbers or units in the Formulas question type. Let's dive into the details and see what's going on.

Description of the Bug

So, the issue is that when you try to combine number and unit input fields with custom formatting, Moodle isn't playing nice. Instead of creating a single, combined input field, it's showing them as two separate fields. This happens even when there's no space between the placeholders, which should tell Moodle to combine them. It was spotted by the awesome @dbauer-ets, so big thanks to them for bringing this to our attention!

Let's take a look at the code snippets that are causing the trouble:

{_0|w=34px|bgcol=red|txtcol=#FFF|left}{_u}
{_0}{_u|w=40px|bgcol=#66F|txtcol=yellow|left}

In both of these cases, you'd expect a single input field where the number and unit are combined. But instead, you get two separate boxes. Not ideal, right?

Why This Matters

This might seem like a small issue, but it can really affect the user experience. Imagine you're creating a quiz question that asks students to enter a value with a unit (like "10 cm"). If the number and unit are in separate fields, it can be confusing and lead to errors. We want to make things as clear and straightforward as possible for our students, so fixing this bug is important.

Digging Deeper

Now, the tricky part is figuring out what the correct behavior should be. Should Moodle automatically combine these fields when formatting is applied? Or should we introduce a new, specific placeholder for combined fields with formatting? That's the million-dollar question!

One suggestion is to create a dedicated placeholder for combined fields when you want to use custom formatting. This would keep things explicit and avoid any ambiguity. We could then reserve the legacy format {_0}{_u} for unformatted fields only. This approach might give us more control and prevent unexpected behavior in the future.

Understanding the Current Behavior

Currently, Moodle's Formulas question type is designed to combine input fields when placeholders for numbers ({_0}, {_1}, etc.) and units ({_u}) are placed directly next to each other without any intervening spaces. This is a neat feature that simplifies the input process for students, allowing them to enter a numerical value and its corresponding unit in a single field. However, this behavior seems to break down when custom formatting is applied to either the number or unit placeholder.

When formatting is introduced using the pipe symbol (|) followed by formatting options (e.g., {_0|w=34px|bgcol=red}), Moodle appears to treat the placeholders as distinct entities, preventing them from being combined. This results in two separate input fields, one for the number and another for the unit, which deviates from the expected behavior. It's like Moodle is saying, "Okay, you want formatting? Then you get separate fields!" which isn't quite what we want.

Exploring the Technical Details

To understand why this is happening, we need to delve into the code that handles these placeholders and their formatting. It's likely that the formatting logic is interfering with the combination logic. Perhaps the formatting options are being parsed in a way that separates the placeholders, or maybe the combination logic isn't designed to handle formatted placeholders. Whatever the reason, it's clear that there's a conflict between these two features.

One potential area to investigate is how Moodle's rendering engine processes the placeholders. It might be that the formatting options are causing the engine to create separate HTML elements for each placeholder, which would naturally result in separate input fields. Alternatively, the JavaScript code that handles the combination of fields might not be recognizing the formatted placeholders as candidates for combination.

The Importance of Consistency

Consistency is key in user interface design. When a feature works in one way under certain conditions but differently under others, it can lead to confusion and frustration. In this case, the inconsistent behavior of combined fields with formatting is a usability issue that needs to be addressed. Students should be able to rely on the fact that if they place a number and unit placeholder next to each other, they will get a combined field, regardless of whether formatting is applied.

The Path Forward

So, what's the best way to tackle this bug? Well, as mentioned earlier, there are a couple of options on the table. We could try to modify the existing combination logic to handle formatted placeholders correctly. This would preserve the current behavior for unformatted fields while extending it to formatted fields. However, this approach might be complex and could potentially introduce new bugs.

The other option is to introduce a new placeholder specifically for combined fields with formatting. This would provide a clear and explicit way to create these fields, avoiding any ambiguity. It would also allow us to keep the legacy format {_0}{_u} for unformatted fields, minimizing the risk of breaking existing questions. This approach might be cleaner and more maintainable in the long run.

Proposed Solutions and Next Steps

Let's brainstorm some potential solutions and figure out the best way forward. Here are a couple of ideas:

1. Modify the existing logic: We could try to tweak the code that handles placeholder combination to correctly handle formatting. This might involve adjusting how the formatting options are parsed or how the fields are rendered.
2. Introduce a new placeholder: We could create a new placeholder syntax specifically for combined fields with formatting. For example, we could use something like {_c0|w=34px|bgcol=red|txtcol=#FFF}{_cu|w=40px|bgcol=#66F|txtcol=yellow|left} to indicate a combined field with custom formatting for both the number and the unit.

Option 1: Modifying the Existing Logic

This approach would involve diving into the existing codebase and identifying the specific areas that handle placeholder combination and formatting. The goal would be to modify the logic in such a way that it correctly combines formatted placeholders without breaking the behavior for unformatted placeholders. This might involve changes to the parsing of formatting options, the rendering of input fields, or the JavaScript code that handles field combination.

One potential challenge with this approach is the complexity of the existing code. Moodle's codebase can be quite intricate, and making changes in one area can sometimes have unintended consequences in other areas. Careful testing would be essential to ensure that the modifications don't introduce new bugs or break existing functionality.

Another challenge is maintaining backward compatibility. We want to ensure that any changes we make don't break existing questions that rely on the current behavior. This might require adding conditional logic to handle different cases or introducing a migration process to update existing questions.

Option 2: Introducing a New Placeholder

This approach would involve creating a new placeholder syntax specifically for combined fields with formatting. This could be a more straightforward solution in the long run, as it provides a clear and explicit way to create these fields. It also avoids the need to modify the existing combination logic, which could reduce the risk of introducing new bugs.

The new placeholder syntax could be designed to accommodate formatting options for both the number and the unit. For example, we could use a syntax like {_c0|w=34px|bgcol=red}{_cu|w=40px|bgcol=#66F} to indicate a combined field with custom formatting for both the number and the unit. The _c0 placeholder would represent the formatted number input, and the _cu placeholder would represent the formatted unit input. The c prefix could stand for "combined," making it clear that these placeholders are intended to be used together.

One potential drawback of this approach is that it would require users to learn a new placeholder syntax. However, this could be mitigated by providing clear documentation and examples. The new syntax could also be designed to be intuitive and easy to remember.

Evaluating the Options

Both of these options have their pros and cons. Modifying the existing logic might be more challenging but could preserve the current behavior for unformatted fields. Introducing a new placeholder might be simpler in the long run but would require users to learn a new syntax.

To make the best decision, we need to carefully evaluate the technical complexity of each option, the potential for introducing new bugs, the impact on backward compatibility, and the usability of the solution. It might also be helpful to get feedback from users and developers on which option they prefer.

The Importance of Testing

No matter which approach we choose, thorough testing will be crucial. We need to test the solution with a variety of different questions and formatting options to ensure that it works correctly in all cases. We also need to test it on different browsers and devices to ensure that it's compatible across platforms.

Testing should include both automated tests and manual tests. Automated tests can help us catch regressions and ensure that the solution continues to work as expected over time. Manual tests can help us identify usability issues and ensure that the solution is intuitive and easy to use.

Let's Discuss!

I'm not entirely sure what the best course of action is here. What do you guys think? Should we try to modify the existing behavior, or is it better to introduce a new placeholder? Let's chat about it and figure out the best way to tackle this issue. Your insights and suggestions are super valuable!

Thanks again to @dbauer-ets for spotting this!

TL;DR: Moodle's Formulas question type isn't combining number and unit fields when formatting is applied. We need to figure out how to fix it – should we tweak the existing code or introduce a new placeholder? Let's discuss!