Please whitelist Aloha Editor

Cool! Looking forward to using it.

The issue is that it's > 10M download (https://github.com/alohaeditor/Aloha-Editor/downloads), which is strictly speaking over the limit. You may know who can make exceptions? Is that you? :)

License: https://github.com/alohaeditor/Aloha-Editor/blob/dev/LICENSE.txt

http://drupal.org/node/1475972#whitelist-criteria

Why is it 12 Megabytes (zipped!) in the first place...?

That's ~1200% of the actual size of the editor library files. Something must be wrong with those tarballs :-/

I agree, the limit should be revisited, it is arbitrary.

Maybe we can work with the Aloha Editor folks and get a "clean" repository from a Drupal perspective (i.e. generated docs should not live in the repository, nor should demos, etc.). But I highly doubt they'll change their practices. I'm sure they have good reasons for that, too (e.g. one nice side-effect is that it's possible to generate docs for any version, whereas we in the Drupal world rely on an out-of-band — version-wise — website for non-API docs).

Also note that the major difference with how Drupal does things is that Aloha Editor has the concept of "builds". That's why there's both a "src" and a "build" directory. Théodore Biadala (nod_) worked with the Aloha Editor folks to get a custom build just for Drupal, so that we can continue to use hook_library() etc., so that we can integrate Aloha Editor in the same way as we've integrated everything else. However, there still are unresolved issues there, which the Aloha Editor folks unfortunately haven't solved just yet.

Furthermore, their builds include many files we don't actually need or want. So, for now, please hold off on actually committing Aloha Editor to drupal.org, while we work with them to solve this.

All of the above is "as far as I know", because Théodore is the guy who worked specifically on the build process/Drupal integration aspect with them. I've reached out to him to get this solved ASAP.

I think the general idea behind 10MB was to make it so that people wouldn't throw huge tarballs all around drupal.org with example images, movies, etc. that were not necessary for the actual functionality. One library had a demo video included in the default download that was something like 40 MB... Is there any way to convince the Aloha people to have a '-min' package, or something?

It seems like, between the docs and the demos, there are already at least 10-20 MB of (uncompressed) waste in there...

I agree demos can create security holes also. I think fckeditor ran into this where it was recommended to delete the examples folder.

Much like contrib module maintainers are expected to manually minify JS files, i.e. build JS stuff manually, we'll have to create a script to build exactly what we want/need from their git repo. They've already committed a custom build profile for us, they're just not doing the build for us, so they're definitely fine with this.

I'll comment here when I have this figured out. (It's not the highest priority though.)

I think it's more than just the .6mb. My guess, since I wasn't in the discussions, was it was supposed to limit the amount of unnecessary files being in the package. That's where the policy should be made.

If I was to write the policy I would put it on the distro maintainers. "For the 3rd party libraries you should try and use the download that has only the files that are necessary for your distribution to work. This not only reduces the download size, but it also helps prevent security holes introduced by examples provided by the 3rd party library. If the 3rd party library doesn't have a download with the minimal files please consider creating a patch file for the library that removes the unnecessary files, then add this patch to the configuration of the library in your drush make file." or something with a better wording.

I vote to allow the .6MB in this case, but the general principle of not including unnecessary code remains. Especially as Aloha will likely become a strong contender for those who don't want to use TinyMCE/CKEditor going forward.

However, I still strongly support pushing other projects to offer downloads free of rampant excess (e.g. demo files and docs that are half or more the size of the actual code being used—and are better off hosted outside of the main repo anyways). It makes for a Better Internet™ :)

@webchick I don't think we are hacking libraries. Sometimes things have to be fixed and a patch is the correct way to do that. Removing example directories is far from hacking. There are plenty of reasons distros will provide a "hack" of core. An example will be the usage of the http://drupal.org/project/robotstxt module. This requires you to delete the robots.txt file from core. I think providing a patch that removes robots.txt in your make file so you can get that module working is a reasonable and an easily documented way of "hacking core".

In the case of 3rd party libraries removing example files actually provides more security.

#16: We're working with the Aloha Editor guys to find a way around this problem that works both for them and for us: https://github.com/alohaeditor/Aloha-Editor/issues/656.

But I wholeheartedly agree, it doesn't make sense to include all the files (to say it disrespectfully: all the cruft) that 99% of all site owners will never even look at for a second.

Maybe the best solution then is to take the same approach Panopoly took? I.e.: apply a patch to the downloaded tarball to add/remove stuff: http://drupalcode.org/project/panopoly.git/blob/refs/heads/7.x-1.x:/drup....
This is a win-win-win approach:
- we get to use Aloha Editor right away
- no excessive file size ends up in the distributions that use Aloha Editor
- no weird work-arounds necessary
We can then continue to work with the Aloha Editor guys to improve the build system so that we can move away from this work-around.

However, for this to work, we *do* need to get it whitelisted ASAP. Since geerlingguy already RTBC'd it yesterday, can we please do that? :)

