Hi,

I have a name field set to accept unlimited values. It always gives me an ajax popup error the second time when I use the "Add another item" button for the node. "An error occurred while attemping to process /system/ajax/. Unable to get value of the property 'field' object is null or undefined".

Thanks in advance for help.

Comments

Alan D.’s picture

Can you let me know the file and line # that this occurred if possible, this should be in the error logs / watchdog tables in the admin reports area.

Thanks

Alan D.’s picture

Crude workaround is to set a finite limit, say 5 names. Being limited to just 10, this wouldn't work if you were defining a team listing :(

smallpotatoe’s picture

Hi Alan,

I looked in mysql watchdog table and the reports error log, this error doesn't get logged. And unfortunately, a team listing is exactly what i'm doing...

Alan D.’s picture

I just tried this on the user bundle (i.e. a user field) and I had no issue using FF (I added 5 fields, using title, first name, last name components). Can you think of any other modules that you have installed that can effect this element?

[EDIT]
I just tried IE9 too with no issues. A Google search, shows this error only 5 times, and 4 are related to issues with other JScript elements on the page (note: on projects completely unrelated to Drupal).

Are there other JScript errors being recorded? Do other multiple fields work on this page? (Maybe try a simple textfield and a date field)

Alan D.’s picture

Also, using FF / FireBug or Chrome what is the error trace in the JavaScript console?

Easiest way to open this is right click on the page and select "inspect element" option in chrome or "inspect element in FireBug" in FF. This should open a new area that has a console tab in it.

If no errors are recorded, use the network tab to see what the server is returning when you click the add more button.

In the JavaScript console, click the network tab and clear this.
Click add more and tell me what is being returned via the system/ajax request

Cheers

smallpotatoe’s picture

Hi Alan,

Thank you very much for your help. Even though inspect console and network both log nothing when I click Add more but I figured out this was caused by textarea fields with jWYSIWYG 0.6 enabled. Disabling jWYSIWYG and the Add more ajax worked fine again. Still trying to figure out where to log this issue.

Alan D.’s picture

Project:Name Field» jWYSIWYG
Version:7.x-1.5» 6.x-2.x-dev
Component:User interface» Code

Switching queues.

It looks like the port (where ever this user found it) is causing issues.

smallpotatoe’s picture

Project:jWYSIWYG» Wysiwyg
Version:6.x-2.x-dev» 7.x-2.x-dev
Component:Code» Editor - jWysiwyg

jWYSIWYG 0.6 was a profile found in the WYSIWYG module.

jhedstrom’s picture

Component:Editor - jWysiwyg» Code
Status:Active» Needs review
StatusFileSize
new548 bytes

I'm seeing this on a file field with a media module widget. The attached patch resolves the issue.

Also since I found this error in the top-level wysiwyg.js file, changing component.

jhedstrom’s picture

Component:Code» Editor - jWysiwyg
Status:Needs review» Active

Actually, regarding #9, what I was seeing was a result of an older version of a patch for issue #356480: Lazy-load editors. Setting back to initial component and status.

TwoD’s picture

Status:Active» Postponed (maintainer needs more info)

@smallpotatoe, can you please confirm this also happens with Wysiwyg 7.x-2.2?

deanflory’s picture

Anyone having lots of AJAX issues might want to try disabling the jquery_update module, worked for me. Just spreading the info, unsure if it's related to this issue.

jlyon’s picture

Status:Postponed (maintainer needs more info)» Needs review

I can confirm the following:

  1. This error is caused by WYSIWYG. I tried the ajax_example module's add more demo (/examples/ajax_example/add_more). It worked initially. As soon as I added a WYSIWYG element to the form, I got the JS error when I tried to click Add another.
  2. The issue exists in a fresh install of wysiwyg-7.x-2.2
  3. It also exists in the latest -dev branch: wysiwyg-7.x-2.x-dev (7.x-2.2+8-dev)
  4. The attached patch solves the issue. I had to re-work the patch from #9 because it wouldn't apply for me in wysiwyg-7.x-2.2 for some reason
jlyon’s picture

StatusFileSize
new530 bytes

Sorry, forgot the updated patch

TwoD’s picture

How did you add the wysiwyg field to the form? I just tried it (both together with the multi-value field and outside the area which gets updated) without issues.

The params argument should always be set because that function gets called from Drupal.behaviors.wysiwygAttach.detach() which finds all the editor instances matching fields in the content to be replaced by the AJAX update and detaches them one by one after fetching the trigger parameters for the fields.

Btw, I couldn't apply the #14 patch either, complained about it being corrupt at line 13.

TwoD’s picture

Status:Needs review» Postponed (maintainer needs more info)
visabhishek’s picture

Component:Editor - jWysiwyg» Editor - TinyMCE

