0

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:

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

  • I'm not 100% sure but check last comment drupal.org/node/2101293#comment-7921275 it says "these hooks can only be implemented by the module that "owns" the types" so if type is defined not in your module, the hook is not going to be called. you could try using function node_ckeditor_link_node_revert(). If it is not used in any other module, it should work, of course it is not very good solution. – Mantas Karanauskas Aug 17 '16 at 11:35
  • @MantasKaranauskas Thanks for your interest to my question. Please look at my edit. – cFreed Aug 17 '16 at 14:11
0
+100

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.

  • Thanks for your interest to my question. Please look at my edit. – cFreed Aug 17 '16 at 14:12
  • Seeing your edit, the best way I see, is altering the revert so it follows either one of the two points you mentioned. If it works, make a patch for it and treat it as any other patches in your project. Contributing that patch back to the project may be nice too then, – Raf Aug 17 '16 at 14:22
  • If I correctly understand, your suggestion is to patch the original CKEditor_link module? I must confess I'm a bit afraid to eventually create new issues otherwise :) but it's true that, at least keeping it purely at my own module level, it might be a solution. Please include this suggestion to your answer, so I can accept it before the bounty ending if no other answer appears. – cFreed Aug 17 '16 at 14:35
  • Done. Also, it's very much appreciated by module maintainers if a bug / issue is raised and a patch is provided along with it. It's the core principle of open source ;-) – Raf Aug 17 '16 at 14:54
  • Great: I just tried your suggestion and it works fine! Thanks a lot. – cFreed Aug 17 '16 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.