CKeditor Enabled Breaks Functionality

By default Dupal core hides all guidelines for textarea's that have widgets enabled. (see https://www.drupal.org/node/2098071)

I think there are two possible solutions:

1. Make the guidelines available again when this module is enabled and the filter option is enabled. So the browser token link is visible again.
2. Make a CK-editor button plugin so the token browser will be available via the ckeditor menu bar.

The second one is my favorite.

Great, I'm making a patch with a CKeditor pluign for this module.
I will keep you all posted.

Made a patch. It's creating a CKEditor button that is opening the token browser in a model.
Big thanks to Beljaako for helping me with getting the right token browser url.

Now i'm facing only one problem. The modal has an overlay and the modal is not drag-able. Already spent some evenings to try and search for the right approach to fix this. The standard options I'm using don't seems to work. jQuery.ui.dialog diolog.js and diolog.ajax.js are using different option names. Maybe someone can help a hand.

You need the patch supplied here to enter tokens in a editor: https://www.drupal.org/files/issues/token-wysiwyg-2235581-10.patch
If you remove the overlay via the inspect tool in the browser the functionality is working.

A zip because it are 3 new files and it seems the patch is not working well with a new image file.

Nice.

However, clicking on the link to add a token in the token browser triggers an alert:

Hello! I found a small issue related to this patch:
https://www.drupal.org/files/issues/broken_icon.jpg
The toolbar icon for CKeditor plugin is broken, I think you could put any simple image and fix this issue. This very confused on editing content.

Regards, Andrii.

@Andriy Khomych, The image is in the zip in this issue. If you can help me to apply a image to a patch it will be great. I couldn't find a method to do so.

Here's a proper patch file for #10, including the image.

Reviewing now...

Here's some PHP code clean-up and coding standards fixes.

I'm confirming #12: Clicking one of the tokens in the list yields the pop-up, even though the text field was selected before opening the box. So it's currently not possible to click or drag these from the modal.

Typing the text in manually works, but that's a huge UX hit. Copying & pasted doesn't work well because it includes the link.

So getting #12 fixed is imperative.

Now, that pop-up shouldn't be necessary to begin with. Given that you're clicking on a specific text area's token button, the token should simply go into that text area. It wouldn't make sense for them to go anywhere else. So we need to tell the JS what field to use, and drop that check entirely. Not sure if we need to add anything to the Token module to make that happen.

Sorry, @Martijn de Wit, I was busy a small, seems it is fixed without my help.

I think the second problem we're having is that context-specific tokens aren't showing up in the list. Even though I'm on a node form, I'm not seeing the any of the Node tokens showing up in the token browser list. They do, however, show up on my site's /admin/help/token. So we need to pass in the context as well.

This fixes #19. As the context isn't always available, it's better to present all available tokens. It takes several seconds to load the entire tree, but there's a "Loading..." message.

I also switched over to using dependency injection so there's no more \Drupal access.

So we're now left with fixing #12.

#1229568: Token UI 2.0 should help with the loading time.

I think CKEditor support is broken in the Token module. Here's the line that is supposed to insert the text:

          // CKeditor module support.
          else if (typeof(CKEDITOR) != 'undefined' && typeof(Drupal.ckeditorActiveId) != 'undefined') {
            CKEDITOR.instances[Drupal.ckeditorActiveId].insertHtml(content);
          }

There's no Drupal.ckeditorActiveId, is that something that was working in D7 but now doesn't?

Here we go. There's a few code standards changes in the plugin.js file but the magic is at line 38:

          // Set the active CKEditor id.
          Drupal.ckeditorActiveId = editor.name;

This fixes #12.

I was wrong about the support being broken, we just weren't using it correctly.

By the way @colan, what did you mean by "the context isn't always available"? That sounds like something that might be fixable, have you got any specific examples where the context isn't available?

#24: I don't have an example. You're absolutely right. I put some time into trying to figure out the context, i.e. the entity we're currently in, and kept running into problems. So I took a shortcut. The token_types array was empty initially so I set it to all as that's a magic term there.

But if you're interested in trying to fix this, please go ahead. I'd welcome the change. It would shrink the table, which would be better for UX.

I believe the best way to go forward with this is to populate that array with entities from the route parameters, which can be fetched using a method described in the forums.

You can then add a getTokenTypes() method to generate them like so:

$token_types = [];
foreach ($entities as $entity) {
  $token_types[$entity->getType()] = $entity;
}
return $token_types;

I believe it wasn't working in my case because I was having trouble figuring out the exact format for this. So there may be more work to do here. Good luck!

In my particular case, I've got a content type that's used as a template. Its values (including tokens) get injected into another content type with Prepopulate. So if we limit the token list in the first context, the ones needed for the second may not be available. But this is done per entity, and they're both nodes, so it probably doesn't matter.

Thank you all. @Darvanen I will review the patch soon!

#25: My biggest concern is that a high proportion of the issues I've been reading for this module are people not understanding the context - "why doesn't a node token work in a block?".

I'll give it a go if I have some time in the next few days. If this gets committed before I get to it we can start a new issue.

Holy cow, you weren't wrong @colan. I think it's more a case of "when IS the context available", not "when is it not".

The Plugin class and manager, and the CKEditor main class all have absolutely no idea which entity they are operating on because they are added in the theme layer on render. Add to this that it seems like none of the available services in the container can tell you which entity the form being built belongs to (on render) and you've pretty much got no context at all. Even the request stack only has paths which are pretty unreliable for implying entity type.

I hesitate to use the methods described in your linked page because they're based off the internal path which only works for the top level form. Nested forms such as comments on a node or media entities inside a node will have different contexts in addition to those available to the parent.

Unless there is some way of making CKEditorPluginManager aware of the parent entity of the element it's being attached to I don't see a way to bring context into this.

Let's assume this is as good as it gets for now then, and wait for someone else to test #23. (I haven't had a chance yet.) If that's all good, we can RTBC it, and then see what the maintainer(s) think(s).

#23 (with the image from the zip) worked for me on Drupal 8.5.0, for both 8.x-1.0-beta1 and 8.x-1.x-dev.

@Darvanen: Thanks for committing, but it would also be nice to provide credit to the rest of us that worked on the issue. See below.

I did?:

Issue #2912947 by Martijn de Wit, colan, Darvanen: CKeditor Enabled Breaks Functionality

https://www.drupal.org/commitlog/commit/8312/e7ea8cbacd1572f69c4c4ba26f2...

If you're talking about the form down the bottom of the screen, it doesn't reflect what's actually in the commit.

Right, but I think that only gets recorded in the commit (and thank you for that). I don't believe the credits show up in profiles from there; the form at the bottom would need to be filled out. Basically, there seems to be a discrepancy between commit credit and issue credit. For my projects, I always do both.

For example, I should be seeing credit on my profile for Token Filter, but there isn't any. Normally when I assign credit to others using that form, it show up immediately on their profiles. Sorry for the trouble, but the UX for this stuff isn't great.

Well that explains a few things if true, sorry mate had no idea about that.
Certainly won't hurt to change it!

Thanks! Worked.