ckeditor_link_ckeditor_link_menu_revert() obstructs other hook implementations

Thanks for the help! Yes, my mistake quoting the wrong lines of the API file.

I still think it's strange to have a hook implementation that will always return FALSE if nothing is found, but your tip works. I implemented hook_ckeditor_link_types_alter like this:

function mymodule_ckeditor_link_types_alter(&$types) {
  // Move 'menu' to the end of the list by copying, unsetting, resetting.
  $entry_for_menu = $types['ckeditor_link.menu'];
  unset($types['ckeditor_link.menu']);
  $types['ckeditor_link.menu'] = $entry_for_menu;
}

Actually, if you are intending for 'menu' always to come last and work as a fallback (and always returning a value or FALSE only makes sense if you do), then IMHO I think you should implement this in your module, rather than have plugin developers implement it in theirs - since your implementation of 'menu' breaks plugins without it.

Thanks again for the workaround, but I would still categorise this as a bug, albeit very minor since there is this workaround.

Maybe I am misunderstanding how you intended the module to be used. Using hook_ckeditor_link_autocomplete(), I place pseudo-'paths' into the page that only make sense to my module. They look like this: 'mlsp/1234'. Then, in my ..._revert() and ..._url() hook implementations, I know that this link belongs to me, I work out what node it should point to, and I do the checks and either return a full URL or nothing at all.

The way your module works, each plugin module should not care about the internal implementation of the links. Indeed, your own documentation says that the hooks should return "nothing if the implementing module is not responsible for the given path." The 'menu' type is not responsible for my 'mlsp/XXX' paths, so your hook description says it should return nothing. Instead, one could say that it is interfering, and blocking, and not giving my module a chance to return a legitimate path!

I think I preferred your earlier explanation and the idea that the checks in 'menu' should come last of all. In any case, the behaviour you have now is not consistent with the documentation, and I prefer the documentation than the actual behaviour! :)

Somebody on d.o thinks I'm right about something?

*faints*

Ha, seriously, thanks for looking into that. :) I haven't looked at your code but I can confirm that the fix does work as expected.