Make Image2 widget linking possible without a direct dependency of Link Plugin.

[Olek Nowodziński]

A followup of ​https://www.drupal.org/node/2510380.

Problem

At the moment, linking of Image2 widgets depends strictly on Link Plugin's CKEDITOR.plugins.link.(parse|get)LinkAttributes

• ​https://github.com/ckeditor/ckeditor-dev/blob/7856fe93f844be5053fa62cad1ece1ba6fc8635b/plugins/image2/plugin.js#L412-L421
• ​https://github.com/ckeditor/ckeditor-dev/blob/7856fe93f844be5053fa62cad1ece1ba6fc8635b/plugins/image2/plugin.js#L615
• ​https://github.com/ckeditor/ckeditor-dev/blob/7856fe93f844be5053fa62cad1ece1ba6fc8635b/plugins/image2/plugin.js#L1355-L1356

Because of this hard dependency, when the Link plugin is not loaded, there's no way to enable Image2 widget linking with an external link parser/serialiser (like (parse|get)LinkAttributes).

Cake recipe

The idea is quite straightforward: let's provide the link parsing/serialisation API via static CKEDITOR.plugins.image2 namespace, which ​already exists.

A method like CKEDITOR.plugins.image2.getLinkAPI() could return CKEDITOR.plugins.link namespace. Or a custom object, if one decided to overwrite it:

CKEDITOR.plugins.image2.getLinkAPI = function() {
    return {
        getLinkAttributes: function () { custom implementation },
        parseLinkAttributes: function () { custom implementation }
    }
}

Profits:

1. Re–enable linking when Link plugin is not loaded.
2. Allow a custom parsers/serialisers, which could be much simpler than default CKEDITOR.plugins.link.(parse|get)LinkAttributes implementations.

[Marek Lewandowski]

cc

[Olek Nowodziński]

A prototype pushed to ​branch:t/13885.

[Wim Leers]

@a.nowodzinski pinged me. I tested this, and it works splendidly.

Full review plus how Drupal would use this API at ​https://www.drupal.org/node/2510380#comment-10522410.

Text from there quoted here:

Good news! @oleq notified me that he has a proposed solution ready for testing at ​http://dev.ckeditor.com/ticket/13885#comment:5. I worked on updating the above patch to use the new API that his patch adds. And it indeed allows us to simplify the code here, *and* not pretend the CKEditor <code>link</code> plugin is present.

Note this is a future interdiff, that we cannot use until we update to CKEditor 4.5.5 (see #2321583) and until that fix is actually <em>committed</em> to CKEditor 4.5.5.

So, hurray, this will become more maintainable with CKEditor 4.5.5!

[Wim Leers]

Remember my rant in chat about how the link plugin's data model is full with legacy stuff that makes it very hard to understand and use?

Well, I'm afraid this API will actually have to explicitly document that. Because if it doesn't use the exact same data structure, then it won't work.

Except… I could actually "ignore" link's data model and just use my own, as long as getLinkAttributes() returns the expected data structure ({set: {…}, remove: {}…}). Because the only thing that "actually" needs to be able to deal with parseLinkAttributes()'s return value, is getLinkAttributes(), right?

[Olek Nowodziński]

@Wim: If you decide to use a custom Link dialog then yes, you can use whatever parseLinkAttributes() (getLinkAttributesParser()) implementation you want and you should be safe.

However you just need to keep the getLinkAttributes() API ({set: {…}, remove: {}…})) because it is used in CKEDITOR.plugins.image2.stateShifter to change the state of the widget.

I'll extend the documentation strings for both methods implemented in this ticket. I think that Link Plugin's legacy data format also deserves a few words of comment.

[Wim Leers]

Okay, thanks for confirming!

[Wim Leers]

This will allow me to fix something in drupallink (Drupal's custom link plugin): the link plugin does "not" support just about any attribute you throw at it. The drupallink plugin does (needs to be able to).

Therefore, with the empowerment to have our own data structure in parseLinkAttributes(), we *can* support that without abusing link's data model.

See ​https://www.drupal.org/node/2608434#comment-10531568.

[Olek Nowodziński]

Pushed an extensive documentation of getLinkAttributes(Parser|Getter)() and updated documentation of (parse|get)LinkAttributes() to ​branch:t/13885.

[Wim Leers]

Thanks!

That looks perfect :)

[Marek Lewandowski]

Great! Merged to master with ​git:68b6b3bc.