Text editor analysis - Replacement of Atto

Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Number of replies: 29
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片

Hi all,

Let's talk about text editors, specifically Atto, and its future.

Atto was designed as a lightweight, accessible, in-house editor for Moodle. While it has arguably achieved all of these goals, it was written nearly a decade ago, uses deprecated technologies, and is difficult to maintain. In addition:

  • Moodle lacks the dedicated, in-house, knowledge to maintain a rich text editor Maintaining our own editor detracts from our core business goals of writing a kick-ass LMS to empower educators.
  • The JavaScript world has moved on, but because Atto is built upon the now-deprecated YUI framework, it is increasingly difficult for us to add new features using modern language features.
  • The library we use to normalise content selection (Rangy) was abandoned shortly after we started to use it, and has a number of known issues that detract from the experience of using Atto.
  • Many of the language features that Atto is based around were experimental at the time of its original writing and never made it to the browser specification. Their continued use is not advisable.
  • Atto is fine for editing short content, but when editing larger, or more complex, content it becomes more challenging. In particular, the undo/redo are problematic, and image handling is tricky.

Possible solutions

As with any problem, we have multiple solutions available - each has their own benefits and problems. To add to this, Moodle also has a number of restrictions which we place upon ourselves and which make any product selection more complex and/or prohibitive, in particular:

  • Our plugin structure does not support files being parachuted into place. We have a strict plugin architecture which must be followed for community plugins to work.
  • We do not use any server-side JS processing, such as WebPack. All of our JS is shipped with Moodle, or community Moodle plugins, as pre-compiled code ready for production. This prevents us from using any editor which tree-shakes code based on configuration, or whose APIs are mangled during their build process.
  • We use our own Translation system (AMOS)
  • We use our own dialogues, menu bars, and other UI features
  • All software we include must be compatible with the GPLv3 license

Rewrite Atto

Perhaps the most obvious solution is to rewrite Atto with more modern JS practices (ES Modules) to match our other JavaScript content. In doing so we would also have to find an alternative to the Rangy library, and to the deprecated Document.execCommand() browser API. In an ideal world we would also maintain backwards compatibility with existing Atto plugins, but this would be extremely difficult given the chagne of technology (moving from YUI to ESM), the necessary change of underlying API, and the replacement of Rangy. The complexity of this project would be high, and Moodle would still be maintaining its own text editor, which is a huge distraction from our core business.

Replace Atto

Atto is not the only rich text editor available, and many other Open Source editors exist. These include editors like CKEditor, Tiny, and Quill. Others do exist but are not included here as they are opinionated in their design and/or abandoned. However, replacing Atto is not a trivial task.

Whilst this approach would work around the issues of finding alternatives to Rangy and the use of deprecated browser APIs, it would not solve the issues of breaking compatibility with all existing third-party plugins; however it can provide a wealth of existing functionality with years of dedicated research and development instead. In many cases the current Moodle plugins can be replaced with existing plugins, negating the need to develop them again for Moodle.

CKEditor

The limitations above immediately preclude the use of CKEditor 5, which requires WebPack, and tree shakes the entire platform. It would not be possible for third-party developers to write plugins for multiple versions of Moodle, and a new compilation step would be required, and could only run when all possible plugins are in place. Configuration would not be trivial.

QuillJS

QuillJS is an editor framework. Whilst it can provide an editor without any further configuration, to do anything more Moodle would need to create all interfaces using our own existing components and integrate these with the QuillJS APIs. This is closer to the Replace Atto approach, but with a well-supported underlying editor API. This approach would still require all of the current overheads of maintaining an editor, albeit without most of the more complex editor parts.

Tiny

Tiny is a full-featured editor, which comes with a number of standard plugins which replace many of Atto’s standard features - these include standard formatting, font and colour selection, alignment and justification, undo/redo, word count, source-code viewing, table support, links, emojis, copy, and paste. Many of these features will work as-is for Moodle.

Some use the Tiny modal and form frameworks and we would have to decide whether to use these in Moodle, or to rewrite them using the standard Moodle interfaces. This decision would not have to be made immediately.

Other options

I looked at a number of other possible editors, but these were either opinionated in their choice of technology (for example jQuery, specific Bootstrap versions), or were abandoned.

