I'm attempting to use Zapier integration with Stripe and WordPress to create posts (cpt: Payments) when payments are completed.
The issue I'm seeing is after authenticating Zapier with the WordPress site, Zapier provides a drop down of post types available on the site. The drop down includes the standard post types, as well as projects (created by Divi), views, templates, template parts, and content templates. Some of these appear to be created by ToolSet, but none of the cpts I've created are available to select.
I have contacted their support as well, so I'm working this from both sides.
Other info: The REST API is turned on per the below support topic.
Any help you can provide is greatly appreciated.
Thanks,
Matt
Is there any documentation that you are following?
I'm guessing the likely problem is that the post types are registered by Types on a later hook in the page loading process than the action that the Zapier integration hooks into so that when it retrieves the list of registered post types those registered with Types are not yet available.
Custom Post Types registered with Types are registered on the init hook with priority 10, so they only become available in the page building process on the init hook with priority 11 or above.
Can the Zapier integration people confirm where they hook in?
If it is earlier, then it may be that you would need to register the post types manually using register_post_type (which is essentially what Types does, though it provides a UI for this).
Actually Matt, there is another solution you can try (I was discussing this with the developers just now).
There is an internal filter which can be used to change which priority the Types custom post types are registered on. The default is 10, and I think this relates to the ability to make some limited changes to the built-in post types such as Posts and Pages. As long as you are not doing that, you should be able to use the code below (added via a plugin or to your theme's functions.php, not as a Code Snippet which itself would run too late) to register the post types earlier, in which case I imagine they would show up in the Zapier integration, though you would need to test to confirm.
add_filter('wpcf_init_custom_types_taxonomies', 'ts_priority_wpcf_init_custom_types_taxonomies');
function ts_priority_wpcf_init_custom_types_taxonomies($p)
{
return 1;
}
I tested the code you provided in the functions.php file and unfortunately it didn't solve the issue, I'll tap zapier to see at what priority they are registering the cpts at. Since Views are visible, it has to be after. That said, I'd rather not register the post types via CLI scaffold if I can help it. If you can think of any other potentail routes to this end let me know, your help is, as always, greatly appreciated.
Just to confirm, I added the same snippet to my own test site and it did make the difference between my CPTs registered with Types showing up at the init hook with default priority of 10 or not.
quick update: While I had the REST API exposure box checked in settings, I did not have the 'show_in_rest' option checked off for the post type though. Now that I do, I see the post type, however none of the custom fields are available. I looked in the post field group and I don't see an individual rest exposure setting for the custom fields, is there something else along those lines I could be missing?
Bear in mind that as far as WordPress is concerned, post types and custom fields created with Types are just the same as post types and custom fields created any other way, including using WordPress API functions like register_post_type (which Types uses under the hood). Naturally, you might choose settings that differ across post types you register, but how you register them doesn't really matter.
So, turning to custom fields. These are stored in wp_postmeta, just like any other custom field, with the proviso that Types adds a 'wpcf-' prefix to the meta_key to distinguish Types custom fields. So a custom field with a slug of 'priority' would have a meta_key of 'wpcf-priority'.
So the raw values of custom fields should always be available to the REST API if the post type is accessible by the REST API.
Now, some custom fields are stored in a particular format that differs from how you would likely want to output the field value. Dates, for example, you might want to output as "3 August 2023", but these are stored as UNIX timestamps. So retrieving the raw value via the REST API would give you the timestamp.
So Toolset additionally makes the formatted values available to the REST API, but you need to enable that option.
Zapier has advised that they identified a bug in their plugin that is causing some of the custom fields not to populate in their interface. Thank you for your help with this, I really apprecaite your time.
