PHP notices when saving nodes

Are you using the WA-provided form element or the native menu form element (which is known to be buggy.)

I just experienced this as well.

I running the latest dev of Workbench Access 2012-Dec-25 and Workbench 7.x-1.1.

I'm using two term reference fields that use autocomplete as Workbench Access control fields.

Everything seems to be working correctly with the autocomplete, but when I hit save when creating a node. It gives the following error.

Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 655 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module).
Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 656 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module).

Note: The node is still created and the terms are still assigned.

Let me know if you need any more information

That's a great report. Thanks.

I can't replicate that error.

What else can you tell me about the field? Can you look at the $node object when it goes into that loop (line 652)?

What is set in the $node->workbench_access_fields array?

From what I can tell, this only happens on node creation. These two fields are core taxonomy term references using autocomplete.

What else can you tell me about the field? Can you look at the $node object when it goes into that loop (line 652)?

Don't know how to do this. If you tell me what to do, I will do it.

This could be because I entered this into the term reference field: "section user is assigned to, test" just to see what would happen. The term "section user is assigned to" is a term that I allowed the user to create content in using workbench accesss. The term "test" is a new term that hasn't yet been created.

Note: the user doesn't have permissions to create terms in this vocabulary, but the term was created anyways. I'm not sure if that is the intended behavior?

If I enter only terms the user is assigned to through Workbench Access then everything works correctly without errors.

Hope that helps, let me know if you need more information.

I believe I only see these errors when a user is using the core term autocomplete field and enters a new term that they have not been assigned to in Workbench Access.

Could this Drupal core bug be related #1078878: Autocomplete term widget: disable creation of new terms? The user shouldn't be able to create new terms unless they have that permission.

I think the two are related and in Drupal 7, we have to account for it here. That core change is unlikely to push through.

Haven't tested but here is a module that might fix the terms from being created:
http://drupal.org/project/taxonomy_access_fix

Also, here is a core issue for this functionality.
#1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission)

Looks like I'm still seeing this with 1.2. This seems to be happening every time I create a new node that uses workbench_access with a core autocomplete taxonomy term reference field. This happens even without any terms entered into the field.

Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 667 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module). (x2)
x
Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 668 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module). (x2)

Let me know if I can provide any more information.

Can you attach a screen shot of the configuration settings for that field?

And, really, the settings for Workbench Access scheme.

Here are the screenshots you requested. I'm not sure but I think I found the problem. I think the problem is that there wasn't any editors or roles assigned to any sections. I'm logged in as user/1, so I assumed I could post to any section. As soon as I assigned a role to the sections it worked. I was able to create content without seeing the errors.

It's still something we should avoid, since it does scare people. That does explain why I couldn't replicate it.

Hi,
I have the same issue. It seems that on first save form_set_value($element, $value, $form_state) does not set the empty value array to the node object in the taxonomy_autocomplete_validate function in the taxonomy module.
I searched the implementation of the select_list widget and there is a separate if clause for the case where they:

// Make sure we populate at least an empty value.
if (empty($values)) {
$values = array(NULL);
}

So, if a initialize(in the taxonomy_autocomplete_validate function) the $value as array(NULL) or make an else clause where to set the $value this way, it's working. I am not sure what is the reason workbench access presave to get node object without the empty taxonomy term reference fields.
This i s where i am now ... and will appreciate any advice or help!

The reason is likely execution order of the pre-save hooks.

Added second error message.

I have a possible fix for this. The problem actually stems from the fact that the presave function was running on ALL nodes, even ones where this was turned off in the workbench_access_node_type_ variable.

BTW the easiest way to replicate this bug is to just do a node_load/node_save on a node that doesn't have menu turned on and is not controlled by workbench_access (when using the menu access scheme, obviously).

Thanks @chromix, but I tried your patch and I'm still getting the problem:

This happens when I leave the taxonomy field (placement tags) blank and then save the node. The "Placement Tags" taxonomy field is the field I use for workbench access.

If I fill in a taxonomy term, then I don't get an error.

Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 676 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module). (x2)
x
Notice: Undefined property: stdClass::$field_placement_tags in workbench_access_node_presave() (line 677 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/workbench_access/workbench_access.module). (x2)

I was also getting this while programmatically saving nodes using menu. This patch should fix both instances, as it ensures that the fields are present if they're required. I haven't been able to test this for taxonomy but it should work. Feedback, as always, is appreciated!

Many thanks @chromix

Your suggestions fixed the problem for me.

I think you left some extra unneeded code in the last patch in #18.

+     ->addTag('workbench_access_role')
+      ->fields('war', array('access_id'))
+      ->condition('war.rid', array_keys($account->roles), 'IN')
+     ->condition('war.access_scheme', $access_scheme);
+    $result = $query->execute()->fetchAll();
+    foreach ($result as $data) {
+      $items[$data->access_id] = $data;
+    }
+    // Add roles.
+    $query = db_select('workbench_access_role', 'war')

Here is a new patch without that code that works for me.

Good to hear! I think I just rolled against the wrong version of the module. Anyone else having similar results?

There's a bit of a gotcha with menu_node_prepare() - it expects the link to be marked enabled in the form submission.
If it's not marked enabled, menu_node_save() will delete the menu link when we do a node_save().

Here's an updated patch to include this check and set the enabled flag accordingly.

Just tested the patch in #21 and it seems to work correctly. Going to set this to RBTC and see what @agentrickard's thoughts are about this.

I'd feel better about it if this were testable.

Are there clear steps to replicate?

I'm not crazy about the menu-specific code here.

The clearest way to reproduce this bug is to programmatically create and save a node that would normally be controlled by workbench_access (a migrate module migration will do this). When this happens, particularly when using workbench_access menu, the menu component of the module will be missing, which will throw the error.

I haven't been able to specifically recreate this for terms, though. Anyone care to take a stab at this?

@chromix -- did the patch fix that issue, at least?

@agentrickard

The patch totally works for my use case (menus as opposed to terms). I've been using this for months without issue.

@chromix - Which patch are you using?

I was getting the same error on 7.x-1.2. It was actually really messing up my permissions - a user who should be able to create 'landing' pages but only in certain sections as specified by Workbench Access was actually bypassing this section access as $menu was not being saved. Therefore there was an empty array given under $node->workbench_access instead of the correct section access.

I can confirm that by changing to 7.x-1.x-dev (didn't solve the problem on it's own) and applying patch #21, this solved my issues. I also had to re-save all the nodes that had the incorrect workbench_access properties on them as this property is attached to the node object on save.

Thanks all who helped with this! :)

Hello,

i have developped a multilingual site and uses worbench access to control the contents.
As steve.stotter, I was getting the same errors (i use the dev version).
With the patch #21 the problem is solved.
Have you planned to include this patch in the next version (dev or stable) ?

Thanks.

@gmclelland Sorry just saw this now. I was using the latest patch, #21. Still using it, still working great :)