Add %conf_path% and %plugin_module_path% to plugin path render placeholders/replacements to make features reusable

This is a way. But it only supports %plugin_module_path% for plugins provided by hook_ckeditor_plugin().

Another (better) way would be if CKEDITOR saved the module path for every plugin, when it collects plugins, but that's more work. Maybe later.

Alright, this is the right method. It's really weird CKEDITOR collects plugins like this...

The way simpler method that applies to 1.13 and dev is to only add %conf_path%, which is enough in my case.

The one in #6 is the best way. That should get in.

Yes, do #6. It's the only one not hidden, but that's not very obvious.

#5 is weird. #7 is only for people with 1.13 (like me).

The issue really was about those placeholders in the plugin path. Not just about adding the relevant module for every plugin info. That was a necessary side effect.

I really need those placeholders, because my make files depend on them :-) and it's The Right Thing.

I could fix and reroll later next week, if necessary.

http://cgit.drupalcode.org/block_usage/tree/block_usage.modules.inc

I'm on my phone in a dubious country so I can't see the interdiff between #6 and #11.

I'm not sure what the aforementioned plug-in problem is, but if it's about the weird contrib inclusion, I agree. But that's a big CKEditor issue and I really don't want to mix into there. It should work like {first link}

OMG fucking phone sucks ass.

BTW, about your

> What is it that needs fixing?

If #6 and #11, you fixed it. I didn't see the patch (change) earlier. Stupid phone, stupid Internet, dubious connection, I'm not sure what's real anymore.

@mikran Yes, you have to do it manually =( (The full paths don't even belong in the export code IMO, but there they are.) Recreating the feature probably breaks it again.

I RTBC because #17 and personal experience.

@jcisio That would be a very good next step, but could be the NEXT step. This issue still fixes a valid problem. We can make more issues to fix it even better.

Modules (not projects) that have ckeditor as dependency:

• ado_permissions
• ck_content_injector
• ckeditor_blocks
• ckeditor_kcfinder
• ckeditor_media
• ckeditor_paragraph_paste_fix
• ckeditor_skin
• ckeditor_syntaxhighlighter
• ckeditor_widgets
• ckgoogledoc
• cod_wysiwyg
• codebook_wysiwyg
• commons_wysiwyg
• drustack_wysiwyg
• entity_embed
• lightning_wysiwyg
• local_storage_ckeditor
• media_ckeditor
• screenshot_paste
• sprout_wysiwyg
• token_insert_ckeditor
• varbase_editor
• vsf_wysiwyg
• wysiwyg_fields
• xeditor

Relevant, but another issue: better tokens in Editor CSS and Styles JS paths.

I'll fix this patch this weekend. I use %conf_path% all the time.

Previous patch was broken. Not sure why. Module path replacement failed, because 'module' wasn't included in the renderable/token data anymore. Probably something changed in ckeditor.module with executing orders or something.

New patch:

• Fixed the 'module' token
• Added a helper to get all plugins, including 'module'
• Removed all explicit 'module' keys from the plugins hook, as stated in #26
• Edited ckeditor.api.php to reflect the new very useful %plugin_module_path% token

I like this a lot. If a module defines its plugin using %plugin_module_path%, it's automatically featurized like that, and reusable everywhere. %conf_path% is still only manual. We could add a pre-featurize alter to add tokens to tokenless paths, but that would have to be another issue.

The interdiff is so big because I could remove a lot from the previous patch.

My test plugin in ck_plugin.module:

/**
 * Implements hook_ckeditor_plugin().
 */
function ck_plugin_ckeditor_plugin() {
  return array(
    'ck' => array(
      'name' => 'ck',
      'desc' => t('A CKEDITOR plugin'),
      'path' => '%plugin_module_path%ckeditor/ck/',
      'buttons' => array(
        'ck' => array(
          'label' => 'CK!',
          'icon' => 'ck.png',
        ),
      ),
    ),
  );
}

I've no idea what's going on with the CI, but it's not the patch.

If there are no tests, why is CI triggered? And even if it is, shouldn't no tests be an automatic pass..?

Green is Good!