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.
Comment | File | Size | Author |
---|---|---|---|
node.jpg | 102.29 KB | Offlein | |
comment.jpg | 108.54 KB | Offlein |
Comments
Comment #1
Offlein CreditAttribution: Offlein commentedThis is probably actually a support request.
Comment #2
BarisW CreditAttribution: BarisW commentedSame here after I've updated my jQuery to version 1.7.2. Might be the cause?
Comment #3
BarisW CreditAttribution: BarisW commentedIgnore 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');
inhook_js_alter().
Removing this sorting fixed my issue.
Comment #4
TwoDHave 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).Comment #5
TwoDWithout further details about the problem I can only close this issue. Please re-open it if you can provide the requested information.
Comment #6
TwoDStatus fix.
Comment #7
yuriy.babenko CreditAttribution: yuriy.babenko commentedRan 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.