Unable to interact with a CKEditor_link hook

Question

TL;DR;

My function MYMODULE_ckeditor_link_TYPE_revert() is never called.

Context

I developed a custom module MMS which works pretty fine regarding its own task, but I've trouble when interacting with the CKEditor_link module.

The problem is that node titles are internally multilingual, including all needed translations of the real title, so they're looking like [multi][en]The title[fr]Le titre[/multi].
The module is responsible to make the final display to be only The title when current language is en, Le titre when it's fr, and so on.

This works fine everywhere else, through different strategies.
Regarding CKEditor_link, I've to do the same when it looks for nodes, first to create autocomplete list of titles, then to revert to a title from a path.

What's working fine

Looking at the ckeditor_link.api.php contents, I first found the hook_ckeditor_link_autocomplete_alter() template from which I could successfully generate the expected autocomplete list using this:

function mms_ckeditor_link_autocomplete_alter(&$results, $string) {
  if ($results) {
    foreach ($results as $key => $value) {
      $results[$key] = ...extract real title from $value...
    }
  }
}

The issue

Regarding the revert process, ckeditor_link.api.php doesn't cite an equivalent hook_ckeditor_link_revert_alter(), so the above strategy can't be used.
At the opposite it shows hook_ckeditor_link_TYPE_revert(), so I imagined I could work like this:

function mms_ckeditor_link_node_revert($path, &$langcode) {
  fb($path, 'Hook revert');##
  $result = ckeditor_link_ckeditor_link_node_revert($path, $langcode);
  if ($result) {
    $result = ...extract real title from $value...
  }
  return $result;
}

But this hook is never called, as I could check using the fb() included above.

I looked for information about that and notably found these issues:

• https://www.drupal.org/node/2101293
• https://www.drupal.org/node/1107954

Although they seem to address my exact problem, I can't figure out what's turning wrong.

---

EDIT: precisions, based on received comments.

As evoked by @Mantas Karanauskas I'd been already puzzled by this:

these hooks can only be implemented by the module that "owns" the types

and I was (and I remain) not really sure of anything about what it actually means.

But we must notice that the MYMODULE__ckeditor_link_autocomplete_alter() hook works fine, while it uses the same node type: so I tend to think that this type, in the context of my module, is well considered as "owned", whatever it means.

Now based on the @Raf suggestion about ckeditor_link_get_types() I just noticed that the CKEditor_link module calls it the same way both in the autocomplete and revert processes: one more time this makes me tend to think that type is not the problem, since it's well recognized in the autocomplete process.

In the other hand, another point puzzles me from the beginning.
From what I could understand of the general Drupal rules about added module hooks interacting with pre-existing original module hooks I notably retain that there are two distinct situations, which need two different strategies to be preliminary enforced by the original module:

1. For added module to be able to alter original module hook results after it worked, original module must have placed a drupal_alter() in its own process.
2. For added module to be able to execute its own hook in place of the original module one, original module must have placed a module_invoke_all() in its own process.

Among the templates showed in ckeditor_link.api.php, we find hook_ckeditor_link_autocomplete_alter(), which relates to #1 above, and hook_ckeditor_link_TYPE_revert() which relates to #2.

Now we can notice that in CKEditor_link module:

• the autocomplete process includes a drupal_alter() call (relates to #1 and works fine)
• but despite what is suggested by ckeditor_link.api.php, the revert process doesn't include any module_invoke_all() call (should relate to #2 and doesn't work)

Strictly following the above reasoning would make conclude that the ckeditor_link.api.php templates are not reliable and that there is no solution for my issue.
But I hope I'm wrong and a solution exists...

Answer 1

My first guess is that TYPE is wrong, and the hook isn't called because of that. It's a vague term, anywasys. I checked the code and found that ckeditor_link_get_types() gets the types. You may want to add a dpm or such in there, so you know for sure which options the module looks for internally.

Edit As discussed in the comments, recapping it here, you may want to patch the CKEditor_link module. From what you explained in your edit, this seems to be a technical flaw in the module itself. Play around in the module to see if any of the options you found, work, make a patch of it, and contribute it to the original module.