[DEPR]: Legacy Problem Editor

[kdmccormick]

Please first read the parent DEPR ticket, [DEPR]: All Legacy Studio Frontends.

RFC Start Date

2025-02-19

Target Plan Acceptance Date

2025-03-14

Target Transition Unblocked Date

2025-11-14

Target Breaking Changes Unblocked Date

2025-12-14

Earliest Open edX Named Release Without This Functionality

Deprecated but available (via opt-out) in Teak. Opting out will also require opting out of the new Unit editor and using the deprecated legacy Unit editor, which will lack some Content Libraries features.

Full removal lands in Verawood.

Rationale

The legacy ProblemBlock (aka "CAPA") editor is based on outdated frontend technologies that do not integrate well with the new React-based Studio micro-frontend. There is a newer React-based editor that replaces it. Supporting both editors is a major burden for maintenance and feature development.

Removal

The old pop-up modal Problem editor will be removed.

Replacement

The React-based Problem editor is the replacement.

Deprecation

We will warn about the pending deprecation in the Teak release notes.

Migration

N/A

Additional Info

N/A

Task List

Remove the LEGACY_STUDIO_PROBLEM_EDITOR waffle flag.

Remove the legacy problem editing UI (defined in edx-platform, ProblemBlock.studio_view) and all orphaned supporting code.

[kdmccormick]

@pdpinch , here's a DEPR for the old Problem editor as we discussed. You mentioned that there were more Problem-specific editor concerns--let's collect those here.

[SIdnani]

Some more specific feedback I have gathered comparing the Legacy Problem Editor to the MFE Editors:

1. Ease of Copy-Paste: The Legacy Editor(Basic or Advanced) allowed you to copy-paste entire problems from text-editors outside the platform to build assessment items. As opposed to the MFE editor that requires you to copy-paste assessment items line by line into a form. A 10-item MCQ quiz with a standard 4 choices and solution and 2 hints goes from 10 copy-pastes actions from an external design doc to the Legacy Basic Editor and becomes 80 copy-paste actions with the addition of extra clicks to select the "correct" answer. This is a huge waste of time and will create errors.
2. The building everything as a form is only useful to folks as a learning aid, the first time they attempt something. After that, bulk building becomes the norm. Not one Instructional Designer or SME across all the institutions I have worked ever wrote content in the CMS of any LMS. So the forms required to build items makes them shy away from building online assessments.
3. Instructional Designers (IDs) often use a multi-step assessment items to hit one learning objective. These items have 1 submit button. For example: Putting an image, e.g. A Graph, with significant areas labeled a, b, c, etc., then 3 text-entry, or 3 numerical entry, or 3 drop-downs asking learners to identify, categorize, or compute values for each of those indicated areas. Sometimes IDs mix assessment types (Drop-downs, MCQ, Text-Entry, Numerical Entry) within one problem to hit different parts of the same learning objective and grade them as one whole.
4. The Legacy Editor allowed multi-assessment items to be generated at the WYSIWYG-level vs. the MFE Editor that forces you through the process of creating only one problem with the form editor for non-technical users then you need to end up in the advanced editor to be able to do anything else. Note: You are required at that point to know the weeds of the XML to get the same problem created.
5. Flexibility of formatting: Legacy Advanced Editor allowed you to implement and preview inline. This meant that you could compare your changes against other items in the Unit and re-format problems using HTML on the fly. You are not stuck with the default formatting available to an individual problem.
6. All of the standard usability changes that applied to Text components applies here as well. Things like location within the course, publication status, and advanced editors require more effort to access when the new MFE editor navigates folks away from their content on the Unit page.

[kdmccormick]

Thank you @SIdnani. Noted on all counts.

[SIdnani]

This was possible in the Legacy editor because the modal wasn't fixed in the window. By scrolling the page, it's possible to remain in the editing state but still see other parts of the courses. So it's not a preview of the content currently being edited, but you can see other parts of the course page and make edits based on the context.

[kdmccormick]

Product proposals relevant to this feedback:

1. https://openedx.atlassian.net/wiki/spaces/COMM/pages/4517232656/Re-enable+Markdown+editing+of+CAPA+problems+to+meet+various+use+cases
2. https://openedx.atlassian.net/wiki/spaces/COMM/pages/4517920789/Help+course+authors+understand+the+context+of+the+text+and+problems+they+are+editing

[kdmccormick]

Communicated via: https://discuss.openedx.org/t/deprecation-removal-all-legacy-studio-frontends/15049

[pdpinch]

I think this bug is pretty serious and should be fixed before we remove the legacy problem editor: https://github.com/openedx/frontend-app-authoring/issues/1491. We're experiencing it on edx.org currently and it's another reason for us not to deploy the new problem editors to our other systems.

[kdmccormick]

Thanks, noted, I've added that bug to the list of items that need to be resolved before removing the legacy editor.

[pdpinch]

