[Resolved] Certain action not working when saving child data via Parent post

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 5 replies, has 2 voices.

Last updated by Rethink 3 years, 8 months ago.

Assigned support staff: Beda.

Author
Posts
#417851

I have a Parent/Child relationship. I want to have it managed from back-end admin so do not want to use CRED for this.

I have many custom functions that fire when child posts are created, and they all work fine except one case. There is a process in which i am updating some taxonomy against a child post. For this, I am using:

wp_set_object_terms($post_id, $new_name, 'category', false );

Which is being called during a save_post::

add_action('save_post', 'add_title_as_category' , 999);

Now, if I am saving or updating the CHILD post directly, everything works great.

But...

If I am saving or updating the CHILD post from *within the parent* (in the Post Relationship section) then all works fine EXCEPT 'wp_set_object_terms' simply does not work.

So, I need to understand why wp_set_object_terms is not working when adding/updating the child post from within the parent? And what I need to do to get it working here. I am guessing it has something to do with order of events - but of course it is a process specific to your software so I defer to you.

Thank you

#417972

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Your code seems correct, as long $new_name returns a Slug or ID of the Term.
https://codex.wordpress.org/Function_Reference/wp_set_object_terms

wp_set_object_terms( $object_id, $terms, $taxonomy, $append );

$object_id
The object to relate to, such as post ID.

$terms
The slug or id of the term (such as category or tag IDs),

$taxonomy
The context in which to relate the term to the object. This can be category, post_tag, or the name of another taxonomy.

$append
If true, tags will be appended to the object. If false, tags will replace existing tags

Your current 3rd Argument "999" seems a priority to me, not a Taxonomy Slug.
This is not available in the used WordPress function.

An example that should work is:

//term is "temporary-test-site" and taxonomy is "genre"
wp_set_object_terms( $post_id, 'thriller', 'genre' ); 

To make sure this gets fired on your Child Post you can try to use save_post_{post_type} as described here:
https://codex.wordpress.org/Plugin_API/Action_Reference/save_post > Custom Post Type: 'book' > note

I think your issue is that the Post ID you use in that code will get the Parent ID, not the Child ID, when used on the Parent Post Update action.

Can you check that the code is applying the correct Post ID?

#418147

Hello, thanks

I think you accidentally confused the '999' in your response, which is being applied in the 'add_action' not the 'wp_set_object_terms' - no big deal but wanted to clarify that so we're on the same page.

But I will definitely take a look at the save_post_{post_type} that you referenced, and see if it can help in this case.

I will also verify the post_id and error responses. I will respond back shortly.

Thanks again

#418179

Hello,

In testing further, and echoing details I am coming to the conclusion that when working inside the Parent post (using the Post Relationship section to add/edit child posts) , and in that section clicking the actual 'SAVE' button, the action 'save_post' (or, 'save_post_gallery' in the case above, citing the save_post_{post_type} option) is not called whatsoever - so it seems that for my code to work at the press of this button, I need to add_action something else. Can you tell me what is actually called when clicking that 'SAVE' button? that I can hook into? Thanks

#418266

Beda
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: Asia/Ho_Chi_Minh (GMT+07:00)

(facepalm)
Of Course, sorry about that.

Now about the action that fires when you save a Child Post from within the Parent Post Screen:
In short, it is not so easy.

1. You save a single Child Post from within Parent edit screen:
- AJAX is used, save_post is not triggered.

2. You save the Parent Post, all Childs get saved along with it, and here save_post is triggered.

3. We are completely refactoring the Many To Many Relationship things.

I mean, completely.
Everything, or almost everything, will change.

For this reason I can not assist the Custom Code.
It will change and break in a close future.

In the new refactored MtM Relationship code we will provide also actions and filters to perform all this sort of custom approaches.

I apologize that for now, this is not very transparently set up, as you see above.

I will update you here in this ticket once the new MtM is ready, but actually you will notice it as it will be a major update.
A first bulk of code will be shipped in the next release and then we will finish it in the over next, at least, this are the plans.

I can not guarantee a detrmined ETA.

#419815

I see. Thank you for the explanation - hopefully in whatever updates you perform, you account for some backwards compatibility.

But as far as my needs, I found the best option then was to limit the fields displayed for those posts, and use admin custom css to hide the 'Save' button for these specific child entries - so that only Add, Edit and Delete appear. In this way, the child post can be added from within the parent, but to complete the process they need to hit 'edit', which then pulls up the actual child post - and then upon saving there, the proper automations are triggered. This works well enough, and forces the proper series of steps required.

I have to also add, when we thought to hide the 'save' button for these specific items, we thought it would be difficult to do so - but thankfully you added excellent classes (or ids, don't recall) which allowed us to display:none easily on the specific buttons we wanted to hide. Hopefully this type of tagging will continue in whatever updates you perform.

Thanks much