Aloha switched to jQuery UI; change module to match

Hi there, yeah I saw that as well, quite excited because it means we can finally remove the warning on the project page about the potential ExtJS bugs.

No-ones started working on this as far as I know, so if you want to provide a patch or put the work up in a github repo we'd love to make this change.

Or you could ask iler to add you as a co-maintainer
http://drupal.org/user/726092

Another thing is that the library is now GPL2 so we could include it in the module. I think this would be worth doing for a couple of reasons.

1. We've had a few support requests from people who can't work out where to put the library. This would make the installation a lot easier.
2. The library is changing so the version that somebody downloads in 6 months time might not work with this module (we actually had this situation back in October, and I've been having the same problems trying to install the new edit module). Including the library with the module will mean that there will always be a working version of the module.

I tweeted iler about becoming involved in the project at the weekend and I got the very distinct impression that he thought there was no point continuing this project - due to the reason you have already mentioned.

I don't know if the edit module works with non spark distro's though does it?
Would there be users who are not going to be using spark who would like to user aloha?

I would vote for this module to continue, as the spark/edit module currently requires having the "Mobile friendly navigation toolbar" activated too.
That's something which really puts me off it and I'm sure alot of other people too.

quicksketch and I were looking into how we could move Aloha Editor into core. To do that, we need to have a clean, short namespace — as core wants it. We think just "aloha" makes a lot of sense, but that namespace is already occupied by this module.

As you are already stating in this issue: the goal of Edit is to work on any site; the dependency on navbar will definitely go away. So, if it is okay with the maintainers, I would like to take over maintainership of this module and move just the Aloha Editor aspect of the Edit module into the Aloha module (this module). We'd be working in the 2.x branch, so the existing code could continue to exist.

Does that sound reasonable to you?

Yeah moving the Aloha pieces out of the Edit module would also provide some great solutions that would solve a number of open issues for this project. They've already switched to using the new jQuery-only branch of the library and have even contributed a build script directly into the Aloha editor Github to avoid the double-building of jQuery into the project (https://github.com/alohaeditor/Aloha-Editor/blob/dev/build/aloha/build-w...), eventually making a lighter footprint overall in addition to avoiding the ExtJS found in the previous versions.

The front-end, inline-editing functionality of Edit module requires quite a bit of infrastructure, I think it makes sense to keep that effort as a decoupled as possible from the basic functionality of Aloha, which would be great to have it as its own project here at the "aloha" namespace.

I don't see any problems with this approach. Actually I've been getting quite a lot of pm's and mails that people would still love a module that only brings the Aloha Editor functionality to Drupal even though the edit module will be available. I've given you both, Wim Leers and quicksketch, access to the project. As proposed it's a good idea to work on 2.x branch and would love to help also with that. I've been waiting to see what will be the direction of Spark to decide how to continue the development of this module.

Great, thanks @iler! Looking forward to working with you. :)

I'll start pulling the code out of Edit module and moving it into the 2.x branch of this project. It might not be a bad idea to just pull out the special build of Aloha editor out of Edit and put it in the 1.x branch also.

There's also a fascinating issue over at #1701784: Please whitelist Aloha Editor that details an explanation of why Edit module started including an Aloha build in their module directly to begin with. Essentially the Aloha team thinks that using the default build tarballs is *crazy* and that Aloha is *intended* to highly customized builds of the library, especially for deep integration with a CMS like Drupal. I've already committed the custom build to the 2.x branch to get things started, but providing this same build to the 1.x branch would probably be a good idea to get the 1.x branch functional again.

Sounds great. The edit module has at the moment many dependicies that not all users want. Toolbar, navbar etc.

I'd gladly help out with writing documentation if that's needed. Do a screencast when the mod and all it's plugins are stable.

Delighted to hear development is going ahead :)

Thanks, @iler!

Also, rock on, @quicksketch, for already having pushed a lot of code :)

Looking forward to work with you guys!

jquery_update dependency?

Why not something like http://drupal.org/project/jqmulti ?

• The main problem with the approach of the jQuery Update module is that newer versions of jQuery tend to break Drupal core JS, as well as contributed JS meant to run on the older version provided with Drupal.
• This module avoids this problem completely, meaning that you can run scripts with new versions of jQuery as soon as they are available, without having to find and fix incompatibilities
• You have complete flexibility to choose which version of jQuery to run.

It's very simple. Instead of wrapping the script in

(function($){ 
 })(jQuery);

You wrap it the targeted jq version.

(function($){
 })(jq171);

No blanket solution. No forced take-it-or-leave-it jQuery version.

Please see #1760386: Migrate Aloha Editor integration from the Edit module and make it work on the back-end and #1782332: Upgrade the Edit module so that it leverages the Aloha module.