Hi

Patch #14 is working for me. ( I am using Wysiwyg 7.x-2.2 with TinyMCE 3.4.8.)
Thanks jlyon.

romansta’s picture

#12 solved my problem.Thank you deanflory.

ralf.strobel’s picture

I can confirm the issue and #14 as a working solution.

serglo’s picture

#14 worked for me

Fons Vandamme’s picture

#14 also worked here! thanks!

muhleder’s picture

#14 works for us too, arrived at the same solution independently, then found this issue.

muhleder’s picture

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Reviewed & tested by the community

Tentatively marking as RTBC.

TwoD’s picture

Could someone able to reproduce this error (without the patch) please insert a breakpoint on the line changed by the patch, then walk up the call stack and see how come params is undefined in the first place, and what value trigger is?

pingwin4eg’s picture

I encountered a similar issue. I couldn't save a panel's custom content in In-Place-Editor because of the same error mentioned in the topic.
The patch in #14 solved the problem. So here goes the details:
In my panel which I'm trying to edit there are WYSIWYG (with CKEditor) and also text format selector with (this is important) jQuery.selectBox on it. I guess the conflict is brought by selectBox because with it disabled - all works good.

Details from JS inspection:
Drupal.wysiwygDetach() is called with trigger = "serialize" from Drupal.behaviors.attachWysiwyg.detach() (in line 97). And params there are gets from Drupal.settings.wysiwyg.triggers[this.id] where triggers have only 'edit-body-format--2' element and this.id = ""(empty string) because this is a.selectBox.filter-list.wysiwyg.form-select.selectBox-dropdown.wysiwyg-processed with no id.

I used:

  • Panels 7.x-3.4
  • Chaos tools 7.x-1.4
  • Wysiwyg 7.x-2.2 (with CKEditor 3.6.6.1.7696 library)
  • jQuery selectBox 7.x-1.0-beta2 (with jQuery selectBox 1.2.0 library)
  • jQuery Update 7.x-2.3 (with jQuery 1.7.1 library)

Hope this'll help you further!
and Thanks for the patch!

TwoD’s picture

Thanks for the additional data. I'll look into replicating this ASAP.

guillaumev’s picture

Same issue here, fixed succesfully by the patch in #14

TwoD’s picture

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.52 KB

There are a couple of problems here:

First, as discovered by @pingwin4eg, the jQuery selectBox plugin is cloning the attributes of the original select element, tricking Wysiwyg into thinking there are more format selectors than it should be. The new "selectbox" does not have an id, and could not have the same id as the original select element anyway, so Wysiwyg does not find the trigger parameters for attaching or detaching the editor.

CTools removes the form (the whole #modalContent wrapper actually) when the modal_dismiss command is returned from the AJAX call initiated by submitting the form. When a form is submitted via AJAX and all response commands have been issued, Drupal Core calls Drupal.attachBehaviors(this.form, settings) where this.form is a lingering reference to the form's element, though it's no longer part of the document.

The patch in #14 works, but I think we can target this with a more precise instrument. If params is for some reason missing, I'd like it to complain loudly early, rather than fail silently and go unnoticed until it causes serious issues.

The first one is easy to get around by making our jQuery class selectors more specific so they only apply to real input elements.

The second one needs a bit of a hack.
I see three different solutions, and I'll rank them in order of my preference:

  1. Fix Core so it only calls Drupal.attachBehaviors(this.form, settings) after first checking document.contains(this.form). That should fix all instances of this problem and avoid asking all behaviors to check if they can attach to elements which are no longer part of the document.
  2. Implement a workaround in CTools so it removes the reference to the removed form. I'll post a patch suggesting this in the CTools issue queue. Should take care of all instances caused by CTools Modals
  3. Add an extra check to Wysiwyg to make sure the format selecting we're trying to get attach parameters for actually exists in the current document. Fixes only Wysiwyg, and should not be needed since we have the context argument, but in this case it can not be trusted. It would also make it impossible to attach Wysiwyg's behavior to a documentFragment and then insert that into the current document (though I doubt most editors would not work in that situation).

I've attached the patch for 3 here, and it'd be really good if we could get 1 and 2 in as well. Links to them should appear here as backreferences from issues I'll create soon.

dealancer’s picture

any progress on that?

  • Commit 52e2675 on 7.x-2.x by TwoD:
    - #1757684 by TwoD: Fixed JS error when given a removed form as context.
    
TwoD’s picture

Status:Needs review» Fixed

Awesome, I had no idea that would happen.

The linked issues have received very little attention so far, so I'm not expecting a proper fix soon, but at least the error won't show up in Wysiwyg.

Considering this "fixed" as in "workaround implemented"...

Status:Fixed» Closed (fixed)

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