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.
I just try this module and I get the following error:
It happens when showing a node form, and changing an editablefield.
It does not happen in a Views display.
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Service unavailable (with message)
ResponseText: Recoverable fatal error: Argument 1 passed to drupal_array_get_nested_value() must be an array, boolean given, called in .../modules/editablefields/editablefields.module on line 343 and defined in drupal_array_get_nested_value() (line 6364 of .../includes/common.inc).
Comment | File | Size | Author |
---|---|---|---|
#65 | editablefields-1206656-65.patch | 3.25 KB | mwsam |
Comments
Comment #1
ShadowMonster CreditAttribution: ShadowMonster commentedAnyway even like this error if I do not choose 'Click to edit' the field are saved. With this option on form not appear.
Comment #2
ShadowMonster CreditAttribution: ShadowMonster commentedUpdate to views-3.x-dev fix this problem
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedMoving the issues back to the main project.
Comment #5
LarsKramer CreditAttribution: LarsKramer commentedHi, this is indeed working with Views module, but when I try to edit a field in normal node view, I get almost the same message, only line numbers differ:
EDIT: I suppose the orignal poster was using Drupal 7.2, and that's why the line numbers differ.
Comment #6
Toxid CreditAttribution: Toxid commentedI've got this too. I get the feeling that it's because of content translation, but I'm not sure.
Comment #7
drugget CreditAttribution: drugget commentedHaving the same issue on standard node view.
Comment #8
olofbokedal CreditAttribution: olofbokedal commented+1.
Default node view, no translations. The field I'm trying to edit is a boolean field, with a single on/off checkbox.
Comment #9
TheOptimizer CreditAttribution: TheOptimizer commentedI have the same error using the alpha1 version.
I believe following functions are used with wrong arguments:
- drupal_array_set_nested_value on line 474
- drupal_array_get_nested_value on line 315
Comment #10
NickWebman CreditAttribution: NickWebman commentedupdating to views-3.x-dev did not fix the problem for me.
Comment #11
MathRo CreditAttribution: MathRo commentedHi, I'm having the same problem, I check this error on the web and found this.
It's look like it's from a wrong used of a _load() method.
I looked for this in my project and just found a node_load(array(... in the trigger module. I replaced it with a correct call of node_load but the problem is still happening.
So the only solution that I found is to add or complete a condition before the call of drupal_array_get_nested_value() in the file editablefields.module.
For example I placed this :
Instead of this :
I just add the condition !is_array($form_state['edit_mode']).
I don't think this is a good solution because we drop the data of $form_state instead of use it, also I didn't look what the method drupal_array_get_nested_value() is doing.
(Hope my english is not too bad)
Comment #12
roald CreditAttribution: roald commented+1
Having the same problem. No content translation, Drupal 7.8, Editable fields 7.x-1.0-alpha1.
Reproduced on nodeview, with both "Click to edit" and direct edit on a text-field
Comment #13
presleyd CreditAttribution: presleyd commentedSame problem here.
Comment #14
charlie-s CreditAttribution: charlie-s commentedsub
Comment #15
markandrewsuttonI have not had a chance to test much, but I did get this to work in limited trials:
On or around line 508 of editablefields.module, the drupal_array_set_nested_value() call is missing the 3rd parameter. See http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_ar...
So I added in the $element to set the value.
drupal_array_set_nested_value($form_state['edit_mode'], $parents, $element, FALSE);
And it's working with a user-ref select list. Have not tried other field types .. . .
Comment #16
presleyd CreditAttribution: presleyd commentedThis seems to fix the error for text list fields too. I still have a problem with multiple editable fields on the same page. Changing a value for more than one of them only saves the change for the last field entered it seems. That seems like a separate issue though.
Comment #17
charlie-s CreditAttribution: charlie-s commentedIndeed, the 3rd argument is missing and the bool FALSE is being used in its place. Here's the current code:
Should be:
Comment #18
charlie-s CreditAttribution: charlie-s commentedHere is a patch against 7.x-1.0-alpha1.
Comment #19
AABoyles CreditAttribution: AABoyles commentedIt seemed to me that the problem had more to do with an incorrect argument than with an absent third argument. I solved the problem by basically casting $form_state['edit_mode'] to an array. Here's how you do it:
Step 1: Insert this code before line 315 of editablefields.module:
Step 2: You're done, should be fixed now.
Comment #20
Anonymous (not verified) CreditAttribution: Anonymous commentedThe code from #19 breaks other functionality. The edit in place editor would not function correctly in views.
EDIT: as well as adding in the $element variable to the function. Both solutions will break the views edit in place.
Comment #21
dgastudio CreditAttribution: dgastudio commentedsame problem.
Comment #22
Yuri CreditAttribution: Yuri commentedI had the same error appearing (with boolean field checkbox)
the patch in #18 solved it for me, but I applied that after applying this patch: http://drupal.org/node/1245326#comment-4850200
Working for normal node field with editable display, and as views editable field.
Although there appears a 'save' button, which is not needed since it auto updates the field when ticking.
I did not apply #19
Comment #23
AABoyles CreditAttribution: AABoyles commentedYeah, sorry about #19. I toyed around with it a bit more and it turned out to be a band-aid for a broken arm. Now looking for alternatives...
edit: I realized that I wasn't getting these errors when I was using editable fields in a regular view without Panel-rendered nodes. I only have this problem in Panels. Is anyone getting this error in Panels but not in Views? If so, it may just be a Panels thing.
Comment #24
Yuri CreditAttribution: Yuri commentedNo, i did'nt have Panels installed while having this issue.
Comment #25
johnvSame as #24, I only use Views & CTools, and I get the "drupal_array_get_nested_value() on line 315".
I do not (yet) get the drupal_array_set_nested_value() on line 473 & 495.
I took some code from #1267886: Fix for saving the Only changed fields, and applied the following the get-part on line 315:
In contrary to #19, this does not alter $form_state, only creates a local copy.
Comment #26
AABoyles CreditAttribution: AABoyles commented#25 is clearly on the right track, but it started throwing another error on my install ("Notice: Undefined index: edit_mode in editablefields_form() (line 321 on ..."). This is a little more verbose, but it works for me--everything is initialized, even if there's nothing in it, and it doesn't dump anything if there's anything there.
Comment #27
ymeiner CreditAttribution: ymeiner commentedFYI, this is not an issue of this module (or it is) but if you use the taxonomy access module you might find yourself stuck with a problem of the user name not being transferred after applying the two solutions over here.
I solved it on the taxonomy access side by replacing line 300
with this:
Comment #28
AABoyles CreditAttribution: AABoyles commentedGood to know! Thanks!
Comment #29
johnvI've been digging into this, and attached patch is the result.
- $form_state['edit_mode'] is now set anytime, and is used to toggle when you use click-to-edit.
- drupal_array_set_nested_value() is removed, since this summer we can use forms-in-fields, and "However if the number of array parent keys is static, the value should always be set directly rather than calling this function."
- drupal_array_get_nested_value() idem.
I still encounter the following problems, I don't know if they are related
- using 2 editablefields in a view gives me WSOD
- using editablefield click-to-edit on a node view gives me the 'empty_text'
- ther is an extra [Save] button at the bottom of the view , which is not necessary.
Comment #30
johnvPerhaps some more explemation on #29 is necessary, especially since I removed all calls to drupal_array_GET/SET_nested_value().
The patch works fine form me, but perhaps others have more complicated field/form structures...
This issues concerns the value of $form_state['edit_mode']. It is a temporary value to indicate that yo hit the [edit this field] button.
The general problem is that drupal_array_GET/SET_nested_value() expects this field to have an array as a value,
so: $form_state['edit_mode'] = array(0 => TRUE);
instead of: $form_state['edit_mode'] = TRUE;
This is corrected in the patch #29.
This way, the call to drupal_array_set_nested_value() is OK, (see #17 by csdco).
IMO the calls to drupal_array_SET/GET_nested_value() are not necessary anymore, and this is why:
- Each Editablefield is/has its own form. We set the value of $form_state['edit_mode'] ourself, when we are IN the form, So we know how to fetch it. You only need drupal_array_SET/GET_nested_value() when you DO NOT know where in a hierarchy your element is, but we DO, so we can call it directly.
Comment #31
AndrzejG CreditAttribution: AndrzejG commentedI have the same error in node view and date field, only number of line is different:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: OK
ResponseText: Recoverable fatal error: Argument 1 passed to drupal_array_get_nested_value() must be an array, boolean given, called in /sites/all/modules/editablefields/editablefields.module on line 315 and defined w drupal_array_get_nested_value() (linia 6368 z /includes/common.inc).
The message occurs when trying to enter a value using no "click to edit" option, and when pressing "Click to edit" button using the second option.
Drupal 7.10, editablefields v. 7.x-1.0-alpha2
Please help asap, as it is blocker of important functionality of my project.
Comment #32
AndrzejG CreditAttribution: AndrzejG commentedMaybe important.
I have a rules triggered by this editable date field, and saving the edited node at the end.
After closing error message I click "View" tab, and the Rules silently (without log message) performs proper action.
Comment #33
akamaus CreditAttribution: akamaus commentedI'm experiencing that error when clicking on edit this field button on node view too.
What puzzles me is the logic behind 315 line? Can someone explain, what the semantics of $display['settings']['click_to_edit'], $form_state['edit_mode'] and $form['#parents'] is?
Why so convoluted logic? Why not to have something simple like
$edit_mode = $form_state['edit_mode'];
It seems to work, btw, at least for viewing nodes.
Comment #34
johnv@akamaus, yes it is a bit confusing:
$display['settings']['click_to_edit'] is set when you set the corresponding field. You can NOT change the field directly, so there are 2 different widgets: [show-field]+[edit-button] or [editfield]. (or, more correctly [editfield]+[hidden edit-button])
if you click the button, then $edit_mode is set, [show-field] is hidden and [edit-field] is shown.
Perhaps you can simplify the logic, by giving $edit_mode more preference, as you suggest!
BTW, in views-list-mode, I also see a button at the bottom of the list.
Comment #35
akamaus CreditAttribution: akamaus commentedHi @johnv, I've tested #29 applied to editablefields-7.x-1.0-alpha2 on D-7.10 with views-7.x-3.0-rc3.
So far, it works correctly for me on node views, but I have some strange issues with multiple editable fields in views. All works ok if I disable click to edit preference. But when it's enabled, forms loaded with ajax after clicking on 'Edit this field' buttons depend on the clicking order. For example, if I click on the second field and then on the first, all is good. But after clicking in the opposite order I get two forms for the first field :)
Comment #36
johnvhm, I think we need some JS-guru...
Comment #37
akamaus CreditAttribution: akamaus commented@johnv, not sure. Your patch doesn't touch editablefield.js. And speaking about editing in views, original version works fine for me. The problem is on the server side, imho.
Comment #38
Jason Dean CreditAttribution: Jason Dean commented#29 has fixed the error for me, using Panels to override node view. Thanks!
Comment #39
iacono CreditAttribution: iacono commentedSame here, the patch in #29 worked for me on Ver. 7.x-1.0-alpha2
Comment #40
johnvcorrecting status.
patch from #29 is tested and OK by #38, #39, but may be not complete as stated by #35.
Comment #41
invisibleink CreditAttribution: invisibleink commentedPerhaps I've missed some step. I applied this patch, and while a revision is being added the first time, subsequent revisions overwrite the last revision instead of creating a new one. (I am using the editable fields formatter text and term reference fields on the node display settings. Both tested independently - same results.)
Changing status to needs work, as I don't think this is expected behavior.
Sorry if I've missed something....please let me know!
Attached is a snapshot of the db changes to the text field revision table.
Comment #42
rooby CreditAttribution: rooby commentedI can confirm that when you save a node it doesn't save a new revision, however I think that can safely be considered separate from this issue.
This patch seems to fix what it is supposed to fix. Revisioning is a separate thing. See #1189196: Doesn't create revision on content-type which revision option is checked.
Setting back to previous status.
Comment #43
tim.plunkettThe patch is not currently in a committable state.
The end-of-line comments in the patch referring to issue numbers and the author need to be removed, and code should be deleted if it is unnecessary, not commented out.
Comment #44
deryck.henson CreditAttribution: deryck.henson commenteddisregard
Comment #45
johnv@tim.plunkett, you are right. However, when I wrote the patch #29, I was unsure if my 'simplification' was correct. Apparently, it seems to be. Feel free to upload a clean version.
I like making 'diff-comments' in my code, since I see the differences with the original one directly in my code directly. Have you suggestions how to avoid this?
Comment #46
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe code is designed to be able to run even when there are several editablefields in the same form, which is the case when the Views-integration mode is used.
So no, it doesn't seem that the simplification is correct.
Comment #47
jhrizz CreditAttribution: jhrizz commentedWas getting the same thing.. #29 worked for me (Against Dev)
Thanks!
- Josh
Comment #48
rooby CreditAttribution: rooby commented@johnv:
You can still do what helps you when doing the dev and then just remove them before creating the patch.
Comment #49
adam_b CreditAttribution: adam_b commentedI posted a separate issue #1457918: Editablefields + View = Ajax 500 error before I found this.
I was also getting different error messages when I tried using fields rather than a rendered node in Views:
Feel free to ignore if this is unrelated.
Comment #50
MurzPatch from #29 solves the problem for me, thanks! Will be good to see this patch in head.
Comment #51
tim.plunkettSee #43
Comment #52
presleyd CreditAttribution: presleyd commentedI issued a bounty for these issues:
#1405854: Multiple fields not saved
#1206656: Error on Node view page: Argument 1 passed to drupal_array_get_nested_value()
#1189196: Doesn't create revision on content-type which revision option is checked.
and I think #1449750: Title field does not save changes (I'm not 100% sure if I understood the problem here but took it to just be problems saving from Views displays which I need but didn't test if it worked previously)
Mwsam has produced fixes, once I finish my tests tomorrow (so I can pay him) he'll post patches here.
Comment #53
mwsam CreditAttribution: mwsam commentedHere is a patch against the latest 7.x-1.x branch. This the fork I used when I'm working on multiple issues of editablefields: https://github.com/mwsam/editablefields
Comment #54
MurzI test patch from #53, it solves this issue on all my sites.
Comment #55
patoshi CreditAttribution: patoshi commented#53 solves the issue, but for text fields i'm still getting an ajax error when i type something in and hit RETURN.. if i dont hit return and just click away it works fine.. something to do with the RETURNS
Comment #56
Anthony Pero CreditAttribution: Anthony Pero commentedAfter I patch the current dev version with #53 (no error messages during patch), I get the following error messages on the site:
This appears to be a permission issue, but I'm having difficulty solving it. Any help would be appreciated... module doesn't function after the patch.
I also notice that the path is messed up in the second warning... Is that a failure on the part of the patch?
Comment #57
MurzAnthony Pero, you must clear cache after applying patch.
Comment #58
Anthony Pero CreditAttribution: Anthony Pero commentedI did clear the cache, Murz, both in the admin interface, and using drush. Thank you for responding, however.
I also emptied my database, reinstalled Drupal from scratch. Got the same error messages. I then cleaned out the database again, and reinstalled drupal, and tried to apply the patch before installing the module. In each case, I got the same error message. I then deleted my entire codebase and database, and started with a completely fresh codebase and database. No change.
I am on an XAMPP dev server on my Win 7 laptop. This seems to be part of the problem with the second message, since it starts with local Windows forward slashes, then switches to backslashes when it arrives at the sites directory. Its probably also why I am having a permission issue on the first message. Anyone able to help me move forward on this?
Comment #59
mwsam CreditAttribution: mwsam commented@duckx: I test with firefox and opera they both work as expected, however, in chrome the error appears. Currently not sure what triggered the error, seems like pressing RETURN submits the form instead of doing AJAX call. But this should be another different issue.
@Anthony Pero: As per the error message, it is file access permission problem. I'm not familiar with WAMP stack in windows, but it sounds like after applying the patch, the file permission get modified and your server process can't read the file.
Comment #60
Anthony Pero CreditAttribution: Anthony Pero commentedWhat about the second error message? It tries to include the editablefields.module, but can't located it. I would imagine that is because the path is wonkers with both \ and / mixed in. Is this a result of the patch on a Windows machine, or something else that I can fix? Thank you again for any help.
Comment #61
tim.plunketts/Get/Gets, and missing @param and @return docs
!empty($parents)
I'd do
return !empty($form_state['edit_mode']);
, or if not, use(bool)
s/Set/Sets, and missing @param and @return docs
!empty($parents)
This should be one line.
I'd do
return !empty($form_state['edit_mode']);
, if not, use(bool)
instead.if (!empty($parents)) {
This should be on one line
Comment #62
presleyd CreditAttribution: presleyd commentedWas it really easier to write that up like that instead of just changing it and rerolling it?
Comment #63
tim.plunkett@presleyd yes, see http://drupal.org/project/dreditor. Plus, if I reroll it, then neither of us can give it an impartial review.
Comment #64
micheas CreditAttribution: micheas commentedUm, OK,
I've tested the patch, and it is working for me.
One issue that I am having with re-rolling the patch is that the editablefields.module is 533 lines and it seems like things are referring to lines well beyond line 533.
A second issue is that I really don't know what half the parameters being passed are.
If someone who knows the module could comment about the missing @params we could get this moving forward.
Thanks for the code.
Comment #65
mwsam CreditAttribution: mwsam commentedHere's a reroll. Just go ahead and change the doc if necessary.
Comment #66
johnvThe patch works fine for me when updating a field on the node view page and on Views displays, but it must be applied together with #1405854: Multiple fields not saved
Comment #67
deryck.henson CreditAttribution: deryck.henson commentedSo I'm just gonna throw this out there.
I fixed this locally by actually adding a replica of the two functions in question and just renamed them and made them bool instead of array and it works every time.
I realize this isn't an actual long-term community fix and that changing core code (even thought it isn't technically changing) is frowned upon but if someone wants more detail let me know and I can provide it here.
Obviously I'm only offering this assuming this patch still isn't working. Otherwise ignore this and use whatever is accepted here.
Comment #68
rooby CreditAttribution: rooby commented@mwsam,
By reroll in this case you mean you have fixed the issues noted by Tim in #61 right?
Comment #69
mwsam CreditAttribution: mwsam commented@johnv: There are several issues with editablefield module, so I think it's better to provide a patch for each issue. As you said, the other patches should be applied as well to make this module fully working again. See comment #52.
@deryck.henson: Changing core code is not the way to go, the patch is working as far as I know, you can help test out the patch. There are several people that report successful fix.
@rooby: That's right.
Comment #70
deryck.henson CreditAttribution: deryck.henson commentedJust installed the module again on my new site I'll so I'll test out the site with no core changes (new CentOS install with nginx and php53 so maybe thatll help too).
Comment #71
dags CreditAttribution: dags commentedThanks to everyone that worked on this issue. Patch committed!
Comment #73
AaronELBorg CreditAttribution: AaronELBorg commentedI'm using 7.x-1.0-alpha2 and having this issue with the Media module's image upload function in a panel.
I don't know why updating views would fix this issue since the error occurs on a node view, right? I guess if your view was showing full node-views you'd still get the error but, again, I don't see how this could be fixed by updating views. Not ruling it out......just sayin.
Anyway, in order to get this to work, I ended up adding this to line 315. It's really hacky so I'm not gonna bother with a patch.
Why I'm having to "hardcode" the array key and value is currently beyond me but I need this to work so there you go. (Note: It doesn't really "work" in the way it's supposed to since I'm having to unhide the 'save' button and manually click it since the triggerHandler('click') in the js file doesn't fire. I'm willing to bet that issue is more on the Media module's side though. And I'd rather only hack one module as opposed to two.)
Thanks.
Comment #74
micheas CreditAttribution: micheas commented@AaronELBorg Please reopen this as a new bug.
One thing to consider is that form elements that have the style of display:none generally do not get submitted unless the browser is implementing IE6 compatiblity. The most recent versions of chrome do not submit those elements and neither does IE < 6 nor IE > 8.
The drupal class to make elements not show, but still not have a display:none attached is class="element-invisible" which resizes the element to 1px x 1 px and places outside the browser viewport.
I don't know if this will help or not. But please start a new bug instead of tagging on to a closed bug report.
Comment #75
AaronELBorg CreditAttribution: AaronELBorg commentedThanks for the response, micheas.
But isn't this the same bug?
Comment #76
Nick Robillard CreditAttribution: Nick Robillard commentedLatest dev release fixes this error for me. Thanks.
Comment #77
henk CreditAttribution: henk commentedLatest dev version work for me to.
Comment #78
sinasalek CreditAttribution: sinasalek commentedConfirm that it's fixed in dev
Comment #79
jhoffmcd CreditAttribution: jhoffmcd commentedHi All,
I'm using version 7.x-1.0-alpha2+7-dev and I'm still having this issue. Works great in a view, but not while on a detail page for an entity.
Note sure if this has anything to do with it or if it occurs because of another error, but in my console I am seeing an error in my editablefields.js file here:
At this line: $this.find('input.form-submit').triggerHandler('click');
I have 4 editable fields on this page.
I did try to run the patch just to try, and the dry run came up as "previously applied", so I know that the codes in there. What gives? Any help would be thoroughly appreciated.
UPDATE:
I just realized, my AJAX error is citing my fields.form.inc file, not the editable fields file. I will create a new thread.
Comment #79.0
jhoffmcd CreditAttribution: jhoffmcd commentedMore detailed description, Updated latest -dev version and D7.12
Comment #80
Feral CreditAttribution: Feral commentedDev version works for me.
Comment #81
subhojit777I was too getting the same error. I wanted to show editable field in node variant of panels. Dev version of module did not worked for me, the error was fixed but I was not able to edit the field. I used the alpha version of this module + patch in #65, and then it worked without error. Thanks!
Comment #82
mparker17#1792776: An AJAX HTTP error occurred when click Save for Field Link is a duplicate of this issue.