What this means

I have just opened MDL-75071 to look at migrating away from Atto in the near future.

At the moment, given the above analysis, we are looking to migrate to the latest version of Tiny.

Important: If you are aware of other editors which meet these criterion, and you feel we should include them in this consideration now is the time to mention them.

At this time we are still analysis the work required to support Tiny 6 and are trying to consider items including:

  • third-party plug migrations
  • accessibility
  • backwards-compatibility with older versions of Moodle
  • The possibility of supporitng Tiny's own 'Premium' pluginset

Best wishes,

Andrew

評比平均分數:Useful (7)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Francis Devine發表於
Core developers的相片
Was returning to TinyMCE not considered? It's still being updated and was the previous editor for those of us who have been around long enough to remember.

Either way, I agree that using a third party editor is a better solution than trying to make one in house.

edit: I've just realised this is the Tiny editor you are referring to, did they rebrand at some point?
In reply to Francis Devine

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Francis,

Yes, they have rebranded. They seem to use Tiny, and TinyMCE interchangably. I think Spock sold the TInyMCE product and/or MoxieCode but not 100% sure.
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Mark Johnson發表於
Core developers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

A somewhat tangential discussion, but would it be possible to deprecate and remove YUI from Moodle core alongside Atto? As I understand it, Atto's reliance on YUI is the main reason it's stuck around so long, would this be a good time to rewrite/remove those smaller parts of the system that rely on YUI as well?

評比平均分數:Useful (2)
In reply to Mark Johnson

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
We are working towards removing YUI but we're not quite there yet. Atto is one of the main consumers of YUI but it is not the only one. Many of our dialogues still use YUI, and we are still using the YUI2 treeview in a number of placels (like the File picker).

We are hoping to work on some projects to update the File Manager, and File picker. Once those, and the removal of Atto occur, we'll have moved most of the YUI code away and it will be more advantageous to work on those final few places using Dialogues etc.
評比平均分數:Useful (1)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Michael Milette發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片 Testers的相片 Translators的相片

I cannot emphasize enough the importance of accessibility and believe that it should be at the top of the priority list when it comes to Moodle's default editor. I am not just talking about the accessibility of using the editor but also the quality of the HTML that the editor generates.

An accessible Moodle LMS that generates non-accessible content does not result in a WCAG 2.1 Level AA compliant website and this is a huge problem for a huge and growing number of site owners today who are now required by law to ensure that their site meets the intention of the accessibility guidelines.

With one of my past clients about 2 years ago, we did a lot of testing of several WYSIWYG editors. The criteria for selecting an editor included (listed in order of priority):

  • Accessibility of the content it generated. Must be valid HTML5, no extra junk tags inserted, WCAG 2.1 Level AA compliant.
  • Accessibility of the editor's UI.
  • Support for multiple languages.
  • Paste clean HTML content from MS Word.
  • Preferably open source or at least available under a site license, not a per-user license.

Notice that generating accessible content is a higher priority in the list that ensuring that the editor interface itself is compliant?

When I spoke with many Moodle LMS site Administrators at in-person and virtual MoodleMoot conferences over the last few years, you might be surprised at just how many told me that are still forcing the now very old TinyMCE editor (included with Moodle) on their users instead of Atto in recent and current versions of Moodle specifically for accessibility reasons. The aging editor looks aweful by today's standards but it often still beats Atto in terms of generating valid and clean HTML content.

