Hi,

Again, I know this is probably something I need, but it would be great if there was some context supplied to hook_INCLUDE_plugin(), so that a module could decide whether a specific plugin should be defined depending on where it's being called from.

A good example would be a plugin that only works on Node wysiwygs opposed to Comment wysiwygs.

Will look at providing a patch assuming this is something that you will consider.

Cheers,
Deciphered.

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Version: 6.x-2.x-dev » 7.x-2.x-dev

Hmm, we might cache the plugin meta data in the future - #841794: Cache wysiwyg_load_includes() - so a context argument in te hook would not be of much use when data is fetced from the cache since the hook would be bypassed.

There's also been a request for an access callback which would get checked before the plugin's buttons are passed to the client. The argument there was that several plugins which required various user roles were in use on the same format. Creating a format for each and every combination of roles with access to one or more plugins was not a viable solution, and just checking access in their dialogs made the toolbar crammed with buttons that did nothing.

Would an access callback (not necessarily tied to user roles) be sufficient in your case, if it is passed the entire form? You should be able to deduct if it's for a node or comment [or any Entity] in D7 using FAPI.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Right, plugin definitions should be (or are about to be) cached, just like other info hooks throughout Drupal.

We need to be bit careful here, since dynamically hidden or disabled plugins must not end up in JS settings, since editors otherwise might break at runtime.

Also note that one further idea that's not mentioned anywhere yet is to write wysiwyg profile settings into (then static) JS files; i.e., instead of outputting a bloat of Drupal.settings on all pages, Wysiwyg might dump the individual profile settings into a JS file per profile and load that when needed. There's no issue or code for that yet.

Can you elaborate a bit more on your particular use-case?

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Wysiwyg Fields creates dynamic Wysiwyg plugins (via a hook_menu callback) for each CCK with the correct configuration, so it needs to be able to define plugins based on the current content type.

Currently it is setting a $_SESSION variable on form_alter() which hook_INCLUDE_plugin() is checking for, if it finds it it reads in the data (content type) and then unsets it so that it has the required context and no other instance of the Wysiwyg (comments for instance) will receive the context.

Not exactly a nice way of doing things, but it's the only way I can really provide accurate context.

@TwoD, yes an access callback sounds like it would work.

Cheers,
Deciphered.