Error on Node view page: Argument 1 passed to drupal_array_get_nested_value()

Moving the issues back to the main project.

Hi, 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:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /drupal-7.4/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 \drupal-7.4\sites\all\modules\editablefields\editablefields.module on line 315
and defined in drupal_array_get_nested_value() (line 6339 of \drupal-7.4\includes\common.inc).

EDIT: I suppose the orignal poster was using Drupal 7.2, and that's why the line numbers differ.

I've got this too. I get the feeling that it's because of content translation, but I'm not sure.

Having the same issue on standard node view.

+1.

Default node view, no translations. The field I'm trying to edit is a boolean field, with a single on/off checkbox.

I 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

updating to views-3.x-dev did not fix the problem for me.

Hi, 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 :

if (!isset($form_state['edit_mode'])  || !is_array($form_state['edit_mode'])) {
    $form_state['edit_mode'] = array();
  }
  drupal_array_set_nested_value($form_state['edit_mode'], $parents, FALSE);

Instead of this :

if (!isset($form_state['edit_mode'])) {
    $form_state['edit_mode'] = array();
  }
  drupal_array_set_nested_value($form_state['edit_mode'], $parents, FALSE);

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)

+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

Same problem here.

sub

I 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 .. . .

This 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.

Indeed, the 3rd argument is missing and the bool FALSE is being used in its place. Here's the current code:

<?php
drupal_array_set_nested_value($form_state['edit_mode'], $parents, FALSE)
?>

Should be:

<?php
drupal_array_set_nested_value($form_state['edit_mode'], $parents, $element, FALSE)
?>

Here is a patch against 7.x-1.0-alpha1.

It 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:

if (!isset($form_state['edit_mode'])) {
    $form_state['edit_mode'] = array();
  }
  $form_state['edit_mode'] = array($form_state['edit_mode']);

Step 2: You're done, should be fixed now.

same problem.

I 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

Yeah, 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.

No, i did'nt have Panels installed while having this issue.

Same 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:

-  $edit_mode_state = isset($form_state['edit_mode']) && drupal_array_get_nested_value($form_state['edit_mode'], $form['#parents']);
+  // Create separate var $e_mode, because it will be passed by reference.
+  $e_mode = is_array($form_state['edit_mode']) ? $form_state['edit_mode'] : array($form_state['edit_mode']);  
+  $edit_mode_state = isset($form_state['edit_mode']) && drupal_array_get_nested_value($e_mode, $form['#parents']);

In contrary to #19, this does not alter $form_state, only creates a local copy.

#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.

  if(isset($form_state['edit_mode'])){
    if(is_array($form_state['edit_mode'])){$e_mode = $form_state['edit_mode'];}
    else{$e_mode = array($form_state['edit_mode']);}}
  else{
    $form_state['edit_mode'] = array();
    $e_mode = array($form_state['edit_mode']);}

FYI, 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

if ($account = user_load_by_name($entity->name)) {

with this:

if (isset($entity->name) && $account = user_load_by_name($entity->name)) {

Good to know! Thanks!

I'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.

Perhaps 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.

I 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.

Maybe 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.

I'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.

@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.

Hi @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 :)

hm, I think we need some JS-guru...

@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.

#29 has fixed the error for me, using Panels to override node view. Thanks!

Same here, the patch in #29 worked for me on Ver. 7.x-1.0-alpha2

correcting status.
patch from #29 is tested and OK by #38, #39, but may be not complete as stated by #35.

Perhaps 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.

I 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.

The 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.

disregard

@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?

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.

The 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.

Was getting the same thing.. #29 worked for me (Against Dev)

Thanks!

- Josh

@johnv:

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?

You can still do what helps you when doing the dev and then just remove them before creating the patch.

I 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:

If I select the "Click to edit" option, when I click that button I get this:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Internal Server Error
ResponseText:

If I don't select that option, the form appears correctly but when I click the Save button I get this:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Service unavailable (with message)
ResponseText: EntityMalformedException: Missing bundle property on entity of type node, in entity_extract_ids() (line 7501 of /var/www/phaidon/includes/common.inc).

Feel free to ignore if this is unrelated.

Patch from #29 solves the problem for me, thanks! Will be good to see this patch in head.

See #43

I 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.

Here 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

I test patch from #53, it solves this issue on all my sites.

#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

After I patch the current dev version with #53 (no error messages during patch), I get the following error messages on the site:

Warning: include_once(C:\xampp\htdocs\gfo\sites\all\modules\editablefields\editablefields.module) [function.include-once]: failed to open stream: Permission denied in drupal_load() (line 1128 of C:\xampp\htdocs\gfo\includes\bootstrap.inc).

Warning: include_once() [function.include]: Failed opening 'C:\xampp\htdocs\gfo/sites/all/modules/editablefields/editablefields.module' for inclusion (include_path='.;C:\xampp\php\PEAR') in drupal_load() (line 1128 of C:\xampp\htdocs\gfo\includes\bootstrap.inc).

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?

Anthony Pero, you must clear cache after applying patch.

I 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?

@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.

What 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.

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+ * Get the edit mode of an editable field in form.

s/Get/Gets, and missing @param and @return docs

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+  if ($parents && is_array($form_state['edit_mode'])) {

!empty($parents)

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+  return (boolean) $form_state['edit_mode'];

I'd do return !empty($form_state['edit_mode']);, or if not, use (bool)

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+ * Set the edit mode of an editable field in form.

s/Set/Sets, and missing @param and @return docs

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+  if ($parents) {

!empty($parents)

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+    if (!isset($form_state['edit_mode'])
+      || !is_array($form_state['edit_mode'])
+    ) {

This should be one line.

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+  return (boolean) $form_state['edit_mode'];

I'd do return !empty($form_state['edit_mode']);, if not, use (bool) instead.

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+  if ($parents) {

if (!empty($parents)) {

+++ b/editablefields.moduleundefined
@@ -539,3 +531,34 @@ function editablefields_form_submit(&$form, &$form_state) {
+    if (!isset($form_state['edit_mode'])
+      || !is_array($form_state['edit_mode'])

This should be on one line

Was it really easier to write that up like that instead of just changing it and rerolling it?

@presleyd yes, see http://drupal.org/project/dreditor. Plus, if I reroll it, then neither of us can give it an impartial review.

Um, 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.

Here's a reroll. Just go ahead and change the doc if necessary.

The 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

So 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.

@mwsam,
By reroll in this case you mean you have fixed the issues noted by Tim in #61 right?

@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.

Just 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).

Thanks to everyone that worked on this issue. Patch committed!

I'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.

  $form_state['edit_mode'] = (isset($form_state['edit_mode']) && is_array($form_state['edit_mode']))?$form_state['edit_mode']:array( 0 => '' );

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.

@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.

Thanks for the response, micheas.

But isn't this the same bug?

Latest dev release fixes this error for me. Thanks.

Latest dev version work for me to.

Confirm that it's fixed in dev

Hi 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:

      // There is only one editable field in that form, we can hide the submit
      // button.
      if ($this.find('input[type=text],textarea,select').length == 1 || $this.find('input[type=radio] ').length > 1) {
        $this.find('input.form-submit').hide();
        $this.find('input[type=text],input[type=radio],textarea,select').change(function() {
          $this.find('input.form-submit').triggerHandler('click');
        });
      }

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.

More detailed description, Updated latest -dev version and D7.12

Dev version works for me.

I 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!

#1792776: An AJAX HTTP error occurred when click Save for Field Link is a duplicate of this issue.