[I do want to express my gratitude to all of the people who have worked to improve Atto's ability to generate valid HTML5 content in recent releases of Moodle. You need to know that your efforts are very much appreciated by many.]

In case it is of interest or useful to anyone, I did a little proof of concept back in 2020 to see if it might be possible to add CKEditor 3.5.2 into Moodle 3.8. (CKEditor used to be included with Moodle many years ago). The latest ALPHA/Dev release of my effort is available from: https://github.com/michael-milette/moodle-editor_ckeditor. I have not tried it in more recent versions of Moodle. Feel free to fork the project and continue its development.

Hope you find this helpful.

Best regards,

Michael Milette

評比平均分數:Useful (3)
In reply to Michael Milette

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片

Hi Michael,

In terms of your personal criteria:

> I cannot emphasize enough the importance of accessibility and believe that it should be at the top of the priority list when it comes to Moodle's default editor. I am not just talking about the accessibility of using the editor but also the quality of the HTML that the editor generates. > > An accessible Moodle LMS that generates non-accessible content does not result in a WCAG 2.1 Level AA compliant website and this is a huge problem for a huge and growing number of site owners today who are now required by law to ensure that their site meets the intention of the accessibility guidelines. > > - Accessibility of the content it generated. Must be valid HTML5, no extra junk tags inserted, WCAG 2.1 Level AA compliant. > - Accessibility of the editor's UI.

Atto was always intended as an accessible editor and we worked very hard to have it generate accessible content with an accessible UI. It currently meets AA and attempts to generate AA-compliant content (this is not easy). Sadly the browser APIs do not make this easy, especially without any normalisation layer included.

As I understand it, TinyMCE 5, and the newly released TinyMCE 6 are significantly better than older version for accessibility both in terms of UI, and generated content. That said, we need to test this.

> - Support for multiple languages.

I presume you mean translation of features. This is something we will of course support, though how we do so is yet to be determined.

> - Paste clean HTML content from MS Word.

We will not be focusing on this. It is available as a "Premium" plugin for TinyMCE and we therefore do not have access to that stock plugin. It's never worked for Atto and unless we get specific funding to work on this in the future I don't know if we'll be able to dedicate time to it in the next 12 months.

> - Preferably open source or at least available under a site license, not a per-user license.

This is a requirement for us as Moodle is distributed under a GPLv3 license. Any included code must be compatible with this license.

> When I spoke with many Moodle LMS site Administrators at in-person and virtual MoodleMoot conferences over the last few years, you might be surprised at just how many told me that are still forcing the now very old TinyMCE editor (included with Moodle) on their users instead of Atto in recent and current versions of Moodle specifically for accessibility reasons. The aging editor looks aweful by today's standards but it often still beats Atto in terms of generating valid and clean HTML content.

I'm very surprised by this because that old version of TinyMCE was terrible for both UI accessibilitty, and generated content accessibility.

> In case it is of interest or useful to anyone, I did a little proof of concept back in 2020 to see if it might be possible to add CKEditor 3.5.2 into Moodle 3.8. (CKEditor used to be included with Moodle many years ago). The latest ALPHA/Dev release of my effort is available from: https://github.com/michael-milette/moodle-editor_ckeditor. I have not tried it in more recent versions of Moodle. Feel free to fork the project and continue its development.

I have a PoC of ckeditor 5.x for Moodle, but it is not compatible with our direction. The latest version(s?) of ckeditor require webpacking, and the standard configuration performs a tree shake and minification. Because of the way that this is done, it becomes extremely difficult (I won't say the impossible because there will be a way) to write plugins for it unless you run the webpack with all plugins in place. It's also not easily compatible with Moodle's plugin and subplugin directory structure. The only way I could get it working and have it such that I could even attempt to write a plugin which is installed at run time was to include the entire source and all dependencies (some 300MB). As I say, if it were possible to run webpack at runtime, it would be fine, but we don't have NodeJS as a runtime dependency for Moodle. You can see my branch of that from July 2020 here: https://github.com/andrewnicols/moodle/tree/ck.

Andrew

In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

sam marshall發表於
Core developers的相片 Peer reviewers的相片 Plugin developers的相片
Couple of questions:

1) It's a long time ago but I thought the decision to replace TinyMCE was partly/largely for accessibility reasons - there were serious problems in accessibility testing and no real indication that these would be fixed. Before moving to any alternative editor, will there be comparative accessibility testing to ensure that, it's at least good as/better than Atto? (I say 'comparative' because if the new editor is accessibility-tested then I guess this will probably come up with some problems, but it's possible that Atto also has equivalent problems, in which case no problem changing.)

2) We have quite a few Atto plugins, and some other places where our code is tightly integrated with the way Atto works. It's going to take us a while to migrate them and we would prefer this doesn't mean we have to delay upgrade to Moodle 4.1 (or 4.2 or whatever version this goes in). Will there be a period (perhaps similar to the code deprecation one) where, ideally at a site level and not per-user, existing installations can select an admin setting to continue to use Atto instead of the new editor?

--sam
評比平均分數:Useful (2)
In reply to sam marshall

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Sam,

1) Yes. Atto was largely an answer to TinyMCE's terrible accessibility and a lot of time was spent on making it generate accessible content. Thankfully the world has moved on and TinyMCE tout their accessible content as a feature. That said we do still need to do some testing on it. Sadly Atto does still have some issue in relation to accessibility.

