Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#28 | wysiwyg-1757684.28.patch | 1.52 KB | TwoD |
#14 | wysiwyg-ajax-error-1757684-13.patch | 530 bytes | jlyon |
#9 | wysiwyg-ajax-error-1757684-09.patch | 548 bytes | jhedstrom |
ajaxerr.jpg | 27.14 KB | smallpotatoe |
Comments
Comment #1
Alan D. CreditAttribution: Alan D. commentedCan 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
Comment #2
Alan D. CreditAttribution: Alan D. commentedCrude 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 :(
Comment #3
smallpotatoe CreditAttribution: smallpotatoe commentedHi 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...
Comment #4
Alan D. CreditAttribution: Alan D. commentedI 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)
Comment #5
Alan D. CreditAttribution: Alan D. commentedAlso, 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
Comment #6
smallpotatoe CreditAttribution: smallpotatoe commentedHi 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.
Comment #7
Alan D. CreditAttribution: Alan D. commentedSwitching queues.
It looks like the port (where ever this user found it) is causing issues.
Comment #8
smallpotatoe CreditAttribution: smallpotatoe commentedjWYSIWYG 0.6 was a profile found in the WYSIWYG module.
Comment #9
jhedstromI'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.
Comment #10
jhedstromActually, 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.
Comment #11
TwoD@smallpotatoe, can you please confirm this also happens with Wysiwyg 7.x-2.2?
Comment #12
deanflory CreditAttribution: deanflory commentedAnyone 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.
Comment #13
jlyon CreditAttribution: jlyon commentedI can confirm the following:
Comment #14
jlyon CreditAttribution: jlyon commentedSorry, forgot the updated patch
Comment #15
TwoDHow 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.
Comment #16
TwoDComment #17
visabhishek CreditAttribution: visabhishek commentedHi
Patch #14 is working for me. ( I am using Wysiwyg 7.x-2.2 with TinyMCE 3.4.8.)
Thanks jlyon.
Comment #18
romansta CreditAttribution: romansta commented#12 solved my problem.Thank you deanflory.
Comment #19
ralf.strobel CreditAttribution: ralf.strobel commentedI can confirm the issue and #14 as a working solution.
Comment #20
serglo CreditAttribution: serglo commented#14 worked for me
Comment #21
f0ns CreditAttribution: f0ns commented#14 also worked here! thanks!
Comment #22
muhleder CreditAttribution: muhleder commented#14 works for us too, arrived at the same solution independently, then found this issue.
Comment #23
muhleder CreditAttribution: muhleder commentedTentatively marking as RTBC.
Comment #24
TwoDCould 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 valuetrigger
is?Comment #25
pingwin4egI 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 withtrigger = "serialize"
fromDrupal.behaviors.attachWysiwyg.detach()
(in line 97). Andparams
there are gets fromDrupal.settings.wysiwyg.triggers[this.id]
where triggers have only 'edit-body-format--2' element andthis.id = ""
(empty string) becausethis
isa.selectBox.filter-list.wysiwyg.form-select.selectBox-dropdown.wysiwyg-processed
with noid
.I used:
Hope this'll help you further!
and Thanks for the patch!
Comment #26
TwoDThanks for the additional data. I'll look into replicating this ASAP.
Comment #27
guillaumev CreditAttribution: guillaumev commentedSame issue here, fixed succesfully by the patch in #14
Comment #28
TwoDThere 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 themodal_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 callsDrupal.attachBehaviors(this.form, settings)
wherethis.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:
Drupal.attachBehaviors(this.form, settings)
after first checkingdocument.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.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.
Comment #29
dealancer CreditAttribution: dealancer commentedany progress on that?
Comment #31
TwoDAwesome, 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"...
Comment #33
nikunjkotechaPatch #28 works even for another scenario.
For me the issue was coming when I was loading node form in ctools modal popup which had a WYSIWYG editor.
Please include this in stable version of the module.
Comment #34
TwoDThank you for the information.
Stable realeases are tagged from the -dev snapshots, so this will automatically be included in the next release.
Please see the link on the project page for my latest comment about stable releases.
Thank you for your patience.