The WYSIWYG 6.x-2.1 plus TinyMCE 3.2.6 HTML editing GUI disappears from the comment field when comment_driven fields are enabled for a user. The resize tab at the bottom of the comment form still shows up though and Firebug is telling me that there are no JavaScript errors. Does that mean that the problem is somewhere in PHP?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

arhak’s picture

Title: Incompatibility with WYSIWYG using TinyMCE? » Compatibility with WYSIWYG
Category: bug » support
Priority: Normal » Minor
Status: Active » Needs review
FileSize
959 bytes
1.57 KB
66.95 KB
49.45 KB

The resize tab at the bottom of the comment form still shows up though

it is provided by Drupal, not by WYSIWYG

Does that mean that the problem is somewhere in PHP?

No, there is no bug at all.

disappears from the comment field when comment_driven fields are enabled for a user

long story made short:
- WYSIWYG works with comment_driven (see screenshot #1)
- you won't see it in the comment because there is a WYSIWYG limitation
- nevertheless, I can bring more support with a tiny patch for each module to make them understand better each other

trial:
- before applying any patch: start enabling the node's body as a driven property and confirm that TinyMCE properly shows up (then both modules can work together without conflicts)
- then apply attached patches (one for cdriven, and one for WYS) and see if both rich editors appear (in node's body AND comment's body, see screeshot #2)
- if so, open a new issue at http://drupal.org/project/issues/wysiwyg requesting them to support this module as well, and drop there a link to this issue, saying something like "here is a tiny patch to support comment_driven #747616: Compatibility with WYSIWYG, which follows the same approach of signature_format support"
(they'll know what that means)
also I recommend you to see what's in the WYSIWYG patch (even if you don't know PHP) to be aware that what you'd be asking is really a tiny detail

long story:
(it is ok if you don't understand every detail I'm about to explain, but this is technical info maintainers would need)
- limitation of WYSIWYG
according to its documentation (Developer info)

If your module uses an input format enabled textarea, your Form API array structure has to use 'format' as array key to trigger the loading

that's ok when using #tree enabled elements, e.g. CCK
but with comment_driven there is a comment_form+node_form merge which makes imposible having two 'format' sharing the same space in $form_state['values'], i.e. they can live together within the same form, but only one of them will pick the proper value (the other one won't work as a radio is expected to do)
therefore, what comment_driven does is to rename comment_form elements so they can leave disguised within a node_form, which makes, the input format of the comment not being named 'format', but 'cdriven-format' (since the former is used by the node's body)
this same issue was recognized and supported by WYSIWYG regarding 'signature_format' therefore, the proposed patch for them is to let them know we also have a compatible format they can consider as well

- support that cdriven might bring
the attached patch for cdriven only avoids disguising sub-elements of the format to let WYSIWYG the chance to recognize it IF they take into consideration the 'cdriven-format' alternative as they did for 'signature_format'

arhak’s picture

Version: 6.x-1.0-unstable7 » 6.x-1.0-unstable9

the patch from this module's side has been committed to HEAD
but the patch for WYSIWYG is still needed

if you don't want (know how) to apply a patch, this is another way to do it:
edit file wysiwyg.module, line 128

it currently reads:

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

it should read:

      if (($item === 'format' || $item === 'signature_format' || $item === 'cdriven-format') && $index > 0) {
bibo’s picture

Priority: Minor » Normal

Has anyone posted an issue about this to the Wysiwyg issues? I'm currently using comment_cck and cant update to to comment_driven, because of this issue (even if its fixed on this modules part).

I don't want to patch the wysiwyg-module manually, since it's very fast changing (and I've managed to keep all other contrib modules unhacked).
As I see it, this is definitely not a minor issue (=> changed to normal, eventhought it's critical from my point of view). This fix needs to go into Wysiwyg dev, or this module is useless to me, and likely many others.

So, I hope there is an existing wysiwyg-issue about this. I didn't find any with a quick search..

bibo’s picture

I posted the wysiwyg patch in the wysiwyg issue queue: #764626: support for comment_driven

arhak’s picture

Status: Needs review » Needs work

#2 is still valid, but after a discussion with sun it seems that the whole support can be achieved from our side #764626-23: support for comment_driven
which will need a delicate refactor for the forms' merging process

ManyNancy’s picture

Actually I think I'm going to be moving from BUEditor to WYSIWYG, so I'll be following this.

sdsheridan’s picture

Subscribing.

bibo’s picture

Issue tags: +wysiwyg

I'm also still hoping that this will be fixed, so I can update wysiwyg normally.

sraborg’s picture

Version: 6.x-1.0-unstable9 » 6.x-1.0-alpha3

Has there been any updates to this issue? I'm having the exact same problem and I haven't found any fix only other than the module hacking (which I really don't want to do) that is posted here...