I just found out the nice hook_wysiwyg_editor_settings_alter() to alter the height of my wysiwyg, cool, but what was missing if some context on what form is calling this wysiwyg textarea. Maybe the hook signature could be extended with the caller form?

function scf_wysiwyg_editor_settings_alter(&$settings, &$context, $form) {

Or is there another way I can already achieve this?

Comments

TwoD’s picture

Category: support » feature

Hmm, if we add the form in there we'd probably put it in the $context variable.
The problem is that the form is not guaranteed to be available when the editor configuration is loaded, the function to load editor configs doesn't know about it. Theoretically, an editor config could also be loaded for use in multiple forms on a single page, but it'll only be loaded once. See #628110-12: Allow to alter profile and editor settings and wysiwyg.module line 349.

What do you need the form for?

scor’s picture

in my use case it's to set different settings for the wysiwyg on the comment form, but I'm assuming this is not the only use case where you'd want to tweak the settings based on the "context" where the wysiwyg appears.

TwoD’s picture

What kind of settings do you need to tweak? Is it things related to the editor's appearance like width/height/skin?
Or is it more related to what features/buttons are available in it?

scor’s picture

In my particular case it was the height.

scor’s picture

The problem right now is that all the wysiwyg settings (like the buttons) are set per text format (D7). So if I have set a text format (say filtered HTML) for authenticated users and have enable a wysiwyg on that text format, the wysiwyg will appear no matter what wherever there is a text field with the option "Filtered text (user selects text format)". I wish there was more granularity so that the wyswig settings can be tweaked on a per field bases, or per form basis. Such context would help, even if there is no UI, there would be a programmatic way of doing it.

TwoD’s picture

I see. One problem with allowing per form/field alterations of settings is that we'd currently need to pass a full copy of the settings object to the client for each form/field. That builds up to quite a lot of bytes fast. Data we also can't cache now.
We eventually have to refactor the storage of the settings to remove redundant data for Wysiwyg 3.0 anyway - or we won't be able to support multiple profiles per format for example.
But, it's a pretty big change so it'll take time, which we've been short of for a while...

With the current code, the hook would only be called for the first form/field on the page, and there's no guarantee it's the comment form.
Depending on how the 3.0 refactoring turns out, maybe we can add the form to the context in a safe way.

scor’s picture

Thanks @TwoD for the insightful explanations, I look forward to seeing more context. for now I will keep using my very dirty hacks to work around this... :(

m4olivei’s picture

I'd like to see the ability to alter setting on a per field basis as well. In my case, I'd like to set 'force_p_newlines' and 'forced_root_block' to FALSE for fields where I don't want paragraph tags automatically inserted. For one project I got lucky in that all the WYSIWYG's on a page needed the settings to FALSE, so I was able to do it in hook_wysiwyg_editor_settings_alter by checking the path. In another project, not so lucky as the field I need to set the settings to FALSE on was together with the Body field on the node form which I wanted to leave alone.

Is there any way to change the settings per field on the client side using Javascript?

TwoD’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)
Related issues: +#2274177: Allow altering settings per editor and field

Please see #2274177: Allow altering settings per editor and field. I could not find this issue at the time of posting that patch.