I think this is another issue that should be resolved, one way or another: Numerical Input Component Incorrectly Handles Formulas as numericalresponse (https://github.com/openedx/frontend-app-authoring/issues/1680)

[kdmccormick]

Thanks Peter, noted. Keep 'em coming.

[robrap]

[inform/request] This ticket was accepted under the old DEPR process. The updated Process States in OEP-21 help add clarity to communications and timing regarding the introduction of breaking changes. This ticket must move to Transition Unblocked before moving to Breaking Changes Unblocked. The default minimum time to wait in Transition Unblocked is 1 month, so early deployers have time to prepare. If you wish to make breaking changes in less than 1 month, please initiate discussions to negotiate a date as soon as possible. Thank you!

[kdmccormick]

^ This has been addressed. The ticket is in Transition Unblocked.

[kdmccormick]

As noted in the description, there are still known issues with the React-based problem editor:

• [ ] https://github.com/openedx/frontend-app-authoring/issues/1680
• [ ] https://github.com/openedx/frontend-app-authoring/issues/1491
• [ ] https://github.com/openedx/frontend-app-authoring/issues/1920
• [ ] https://github.com/openedx/frontend-app-authoring/issues/2073
• [ ] https://github.com/openedx/platform-roadmap/issues/447

Until we either fix those issues or decide that they are not blockers for deprecating the new editor, I've moving this ticket back from "Transition Unblocked" to "Plan Accepted". The new target date to resolve these issues and unblock the transition is 2025-08-14. Presuming we hit that goal, the target date to the remove the old editor remains as 2025-09-14.

[robrap]

Thanks @kdmccormick. [inform] Based on your comment, I added 8-14 as the Review After Date, and moved the ticket to the top of the column, ordered by this date. See https://github.com/orgs/openedx/projects/9/views/4.

[kdmccormick]

The issues noted in my comment above are still blockers for full removal. However, we have MIT ODL and WGU helping with them, and I expect we will be able to resolve all of them before the target removal date (Sep 14).

[kdmccormick]

@robrap @dianakhuang , could you check whether you still use the legacy problem editor on any of your environments?

[robrap]

@robrap @dianakhuang , could you check whether you still use the legacy problem editor on any of your environments?

@kdmccormick: I've passed on the request. Hopefully someone at 2U (or I) will let you know.

[robrap]

@robrap @dianakhuang could you check whether you still use the legacy problem editor on any of your environments?

@Faraz32123 @papphelix: Can you get 2U's answer to this question?

[Faraz32123]

We are not using legacy problem editor in any of our environments. From legacy pages, we are only using legacy unit page with flag legacy_studio.unit_editor. @kdmccormick @robrap

[kdmccormick]

Excellent, thank you for checking that.

In that case, we will coordinate directly with MIT ODL to see whether or not pre-Ulmo removal of the legacy editor is possible, pending the linked bugfixes.

[pdpinch]

whether or not pre-Ulmo removal of the legacy editor is possible, pending the linked bugfixes

It doesn't look like the bugfixes will make it before Ulmo.

MIT OL is going to need some more time to evaluate whether any of the linked bugfixes are blocking for us.

[kdmccormick]

[UPDATE] We are no longer targeting to remove the legacy Problem editor by the Ulmo cutoff, but we are still hoping to get as many of the linked bugfixes and enhancement into Ulmo as possible so that the vast majority of operators can smoothly use the new Problem editor. We plan to remove the legacy editor before the Verawood release.

[kdmccormick]

@pdpinch As we discussed in Maintenance WG, I'm looking to the MD formatting buttons merged before removing the old editor, which should be done in the next couple of weeks. I believe you were looking to have some time to test the OLX conversion fix as well.

As it stands, the current Removal Unblocked date for the legacy problem editor is ~14 October~ 14 December. Assuming we get the MD buttons done by then, do you have any concerns with removal beginning as soon as that date? As far as I can tell, the three other bugs listed as sub-issues on this ticket are OK to fix after we remove the old editor--let me know if you disagree.

[pdpinch]

Did you mean November 14?

I do have concerns about October 14. 🙂

[kdmccormick]

I actually meant December 14th 😅

[kdmccormick]

[Update]

We've determined that these remaining sub-tasks of this DEPR are not blockers for removal of the legacy problem editor:

1. https://github.com/openedx/frontend-app-authoring/issues/1680
   • Why not a blocker? The new markdown editor has the same behavior of the legacy (markdown) editor, so authors desiring the old behavior (auto-convert-to-stringresponse) can still get it via markdown.
   • Work in progress: There is a PR that needs some rework, but should be done within the next few weeks: https://github.com/openedx/frontend-app-authoring/pull/2615
2. https://github.com/openedx/frontend-app-authoring/issues/2073
   • Why not a blocker? MIT OL has confirmed that they don't see this as critical feature of the markdown editor.
   • Work in progress: There is a PR that needs some refactoring, but should be done within the next few weeks: https://github.com/openedx/frontend-app-authoring/pull/2456
3. https://github.com/openedx/frontend-app-authoring/issues/2444
   • Why not a blocker? The legacy editor had the same issue.
   • Work in progress: None yet. We might be able to rename the editor by Verawood. We're not going to introduce "real" markdown support by Verawood, or possibly ever.

So, I'm marking this ticket as Transition Unblocked and confirming that the planned removal date is 14 December.

Please let me know if there are concerns with any of the above.

fyi @pdpinch @feanil

[kdmccormick]

This is unblocked for removal.