Hi,

I've been getting this error: Uncaught TypeError: Cannot read property 'configs' of undefined - wysiwyg.js:16

I mentioned it in #1794782: Editor disappears when switching to and from an Input Format but it was unrelated. It's back now. One thing that I note -- I can't seem to access any properties of Drupal.settings.wysiwyg whatsoever from wysiwyg.js (if I hack it and test). It gives Undefined. For instance, I modified it to read:

Drupal.wysiwygInit = function() {
  // This breaks in Konqueror. Prevent it from running.
  if (/KDE/.test(navigator.vendor)) {
    return;
  }
  jQuery.each(Drupal.wysiwyg.editor.init, function(editor) {
    // Clone, so original settings are not overwritten.
    console.log(Drupal.settings.wysiwyg);
    this(jQuery.extend(true, {}, Drupal.settings.wysiwyg.configs[editor]));
  });
};

The new console.log() line produces "undefined" and the next line produces that error. Interestingly, if I go into Chrome's console tool and type the name of that object (Drupal.settings.wysiwyg) it comes out fine! it's like it can't be seen within the scope of the file for some reason.

More troubling -- this only comes up on pages with Comment forms. If you are viewing a node with a comment form and then "Edit" that node in the Drupal overlay, the code loads twice -- with an error the first time (for the comment form) and then properly with no error the second time (for the node edit form in the overlay).

I've attached screenshots of Google Chrome's Console displaying the objects for both its comment and node instances.

CommentFileSizeAuthor
node.jpg102.29 KBOfflein
comment.jpg108.54 KBOfflein
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Offlein’s picture

Category: bug » support

This is probably actually a support request.

BarisW’s picture

Same here after I've updated my jQuery to version 1.7.2. Might be the cause?

BarisW’s picture

Ignore my comment. Had nothing to do with the jQuery update, but because I've sorted my javascripts using an uasort($javascript, 'drupal_sort_css_js'); in hook_js_alter().

Removing this sorting fixed my issue.

TwoD’s picture

Status: Active » Postponed (maintainer needs more info)

Have you by any chance changed the ordering of the scripts in the document? Some themes and script aggregation/minification modules may do this. Perhaps you are using an admin theme where this works but a front-end theme where scripts are ordered differently?
It sounds almost as if wysiwyg.js now gets loaded into the head tag, before Drupal.settings gets defined, instead of in the footer (or at least after wyswiyg.init.js and the settings).

TwoD’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

Without further details about the problem I can only close this issue. Please re-open it if you can provide the requested information.

TwoD’s picture

Status: Closed (duplicate) » Closed (cannot reproduce)

Status fix.

yuriy.babenko’s picture

Ran into the same exact issue. Sure enough, wysiwyg.js was being loaded ahead of Drupal.settings.

In my case this was being caused by the base theme, ZURB Foundation, moving all JavaScript into the footer (via hook_js_alter() in template.php) with zero regard for where that JS actually needed to be.