Updated: Comment #10


There are some big features and fixes in dev version that would be nice to have an official release for. There are also some issues that need to get fixed before an official release can be made. You can help by reviewing patches on these issues!

Remaining tasks

#1956778: Ckeditor 4.1 ACF
#1968318: Support for TinyMCE 4.x
#1338956: [upstream] HTML5 "required" attribute prevents forms from submitting

Original report by @andrewmacpherson

Are we ready for 7.x2.3 and 6.x-2.5 releases?

Following #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected., it would be a big help if new supported releases could be rolledout.
Assuming a site-builder has downloaded the latest (non-dev) releases of wysiwyg.module and CKeditor, then the "CKEditor not detected" message is a big confusing WTF moment.


+1. Would quite like to see a release soon - just got asked to password-protect a site with HTTP-auth and seeing errors from #1802394: Warning: file_get_contents from 7.x-2.1 to 7.x-2.2.

I just did some clean-up of critical issues and it looks like there's only one remaining:


There are a couple of issues I'd really like to have fixed before the next release. I'll sum them up here later, but one really important issue is #1956778: Ckeditor 4.1 ACF.

#1968318: Support for TinyMCE 4.x would be really good to have as well. Would preferably not have to rush another release soon after then next one just to get TinyMCE 4 support in.

I don't know if this addresses the concerns with ACF sufficiently, but the issue has been sitting for a while http://drupal.org/node/1956778#comment-7237182


We're holding up bug fixes on feature requests? What exactly does a release cost the project that one can't simply do another one after those features are ready?

The cost of releasing the current 7.x-2.x-dev as 7.x-2.3 could be data-loss. That's also why I'm not currently making it the recommended package, despite me often telling people they should stay with the -dev snapshots for the most up-to-date editor support. This one, you don't want, unless you've taken the time to dig through the issue queue and are aware of the risks (and existing workarounds).

CKEditor 4.1 ACF support is pretty critical, and I don't want to revert all of the CKEditor 4 support already in 7.x-2.x-dev because of that one thing. I would personally see that as a step backwards, looking at how many people have been pushing to get that in (with official support being in Drupal 8 Core and all).

When CKEditor 4 support was committed the full effects of the ACF - introduced shortly afterwards in CKEditor 4.1 - on our cross-editor plugins (like the bundled Teaser Break) weren't seen. Without a way to tell CKEditor which tags are allowed (or to not filter at all) users risk having much of the content instantly filtered out when the editor gets attached, because the editor does not know it was provided by legitimate cross-editor plugins provided by Drupal modules.

And on TinyMCE 4 support, I foresee people going on very long rants in the issue queue if we don't include that together with CKEditor 4 support...

And yes, there have been long delays, which pretty much sums up my life in the last couple of years... :(
Fortunately, a couple of brave souls have recently started poking around in the issue queue looking for things to help out with, both coding and reviewing. If I can at least provide feedback from a maintainer POV to them - I write plain text a lot faster than code - the project will not be completely stationary and it might even bump up the tempo a bit. That's pretty much what happened when I first dipped my toes in to the queue and Sun could focus on the big picture. Sun is now forced to put his focus elsewhere - Drupal Core being a huge part, which also dragged me in for a bit, so I've pretty much been on my own for a while. I've tried to prioritize easy and/or important bug-fixes/features first, but it's very easy to lose the big picture when other things happen around you in the "outside" world. Family, relations, work, you know...

Hi TwoD,

Why not keep the current dev as dev, checkout 7.x-2.2, reimplement the bugfixes and release it as 7.x-2.3, a pure bugfix-release?

I've not tried to do that here on d.o before. I suppose I'd have to make a new branch for "7.x-2.3-dev", cherry-pick almost all patches from the current 7.x-2.x-dev, tag that and push it all to d.o. Then I could probably create a release from that new tag.

I'll see if that's possible. Otherwise, I suppose we could revert the CKEditor 4 support commit before tagging 7.x-2.3 off 7.x-2.x-dev and then re-commit that part, if it can be done cleanly. I'm currently at work though.

It's a bit late now, but this situation is why DVCS projects with mature workflows tend to include the use of feature branches. DVCS make branching and merging cheap. Long projects and other partial work can be committed and collaborated on but isolated to their own branches. The release branch is always ready for release.

Unfortunately, D.O still has somewhat lacking ability to manage feature branches (no explicit relationships between repositories (i.e Github "forks"), no branch-based comparison and review (i.e. Github "Pull Requests"), no explicit relationship between issues and branches (Github PR's again)) we can only use patch sets in issues, and the pain of dealing with the patch workflow seems to lead to people committing code into their release branches prematurely.

Issue summary:View changes

Updated issue summary.

I've just run into the same issue which started this thread: #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected. and I'm wondering whether the dev version might be stable enough now for a formal release?

I have tried to read through all the threads on this - people have done a huge amount of work on this - and regarding comment #7 above, that's why I was wondering whether things have progressed sufficiently since then to consider a 2.3 release?

Issue summary:View changes
Issue tags:+maintain

It's been over a year now since the last release. There was a dev release from January which is great. I like @petey318's idea of rolling up a stable release for folks based on the dev and going from there.

Are there enough incentives to ensure that this module is properly maintained? What is different about this project vs others? I do think that having some motivation to go through the issue queue and see that reports that people have made are acknowledged, repeatable, fixable and eventually closed would be important, but your team seems to have this.

I don't know if the use of of Flattr & Gittip would help. Or for that matter initiatives like Top Shelf Modules and DrupalFund.us.

I tried to highlight how Gittip could be incorporated into d.o's issue queue in order to provide incentives to individual contributors. From feedback there, I decided to look at how Corporate logos could be incorporated into the issue queues (even for anonymous users). How would either of those solutions affect how this module's developers interact?

None of these solutions is without it's problems. Some of these solutions will work better to support some projects than others. I think there are probably hundreds of other ways to help shape participation in the Drupal community such that end users, developers, designers and Drupal shops are able to find easier ways to contribute back. But I think we need to get the conversation moving about how to see that important projects like this get the support that they need to see that they are properly resourced.

There's a place to discuss Drupal.org improvements in GDO but there isn't a lot of active participation there.

Any word here? What would it take to get a new tagged release with some of the bug fixes like https://drupal.org/node/1802394?

Right now, I keep getting updates that wipe out the development version with the defective release version. Until you get your act together, at the very least, you should stage the dev version as the release version since the current release version does not work with the most popular editors. I have reinstalled WYSIWYG 3 times now!

Priority:Normal» Major

It's concerning that this issue has been sitting for so long without any feedback from the module maintainer (no comment in more than six months), even when the offer of money (Gittip, Flattr) was made.

This is a critical module for so many sites. New features, even important new features, are great, but it's just crazy to be running on +x-dev releases for years now.

Yes, #1968318: Support for TinyMCE 4.x would be "good to have," but considering the current stable release doesn't support TinyMCE 4.x or CKEditor 4.x, it seems like it would be an improvement to release a version that takes care of one of those two, doesn't it? (Along with a dozen other bugfixes.)

#1338956: [upstream] HTML5 "required" attribute prevents forms from submitting is marked as "upstream" -- as in, needs to be fixed in editors like TinyMCE and CKEditor themselves -- so I'm not sure that means anything for us. It certainly shouldn't hold this up.

What path can we chart forward to get a stable release done?