I find it quite confusing that this Plugin, which as far I see is a Display and search (just as Views) Plugin, hooks into the save/update actions.
Why? A Search and display plugin should not do that.
Anyway, I think they either have a GUI setting or a filter you can use.
Then just pass the Pages or Posts /CRED Forms that you want to exclude.
This should be possible, otherwise I would suggest to contact them and ask for reasons and solutions, we are also interested in the case.
I'm wondering why using cred_field doesn't result in this issue though...
The plugin maintains it's own database table, it's not actually using/searching the WP post table. That's why it needs to run everytime a post is changed...
I see.
Well, as far I understood you, whether or not you use generic Fields or other sources, even hard coded, as long that Plugin is active you get the delay.
It's clear why:
- the plugin hooks into the update post action
- since you update several terms, it needs to do that as well, along with all other changes.
Obviously, the plugin is running into a bottleneck here.
We cannot change how CRED updates posts, it's done by WordPress default rules.
I apologise that I cannot change this.
For some reason it actually works find when using cred_field, just not when using generic fields and the custom hook.
Anyway, I agree this problem is not related to CRED but caused by the other plugin. Thanks for taking the time to help me figure this out!
Cheers,
Thomas
Quick followup question: For now, removing and re-adding the WP save_post action (which FacetWP uses) before and after my cred_save_data custom code runs seems to do the trick.
Any objections regarding how CRED handles post updates? Could this "fix" result in problems?
It is not something we test in our QA, of course, but it should not affect the form.
Does that solve the problem? And most important, is the data still saved properly?
Yes, it seems so. I will do some further tests though. I had a look at the FacetWP code and it uses save_post for its indexing.
I actually just found this in the FacetWP code, probably explains our whole discussion here so far:
/**
* We're hijacking wp_insert_post_parent
* Prevent our set_object_terms() hook from firing within wp_insert_post
* @since 2.2.2
*/
function is_wp_insert_post( $post_parent ) {
$this->is_saving = true;
return $post_parent;
}
I couldn't find a similar function for wp_update_post. So it makes sense the issue is only related to edit forms.
I contacted the FacetWP devs though, both CRED and their plugin are popular and should work smoothly together...
Well, the save_post hack/"fix" doesn't work after all.
Is there a way to check for a CRED form submission - e.g. similar to wp_is_post_revision? It seems for now the only solution is to change the FacetWP core files and stop the save_post part from running when a CRED edit form is submitted.
You could try to check for:
isset($_GET['cred-edit-form'])
That should detect whether you are calling a CRED edit form.
So you could use that to subsequently disable certain code on that call.
I need to ensure this is not on our end - might you send me a ZIP of that Plugin (it's paid 🙁 ) so I can test it?
A few instructions on the steps I need to take with that Plugin so to replicate the issue would be useful too.
I do not think we can do anything here, but I want to have a closer look to be sure, and provide an eventual workaround.
FacetWP introduced a new filter yesterday which enables you to deactivate the term indexing. Together with the conditional you suggested I was able to remove the bottleneck when using CRED forms for updating WooCommerce attributes.
It seems WooCommerce 3.0.0 introduced changes that FacetWP need to address in order to speed things up when it comes to term indexing.
I am sorry, previously I misunderstood you, about removing and readding the save action before and after the CRED code.
That won't work as we need it in the action itself.
As I see above the issue is now solved with the new filter of the FacetWP plugin?
Otherwise, I'll need a copy of the plugin and instructions as previously mentioned.
