[Resolved] Unable to update field's value programatically on save_post
The Toolset Community Forum is closed, for technical support questions, please head on to our Toolset Professional Support (for paid clients), with any pre-sale or admin question please contact us here.
This support ticket is created 7 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the community support forum for Types plugin, which is part of Toolset. Toolset is a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients and people who registered for Types community support can post in it.
I'm trying to update Types field's value on post save.
add_action('save_post_my_post_type', function ($postId) {
update_post_meta($postId, 'field-name', 'test'); // This field gets update
update_post_meta($postId, 'wpcf-field-name', 'test'); // This one is not updated
});
This action executes on each `my_post_type` post save. the `field_name` field gets update properly, as expected. `wpcf-field-name` field is under Types control and its value remains empty after page reload.
I tried to increase the priority parameter of the `add_action` function, but it didn't help. I guess that something happens afterwards and overwrites the update I made.
And I can see that the result of var_dump($updated) call is not empty - I can see the updated meta ID. So the value is updated, but probably Types plugins overwrites the value afterwards.
Is there any undocumented hook I could hook into in order to take control over Types (something like `acf/save_post` filter in the ACF plugin)?
No. It doesn't. The 4th parameter is `$prev_value` and it's optional.
As I said in my first post - it affects only fields that are under Types plugin control. Fields that are not controlled by Types are saved properly.
And I can see that the value is saved by `update_post_meta()` call (see the second code I've posted and the explanation), but it seems that Types plugin does something after my code is executed and overwrites the field I've just saved with an empty value.
So the question is: what Types plugin does afterwards and is there any hook I can hook into in order to execute my code after Types' plugin job is done.
Okay when I run tests locally I can't reproduce the same problem. Have you tried the following standard troubleshooting steps?
- Temporarily disable all non-Toolset plugins
- Temporarily activate a default theme like Twenty Seventeen
If these don't work, I'd like to try to replicate this issue in your environment by making a clone of your site. If that's okay with you, please provide login credentials for me in the private reply fields enabled here. I will create a clone using the Duplicator Pro plugin, then install it in my local environment so I can run some further tests and get this figured out for you as soon as possible.
Please confirm that you did the same thing as I did.
- Created a field with Types
- Assigned it to any post type
- Used the `save_{post_type}` hook
- Clicked the "publish" button on the post edit page in order to save the post and trigger the `save_{post_type}` hook.
The issue I'm having is not related to the `update_post_meta()` function itself, because it simply works fine, but to the specific scenario that I've described in this topic.
Also, please answer the question that I've asked in my previous comment.
> So the question is: what Types plugin does afterwards and is there any hook I can hook into in order to execute my code after Types' plugin job is done.
I'm not asking for a copy/paste solution. I'd like to know how the Types plugin works and what hooks (with what priorities) does it use in order to handle the post meta update.
- Used the `save_{post_type}` hook
I see now, this is a critical difference I overlooked in my local tests. When I use the save_post hook I have different results, and I'm not clear why there is a difference. I'll ask my developers why the behavior changes if I use the CPT-specific hook - my guess is that they're somehow manipulating all save_post hook callbacks but not those attached using the save_post_{post-type} hook. I'll update you when I have some more information about that.
Hi, after a discussion with some other team members it appears that save_post_{post-type} isn't the best hook to use when modifying post meta information. This event fires before save_post, where Toolset some modifications, so this is why values are being overwritten unexpectedly. For best results, our developers recommend using only the save_post hook instead of save_post_{post-type}.
> Hi, after a discussion with some other team members it appears that save_post_{post-type} isn't the best hook to use when modifying post meta information. This event fires before save_post, where Toolset some modifications
Yes, you're right. I dug into WordPress source code, and it is indeed true. The `save_post_{post_type}` is triggered just before the generic `save_post` hook (literally: it's one line after another).
> For best results, our developers recommend using only the save_post hook instead of save_post_{post-type}.
It would be better if there was a Types hook I could hook into. Is there any hook that executes after Types data is saved? I understand that I can use `save_post` with a high priority (higher than Types uses), but relying on priorities is not a good practice and it's error-prone (I can't be 100% sure that a priority will not change in a future Types plugin release.)
Sure, I've marked this ticket as a Feature Request and forwarded your thoughts along to Minesh, our Types developer liaison. He will discuss the idea with our developers and I will follow up with any information I receive.
As for the priority, I have been informed that you must use a minimum priority of 15 for save_post, so I assume that Types expects to use up to 14.
The forum ‘Types Community Support’ is closed to new topics and replies.