2) That's already possible - it's an admin setting and you can enable/disable individual editors, and set the default for all users. You can configure Atto to remain default, and even add it back in after we've removed it if you see fit (though with the obvious caveats).

Andrew
評比平均分數:Useful (3)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Brandon Jimenez發表於
Hello Andrew et al,

All of your posts are really helpful as I'm currently developing a couple of atto plugins. I'd like to know if there's some sort of timetable for a possible replacement of the Atto editor and/or deprecation/removal of YUI.
In reply to Brandon Jimenez

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Brandon,

Sorry that I missed your question. I was off work for several weeks due to a family matter.

The provisional timetable is to provide TinyMCE version 6 in Moodle 4.1. We hope to also make it available in the plugins database for Moodle 4.0, and possibly 3.11 and 3.9 too (to be confirmed). Atto will remain the default editor for Moodle 4.1.

From Moodle 4.2, Tiny will be the default editor, and we are considering moving Atto out of core and into the plugins database at the same time. This will depend on community feedback, and uptake from plugin developers.

We do not accept any new YUI code into core, and have not done so for some time. We accept patches to existing YUI code and we strongly encourage migration of all non-atto YUI code to ES modules (ESMs) as quickly as possible.

Right now we have too many things which are dependent upon YUI to know what the deprecation schedule will be. Once Atto has been removed, we will also be looking at updating the File manager, File picker, and Repository client. At this time we have 191 YUI JS files in core, plus some other locations which explicitly use YUI. After Atto's removal this will drop to 114. Some of those are compatability layers, or YUI itself, so the number is closer to 100. I know that the quiz code will shortly be updated to move to ESMs, and a number of other locations only use YUI code as part of their migration paths (course formats). The other big location using YUI is the EditPDF interface in the assignment activity, but this will require substantial work to migrate.

Hope this helps,

Andrew
評比平均分數:Useful (1)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

"From Moodle 4.2, Tiny will be the default editor for new installs". seems OK to me.

In terms of when to remove atto, why not follow the standard deprecation process? That would suggest Atto should not be removed until 4.5 if TinyMCE is in 4.1.

評比平均分數:Useful (1)
In reply to Tim Hunt

Re: Text editor analysis - Replacement of Atto

Randy Thornton發表於
Agree with Tim. The standard deprecation process is there for a good reason. Simple removing Atto from core immediately concurrent with introducing a new editor is a recipe for disaster. A conversion window of a few versions must be provided for this.

Like Michael, I have lots of clients still actively using TinyMCE in many situations, especially in technical subjects (math, sciences, language) where teachers and course designers know html or javascript and have complex pages. It is by no means dead but very much alive and in active use. A new editor will need to support those same advanced features.
In reply to Randy Thornton

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
We will definitely be removing legacy TinyMCE as soon as possible and placing it into the plugins database.

We have not supported this version in many years, and I think that placing it in the plugin database where it can be installed if desired with known caveats, is a better representation of this state.

That is not to say that the Plugins Database is where plugins go to die, but that it will not be supported by MoodleHQ in any way, shape, or form, but we make it available for those who still wish to use it. The plugins database just allows it to be more easily discoverable for this situation (otherwise I would just put it onto GitHub and nothing more).
In reply to Tim Hunt

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Tim,

Thanks for the feedback.

This is a bit of a tough one because Atto consumes a *lot* of resources for mundane bugs. We are not preventing people from installing it, and the proposal is to make it available within the Plugins database too.

It may be that we delay this removal slightly (for example, until 4.3) but I do not feel that we can continue to support it for a further two years. It's simply unsustainable.
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片
git log v4.0.0..master lib/editor/atto/

Are you sure you are arguing based on reality?

If Atto is no longer the default editor, and we know it is getting removed in 4.5, then I would only expect the rate of bug fixing to slow down - probably down to something closer to the effort expended on editor_tinymce in core iin recent years (so, approximately zero.)

