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()
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Hi 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.

das-peter’s picture

Status: Needs review » Postponed (maintainer needs more info)

Thanks a lot for your patch. The major issue with your patch is that it introduced Aloha Editor-specific hooks.

Indeed, 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 ;).

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.

Absolutely awesome! The only thing which really scares me is following part in the README.txt:

35 4) Finally, to ensure that Drupal will make your Aloha Editor plug-in available
36    wherever Aloha Editor is available, you should implement hook_library_alter()
37    and whenever $module == "aloha", you can add your dependency like so:
38      $libraries['aloha']['dependencies'][] = array('mymodule', 'mymodule.aloha');

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.

Wim Leers’s picture

Yes, 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!

jghyde’s picture

Peter @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

Wim Leers’s picture

Title: Make aloha editor extensible - plugins / bundles » Aloha Editor + Media module integration

Retitling this issue to reflect the direction we've been moving towards.

Wim Leers’s picture

Priority: Normal » Major
Status: Postponed (maintainer needs more info) » Active

Designs & specs for Aloha Editor + Media: #1773748: [meta] Media + in-place editing.

Wim Leers’s picture

Project: Edit » Aloha Editor
Version: 7.x-1.x-dev » 7.x-2.x-dev
Component: Aloha Editor » Miscellaneous

Moving to the Aloha project.

Wim Leers’s picture

Component: Miscellaneous » Code
das-peter’s picture

First 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!

Wim Leers’s picture

That's GREAT! Do I have to set up the Media module in a specific way to get this to work?

das-peter’s picture

Do I have to set up the Media module in a specific way to get this to work?

No, 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.

Wim Leers’s picture

I did document it in the README.txt, and documented it by full example in the Caption module. That was insufficient?

das-peter’s picture

Damn, 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):

define([
  'jquery',
  'aloha/plugin',
  'util/class',
  'i18n!image/nls/i18n',
  'i18n!aloha/nls/i18n',
  'ui/ui',
  'ui/scopes',
  'ui/button',
  'ui/toggleButton',
  'ui/port-helper-attribute-field'
], function (
  jQuery,
  plugin,
  Class,
  i18n,
  i18nCore,
  Ui,
  Scopes,
  Button,
  ToggleButton,
  AttributeField
  ){

  return plugin.create('media-aloha', {
...

But this will only work if I register the JS like this:

  $libraries['aloha.media_aloha.media-aloha'] = array(
    'title' => 'Media Aloha integration',
    'version' => '0.1-alpha',
    'js' => array(
      aloha_plugin_js_settings(array(
        'bundles' => array(
          'media_aloha' => file_create_url(drupal_get_path('module', 'media_aloha')),
        ),
        'plugins' => array(
          'load' => array('media_aloha/media-aloha'),
        ),
      )),
    ),
    'dependencies' => array(
      array('media', 'media_browser'),
      // Ensure the "drupal" bundle is registered.
      array('aloha', 'aloha.drupal'),
    ),
  );

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.

webchick’s picture

Priority: Major » Critical

WANT. :)

jghyde’s picture

das-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.

das-peter’s picture

@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?

jghyde’s picture

@wim leers was mentioning some kind of token technique to replace the Media module's json array placeholder.

jghyde’s picture

Just 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!!

Only local images are allowed.

joe

das-peter’s picture

Yay, I was able to switch the filter type from FILTER_TYPE_SECURITY to FILTER_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:

  • attach:
    In Aloha.bind('aloha-editable-created') I've to check if Drupal.edit is available. Because if it is available I've to wait with the token replacement until Drupal.edit.state.fieldBeingHighlighted.bind('edit-form-loaded.edit') is fired.
  • detach:
    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 use aloha.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 before Aloha.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!

Laz5530’s picture

Hi

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.

Kazanir’s picture

What 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.

Kazanir’s picture

Testing the available sandbox and it appears to make Aloha + Media (latest devs of everything which is probably the issue somewhere) not work.