Drupal 8/9/10 version?

Today; no. In the future, maybe.

So far there has been little to no interest in a D8 version. Likely since D8 already comes with CKEditor fully integrated, including custom Drupal related plugins.

I do not currently have the time to do this myself. I did make a test-port when the Editor API in D8 was being built, but it's likely no longer usable since I have not looked back at it. That port was enough to convince me it was possible to use the D8 APIs, should the need/demand arise.

I am currently focusing on evolving the internals of the D7 version since it will still be supported for a long time. While I can, I'm also keeping the D6 branch alive since I know many still use it. It's likely the Wysiwyg API will differ from the D8 Editor API in several ways, but I would not make any promises about full backward compatibility if a Wysiwyg port does happen anyway. D8 already handles much of what Wysiwyg does, and in some instances more, so a port would more or less be a rewrite.

Comments and suggestions are very welcome.

I have used WYSIWYG for a long time on all my sites, and will of course keep it until they are migrated to D8 in the future. So I just wanted to thank you for all of your work.

I don't think there's any benefit to WYSIWYG itself being ported as-is to D8, but maybe the namespace could be used to build some migration plugins to convert D7 configurations? This is especially important as we don't need a competing API to what's already in core, there's little enough effort being put into maintaining the D7 version that effort for a D8 version IMHO would be a waste of time.

Something (certainly not the only thing) that people like about the WYSIWYG project is that multiple editors are supported out-of-the-box, with instructions included on how to install/enable your editor of choice. For example, see #2966864-23: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10. Drupal 8 core, via its editor.module, supports that at an API level, but I don't know if there are existing projects that actually integrate any other editor, let alone a single project that integrates several of the major one. So maybe a D8 port of WYSIWYG that includes that aspect of it (along with #4) would make sense? Or maybe that makes sense in a project of a different name (e.g., editors)?

+1 to #5 or possibly filling in some of the gaps of the editor module. Currently switching editors means loosing all Drupal contrib module integration. It would be nice to have WYSIWYG offer a cross editor entity-embed button integration or something in that vein.

My current thoughts on this as a maintainer mainly revolve around these things:

