hey folks,

i'm using version 6.x-2.x-dev (i need jQuery 1.3.x for the fancybox module) and noticed, that the node/*/edit and node/add userinterface is somewhat corrupted.

some more detailed info on behaviour:

  • hierarchical select (for selecting/creating taxonomy terms at node/*/edit, node/add) brings "You don't have JavaScript enabled"
  • wysiwyg (with tinymce activated) won't show up
  • uberimage js-widget (with tabledrag functionality) breaks

when i'm on the node/*/edit and node/add screens, my firebug-console gives me the following error: "cell[0] is undefined" (tabledrag.js / line 130)

the strange thing is, that e.g. on the content/taxonomy admin page, the tabledrag functionality works find and no error is thrown in the firebug console.

any help or tips greatly appreciated

(if i should provide more detailed info, i will try my best)

#9 775162.patch2.81 KBBevan
Members fund testing for the Drupal project. Drupal Association Learn more


elly’s picture

Just ran into this myself - investigating but wanted to add a "me too" in the interim.

jenlampton’s picture

This latest update also breaks the CCK reordering on admin/content/types/contenttype/fields :(

Someone posted a duplicate issue with some info that might be useful here:

elly’s picture


My "cell[0] is undefined" errors from tabledrag.js turned out to be a conflict with some form alter code in one of our custom modules - not specific to jquery update (was causing trouble with tabledrag.js in /misc, with jquery update disabled, too). This seems to be related to how the form is rendering its table html, not with any js conflicts. Just wanted to post in case anyone else who's having this problem is googling around - investigate for form alter shenanigans!

markus_petrux’s picture

To add a bit more information to #3...

The kind of things that can generate this error is a form alteration that unsets or locks access to a high level form element that is also exposed to CCK via hook_content_extra_fields(). For example, one may do unset($form['menu']) without checking the form id, or things like this, but it has the side effect to break the tables generated by CCK in Manage Fields screen with empty TR elements, which is what then causes the javascript error in tabledrag.js

Since there may probably be a lot of other possible causes to render empty TR elements, which is a bad thing, maybe tabledrag.js could be fixed to ignore empty rows, or maybe even remove them from the DOM before parsing the table. I would say the second is a lot easier to do.

Breakerandi’s picture

Same problem here! Additionally, no collabsibly field works anymore, so for example, i cant click on "Input format"..

I created a new issue, because i think it has nothing to to with tabledrag.js: http://drupal.org/node/806352

arrrgh’s picture

I have encountered part of this problem updating to 6.x-2.x-dev (23 Apr 10) with the WYSIWYG module. Tried with latest versions of TinyMCE and CKEditor libraries and they will not appear in the text area with jQuery Update enabled. Collapsible fieldsets (along with vertical tabs, autotype for taxonomy terms etc) do, however, still work. So it doesn't look like there will be a simple answer to this problem.

Bevan’s picture

Title: bug in tabledrag.js (causing broken UI on node/*/edit) » tabledrag.js missing core patches, errors with nested <table>s
Status: Active » Needs review

This seems to be because #329797: tabledrag.js doesn't play nice with nested tables never got ported to jQuery Update's replace/tabledrag.js. Which is rather odd. What is the process for porting core javascript patches to jquery update?

sinasalek’s picture

I also have the same problem described in #6

Bevan’s picture

2.81 KB

The patch for Drupal core applied cleanly to jQuery Update's replace/tabledrag.js, and testing on admin/build/menu, admin/build/block, single & multiple CCK text fields as well as single & multiple CCK tablefield fields (nested tables) passed. A CVS patch for jQuery Update is attached.

Please test & review the patch.

Given this is the same as the core patch and no further changes were introduced, perhaps this is already RTBC?

arrrgh’s picture

With the latest DEV version of jquery_update (11 July 2010), I removed problems reported with rendering the WYSIWYG buttons on core 6.17 site.

However, just tried out the core updates to 6.19, and I'm back to the same problem of losing all WYSIWYG buttons (CK Editor and TinyMCE). Haven't had the same problems with table drags, vertical tabs etc reported earlier in this thread.

I tried the patch at #9 with no effect. And the patch at #329797-21: tabledrag.js doesn't play nice with nested tables was committed, so I'm assuming was in core 6.19 release anyway. Only way to bring back WYSIWYG buttons is to disable jquery_update, or may just try updating core to 6.18 (security updates only) on the live site. For info, I also tried the patch at #858578-1: Errors due to changed order of scripts, which stops jquery_update effecting the order that the scripts are loaded, but, again, that didn't help.

So it may be that the WYSIWYG aspect is a separate, but related issue.

danyalejandro’s picture

testing with the ckeditor module instead of the wysiwyg module. Everything works fine. Maybe it's something about the wysiwyg module?

arrrgh’s picture

Just tried again - think some Drush finger problems knocked out a few of my DEV modules during an update. All seems fine now with WYSIWYG.

So far the latest version of jQuery_Update 6.x-2.x-dev (and core 6.19) seems to work with latest stable releases of:

  • WYSIWYG - TinyMCE and CK Editor
  • Node Relationships - although that needs DEV version of Lightbox2 to get Modal Windows to work
  • Vertical Tabs
  • Table Drags - including nesting - on Taxonomy, Book, Blocks, CCK fields etc

But not tried with Uberimage.

So maybe this is clear now? Maybe if one other has found all to be well, please change the status to RTBC...

Bevan’s picture

Status: Needs review » Reviewed & tested by the community

I don't think the issue in #10 is related to this, marking RTBC, as this has now been tested more thoroughly on a production site.

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed to 2.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status: Fixed » Closed (fixed)

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

hgouveia’s picture

i had the same problem in misc/tabledrag.js , "cell[0] is undefined" on the line 133 , so i went to that line and changed it

if (cell[0].colSpan > 1) {
if (typeof cell  == "undefined" && cell[0].colSpan > 1) {

and it worked for me

ywarnier’s picture

#16 solved my problem. Without going into the debugging details, it seems only fair to me to check the existence of the cell before trying to access it. Reading from the whole set of related bugs, it appears that many javascript code attempts might break this little code right here at line 133, and having a simple check is just good practice (and solves the problem).

Except in this case we are checking if it is undefined, and if it is, we go further... !?

Bevan’s picture

If you are still having this problem with versions since this was fixed, please open a new issue.

mr.andrey’s picture

Just for reference, to get jQuery 1.7 working with jQuery UI 1.8.24, I needed to do the following:

Fix the tabledrag issue:
http://drupal.org/node/775162#comment-4316658 (#16, makes the cell[0] error go away)
http://drupal.org/node/893538#comment-4255934 (restores the handles)

Then patch jQuery UI module with this:
http://drupal.org/node/749126#comment-5897444 (accept versions higher than 1.7)

Get jQuery UI code unpacked into sites/all/libraries/jquery.ui.
Create a "versions.txt" file that says "1.8.24", so the patched jQuery UI module can tell the version and act accordingly.

Now blocks/draggable views seem to work as well as some custom code I use that needed higher versions of jQuery and jQuery UI for.

Hope this saves someone a headache.