Investigate wp_after_insert_post hook in WordPress 5.6

[jonathanstegall]

Is your feature request related to a problem? Please describe.
When we run code on the save_post hook, the metadata is not always present. This causes problems if, for example, a meta value is required in Salesforce.

Describe the solution you'd like
There's a new hook that runs after the post and its metadata have been saved. It's called wp_after_insert_post. The way it reads, it sounds like the metadata would already be there.

[jonathanstegall]

We'd also want to see if there are similar hooks for users, terms, etc.

[jonathanstegall]

Partially related to #189

[timnolte]

It seems like there is something going on at least in the 2.0.3 version of the plugin where a Post create is causing a Salesforce Create Push & then multiple Update Pushes all at the same time instead of seeing just 1 Create push action. I really think there needs to be a move to using this hook. We are seeing this issue causing 504 timeouts because of all of these Push actions happening at once. In one case a CPT generated 100+ log entries related to create/updates when the post was first pushed.

[timnolte]

I have confirmed that this issue is not happening currently in our Production environment running 1.9.9.

[jonathanstegall]

I had previously done some basic testing with wp_after_insert_post and it did not include any metadata. I'm not sure that this hook would be a solution, unless I was using it incorrectly (which is possible). I haven't seen this, but we don't sync posts in our setup, so if it's related to save_post that would make sense.

I should be clear: it's obviously going to be a bit before I can investigate this in any kind of depth. I don't get a lot of dedicated time on this plugin, for better or worse.

[timnolte]

Yeah, I think if you used that hook you'd have to manually do a get_postmeta. However, I'm still confused as to what changed after 1.9.9 that started to cause this.

[jonathanstegall]

I'm surprised by it. It could be the upgrade to 3.x of Action Scheduler. It does a lot of things. I don't think it should have that kind of result, but I also can't think of anything else that would have it.

[timnolte]

Wouldn't that only affect it in the event that the field mapping was set to by asynchronous? This is happening for a CPT that is setup as synchronous push.

[jonathanstegall]

Yeah, that's accurate. That's good to know.

[timnolte]

FYI, I did find that the issue I was reporting is occurring on more than 1 Custom Post Type. I also confirmed that this is only occurring for synchronous pushes, not asynchronous pushes.

[jonathanstegall]

Wow, it only occurs for synchronous ones? So if everything else is identical it only happens on the synchronous pushes?

[timnolte]

That is correct, for the same Custom Post Type, switching from synchronous to asynchronous resolves the issue of a bunch of extra pushes. I'm going to do another test as I'm curious if our Redis Object Cache, which hasn't been released to Production yet, would be attributing to this issue.

[timnolte]

@jonathanstegall so to follow-up, while I still think it might ultimately be a good this to leverage this hook I think the issue I was seeing was somehow related the Redis Object Cache. After clearing the object cache, plugin, cache and deactivating and reactivating the plugin things seem to be operating normally again.

[jonathanstegall]

That is super helpful, thank you.

My original hope in telling myself about this hook was that it might be a new situation where we could access the core post data along with the metadata instead of having to make separate calls, but it definitely is not that kind of thing.