Repository navigation
[DEPR]: Legacy Text Editor #34692
Description
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-03-14
Target Breaking Changes Unblocked Date
2025-09-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 Ulmo.
Rationale
The legacy Text Editor has been replaced by a React-based Text editor for multiple releases. The toggle new_core_editors.use_new_text_editor has been toggled on in Tutor since at least Redwood.
Furthermore, the EditImageModal component that is used it the legacy Text Editor is also set for deprecation and removal (openedx-unsupported/studio-frontend#381). To prevent errors and regression while using the legacy Text Editor, it is best to remove it completely from the platform.
Removal
- Remove toggle for switching between editors
- Remove dependency on toggle for text editor redirect and make it always true
- Remove dependencies on toggles when fetching the course authoring mfe url
Replacement
This legacy editor is replaced by the frontend-lib-content-components/TextEditor. This text editor is a React based component and is rendered in the Course Authoring MFE.
Additional Info
Pending the restoration of the "floating" editors:
Activity
felipemontoya commentedon May 10, 2024
The removal of the ENABLE_NEW_TEXT_EDITOR_FLAG was done at the frontend in this PR openedx/frontend-app-authoring#951. This happened due to a bug before the redwood cut.
kdmccormick commentedon May 20, 2024
If you're watching the issue, then FYI there is some conversation about StudioEditableXBlockMixin going on in the related forum thread: https://discuss.openedx.org/t/deprecation-removal-text-editor-in-edx-platform-34692
kdmccormick commentedon May 30, 2024
Based on the forum discussion, it looks like there are no blockers to removing this. @KristinAoki are we ready to move this to Accepted?
kdmccormick commentedon Jul 24, 2024
@jristau1984 @robrap Technically the 6-month grace period for this would end Nov 17th. IIRC, the new text editor is already fulled rolled out on edX.org and Edge. Given that, do you have any opposition to waiving the rest of the grace period and making this available for removal?
@pdpinch , same question for you-- Would you have any opposition to the legacy Text component (ie, HTMLBlock) editor being removed on the master branch of edx-platform at this point?
Two notes:
jristau1984 commentedon Jul 24, 2024
@kdmccormick I believe the legacy edtior is still avilable through the container page (directly navigable, and available thru the library block experience?), so removing it would have side effects.
kdmccormick commentedon Jul 24, 2024
@jristau1984 Both in a Tutor environment and in edX Stage, I made a library with a text component, and then referenced that library in a course. When I entered the library_container view and edited the text component, it fired up the new editor for me: https://studio.stage.edx.org/container/block-v1:edx+tmccormack-test+1+type@library_content+block@997ed8d15d0144c9895ce87f6140ec9b#block-v1:edx+tmccormack-test+1+type@html+block@e53730f804cc4bd2205f
robrap commentedon Jul 24, 2024
@jristau1984: Could we use observability to confirm if we have any usage of the deprecated code?
jristau1984 commentedon Jul 24, 2024
@robrap I think we could, I just dont know if people go there. I know that the Partner Support has used the container page as a workaround sometimes, but I dont know the frequency (especially recently).
kdmccormick commentedon Jul 24, 2024
@jristau1984 We certainly need to keep the container page working, but my testing so far is showing that the container page has already been upgraded to use the new editor.
@robrap Observability-wise, you could check for any usages of the legacy text editor by looking for invocations of the HTMLBlock's studio_view, which is a GET to URLs of the form:
https://<CMS_BASE>/xblock/block-v1:<ORG>+<COURSE>+<RUN>+type@html@<BLOCK_ID>/studio_view. Is that feasible with your tools? If not, we could instead check for invocations of the studio_view definition; is an edx_monitoring_utils custom attribute the way to go there?11 remaining items
jmakowski1123 commentedon Sep 16, 2024
Apologies @pdpinch , I'm not seeing your questions here? https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4434264072/Libraries+Support+Unit+Subsections+and+Sections
pdpinch commentedon Sep 16, 2024
kdmccormick commentedon Feb 10, 2025
Product proposal relevant to this feedback: https://openedx.atlassian.net/wiki/spaces/COMM/pages/4517920789/Help+course+authors+understand+the+context+of+the+text+and+problems+they+are+editing
kdmccormick commentedon Feb 19, 2025
Communicated via: https://discuss.openedx.org/t/deprecation-removal-all-legacy-studio-frontends/15049
robrap commentedon May 29, 2025
[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 commentedon Jun 3, 2025
^ This has been addressed. The ticket is in Transition Unblocked.