Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
I'm working on an integration of the media module for the aloha editor. To do so I need to be able to extend the configuration of the aloha editor.
Proposed resolution
Provide the necessary hooks to extend the configuration of the aloha editor.
The attached patch introduces such hooks. The approach bases on the possibility to use bundles for the aloha editor configuration: http://aloha-editor.org/builds/development/alohaeditor-0.21.0-SNAPSHOT-s...
Remaining tasks
Reviews of the approach needed. Currently it looks fairly easy - to good to be true ;)
User interface changes
none
API changes
New hooks:
edit_aloha_bundle_info()
edit_aloha_bundle_info_alter()
Comment | File | Size | Author |
---|---|---|---|
#18 | Screen Shot 2012-09-28 at 4.43.58 PM.png | 21.18 KB | jghyde |
edit-make-aloha-editor-extensible-by-other-modules.patch | 5.69 KB | das-peter |
Comments
Comment #1
Wim LeersHi Peter!
Thanks a lot for your patch. The major issue with your patch is that it introduced Aloha Editor-specific hooks. I'd really like to avoid that, if possible, and just rely on Drupal's hook_library()-based dependency system.
I've got a counter proposal for you: #1760386-4: Migrate Aloha Editor integration from the Edit module and make it work on the back-end.
- Look at the sample implementation (search for
/* @aloha */
to find all Aloha-specific code).- Look at the
drupal-aloha
bundle for AE for more details.- Finally, look at the README: http://drupalcode.org/project/aloha.git/blob/7516db6:/README.txt#l20
- I know that it is not as clean as what you proposed, but it does "correctly" mesh Drupal's JS dependencies handling and Aloha's dependency handling.
Marking as "postponed (maintainer needs more info)" first, before potentially closing this. I'd love your input :)
EDIT: fixed link.
Comment #2
das-peter CreditAttribution: das-peter commentedIndeed, I didn't like that either. I still like the approach of wysiwyg - an unified API for different wysiwyg's, however Aloha could really become the one and only ;).
Absolutely awesome! The only thing which really scares me is following part in the README.txt:
I hope we can make this somehow obsolete by
3. Improve our build of Aloha Editor, so that we can leverage Drupal's hook_library() even better.
I'll switch to the new approach asap.. Since I've next week off it could take a bit until I can provide a feedback.
Another interesting thing is #807996-14: [meta] Input filters and text formats, the Media module really could use a generic / clean way to handle this.
A very exciting idea is the "Nested editables" (oEmbed) as described in the Drupal 8 WYSIWYG Roadmap.
Comment #3
Wim LeersYes, for now even @sun agrees we shouldn't put a WYSIWYG API in core, we should merely ensure that other WYSIWYG editors can have the same abilities.
Why does that part in the README scare you? It won't be made obsolete by the improved build; the improved build will only affect Aloha Editor itself. The example in the README is about modules that ship with their own custom Aloha Editor plug-ins. I think something just might not yet be clear to you. Have you taken a look at the ASCII diagram in the README? Let me know if I need to explain something more clearly :)
With regards to macro tags and handling that: please see #807996-23: [meta] Input filters and text formats (just posted that). Let's continue (and centralize!) the discussion there? :) And yes, "nested editables" are very exciting. But they can be interpreted in a myriad of ways. Spark alpha 5 ships with one nested editable: captioned images. "Nested editables" does *not* imply oEmbed, though it *could*.
Nested editables can also be just
<img>
tags (i.e. that's the example I just mentioned), but they can also be the generic "macro tag" stuff. The generic "macro tag" stuff could be based upon oEmbed though. You're aware of the token_filter proof-of-concept we did? I'd be happy to give you a demo of that as well — I think you'll like it :)Finally, you're saying that you're working on Media module integration for Aloha Editor. That's AWESOME — thank you! :)
At DrupalCon, Joe Hyde stepped up and volunteered to work on kick-ass Media module integration for Aloha Editor. Needless to say, I think it makes a lot of sense for the two of you to collaborate, to avoid duplicate effort and for greater velocity :)
Immediately after posting this comment, I'll be e-mailing him and pointing him to this very comment, that should get the two of you in touch with each other.
P.S.: you may want to consider enabling your drupal.org contact form, right now there is *no* way to reach out to you!
Comment #4
jghyde CreditAttribution: jghyde commentedPeter @das-peter--
Let's collaborate! I sent to an email. And anyone else who wants to get this media_aloha going (that is, the integration of the media module with the Aloha WYSIWYG) please join us!
Joe
Comment #5
Wim LeersRetitling this issue to reflect the direction we've been moving towards.
Comment #6
Wim LeersDesigns & specs for Aloha Editor + Media: #1773748: [meta] Media + in-place editing.
Comment #7
Wim LeersMoving to the Aloha project.
Comment #8
Wim LeersComment #9
das-peter CreditAttribution: das-peter commentedFirst rudimentary integration based on the "new" aloha/drupal plugin architecture is pushed to Joe Hydes sandbox.
Commit: http://drupalcode.org/sandbox/jghyde/1770808.git/commit/f241aa6
Local tests were successful, however there's still a lot to do!
Comment #10
Wim LeersThat's GREAT! Do I have to set up the Media module in a specific way to get this to work?
Comment #11
das-peter CreditAttribution: das-peter commentedNo, at least not as far as I know. But I'm not sure if it works with the 7.1 version of the Media module, I've used it always with the 7.2 branch.
@Wim Leers I really struggled to use the new architecture to define aloha plugins - took a while I figured out how I could achieve a proper integration. It would be awesome if you could check if the way I did it now is the right approach. If so I'll provide a very basic example for the documentation.
Comment #12
Wim LeersI did document it in the README.txt, and documented it by full example in the Caption module. That was insufficient?
Comment #13
das-peter CreditAttribution: das-peter commentedDamn, I didn't recognise the Caption module as example because I used, and thus searched, a different pattern to define the aloha plugin.
I use following code to define the aloha plugin (copy paste from another plugin):
But this will only work if I register the JS like this:
Key is, that it won't work if I register the JS-file with the plugin in the library array. I've to register the bundle and define the plugin to load. That will find the js file, if it's naming matches the standard, and initialize the plugin.
Comment #14
webchickWANT. :)
Comment #15
jghyde CreditAttribution: jghyde commenteddas-peter--
Thanks for the module! I'm about to try it out.
Even though the last time I peeked at the Media Project, v2 was still *dev, Media 7.x-2.x is the way to go, IMO. They are moving parts that were in 7.x.-1.x media module into separate projects.
Comment #16
das-peter CreditAttribution: das-peter commented@jghyde: You're absolutely right. I don't think it makes a lot sense to take media 1.x into account. And I hope as soon as this integration is ready the 2.x version will be the recommended one.
I think the most important next step will be to define how the text filter of the media module has to work ( Also see #1664418: Replace custom WYSIWYG integration and support WYSIWYG Fields module instead).
Currently it inserts media module specific placeholder-text. To make this working with the true wysiwyg approach I had to declare the media filter as security filter :|
We need to keep a close eye on these issues too:
#807996: [meta] Input filters and text formats
#1706688: [meta] In-place editing, inline macros, editables, and Wysiwyg in core
As soon as we've a decision how the filter has to work (it has also to be compatible with other filters e.g. Image Resize Filter) we can flesh out the integration, mainly the JS, to make it as shiny as the screens in #1773748: [meta] Media + in-place editing
I don't think we should rush on the aloha media integration itself and prefer to make the media filter thing future proof in a first step.
Does that sound sane?
Comment #17
jghyde CreditAttribution: jghyde commented@wim leers was mentioning some kind of token technique to replace the Media module's json array placeholder.
Comment #18
jghyde CreditAttribution: jghyde commentedJust finished testing. This module 7.x-1.x or media_aloha successfully inserted the image into a textarea! Beautiful!
A couple of notes for others trying this. Make sure that you have the most current Aloha git pull of 7.x-2.x. If it's been a while, you will also need to download and enable the Admin Icons module http://drupal.org/project/admin_icons.
Get the latest 7.x.-1.x branch of media_aloha to test http://drupal.org/sandbox/jghyde/1770808
Thanks das-peter!!
joe
Comment #19
das-peter CreditAttribution: das-peter commentedYay, I was able to switch the filter type from
FILTER_TYPE_SECURITY
toFILTER_TYPE_TRANSFORM_DOM
- just took about 5 hours... :|It's likely that before this change, the stored value contained the raw html instead the media filter token after several edit actions.
Now the token should be kept. That way the file display stays configurable.
The hardest part for me was to properly handle the aloha detach and attach:
In
Aloha.bind('aloha-editable-created')
I've to check ifDrupal.edit
is available. Because if it is available I've to wait with the token replacement untilDrupal.edit.state.fieldBeingHighlighted.bind('edit-form-loaded.edit')
is fired.To ensure the media token is stored I've to replace the placeholders used during editing. I use
Aloha.bind('aloha-editable-destroyed')
to know when to replace the placeholders and store the media filter tokens into the content that will be stored. Unfortunately at that point I can't usealoha.setContents('...contents...')
because that would re-enable the editor. Thus I ended up with some ugly code to figure out if I deal with a textarea/input of another html element.Regarding attach; I suggest we try to ensure, that
Drupal.edit.state.fieldBeingHighlighted.bind('edit-form-loaded.edit')
happens beforeAloha.bind('aloha-editable-created')
.Regarding the detach; I'm not sure if I ended up with this solution because of my lack of knowledge or because of a "flaw" in aloha.
Ideas very welcome!
Comment #20
Laz5530 CreditAttribution: Laz5530 commentedHi
its great what you've done here.
Do you know how could i integrate the common/table plugin?
It should be pretty much the same to integrate as the common/image plugin.
Comment #21
Kazanir CreditAttribution: Kazanir commentedWhat is the current condition of this integration? This would really be awesome to see some more work on and I'd be potentially interested in sponsoring it if necessary -- I'm already involved in harassing the existing Media developers and helping 7.x-2.x to progress.
Comment #22
Kazanir CreditAttribution: Kazanir commentedTesting the available sandbox and it appears to make Aloha + Media (latest devs of everything which is probably the issue somewhere) not work.