Roll 7.x-2.3 release of Wysiwyg

+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:
http://drupal.org/project/issues/wysiwyg?text=&status=Open&priorities=1&...

Thanks.

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

+1

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.

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?

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!

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?

I would also be interested in this, at least some kind of alpha or beta release, as the latest stable version is now more than a year old...

@TwoD (and @sun if he's around) do you want to make a call for a co-maintainer?

Again I'll underscore how concerning it is that such a widely-used module used across the community is essentially broken in its current state, and despite offers of help and money we haven't even gotten a response from a maintainer in 8 months.

If there are release-blockers, let's please identify them. (I gave my opinion above why the two mentioned don't seem like release-blockers to me.)

If you need a co-maintainer, let's get the word out there.

If you need funding to do the work, that's been offered, and I for one would contribute and help promote it.

If it's not possible to move forward on at least one of those fronts, I think we should explore establishing this as an abandoned module so we can get another maintainer to work on it.

The last commit was just a month ago. Also the last comment in #1968318: Support for TinyMCE 4.x is by TwoD. I think suggesting the abandoned module path is counterproductive.

Still, speeding up development would be great, and hopefully a call for co-maintainership would help. (However, the current maintainers would have every reason to require someone with a great track record and prior involvement in the wysiwyg issue queue, so it's not trivial to find someone for that role).

Would be great to have this as a stable release. I think the two outstanding issues blocking this are testing these patches and marking them RTBC:

#1968318: Support for TinyMCE 4.x
#1338956-11: [upstream] HTML5 "required" attribute prevents forms from submitting

They should be tested against the -dev snapshots from what I can tell. I usually test against the git repo in other projects, but whichever. Since @TwoD wrote it, it probably just needs a sanity check and some basic testing.

I think the upstream issue has been "fixed in ckeditor since 4.2." according to an earlier comment. This can be tested.

But ya, @rootwork's points in 17 make sense.

It's worth noting that this issue has itself been open for 13 months... I'd say that's more than enough time.

Yes, I've been working on that TinyMCE 4 patch a lot lately. Got really sick about two weeks ago though and was much too tired to dig deep into it, but now I'm back at it. More details over there.

I don't reply much to issues like this one since they're not really about any specific problem and I don't want to repeat things across multiple issues. Just keeping the queue clean of duplicates is annoying enough as it is.

Money is not an issue, at least not a prominent one. Sun managed donations, so I have no idea how much we got or how frequent they were, beyond a bit I got a few years ago. To be honest, it felt a bit weird accepting money that way, and I have no idea about tax rules etc, but he insisted I had earned it - at least back then hehe. ;)

So if it's not about money...?

I work full time - making camshafts for truck engines, so no Drupal :( - and am currently on a 4 week rotating schedule, with weekends every 3rd week and the 4th week off. I have to get a lot of stuff done in that week off, much of which is related to me also wanting to get my own business going, and us having dogs, sheep, cats, and house renovations to tend to. Life, you know... Every opening I get, I squeeze module work in there, but sometimes you're just too tired to do anything more meaningful than scan the issue queue. Most of the I write comments, like right now, I've got a few minuts off at work. The upside is I do get a lot of laughs and questions about "all the colors on the screen" when I SSH home to look up a piece of code in Vim, but I don't know what the IT department feels about how easy it was to abuse their proxy...

Getting back on topic...
In-depth knowledge about Wysiwyg module, the editor libraries, and the future plans for how to deal with them is a bigger issue. To be honest, I don't know anyone but Sun and me with as much knowledge about the various quirks in these code piles, and Sun is usually occupied elsewhere. I'd love to know if you do have that or are willing to spend the time needed to get to know it.

I know someone did ask for co-maintainership a while back, but they mostly talked to Sun and I lost track of that conversation. I'm very sorry for that. :(

I'll try be better at clearly marking what I think are release-blockers. The three listed in the OP do sum it up pretty well though. We get a lot of questions about TinyMCE 4, and feel the frustration that follows when you're hit with it not being recognized by Wysiwyg. It is a very good alternative to CKEditor 4, so I can understand them. TinyMCE has served us well before and making a release without supporting their latest major version feels like a betrayal.

Thanks for this @TwoD - really liked your tangent!

I was going to comment in line with the above and ask when a new release would be done.

Instead I'll say that TwoD's summation is about right. Looks to me like we have two release blockers on this, one of which is upstream so maybe not an issue at all right now.

Perhaps instead of asking what Drupal can do for us, demanding a release, we should ask what we can do for Drupal, and resolve the two outstanding issues.

I'll see if I can find the time myself, but as TwoD said, we're all busy with real life which is why important modules like this are sometimes left for a while.

So, I for one will try and pull my finger out, if everyone did the same we'd resolve the last two issues then we can complain to TwoD to get a release done :D

Good luck to us all and well done for all the work TwoD, there are many sites much improved by your work and camshafts.

#2343445: Stable release of Wysiwyg module, v7.x-2.4 please has more established parent/child links so depreciating this issue. This had more followers, but...