I think Moodle HQ staff should lead by example in following their own policies (in this case the deprecation one) rather than just granting themselves exceptions whenver they find their own rules a little inconvenitent.
評比平均分數:Useful (4)
In reply to Tim Hunt

Re: Text editor analysis - Replacement of Atto

Marcus Green發表於
Core developers的相片 Particularly helpful Moodlers的相片 Plugin developers的相片 Testers的相片
Tim, do you mean that you would expect the rate of bug reports to slow down because fewer people would be using it once it is not the default editor?
In reply to Tim Hunt

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Tim,

If we support Atto for the duration of Moodle 4.5, which is due for release in November 2024; and which is an LTS (and therefore has a three year support cycle); means continuing to support both Atto, and all YUI features for over five more years. I'm sorry, but this is the reality. We *need* to make inroads to remove YUI and, as long as Atto is in core, I suspect it's highly unlikely that will happen.

The deprecation policy is a little grey on its impact with regards the removal of plugins from core, and we haven't really applied it in that sense in the past. We removed a number of legacy plugins in Moodle 4.0 as a part of MDL-72046 and these were not subject to the deprecation policy either. I'm not sure why Atto is any different to those.

Whilst Atto has been the default editor for a number of years, we've all known that it will be retired sooner rather than later due to its reliance upon YUI.

We are trying to make it as easy as possible for developers to transition their plugins to support Tiny - for example, we are making Tiny available in the plugins database so that developers have a wider audience (hopefully back to Moodle 3.9 but TBC).

I do understand where you're coming from, but I think there needs to be some give and take.

