Using CKeditor 3.0.1.4391 I get the following error:

$("#wysiwyg_imagefield-wrapper").dialog is not a function
http://mytestsite/sites/mytestsite/modules/wysiwyg_imagefield/plugins/wy...
Line 36

Comments

kirilius’s picture

Same here

deciphered’s picture

Hi guys,

Have you installed jQuery UI correctly? Check the jQuery UI README.txt for more details.

Cheers,
Deciphered.

deciphered’s picture

Status: Active » Postponed (maintainer needs more info)

Marking as more information required.

kirilius’s picture

I have the jQuery UI installed properly I believe. In the readme it says I should use version 1.6 of the library and that's what I have.

mikebell_’s picture

Hi,

Status report says jquery UI 1.6 is installed correctly.

I'll poke around a bit more.

deciphered’s picture

Status: Postponed (maintainer needs more info) » Active

No problem,

Have you you followed the WYSIWYG ImageField instructions for setting up a field?

Cheers,
Deciphered.

deciphered’s picture

Title: JS error using CKEditor » WYSIWYG plugin error on unconfigured content type

Ok, considering kirilius got past this error by configuring the module as per the instructions, my conclusion is that the WYSIWYG plugin is trying to trigger a dialog when it shouldn't be.

Hopefully I can get this issue fixed very shortly.

Thanks for the report guys.

Cheers,
Deciphered.

deciphered’s picture

Status: Active » Fixed

Fix committed to HEAD.

Will be included in next Development release.

Cheers,
Deciphered.

zach harkey’s picture

I was getting the same error, so I updated to 6.x-1.x-dev. Now the error is gone, and CKEditor is working properly again, but the wysiwyg_imagefield button is completely gone even though it's still checked under the wysiwyg profile.

Drupal 6.19
Wysiwyg 6.x-2.1 (CKEditor 3.3.2.5805)
WYSIWYG ImageField 6.x-1.x-dev
jQuery UI 6.x-1.3 (jQuery UI 1.7.2)
FileField Sources 6.x-1.2
ImageField 6.x-3.7
Insert 6.x-1.0-beta6
Views 6.x-2.11

karens’s picture

Status: Fixed » Needs work

Same error on blocks, perhaps the same error on comments (not tested). I think the default return value for the button should be FALSE instead of TRUE, or you get the button in places where it won't work.

karens’s picture

See also #895830: enabling wysiwyg imagefield widget renders blocks uneditable (?). The error went away when I changed the default return value in _wysiwyg_imagefield_attach_plugin() from TRUE to FALSE.

deciphered’s picture

Hi KarenS,

Can you confirm which version you are using? This issue is still marked for 6.x-1.0, but there are changes in both 6.x-1.1 and 6.x-1.x-dev that should resolve this issue (especially in the dev release), so can you (and everyone else) please confirm whether or not the changes in 6.x-1.x-dev resolve this issue?

Cheers,
Deciphered.

karens’s picture

I'm using latest dev version and the problem is still there. Here is what that function currently looks like:

/**
 * Helper function for WYSIWYG ImageField WYSIWYG plugin.
 */
function _wysiwyg_imagefield_attach_plugin() {
  if (arg(0) == 'node') {
    if (arg(1) == 'add') {
      $content_type = str_replace('-', '_', arg(2));
      if (variable_get('wysiwyg_imagefield_' . $content_type, NULL) != NULL) {
        return TRUE;
      }
      return FALSE;
    }

    elseif (arg(2) == 'edit') {
      $node = node_load(arg(1));
      if (variable_get('wysiwyg_imagefield_' . $node->type, NULL) != NULL) {
        return TRUE;
      }
      return FALSE;
    }
  }
  return TRUE;
}

The problem is the very last 'return TRUE'. That gets triggered if you are, say, using this in a block. I changed it to 'return FALSE' and my problems were fixed.

To test this, turn the widget on for one content type and configure your wysiwyg editor so you will see the button on filtered html. Then try to create and edit a block and notice the wysiwyg editor has the image button and behaves badly -- won't allow you to input and save text as you should. The button doesn't do anything but it seems to keep the rest of the editor from working either.

Then apply the fix and the problems go away.

deciphered’s picture

Version: 6.x-1.0 » 6.x-1.x-dev

Thanks KarenS,

I had suspected that that section would cause issues, there's too many outlying cases.
I think the best solution will be in Javascript, as there is more data available, but unfortunately my initial approach to do that was hindered by the way that WYIWYG plugins are defined. Should have a solution soon.

Cheers,
Deciphered.

kostajh’s picture

Solution in comment #14 worked for me.

karens’s picture

Also see #895256: Drupal.settings.WYSIWYGImageField is undefined on forms without imagefields which has a different solution to this problem.

jide’s picture

The approach used by _wysiwyg_imagefield_attach_plugin() is wrong IMO, we should not rely on path since a node form could be located anywhere. Just try this with node clone or from within a dialog for example...

We could have used menu_get_object() to retrieve the node, but that would not resolve the issue since a node could have been loaded when displaying its comments for example.

Unfortunately, there is no good way to be sure that we have to deal with a node form inside wysiwyg_imagefield_wysiwyg_imagefield_plugin(), so the pure JS approach taken in #895256: Drupal.settings.WYSIWYGImageField is undefined on forms without imagefields, comment 6 is the best option.

deciphered’s picture

Status: Needs work » Closed (duplicate)

Marking this as a duplicate.

I had originally intended to take a JS approach, but my original approach did not work and _wysiwyg_imagefield_attach_plugin() was simply a quickfix.