I am working on a node based module. The node type there has it's own textarea ('article') besides the default "body" textarea with it's own filter format, which is stored in a field 'article_format'. This format field is not discovered by the function wysiwyg_process_form in wysiwyg.module, because it's form key is 'article_format' and not 'format' as the comparison in code line 111 of wysiwyg.module requires:

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

IMHO there is no need to name a format field 'format' and as I may have more than one textarea in an own node type with different filter formats I have to use different field names. So those textareas won't show up with a Wysiwyig Editor.

The form element itself does'nt seem to have any positive property which says that it is a field for a filter format. In my case it has $element['#element_validate']="filter_form_validate" which in this case could be used for discovering the field. But I don't know if every form element which is for filter format has this property?

Comments

sun’s picture

Category: bug » support
Status: Active » Fixed

You can safely have multiple 'format' form elements in one form, just use #tree to assign the correct form element parents (and map them also structurally to the target textarea). This is also what the third argument to filter_form() is for. See http://api.drupal.org/api/function/filter_form/6

Until D7, there is no other way for Wysiwyg API to determine whether a form element is an input format selector or contains formatting guidelines.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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

Viybel’s picture

Version: 6.x-0.4 » 6.x-2.0
Category: support » bug
Status: Closed (fixed) » Closed (won't fix)

A consequence of this limitation is that Wysiwyg doesn't work in Ubercart admin : admin/store/settings/checkout/edit/messages

Workaround:

In wysiwyg.module, replace line 124:

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

by

      if (substr($item,-6) === 'format' && $index > 0) {

Any chance this can be changed in Head?

I know it's "dirty", but the Wysiwyg module's goals should primarily be towards end users, especially for features that all other wysiwyg modules had.

Vianney Stroebel
Likwid - Spécialistes Drupal - Paris

wickedskaman’s picture

I've noticed this as well. I have not been able to get WYSIWYG or FCKEditor modules working in a fresh install of Ubercart 6.x-2.x. I will try 5.x-1.x but that is not the ideal solution. I was to take steps forward, not steps backward. WYSIWYG being less specific and allowing all fields to be converted would be ideal... a blacklist for pages where it shouldn't render would be helpful as exists in the FCKEditor module.