Atto will be the default editor in Moodle 4.1 (LTS), which has a support end date of Nov 2023, and is security supported until Nov 2025. This the absolute latest we should consider supporting Atto to. We could (and I'm not saying we will) include it but not recommend it until Moodle 4.4, which has the same security support end date.

Andrew
評比平均分數:Useful (4)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片
Andrew, it is good that you are working to remove all YUI from core. Definitely a goal we should be persuing.

You keep taking about HQ 'supporting' Atto, as if HQ atually actively workes to fix the majority of bugs that are reported in Atto. I am sorry, that is just not true. HQ has ignored most Atto bugs for years. (I wonder how has fixed more Atto bugs? HQ or OU? Care to check?) That can continue, and, as I aready said, work on Atto can continue to ramp down. Just ignoring bug reports is very different from ripping it out.

I can see your LTS point. So, that is an argument for removing Atto before 4.5. So, I think you should plan to icnldue it up to 4.4. If, by watching all the third-party atto_ plugins in the plugins DB, and montioring use of the various editors on a sample of Moodle sites (e.g. talk to partners), you later get the evidence that no sigificant harm would be done by removing Atto in 4.3 or 4.2, then make that case when you can prove it. But, for now, I think plan A should be to leave it in until 4.4.
評比平均分數:Useful (4)
In reply to Tim Hunt

Re: Text editor analysis - Replacement of Atto

Randy Thornton發表於
Again, I agree with Tim.

Specifically, to address what Andrew says, "We removed a number of legacy plugins in Moodle 4.0 as a part of MDL-72046 and these were not subject to the deprecation policy either. I'm not sure why Atto is any different to those."

The difference is that almost every single piece of text and a lot of other content beside (video etc) in Moodle is and has been done with Atto since it came out. I don't think there is a more important tool for content in the whole system. Not a single one of the plugins in 72046 or related trackers are on a par with Atto for functionality: they were all old long before removed and they had mature replacements. They had long outlived a formal deprecation window. There is a long history, for good reason, of co-supporting key deprecated tools, e.g,. Legacy files (which still exists in 4.0), old Assignment (only removed in 4.0), both got a decade of extra life.

I agree with Tim that leaving it until 4.4 is a realistic plan to give people the necessary time to work through the inevitable issues of moving content over.

I would call it the minimum realistic plan because the history of replacing things that become legacy is pretty clear in my experience in the field: if the new replacement does not work flawlessly %99.9999 out of the box, it will not be adopted right away. People shy away from it and stick with what works until it starts to break or just disappears. And none of us really want to put people in the position of having to move to something that doesn't work well.

When Atto arrived, it mostly replaced Tiny right away for new content not only because it was the default but was simple and worked well. Even then it took a while, a year or two. But meanwhile, old content stayed on: only with the revamping of old content every two or three years did Tiny use fade away. The cycle of content updating plays a key role. On large sites with thousands of courses, many on a two year or three teaching cycle, that won't happen in eighteen months. If Atto is available as a extra plugin, I can easily predict it will be installed widely to get around this issue - because keeping Atto around will be less disruptive to teaching and is easier than updating hundreds of thousands or millions of pieces of text content -- unless the replacement process is almost frictionless, which is really the key.


If the new Tiny can meet the accessibility bar, that would be a good choice, since I know it can meet the advanced user needs I see in the technical teaching areas. However, the really great thing about Atto is it is simple and clean: it supports all the ordinary needs without cluttering things up.

Ideally we would like to have two modes for the editor, basic and advanced. Right now, advanced users can simply swap to Tiny in the preferences. That is working pretty well as far as I have seen. Basic Atto works very well for everything else. If we had a "Basic Tiny" with the same set of features as Atto comes with, paired with a "Advanced Tiny" with all the buttons, that would certainly lower the inevitable friction in converting. This could be a preference or even a capability, but I think having one and only one editor with one view for everyone will present some challenges.

Atto's great virtue is it is simple (but not too simple). And advanced users still have a way to get those extra tools. Keeping that dual ability would be really ideal.

評比平均分數:Useful (6)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Peter Diedrichs發表於
Particularly helpful Moodlers的相片
Can Tiny also be made to auto-save, like Atto does?
In reply to Peter Diedrichs

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Peter,

This functionality is inlcuded by default. It doesn't work in quite the same way that Atto did though.

Atto uses a time-based auto-save mechanism and can be configured to save the content if there have been changes on a regular cadence (for example every 15 seconds).

TinyMCE autosaves the content every time a savepoint is generated. That happens when the undo stack is modified - usually whenever you click out of the editor, use a button, or press the [return] key.

Hope this heps,

Andrew
評比平均分數:Useful (4)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Matthias Giger發表於
Particularly helpful Moodlers的相片
What happens when you edit a page and then open a new tab in the browser to do some other work. Will that also trigger an autosave? I'm asking because this is a frequent scenario when working with the editor in Moodle.
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Salah Majadly發表於

Hello,

So was this implemented in 4.1? 

what in terms of third party embeds in the editor?

we got clients asking if in 4.1 we will support TinyMCE as Atto is deprecated (which our product uses)

1. is it officially deprecated?

2. should we worry about the move in 4.1?

In reply to Salah Majadly

Re: Text editor analysis - Replacement of Atto

Andrew Lyons發表於
Core developers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片 Testers的相片
Hi Saleh,

From Moodle 4.1:
  • The default editor for new and existing installs is still Atto
  • The legacy version for TinyMCE (TinyMCE 3) is still available
  • TinyMCE 6 is available as an administrator setting, or user preference
Developers are working on creating and/or migrating plugins that were available for Atto to TinyMCE 6. We are planning to work on changes to make it easier to use native TinyMCE plugins too but these are not yet complete and our investigation is not complete.

From Moodle 4.2:
  • the legacy version of TinyMCE has been removed
  • TinyMCE 6 becomes the default editor for new installations of Moodle
  • there is no change to the default editor for existing installs

From Moodle 4.3:
  • TinyMCE 6 will become the default editor for existing installations

From Moodle 4.5:
  • Atto will be removed but can still be installed from the plugins database

From Moodle 4.6:
  • The underlying libraries that Atto uses are planned for removal and it will no longer be possible to use Atto at all.

Hope this helps,

Andrew

評比平均分數:Useful (4)
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Salah Majadly發表於
Thanks a lot Andrew, helps for sure
was confusing with all the tickets and comments
In reply to Andrew Lyons

Re: Text editor analysis - Replacement of Atto

Justin Ible發表於
HI Andrew,

Thank you, a question to a post earlier was that 4.5 is slated for Nov 2024... based on the release schedule posted, was expecting 4.4 on that date. Is 4.4 to be released earlier?

Justin