Plugin configuration

Yes, it doesn't configure the plugin per text format. Global configuration is pretty easy to deal with. What I'm after is being able to configure plugins depending on the text format.

Yes, but in this case there is no tag to bind to. These plugins handle custom tags (much like how the Media module inserts media), and hides the custom tag and replace them with HTML for rendering in the editor. In this case, the plugin needs to get the tag that the filter is configured to use for subheadlines, in order to display the placeholder in Aloha with the same tag (so I'll render the same way as it will end up looking when the filter later does the same thing).

Other plugin might have other configuration they want from the filter. For instance, a Media module plugin might be configured on one text format (available to most users) to only allow inserting images from OEmbed, while another text format (for editors) configures it to allow uploading of images.

As Aloha has already implemented all the complex trickery involved in getting settings from the filter to the editor depending on text format, it seems a shame not to let plugins in on the deal so the end experience of the user simply is that they configure the plugins on a text format basis (which would seem logic to them).

Well, an event would be simple to implement in the current Aloha, but I don't think it's easy from a plugin developers viewpoint.

I still think the easiest for both parties would be piggy-backing on Aloha's selection of configuration, using a class.

I'll attempt to cook up a patch to see if it is a workable idea.

Here: http://aloha-editor.org/guides/plugins.html

I figure that if the code that fixes the data-allowed-tags when changing text format, also set a class on the element depending on the format, the plugin could provide a configuration with the 'editables' setting the correct configuration per class. If you look at that first example on that page, and mentally replace #title and #teaser with .plain-format and .simple-format (these being the classification of the text format machine name), you'll get the idea.

Then we'll only need a hook in the aloha_pre_render_text_format to allow the plugin module to discover that it should provide the proper configuration for the text formats being used. Really, it could be done without this, but then it would be up to the plugin module to add the proper settings to the configuration all on its own.

I discovered that it is somewhat complicated by what I'd call a Aloha bug. Currently the standard plugins use the editable.obj to figure out what config to use, but that's the div that Aloha creates for textareas, instead of the original textarea that has the classes.

We can work around this for the moment being by using getEditableConfig(editable.originalObj) instead of getEditableConfig(editable.obj) in the plugins, but we loose the option of configuring standard plugin this way. However, it's really a but that should be fixed in Aloha.

With the attached patch, a module might pass its filter configuration to the plugin like so:

function mymodule_aloha_filter_settings($format_id, $selector) {
  $list = filter_list_format($format_id);
  // See if the format uses our filter.
  if (isset($list['mymodule']) && $list['mymodule']->status) {
    if (isset($list['mymodule']->settings['config_setting'])) {
      return array(
        'plugins' => array(
          'myplugin' => array(
            'config' => array('setting' => 'default'),
            'editables' => array(
              $selector => array('setting' => $list['mymodule']->settings['config_setting']),
            ),
          ),
        ),
      );
    }
  }
}

Input?

I see you beat me too it in #1791758: Manage our own textarea -> div mapping (fixes Aloha on textarea having style="width: x; height: y;" set).

I'll reroll this one.

There.

I know it's the global settings, as there's really no concept of local settings in Aloha. In particular, the 'local' settings for a particular editor is in the global Aloha.settings.plugins.myplugin.config.editables.. I decided to let hook_aloha_filter_settings return a "full" Aloha settings array to merge in, in order to allow it to add in global configuration if it was needed, but it could also be modified to assume that what the hook_aloha_filter_settings returns should go under Aloha.settings.plugins (can't go any deeper, as aloha.module can't assume anything about what plugins a module implements.

Doing it like the caption module does it, is not an option, as the point was to be able to configure it per text format.

The two examples you give looks simple, but are problematic to implement. Where is "$form['some textarea with processed text']" supposed to be? It can't be an form_alter function, as this would require the plugin module to know all forms which might contain (differently named) textareas using Aloha.

One way to get all the textareas is using a pre_render function on the form element, just as aloha.module does to add it's settings, but take a look at the logic of that function (which has been split in two by your latest commit). We'll have to duplicate most of it for each plugin, which was what I was trying to avoid by letting it call a hook to make things simple for the plugin developer. I have tried implementing a plugin this way, and it sucked so hard that I created this patch in the first place.

I don't understand the resistance towards adding a hook to make it easy for plugin developers to add their text format settings without having to add a lot of boilerplate code. The specific implementation might need some work. An alternative way, which I just thought of, don't know if work, and don't know if you'll dislike as much as a hook, is to use a new "aloha_plugin_settings" key to the array returned from hook_filter_info, and let aloha.module call that to get the plugin configuration. Not a new hook, but a callback.

I know Aloha jumps through quite a few hoops in order to support configuration per editable, but I'm not sure about what you want me to create an issue for? What I don't get is, why do it all the way down under Aloha.settings.plugins.myplugin.config.editables, instead of having the whole tree under Aloha.settings being editor specific. Makes more sense to me. Paired with a form of inheritance of a default configuration, where each editable can then have specific config items overridden would make things easier, in my opinion.

OK, I agree that using drupal_add_js is just as good, but as you say, determining when to inject text format dependent settings is the tricky part.

However, we do have the advantage over modules adding CSS in hook_init(), as we can know what filters are available on a given page, due to the pre_render function in aloha.module. We only care about when what filter is being used in an editing context (CSS for the end result will still have to be done the $every_page way), and so aloha can just add the settings for the used filters.

I'm trying to make sure that Drupal 8 won't ship with Aloha-specific hooks. We want to make the barrier as low as possible for alternative WYSIWYG implementations.

Well, we have a conflict of interest here. We (the project I'm working on) chose Aloha for the possibilities for custom extension, not for it's swapability. In theory I agree that it's a noble goal to make the RTE as swappable as possible, the problem is that you end up with the lowest common denominator. The WYSIWYG module has been going down this path for some time, and how many addons for it is there?

Playing the devils advocate, this whole issue goes against that goal, if we see it as something alternative RTEs should be able to duplicate. CKEditor can never use a plugin written for Aloha. No matter what the solution, there's a hook, explicit or implicit, that's Aloha specific.

That said, however, I prefer solution 1. Apart from having the excellent quality of being my own idea, it's simple to understand, explain, and implement. And it makes sense to have it in the filter_info. If we get a competing RTE editor, it can use a similar mechanism, and allow modules to support both, if they have the resources.

I'm not even sure I understand option 2 and 3, and I consider myself a pretty capable Drupal developer. I think there's a bit too much fiddling with magic arrays involved with working with aloha.module, for my liking already, and I can't imagine how a relative newbie might feel.

There is only a single, global instance. A singleton. Hence it must be reconfigured on a per-editable basis.

If we could dynamically swap the settings for that instance, it wouldn't be such a problem, but that's not possible with the current architecture. But it is somewhat a problem that Aloha works under the assumption that every editable on the page is equal, with the "plugin configuration per editable" feature haphazardly thrown in for good measure. But it's complicated to change, even if getting blessed by the upstream maintainers.

To make it easier (trivial!) for plug-ins to support editable-specific settings.

Oh, right. Well, I was a bit confused by the things you linked to. the last one is definitely wrong, it should use Aloha.activeEditable.is() on the keys of something, in order to duplicate the logic of the plugin implementation... But as you say, it complicates things. Perhaps a more solid solution would be to implement a config class (I'm surprised they haven't already), and let it handle the logic of finding the right settings. But I haven't looked into all of Alohas config usage, so I don't know if that's feasible.

We only know that for *forms* that use the format selector!

Yes, but that's pretty much what we can support out of the box.

From what I can gather from a quick lookie, edit.module looks at the fields and extracts the filter id, so it knows the filter of the fields.

Also it seems to gather the data-allowed-tags attribute, which duplicates code in aloha.module. Shouldn't it rather call a hook in the selected wysiwyg module, to allow the given module to do whatever magic it needs?

Modules that uses formats in odd ways not through the format selector? Well, there's nothing much we can do about that.

I agree. But the only way we're going to get this in Drupal 8 core, is if it's going to be swappable.

So basically, we can't implement this, because if it's in core, it needs to be swappable, and custom Aloha plugins is never going to be swappable? Do we have to create a adv_aloha module for this kind of thing then?

Hmm, talking a step back, WYSIWYG plugins is always going to be bound to a particular editor, and if Aloha gets in core, it'll get an advantage over other editors, as people is more likely to make plugins for it due to it being the de-facto standard editor. And that's going to happen whether we provide an API for integration or not, if we don't, people will just hack around the lack of API (look at how Page Manager overrides standard Drupal menu callbacks for an example), in order to make Cool Stuff (TM). Really, the only way to ensure swapability is to *not* include any editor at all but only an API.

One might argue that an API where it's well documented what's general
WYSIWYG API, and what's specific to a particular editor is more likely to foster interoperability.

Oh noes! I was going to say that this makes most conceptual sense to me too. But then I realized this is hook_FILTER_info(). It's about filters. We don't need to be able to configure editables based on filters, but on text formats. Hence this actually doesn't work…

But a text format is a collection of filters. Without any filters, it's nothing (well, a pass-through security hole in any case). Filters are the things that makes text formats work.

But yes, it assumes that any plugin that needs configuration will have a companion filter that does something. A hook doesn't have this limitation.

Which only leaves three options:

As I see it, it still hard to implement per text format settings in 2 and 3. At that point in the request, there's no way to know what formats is being used on the page, so the only option is to loop through all formats defined in the site (but that might be the safer bet), whether aloha is active for the given format (which is not possible in the current version), check if it applies to a given format (in the case that it has a companion filter), and add settings for all, as the current aloha_add_format_settings() does. Which is doable, but currently it requires all plugin modules to duplicate the looping logic of said function, which seems a waste to me.

In any case, seems to me that 2 and 3 requires patching core, which is problematic with D7?

Currently, the only workable solution I can see is a hook. A hook_aloha_add_format_settings_alter might be all that's needed. But I could still be missing something.

Gods, getting Alohas plugin configuration code fixed up might turn out to be the easy part. :-)

You're saying that it should really have the following "levels" of configuration: 1) global, 2) text-format, 3) filter.

Well, what I really meant was closer to what you're describing. I agree that a filter on its own doesn't make sense, I was thinking more along the lines of "this filter, in this text format".

hook_aloha_format_settings($format)

I like that. Plugin doesn't have to loop through the formats themselves, but can let aloha.module figure out which formats we'll want config for (whether aloha then loops through them all, is alohas business). Having to check for your own filter is fine as you say, it allows for non-filter specific plugins to use it too.

I think it's the best of both worlds, no?

Indeed. :-)

Just to check the details:

I'd say that hook_aloha_format_settings() should provide the class name used for the format ether as an argument, or in the $format object, so the plugin module doesn't have to guess it.

Implementing hook_aloha_format_settings() could look like this (passing the class as $format->selector):

function mymodule_aloha_format_settings($format) {
  $list = filter_list_format($format->format);
  // See if the format uses our filter.
  if (isset($list['myfilter']) && $list['myfilter']->status) {
    if (isset($list['myfilter']->settings['somesetting'])) {
      $settings =  array(
        'plugins' => array(
          'myplugin' => array(
            'config' => array(),
            'editables' => array(
              $format->selector => array(, $list['myfilter']->settings['somesetting']),
            ),
          ),
        ),
      );
      drupal_add_js(array('aloha' => array('settings' => $settings)), 'setting');
    }
  }
}

Yes?

It is tempting to create a helper function so it becomes:

drupal_add_js(aloha_plugin_settings('myplugin', $conf), 'setting');

It sure could be better, but this is workable, no?

It's a bit wonky, but it works yes. There's some issues around the contentHandler.sanitize thing you pointed out, but it's serviceable for now.

Exactly! :) Glad we're on the same page :)

Excellent. :-)

Of course. I'd say: hook_aloha_format_settings($format, $selector).

Fine by me, makes total sense.

I'd rather not do that :)

I get the motivation behind removing it, but on the other hand I think it's pretty ugly to have these big nested arrays where half the keys are boilerplate. Goes with Drupal.settings, I guess...

I can whip up a patch tomorrow, I already have code that wants to use the feature.

And here. Pretty close so what I had in the original patch.

I've taken the liberty of changing the $selector argument to $class. Means that the hook has to add the leading dot itself, but then it doesn't have to do string manipulation to get the simple class name (in case it wants to invoke other kinds of JS magic).

After a bit of rewriting, my module that uses the feature works fine.

That's pretty close to my original version, apart from it letting the plugin return the settings rather than altering them. ;-)

But, yeah, having each plugin do a drupal_add_js seems to be a bit roundabout when in 99% of the cases the plugin wants to add settings to the aloha settings array.

I can add in the $settings by reference thing, if want?