Add a new editor: http://aloha-editor.com
It looks pretty capable, but I wouldn't agree it's the most advanced editor in the world, not yet at least. ;)
The experience using it will probably not come close to the speedups/simplifications claimed compared to the other editors though, mostly because Drupal uses separate Edit pages. (Some AJAX editing modules might be able to edit things from the View page, but Wysiwyg currently won't.) For the same reason, you probably won't get as much of a WYSIWYG experience since the theme's stylesheets won't be loaded in the editing area (which is part of why the major brands use an iframe).
I can't access their API pages to check how to best integrate the editor with Wysiwyg module, but from their wiki it looks like it should work pretty much like other editors with a jQuery initialization.
If you want to implement this yourself, the please re-assign yourself. Otherwise we'll leave this unassigned so anyone wanting to do so can claim it.
We, maintainers, are currently working on improving the module to better support what we already have integrated and to make it easier to write new editor/plugin implementations, so we will most likely not have time to do this ourselves. Anyone is of course welcome to help to do this if they can.
https://github.com/evo42/aloha-drupal -- here you'll find a pre-better-alpha-0.9-release... needs a bit work... 1 known bug -- if you find others you'll get an aloha sticker ; )
Nice one, thanks :) That code will need some clean-up, but I didn't really expect a patch in the first place, so awesome! :)
I've read the note about not properly detaching from the textarea; interestingly, almost all editors that we're supporting were struggling with the detaching behavior at the beginning ;) Glad to see that the aloha dev team has taken notice of this detail ;)
I think we can proceed from here, but it would be great if you'd be available for potentially upcoming questions :)
you're welcome -- and also thanx : )
the "detaching from the textarea" problem was fixed by the aloha team & i'm going to update the wysiwyg module code on github by the end of this week...
* move all drupal related aloha js code to a new aloha plugin https://github.com/evo42/Aloha-Plugin-Drupal
* add config options for plugins/aloha to editor config file in wysiwyg module
* move all drupal related php/backend/config code to a drupal aloha module in https://github.com/evo42/aloha-drupal
* enable the editor/editing without going to the dedicated edit page (contentEditable frontend editing) like http://aloha-drupal.evo42.net/latest/node/3
if you have any questions or suggestions, feel free to ask ; )
Thanks! Sounds nice.
However, three caveats for three of those todos:
move all drupal related php/backend/config code to a drupal aloha module
Not sure what you mean with this, but in case you meant to build an own/custom module for Aloha editor integration, then I would not recommend to do that. The purpose of the Wysiwyg project is to abstract and standardize the integration of editors into a single Drupal module, in order to allow the Drupal community to join forces on fundamental integration issues and also provide a unique API (regardless of editor) for third-party modules that may want to expose content editing functionality (e.g., plugins/buttons and other behavior).
add config options for plugins/aloha to editor config file in wysiwyg module
As of now, the available configuration options are limited to those that Wysiwyg module hard-codes in its editor profile configuration UI. We're aware that this is very limiting and will hopefully solve it via #313497: Allow configuration of advanced editor settings soon. Until then, editors are supposed to support and "translate" the configuration options that Wysiwyg currently hard-codes.
enable the editor/editing without going to the dedicated edit page (contentEditable frontend editing)
This is something I'd like to defer to separate issues. I already started to think about this topic and totally agree that editors like Aloha need something different/new. However, Drupal's APIs and general design makes this very hard to implement. One highly important and extremely challenging issue with that is going to be security. In the end, this totally is within the scope and goals of the Wysiwyg project, and it's going to be the job of Wysiwyg module's API to provide the infrastructure and triggering/invocation of (compatible) editors at the right time, in the right place, for the right content, and for the right user. Individual editor plugins/implementations should not have to think and worry about that. So for now, let's focus on the regular integration with forms.
This is exciting stuff, I like the Aloha demos. I hate to be the doubter here, but it feels like WYSIWYG would require a *lot* of work to properly support this sort of in place editing? Correct me if I'm wrong. I'd be curious to see some sort of roadmap as to the changes WYSIWYG would require to properly implement an editor like this. If we can get the tasks lined up as tickets, maybe we can tackle them one by one as a community? It's probably too much to expect one person to do it - the temptation will always be to just make a custom module, because it probably will be easier...
Just thinking aloud... comments/thoughts/rants? ;-)
We recently lost a bid because Drupal had no inline editor. Their current (5 year old website) had this feature and they wouldn't live without it. It would be great to have this available!
@greg.harvey, The closest thing to such a roadmap would be the Wysiwyg 3.x Roadmap, but so far there's (strangely enough) been low interest in helping out getting there. However, to get closest to the experience in the editor demos (that is, editing content inline without first going to an edit-tab) we'll probable need help from another module focused on "AJAX-fied/on-demand" editing to create the basic form, if you see what I mean.
@BarisW, I'm sorry to hear that you lost the bid, I wish there was something more I could have done at this point - other than saying that's where we'd like to be, but we need more help from the community.
The roadmap group post looks interesting. I guess we should get it broken down in to open 'task' issues people can pick away at. There might be low interest in helping out, but as people tackle things perhaps there's scope to drive effort towards some key roadmap issues?
Regarding the AJAX stuff, I took a quick look around - this could be interesting:http://drupal.org/project/jstools
@sun: The AJAX/AHAH-driven inline editing could be really good and is the direction that would need to be taken for an effective Aloha Editor integration, otherwise the benefits of AE are lost. Of course AE already provides functionality for doing this, we just need a (wafer-)thin layer to integrate it.
Very interesting... at first glance the Aloha repositories concept seems like it could/should/might play well with Media somehow
Subscribing. I think an effective inline HTML5 editor is something that every Drupal site could use. I know my clients would absolutely love this feature.
Just a warning to anyone who implements Aloha, it doesn't work in IE 8 or older. Only the latest browsers will work. The editor requires ECMAScript 5. Older browsers, like IE 8, will throw errors and the JS on the page will be broken. https://img.skitch.com/20110529-gc4gxjmcgt69gjcwihu4ju1fkt.png
Additionally, the aloha.js file is 1 meg minified.
Subscribing. This would be awesome!
Sub. I know clients would love this, and it's an excuse to get them to stop using older IE versions.
Subscribe. This is very interesting and would like to she support.
Looks promising, subscribing of course.
Compatible browsers are listed here : http://www.aloha-editor.org/wiki/Browser_Support and it includes Internet Explorer >= 7.
Their wiki says they support IE7+. But, none of the demos work in IE7. Can someone point me to one that does?
@mfer: I'm wondering if this can be because IE needs HTML5 shiv or a specific library/tool ? But indeed, that's curious to see broken demos although they claim it is compatible (I don't have IE right now to test unfortunately).
They have browser tests at : http://testswarm.aloha-editor.org/run/alohaeditor
Which produce this obscure graph : http://testswarm.aloha-editor.org/user/alohaeditor.
@jide The InnerShiv code has only been adopted in HTML5Shiv and Modernizr since April 2011. @mfer Is any of these included in the 1M? At first glance Aloha just seems to call jQuery directly for any dom rebuilding. Info on InnerShiv. I am not familiar with ExtJS though and I don't have more time to look.
I'm the project manager for NYSenate.gov. We'd be interested in using this editor if a stable implementation were to be developed. Subscribed.
Agreed, it looks promising.
inline editing would be a huge usability improvement for drupal and clients would totally love it. +1
Subscribe! Definitedly! :D
I am working with a programmer to develop a D7 module for this. An example can be seen (and used) at http://inlineedit.venturacottage.com (user and password are demo)
Looks awesome, artatac! Worked fine on Chrome.
Man, I can't wait to use that on my sites, artatac! Seems to work fine in Safari.
Yup, that just blew my mind.
As I paid a programmer to develop a D7 module for this, I decided to make it available via my site for a small charge for those who regard it as valuable, and to help me make my money back.
And I guess the license for the module is GPL right?
absolutely, I hope people take it improve it and do what they want with it - that is fine. Much of what I do with Drupal myself I try and offer back (free) via my sites tutorial section of helping in the forums/issue queues. I am just hoping that as I had to shell out real money for this others who want it now will chip in.
@artatac/@jackbravo: Nice work, but this really needs to be taken to its own discussion. Food for thought: offer it as an alternative method for fundraising, set a sales goal at which point you'd release the code to d.o?
Good points (i am new to this as an idea) I paid $150 for the module so if I can get that back I am happy to make it available free.
@artatac: maybe update your store to have a stock counter, setting a total to the number you want to sell to recoup your costs? And no, I don't know how to do that, other than manually changing the description ;-) But thank you for being very accommodating!
Drupal Commerce has a stock option that I DO use but of course as it is a digital product that never runs out (I dont really want to add it to the product type just for this purpose. It also seems that human nature would be that people would see it will be free once 10 have been sold and just wait til others trigger the threshold. I think the bottom line is that it was worth it to me to put my hand in my pocket and pay to create it, others will decide if it is worth it to them.
TBH, while it looks very cool, and although you seem open to release this as GPL if your get your money back, I have to say that it feels like something against drupal principles to sell a module like this. I understand you spent some money on this, but I guess you had a reason to (I mean a professional project or something ?), and I can't remember how many hours and money I spent (lost sometimes) to develop modules, patches, contributions in general (and I am far away from other contributors)... I guess it's ok to do so (and of course you absolutely have the right to), but as far as I can tell, this is the first time I see a module sold in issues queue. Hopefully, people behind WYSIWYG did not sell the module ;p
BTW, It could be interesting to know who the developer is, we are an open community here I think, and other developers could help continuing this work.
In case it was unclear, I totally get the fact you paid for it and you are open to release this free if you've got your money back, and I did notice you are totally transparent about how you got it developed. I hope i did not hurt any feeling here, but I had to say this.
No hurt feelings. Like you I have really benefited from the free help advice (and contributed modules) that enable me to sell my time by adding value to my clients websites. In hindsight I should have seen if there was enough of us who wanted to raise a bounty of $160 to pay my developer to create it and then give it back to the community for free. I seem to have gone about this the wrong way. So perhaps I can do this now and ask who wants to chip it $16 towards this. - I will remember for future
Just added my $16 to to the lot.
Thanks - 2 down 8 to go...
Looks interesting, subscribing.
Chipped in $16. Thumbs up for the good work.
Thanks for all your support it is appreciated. this is now available free via http://drupal.org/project/aloha Can anyone help me get it into git. Also keen to hear from people with programming skills to help make it even better!
drup me a mail any time to axel.rutz at clever-systems.net and we will git it in!
would be happy to help.
code still needs some love...
Attached patch is more or less same in green, but using Wysiwyg API.
Aloha.module's overly eager and exciting idea of editing in the front end is completely unsupported by Drupal (core)'s APIs and way of thinking. Sorry, a blunt truth.
The way to success is to think in small steps. The entire topic of "contenteditable" (or rather: "true wysiwyg") is a monster topic, a huge can of worms, and something we definitely want to attack in the Wysiwyg project - but again, to make any substantial progress in the first place, we need to "think small", in actionable tasks and milestones.
And that means to get the editor loaded and working in the first place.
Going to commit this to a 7.x-aloha branch in a minute.
@sun: thanks, that's a great step forwards. While the stand-alone module does some crazed hackery, the benefits of inline editing are clear, so you might consider this to having been a brief tangent that showed some possibilities and will hopefully get more people interested in contributing.
And maybe we are early enough in the d8 cycle to influence it's structure to accept inline editing without hacks
@DamienMcKenna & others: As mentioned before, "inline editing", (true) "wysiwyg" and whatnot are amazing buzz-words. No one ever stated that this wouldn't be the goal of the Wysiwyg project. In fact, it totally is (as the name implies). And another fact is, as also mentioned before, that the attempt in aloha.module opens a dozen of cans of worms (of which most are very well known and discussed already, just look into our queue), and the mere fact of opening all cans at the same time without having any answers or solid understanding of the underlying APIs doesn't really provide any kind of hope for resolving the issues at this scale anytime soon.
The way to make substantial progress is to evolve in small but solid steps at a time. The Wysiwyg project provides the dedicated collaboration space and module-wise technical infrastructure for accomplishing the tasks and challenges at hand. Also note that #1275560: Add editor: Mercury arose as a new competitor in this field recently. Which, on its own, manifests this project's foundation once again: Even in times of html5 and modern technologies, there are multiple solutions that people might want to use (or not), but regardless of which, the technical challenges, questions, and answers remain the same.
Fact is, this patch/branch (and likewise aloha.module) is supposed to work, but it does not. Critical bugs/challenges are outlined as @todo in the patch/branch. We need to get the fundamental editor working and integrated into Drupal, before even thinking about long-term vaporware.
If you want to help to move this forward, make sure to create patches against the 7.x-aloha branch, please. :)
@sun: could you possibly outline a plan and create a chipin for a thorough approach to solve this?
I've got a somewhat working patch for 6.x that I've been working on. Should I open a new issue under 6.x for it?
One thing to look at is the aloha-nodeps.js rather then aloha.js. This version does not try to load its own jQuery, but then I run into a problem with it looking for a lot of other needed extensions it is looking for.
Oh, now I see in the patch that the aloha-nodeps.js is being loaded, disregard above
Attached is a patch (to the aloha branch) that should work with the current aloha dev branch (https://github.com/alohaeditor/Aloha-Editor.git)
Things I've learned today:
Things I haven't learned today:
To be continued...
hm, been looking around for a couple hours, and correct me if I'm wrong, but it appears like there is no way for an editor to define global settings that can be changed through the UI. I did find a todo in wysiwyg_load_editor that seemed related to global settings, but I would need to get at these settings before they are populated into Drupal.settings.wysiwyg.configs.aloha.global, as they need to go in Aloha.settings before aloha.js loads. If we could simply load them up from wysiwyg_aloha_load, we could at least get configurable, albeit global, plugins going.
Attached patched works with the downloaded version.
It includes a rather dirty hack using doc.rdy to set an attribute on a script tag, this is necessary because the downloaded version is missing this commit: https://github.com/alohaeditor/Aloha-Editor/commit/e02d210171ad226932853...
Which allows one to set the plugins to be loaded from Aloha.settings.plugins.load.
I tried to monkey-patch around this by redefining Aloha.getPluginsToBeLoaded, but the problem is that you would have to redefine it in between aloha.js loading and Aloha.init running, which is impossible afaict.
I also tried to re-run Aloha.init after redefining it, but this just caused a shitstorm of errors...
It also seems like the current version of Aloha (0.10.0) is feature frozen, but the API is still changing dramatically. Simply compare the exposed Aloha object in the zip download with a recent dev checkout.
That being said, it doesn't look like there is a chance that the ability to have a different set of controls for different fields will be added any time soon.
related: make contenthandler configurable per editable
@seutje I've just caught wind of the Aloha editor and I'm evaluating what work has been done on the Drupal front for integration. I haven't had a chance to test your patch yet but the Aloha module is working pretty well right now (I've only tested in my sandbox so far, see #1486488: Roadmap). What advantages are you seeking by using the WYSIWYG module to achieve Aloha editor integration?
Unity, consistency, centralization and history, I guess.
Basically, I was tinkering around with http://drupal.org/sandbox/kmadel/1218202 and felt kinda silly, as I was pretty much building my own contentEditable editor, and my own vessel for attaching it to the elements I wanted. These are 2 pieces of functionality that already exist and have their own team behind them. So it seems like the more sane solution to adapt WYSIWYG module to support a contentEditable editor, and then make WYSIWYG support in-place editing (probably in a separate module), if there aren't already efforts towards that.
All due respect to the guys working on http://drupal.org/project/aloha, but I have absolutely no desire to work on a stand-alone project. We've been here before with TinyMCE and FCKeditor modules, and I don't want to go back to that.
Also, considering WYSIWYG module already has a large number of users, adding an editor to it will increase exposure for that editor, which would hopefully increase awareness of alternatives to iframe-editors.
Thanks for your reply on your line of thinking! My original line of thinking was that contentEditable WYSIWYGs were different enough from iframe WYSIWYGs that they would be completely different approaches, perhaps with the WYSIWYG module renaming itself to iframe WYSIWYG and a contentEditable WYSIWYG module popping up. But I'm sure I'm not thinking this all the way through. For example, perhaps it is valuable to have the Aloha editor enabled on the edit page? I'm not entirely sure and I'm really curious as to what your thinking is on this.
On a side note, if we do deem the approaches for the two types of WYSIWYGs different enough to put efforts into a separate project, I don't have any problem starting with a stand-alone project that doesn't integrate with other contentEditable WYSIWYGs (like the aloha module) because I believe we have a few lessons to learn before we can architect an effective generalized solution. My belief is inspired by one of Brooke's laws, "When designing a new kind of system, a team will design a throw-away system (whether it intends to or not)." http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pilot_system
Their internal working might be vastly different, but that doesn't really matter. If Aloha Editor wasn't able to act properly upon textareas (which, as I stated earlier, it isn't), swapping it for a contentEditable div can easily be achieved in WYSIWYGs attach hook.
As I stated earlier, I first want to integrate the editor into WYSIWYG. The patch in #77 does this, on the edit page or wherever else a WYSIWYG field is rendered with an input format that invokes Aloha Editor.
I've written a quick (and dirty) inline editing module to test this and it also works fine. Except detaching editors not part of the active form (or something).
Either you believe this belongs in the WYSIWYG module, and then please, test the patch (against the aloha branch) and provide feedback on it, or you believe this belongs in a separate module, and then by all means, develop said module.
A lot of what you said seemed very offensive towards the maintainers of WYSIWYG, as you made it sound like you would rather work on a stand-alone module, because WYSIWYG module is a throw-away solution. I hope I misunderstood this, because I feel that making a separate module per editor is the throw-away solution.
Hi artatac (and everyone interested in what happened here),
The reason you don't see folks selling modules in this community is because the GPL licence allows the first person you sold it to to post it for free. Just one of the magical things about open source is that because we're all using the same code, we all have an interest in improving that code together. With no one private company we depend on for supporting our systems, we reduce our being left out in the cold (imagine the fallout if Microsoft suddenly crumbled). If you are interested in learning more about what makes open source work so well, the most famous text on the matter to this date The Cathedral and The Bazaar by Eric S. Raymond http://www.catb.org/~esr/writings/homesteading/ (it's free).
@seutje The way I'm read everything I hear us agreeing for the most part so let's see if I can write my point out more clearly.
You suggested "make WYSIWYG support in-place editing (probably in a separate module)," which makes sense to me. The logic behind implementing something on an edit form and acting on a text box is different from inline editing. So we agree, the inline editing logic is probably going to be in a separate module.
When you said, "I have absolutely no desire to work on a stand-alone project" I think what you meant was that you have no interest in working on an inline editing module that isn't trying to support all of the WYSIWYGs already integrated with the WYSIWYG module. I also agree with the point that it is a good goal.
My message I was going for in comment #81 was to make the point that sometimes it's not always best to start with a one-size-fits-all solution as suggested by one of Brooke's law. As sun mentioned, "the entire topic of "contenteditable" (or rather: "true wysiwyg") is a monster topic, a huge can of worms." As the the issue of how best to do "true wysiwyg" is a monster topic, how best to do "iframe wysiwyg" was a monster topic before the WYSIWYG module nailed it. It's possible that the WYSIWYG module could not have succeeded without the lessons learned of those that came before it (TinyMCE module, FCKeditor module, etc.) so perhaps we should consider participating in the Aloha module's efforts for it may be that valuable first try that gives us the insight we need to make a generalized solution really rock.
In other words, instead of designing the problems of the first draft into WYSIWYG, where they will be hard to remove later on, it might make sense to learn the hard lessons someplace else, that will hurt less when you have to throw it away: the aloha module.
So any editor first needs a 7-year fail run in a standalone module, like FCK and TinyMCE?
I give up, didn't really need this anyway.
kinda misleading that this issue was marked as "needs review"
Maybe something could be built around the editorial functionality provided by Panels' In-Place Editor (IPE), which gives glorious in-place editing of a panel page's layout, and the new Field API Pane Editor which lets you edit individual fields one at a time using the Overlay module? Just brainstorming.
@seutje I just tested #77 and it works like a charm! I'm sorry if I gave you the impression that I was suggesting that Aloha integration with the WYSIWYG module on the edit page was a bad idea :-/.
Let's move the discussion of how to do inline editing to #1514272: Inline Editing and the WYSIWYG module and let this issue be focused on adding the Aloha editor to the edit page as the WYSIWYG module intends it.
Thanks for trying the patch!
seutje: I'd love to try this patch but I assume that it needs a reroll against the latest dev version and the latest version of Aloha. This seems like a good issue to get some attention now that it is clear Aloha WON'T be in D8 core after all. I'd much prefer to keep using the WYSIWYG module (primarily because of Media's integration) rather than standalones so if this issue could get renewed attention that would be awesome.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.