The WYSIWYG seems to be unavailable when form fields generated by filter_form() are in a form element with a name other than "format".

For example, I'm writing a custom module with a settings page. The settings page contains a form which is processed by system_settings_form(). Within the form, there are three elements for a filtered text field:

        /* Code slightly modified from original. */
	$form['hub']['intro'] = array(
		'#tree' => false,
		'#weight' => 30,
	);
	$form['hub']['intro']['mymodule_search_hub_intro_text'] = array(
		'#default_value' => variable_get('mymodule_search_hub_intro_text', ''),
		'#description' => t('Introduction text displayed on the search page.  You may include instructions for the user here.  Please note due to system limitations, the WYSIWYG editor cannot work for this field.'),
		'#title' => t('Introduction'),
		'#type' => 'textarea',
		'#weight' => 10,
	);
	$form['hub']['intro']['mymodule_search_hub_intro_format'] = filter_form(variable_get('mymodule_search_hub_intro_format', variable_get('filter_default_format', 1)), 20, array('mymodule_search_hub_intro_format'));

Although I have a filter_form() properly set up, the code in wysiwyg_process_form() in wysiwyg.module will ignore the field. For this reason, the WYSIWYG editor will not be displayed. The following, however, because the field previously named "mymodule_search_hub_intro_format" has been renamed to "format", displays the WYSIWYG editor (but will not work as needed with system_settings_form_submit()):

	$form['hub']['intro'] = array(
		'#tree' => false,
		'#weight' => 30,
	);
	$form['hub']['intro']['mymodule_search_hub_intro_text'] = array(
		'#default_value' => variable_get('mymodule_search_hub_intro_text', ''),
		'#description' => t('Introduction text displayed on the search page.  You may include instructions for the user here.  Please note due to system limitations, the WYSIWYG editor cannot work for this field.'),
		'#title' => t('Introduction'),
		'#type' => 'textarea',
		'#weight' => 10,
	);
	$form['hub']['intro']['format'] = filter_form(variable_get('mymodule_search_hub_intro_format', variable_get('filter_default_format', 1)), 20, array('format'));

Comments

remi’s picture

remi commented

I replaced line 89 in wysiwyg.module.

Original:

      if ($item === 'format' && $index > 0) {

Modified:

      if (isset($element['#validate']) && isset($element['#validate']['filter_form_validate']) && $index > 0) {

That seems to be doing the trick for me. I didn't do any extensive testing, however.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I'm inclined to mark this issue won't fix.

If you look at the definition of http://api.drupal.org/api/function/filter_form/5, then you will observe that all you need to do is to pass the third $parents argument properly, to use 'format' as form array element key, and have the submit value use the desired key name.

All of this will be much improved in D7.

remi’s picture

remi commented

I see what you're saying. Let me give you a bit more information about my module.

The form I'm trying to make the WYSIWYG module work with is with one that is passed to system_settings_form(). This eliminates the need to write my own _validate() and _submit() functions, since system_settings_form() will take care of everything.

But I also need the form to work with the i18n module, and I need to display in my form which variables are multilingual variables (meaning those that can be different across language versions of the site).

There are also two filter_form()'s in my settings page. For all this to work, I had to use the following line, which I wrote above:

$form['hub']['intro']['mymodule_search_hub_intro_format'] = filter_form(variable_get('mymodule_search_hub_intro_format', variable_get('filter_default_format', 1)), 20, array('mymodule_search_hub_intro_format'));

I have to keep the "mymodule_search_hub_intro_format" name, in form arrays with #tree set to false, because:

1. I have to give it a different name than "format" because there are two filter_form()'s. Both of them are in different fieldsets with #tree set to false.
2. If I name it "format," the variable value will be set with the name "format". I.e. variable_set('format', $value) instead of variable_set('mymodule_search_hub_intro_format', $value).
3. The "mymodule_search_hub_intro_format" matches the variable name I specified in the settings.php file to be multilingual.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I can understand that FAPI and filter_form() are not easy to grasp. Just use the following, which should eliminate your issues:

$form['hub']['intro']['format'] = filter_form(variable_get('mymodule_search_hub_intro_format', variable_get('filter_default_format', 1)), 20, array('mymodule_search_hub_intro_format'));
remi’s picture

remi commented
Status: Active » Closed (won't fix)

Well, you win! I rolled back my wysiwyg.module to the original version, edited my settings form using your code, and it worked!

I do agree that I was having a hard time figuring out filter_form(). Thanks for the help!

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: Module doesn't attach itself to fields generated by filter_form() with an element name other than "format" » Docs: Proper use of filter_form()
Status: Closed (won't fix) » Reviewed & tested by the community

Actually, I would like to add this to handbook pages for Wysiwyg, resp. content-editing, which do not exist yet.

Did you encounter any other stuff that would be good to document?

remi’s picture

remi commented

Not that I know of. I think I described everything I could in the above.

I really wish there was an example for it in the API documentation. The handbook is good start, however. Thanks for posting this!

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Reviewed & tested by the community » Fixed

I have added new handbook pages here: http://drupal.org/node/358296

Could you please verify that all is correct there?

remi’s picture

remi commented

Looks all good to me! Thanks for posting this.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.