1. I've been away from the project a long time. Work and personal life simply got in the way of hobbies. I still wanted to work on Wysiwyg, I just couldn't. I still do want to work on Wysiwyg, but not at the same pace as before.
2. If there would be a port of this module it would be based on the Core Editor module's API. It may extend it, as some other modules extend other Core APIs, but the intention would be to be interface compliant.
3. For CKEditor a D8+ Wysiwyg could perhaps extend Core's CKEditor module to implement the API extensions mentioned above instead of replacing it. I don't actually know if this is feasable yet since I don't know exactly which API extensions there would be. I don't want to "compete" with Core's Editor or CKEditor module if I don't have to. (I'm also listed as a maintainer for those modules so it would feel doubly counter-productive hehe.)
4. Wysiwyg module would most likely only bring with it TinyMCE support beyond D7. I've not yet seen any other editor which has stayed active enough to motivate porting them myself. (Well, unless I get a lot of spare time and get really bored.)
5. The latest major changes in Wysiwyg module centered around rewriting the internals to track state better and be less exposed to the editors/plugins. The hard part has been keeping the API the same (and defining it better) but I think it's been reasonably successful at that.
6. The above point was motivated by wanting to both expand the API and flexibility for cross-editor plugins. For example. there's now a more clear separation of concepts there so a cross-editor plugin can have none or multiple buttons, which was not possible from the start.
7. It would not be an understatement to say that the most requested feature has been a better configuration GUI for editor profiles, something which the Core modules thankfully did very well. For various reasons this became a big task both in terms of code complexity and a psycological obstacle, which lead me to be somewhat tired with the project. However, I think it's more likely at least I would continue with that (since I still believe D7 will be around for a while) before porting all of Wysiwyg to D8+.
8. Testing all the supported editors and versions/variants of them is tedious. There's about 150 library versions to test if one would do a full run of everything within the verified version ranges today. Some of those versions are no longer available online. The testing infrastructure here on d.o. was obviously and understandably not set up with this use case in mind so a few years ago I cobbled something together that surprisingly works reasonably well, but only on my LAN, and the tests it does are fairly limited. The tests do actually interact with all editors and is able to for example check that certain buttons exist and that pressing them does the correct thing, so it can catch regressions. Expanding this automation to cover more is a must to preserve my sanity if I get back into working on Wysiwyg. It's also becoming a bit more fragile as the underlying stack changes so containerizing it would be good, and that may bring portability.

RE #7

One of Drupal core's big limitations in this area is the idea that all filter settings are exclusive to the editor settings. While there is some overlap there is also some room for some big improvements. Especially in the realm of html filtering there is currently a very tight coupling of CKEditor to the html filter settings (to the point of breaking custom settings if CKEditor settings are changed).

It would be nice to re-imagine this in terms of layers of filtering where there are some global configurations that can be applied to a wysiwyg. D8+ doesn't seem to ever imagine a time where someone would use anything other than CKEditor. You might also want to collaborate with the TinyMCE project to see where some of the pain points in offering an alternate WYSIWYG for D8 are. https://www.drupal.org/project/tinymce

#8:

all filter settings are exclusive to the editor settings

Can you elaborate on this?

Because back when editor.module was introduced into Drupal core, we painstakingly made sure that text formats (FilterFormat config entities) are 100% independent and usable without text editors (Editor config entities).

Especially in the realm of html filtering there is currently a very tight coupling of CKEditor to the html filter settings (to the point of breaking custom settings if CKEditor settings are changed).

Can you elaborate on this?

See core/modules/editor/js/editor.admin.es6.js: this allows any \Drupal\filter\Plugin\FilterInterface::TYPE_HTML_RESTRICTOR-type filter to react to text editor configuration changes. Drupal core uses this in core/modules/filter/filter.filter_html.admin.es6.js. Any contrib module is free to implement it but we cannot require it.

D8+ doesn't seem to ever imagine a time where someone would use anything other than CKEditor.

See above. This is not true: nothing in Drupal core assumes CKEditor. It is absolutely possible to swap everything out. If that's not the case, that'd be a regression. And then I'd love to hear where that regression is 😊

It would be nice to re-imagine this in terms of layers of filtering where there are some global configurations that can be applied to a wysiwyg.

Can you elaborate on this?

AFAICT this is saying that certain filters should be able to work with any text editor. If this is what you mean: I 100% agree and it's already in core:\Drupal\filter\Plugin\FilterInterface::TYPE_TRANSFORM_REVERSIBLE + \Drupal\filter\Plugin\FilterInterface::TYPE_TRANSFORM_IRREVERSIBLE filters.

All of this reminds me of:

1. #807996: [meta] Input filters and text formats
2. #226963: Context-aware text filters (provide more meta information to the filter system)
3. (and at least one issue I currently am unable to find 😬)

@Wim Leers I expect the editor api to be robust, but the way core uses it and thus the UX that I feel like the big improvements could be made. In all honesty, I haven't dug into the Editor API much and so none-to-little of the above criticisms are of the API.

all filter settings are exclusive to the editor settings

Currently I have a site which has a robust HTML editor experience using the ACE Editor and two which use CKEditor (and even a Gutenberg node type). Across all of these editors I have a base line of HTML filtering that I ALWAYS want to happen. Currently I have to duplicate this configuration across multiple WYSIWYG editor configurations. This is especially cumbersome due to #2710427: Broken "Allowed Tags" updating: after all values for an attribute are allowed, it should not be overridden to allow only certain attribute values as that bug rewrites the html filter rules.

Contrast this with the way the Pathologic module works; in Pathologic a user creates a global configuration and then can overwrite this configuration in the WYSIWYG config. This is a simplified example but I think it illustrates the benefits on this UX over what we currently implement in core. This is what I was referring to when I recommended "It would be nice to re-imagine this in terms of layers of filtering where there are some global configurations that can be applied to a wysiwyg. "

Especially in the realm of html filtering there is currently a very tight coupling of CKEditor to the html filter settings (to the point of breaking custom settings if CKEditor settings are changed).

#3 (and at least one issue I currently am unable to find 😬) might be #2710427: Broken "Allowed Tags" updating: after all values for an attribute are allowed, it should not be overridden to allow only certain attribute values which is exactly the tight coupling I am talking about.

Right now the TinyMCE module is struggling with things like drupal entity embeds because the entity embed module only supports CKEditor. But it is the same with the editor drag and drop interfaces and the like. I would like to elaborate more but I would prefer to keep this comment a bit short.

The fundamental question about a Drupal 8/9/10 version of wysiwyg now really revolves around the paradigm shift with CKEditor 4 EOL in 2023 and the very significant changes with CKEditor 5. This is extensively discussed in a video from May 2021 Reimagining the WYSIWYG CKEditor 5 in Drupal Core / DrupalCon North America 2021. How would the wysiwyg module fit with this paradigm shift?

I am not sure if porting this module to 9/10 make any sense. Example, there is currently a lot of work going into Drupal 10 and getting CK5 ready to be shipped. and perhaps the development effort hours could be used helping out core and/or helping keeping the D7 version of this module up2date with ever changing editors and PHP versions?