1) Apparently they DO have some sort of "min build", they just do a very bad job of making it publicly available/explaining it. See https://github.com/alohaeditor/Aloha-Editor/issues/656#issuecomment-7550181. It's available from http://archiva.gentics.com:8081/archiva/repository/com.gentics.public/or... and is only 5 MB. I've asked them to make this more of an official practice, with less hacky download URLs. But, for now, this meets all previously unmet requirements: size and security wise. Could you please whitelist the above URL?

2) I've gone ahead and went with the approach outlined in #18.

This works well:

libraries[alohaeditor][download][type] = get
libraries[alohaeditor][download][url] = http://archiva.gentics.com:8081/archiva/repository/com.gentics.public/org/alohaeditor/alohaeditor/0.21.1/alohaeditor-0.21.1-cdn.zip
libraries[alohaeditor][patch][] = http://drupal.org/files/1702248-5.patch
libraries[alohaeditor][patch][] = http://drupal.org/files/1702248-pull_request_642-6.patch
libraries[alohaeditor][patch][] = http://drupal.org/files/1702248-pull_request_643-6.patch

All that is needed now, is whitelisting this baby :)

You used pipes | in your regular expression instead of backslashes, I fixed it for you. :)

Great news; they've now started uploading these packages to Github as well instead of that seemingly "internal use only" URL!

- URL: https://github.com/downloads/alohaeditor/Aloha-Editor/alohaeditor-0.21.1-cdn.zip
- regexp: ^https://github\.com/downloads/alohaeditor/Aloha-Editor/.+$

For future reference: https://github.com/alohaeditor/Aloha-Editor/issues/656#issuecomment-7578680.

I just realized we may want to prevent "non CDN versions" from being downloaded, otherwise we're still exceeding that 10 MB limit:

^https://github\.com/downloads/alohaeditor/Aloha-Editor/.+-cdn\.zip$

The one thing I can add to what Angie said is that we're working on a "generic Drupal-optimized build" of Aloha Editor.
That build will have each Aloha Editor plug-in in a separate directory. Then we'll be able to define each Aloha Editor plug-in as a JS library in Drupal (through hook_library()), meaning that we'll be able to have dependencies defined in Drupal, the Way It Should Be.

That's what we should do, but it's not allowed by the current d.o policies.

So right now, we have a custom build of Aloha Editor with just the things that the Edit module/Spark use (that's the extremely temporary measure Angie mentions). I'm going to commit this to the Edit module and as soon as we can do things the right way (see above), we'll shift to doing that instead.

Note for those who read the above and still wonder why we don't use the "CDN package": that build also includes five versions of jQuery and five different aggregated versions of Aloha Editor. As such, it is extremely suboptimal. (There are even more reasons, but that'd make this comment too long.)

I'm going to have to defer to someone else... this is an interesting issue, and my gut instinct would be to create an aloha_library project and go with that. That would definitely break the 'no hosting third-party code' rule, though (as you mentioned). Only other option would be to do something like set up a 'drupal' organization on GitHub and tell people they can host 3rd party code there. Would be a weird situation, though.

#29: the 1.6 MB is unzipped, BTW. So it's a 90% size reduction.

The "no 3rd part rule" says that we can't host code on d.o that is available elsewhere. If that _specific_ collection of 3rd party code doesn't exist anywhere else, I see no problem hosting it on d.o.

Awesome news!

I'm sure I didn't explain it clearly enough in #27, but indeed the goal still is to have a build that's suitable for *any* Drupal site or distribution, without any bias towards the Edit module. (Or, if it makes sense, maybe a branch that is biased to the Edit module and one that is generic.)

Is it too onerous to create a patch for aloha editor and use that in your make file? This would pretty much accomplish the same thing.

#35: the patch would have to be tens of megabytes large. Plus, it wouldn't actually be able to accomplish the same things.

Ok for me doing a custom library is a last resort as it becomes difficult to determine what has actually changed, but I understand if something is just way too difficult to put together.

Edit: Also Killes has given his ok so I say go for it.

We've worked with the maintainer of the Aloha project on drupal.org to make the "aloha" namespace available for our purposes for this special build of Aloha (see #1704414: Aloha switched to jQuery UI; change module to match). Considering there's also *a lot* of things that we can integrate Aloha with *without* getting into the inline editing portion of Edit module, this also makes an excellent home for providing basic Aloha functionality on the node/x/edit page. It also provides a stepping stone for a properly namespaced module to be added to Drupal core (so we can add "aloha" first, then "edit" later).

I'm working on pulling out Aloha out of Edit module and making it a stand-alone project, though more collaboration with Wim will be necessary since I'm not yet familiar with all the trimmings that the Spark team as put into these custom plugins that come with the Edit module.

I wasn't notified of Nate's comment — weird. Needless to say, I'm on it :)

@quicksketch / #39 - any progress on getting the Aloha project up and running yet?

Moving this back to fixed this since the original URLs are already whitelisted and reason it was reopened (https://drupal.org/node/1701784#comment-6363974) is no longer relavant.