Ive been following the progress of this module since the beginning and am very impressed with the effort put in so far. I'm wondering if there is a roadmap and list of blockers for a stable release? I suspect it's too early for the blocker list and that the team is waiting for the jQuery library version to be released first. It would be great to have a rough roadmap to understand where this module is now and what it wants to achieve in the near future.

As soon as time permits I'd like to lend a hand in getting this to a stable release.

Comments

muhleder’s picture

muhleder commented

Hi Tanc,

I think the main blocker for a stable release would be more testing in the wild. Until it's been used thoroughly by a variety of people and sites we don't really know if we need to make any breaking changes.

In terms of known tasks there are a few things which we know need to be done.

1. Enable disabling of aloha by site builders based on jquery selector.
2. Decide what to do with content areas which may have been processed by filters or other modules.
Case 1: plaintext filter will strip all html tags, saving that field from the front end will remove all those tags from the db).
Case 2: Views is often used to truncate a field and add elipses, or rewrite fields in other ways. Do we attempt to handle this or decide to let site builders know that they are responsible for dealing with this issue (using 1 above).
3. Write tests. Not sure how much we can cover without using something like Selenium, but we should be able to do access checks.
4. Performance. There could be pages with hundreds of fields on a Drupal site. It would be nice to look at the order of access checks to see if there's anyway we can reduce the performance impact of this module in those cases.
5. Documentation and DX. Would be good to add a link after install and a status check to give devs the link to download the aloha library. A drush command to install the library would be useful as well (though not supported by drush yet afaik). The link should be to the latest 0.2.x version of aloha (or whatever is appropriate at the time - I spent quite a bit of time when I first installed this wondering why it wasn't working as the aloha library had been updated).

So those are probably the blockers for a stable release if you like, as far as I know anyway. Not sure if anyone else has other thoughts that need to be added. For me I'd say once these are covered we could move to a beta tag rather than alpha.

Longer term it would be good to be able to support other front end editors, and possibly merge with other modules providing front end editing as a lot of the problems will be the same. Createjs and Hallo are a couple of examples there.
Personally I don't think we should try to support wysiwyg module as that looks like a lot of work and requires work on wysiwyg itself the last time I checked.

As far as I'm concerned co-maintainers are very welcome. Think that would be an issue for illes to approve.

iler’s picture

iler commented

I have pretty much same thoughts than Muhleder. The main point is that we could get more people to test this module in different environments so we could find possible bugs and performance bottlenecks.

I have been pretty busy with my other projects lately but now it seems that I've got finally time to do some work with d.o projects as well. But still co-maintainers are more than welcome.

R.J. Steinert’s picture

R.J. Steinert commented

The progress on this module is down right jaw dropping :-O. I'm late to the game here having just heard of Aloha editor today and I want to reach out say thank you for getting this amazing tool integrated with Drupal as far as you have. I'm currently testing it locally on my part time project FarmHack.net and right now, out of the box, I'm editing content even on nodes in Views successfully!

As for deciding on what features are blockers, perhaps it would help if we considered the different use cases this module is trying to cover.

1. Enabling this module and then creating a new field with front end editing enabled.
2. Enabling this module and then enabling front end editing on existing fields.
3. Enabling this module and allowing the editing of fields in complex views.
4. Enabling this module and allowing the editing of fields from many nodes on one page.

Perhaps the focus for beta1 could be on the first use case and make it abundantly clear that 2, 3, and 4 will come later. I haven't read through all of the issues but AFAIK use cases 2, 3, and 4 may not even be possible.

Thanks again and count me in for testing and maybe even some patches!

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Closed (won't fix)

In the 2.x version of this module, Aloha Editor now works on the back-end, out-of-the-box (i.e. you don't have to download Aloha Editor separately anymore). Please *do* follow the included installation instructions.

If you want to use Aloha Editor on the front-end as well, please see #1782332: Upgrade the Edit module so that it leverages the Aloha module.

I believe this roadmap is now irrelevant. At the very least, it should be reconsidered in the light of recent events.