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)
Comment | File | Size | Author |
---|---|---|---|
#9 | 775162.patch | 2.81 KB | Bevan |
Comments
Comment #1
elly CreditAttribution: elly commentedJust ran into this myself - investigating but wanted to add a "me too" in the interim.
Comment #2
jenlamptonThis 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:
http://drupal.org/node/789612#comment-2926980
Comment #3
elly CreditAttribution: elly commentedUpdate:
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!
Comment #4
markus_petrux CreditAttribution: markus_petrux commentedTo 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.
Comment #5
Breakerandi CreditAttribution: Breakerandi commentedSame 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
Comment #6
robcarrI 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.
Comment #7
Bevan CreditAttribution: Bevan commentedThis 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?
Comment #8
sinasalek CreditAttribution: sinasalek commentedI also have the same problem described in #6
Comment #9
Bevan CreditAttribution: Bevan commentedThe 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?
Comment #10
robcarrWith 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.
Comment #11
danyalejandro CreditAttribution: danyalejandro commentedtesting with the ckeditor module instead of the wysiwyg module. Everything works fine. Maybe it's something about the wysiwyg module?
Comment #12
robcarrJust 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:
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...
Comment #13
Bevan CreditAttribution: Bevan commentedI 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.
Comment #14
sunThanks 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.
Comment #16
hgouveia CreditAttribution: hgouveia commentedi 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
and it worked for me
Comment #17
ywarnier CreditAttribution: ywarnier commented#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... !?
Comment #18
Bevan CreditAttribution: Bevan commentedIf you are still having this problem with versions since this was fixed, please open a new issue.
Comment #19
mr.andrey CreditAttribution: mr.andrey commentedJust 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)
AND
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.
Cheers,
Andrey.