No matter what configuration I use, I cannot get my changes to take effect.

1) I select the checkboxes of the nodes I want to modift.
2) I click "modify node taxonomy terms."
3) I select new nodes to be added.
4) I click "next."
5) The top of the page states "(number) rows processed in about (number) ms:" and lists the nodes, but the changes have not actually taken effect.

Comments

infojunkie’s picture

Category: bug » support
Priority: Critical » Normal

In the description above, you don't mention getting a taxonomy form where you choose the new terms. Is that the case? Are you getting a message stating "The selected nodes are not associated with any vocabulary. Please select other nodes and try again." ?

jakery’s picture

Sorry, I forgot to mention that step. I've tried both configurations -- selecting taxonomies on the same page and selecting them on the following page. I select them from the multi-select box and submit the form. In either configuration, the result is the same: A message reporting which rows were processed, but the changes don't actually go into effect.

entrepreneur27’s picture

I have the identical problem. Running the latest version of core. Not sure if it worked before I upgraded core this morning.

infojunkie’s picture

Do other actions that modify the node (e.g., publish, change author) work correctly?

jakery’s picture

I tested a couple others and they seem to work fine.

pedrorestu’s picture

suscribing!
not working for me also, using last official release.

rootwork’s picture

Version: 6.x-1.8 » 6.x-1.9
Category: support » bug

This is happening to me as well via its integration with Flag and core Actions modules. It may be due to one of those modules, but it's so similar to the behavior described above I'm thinking it's VBO. (But if I'm wrong, I'll be happy to delete this and post a new bug report in one of those queues.)

Steps to reproduce my version:

1. Enable VBO, actions, flag module and actions integration for flag module.
2. Add a flag for nodes at /admin/build/flags/add.
3. Add an action for that flag, select "Modify node taxonomy terms."
4. Leave the default selection of "Add the selected terms" and choose one or more existing terms, submit the page.
5. Edit the action. The terms will have reverted black to blank/None/None Selected in each vocabulary, regardless of previous selection.

Using: Drupal 6.16, Views 2.8, VBO 1.9, Flag 1.2

infojunkie’s picture

@rootwork: I'm not sure I understand your report. Step 5:

Edit the action. The terms will have reverted black to blank/None/None Selected in each vocabulary, regardless of previous selection.

What does "Edit the action" mean? Edit the node to check the terms in it? Or execute the same action again?

rootwork’s picture

StatusFileSize
new2.93 KB

@infojunkie no, I mean in the Flags configuration page, on which there's an Actions tab, edit the action you just created for that Flag.

Attached is an image of what I mean -- "Archive" is the name of the flag; on the right you'll see the edit link to the action I've set up on it.

But I'm pretty sure all of this is coming from VBO's "Modify node taxonomy terms" as that's the action that's attempting to get saved.

infojunkie’s picture

@rootwork: this is a bug in flag_actions.module, and it's not related to the original report in this thread. To convince yourself it's not a VBO bug, go to admin/settings/actions/manage and create a new advanced action with "Modify node taxonomy terms". Enter some values and save the action. Then click "configure" on that new action you just created: the taxonomy values are still there (except for the "Action to take" field and I will fix this).

In flag_actions.module, the code in flag_actions_form_submit() does:

$parameters = $form_state['values'];
unset($parameters['flag']);

while the correct handling for actions parameters should be:

$parameters = call_user_func($callback . '_submit', $form, $form_state);

You might want to report that on the Flag module issue queue. Thanks for bringing it to my attention though, it did unearth a minor bug :-)

rootwork’s picture

Ah, interesting! I tried your code and it worked, so I posted an issue in the Flag queue: #750100: Modify node taxonomy (VBO) action - taxonomies not being saved

Thanks for solving my issue even though it didn't involve your module! And I'm glad it helped uncover a couple other little things :)

davidtrainer’s picture

Having the same issue.

Publish, Unpublish, and Change Author work as expected. Interestingly, changing the taxonomy terms via the Modify Node Fields operation also works.

tatewaky’s picture

Regards,

does anyone fix this?? i appreciate any help, thanks in advance

tatewaky’s picture

Version: 6.x-1.9 » 6.x-1.10
Component: Core » Actions
Category: bug » task
Status: Active » Needs review
StatusFileSize
new1.38 KB

HI,

After a day of work i realized that this problem appears because the content taxonomy field never updates its value. Even if you choose a vocabulary in the content field global settings.

What we need to do is before the action ends, modify the node content field values for the ones in the taxonomy term. After this, changes will take effect.

This patch applies only to content types using content taxonomy fields.

enjoy it.

manu manu’s picture

Status: Needs review » Needs work

Caution, this patch overwrites all the contents fields.

$node->$field['field_name'] = $new_values; should be moved insinde if ($field['vid']) { }

Sorry, I can't provide a patch right now...

infojunkie’s picture

Version: 6.x-1.10 » 6.x-1.x-dev
Category: task » bug
Status: Needs work » Fixed

Thanks all for your patch and review. I tested the patch above with the comment #17 and committed the fix to 6.x-1.x-dev. Please try it (12 hours from now) and let me know if it works now!

Status: Fixed » Closed (fixed)

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

tatewaky’s picture

i think this modification would be better

   if ($new_values[0]['value'] || $context['do'] == TAXONOMY_ACTION_DELETE){
                    $node->$field['field_name'] = $new_values;
   }

after think about the #17 suggestion i thought that might be the best to do, however im open to new suggestions.

thanks

nigelcunningham’s picture

Status: Closed (fixed) » Active

Sorry to say this, but I've just found the same issue with 6.x-1.12. I'll see if I can diagnose what's going on and provide a patch.

nigelcunningham’s picture

Status: Active » Closed (fixed)

Found the problem - workflow interfered, making a pending revision of the changes, which meant they didn't show up immediately.

Sorry for the noise, but hope this helps someone else who hits the same issue :)