Babak Fakhamzadeh

Thanks. That worked.

And what also worked is that configuring the app for the ‘main’ site in my Multisite installation propagated the settings to the (currently 1) network site.

I tried setting up this plugin, using Gmail’s SMTP server, but test mails are not being sent.

I also found this:

https://support.google.com/a/answer/9003945?hl=en

So, I take it that, as of last month, this plugin no longer supports Gmail?

Thanks.

You’re saying that it needs to be configured within one of the sites, after which it will be setup for all of the sites?

I do not, as this does not serve a useful purpose. After all, the request itself includes the type, and is part of the URL.

So, you’re saying that if I include the type, the plugin will correctly associate the REST request with an object type?

@rockfire Indeed, it is. And, indeed, I include the id of the requested objects.

Thanks.

In my example, ‘post_type’ was a placeholder for my custom post type. So, its value depends on what endpoint is requested. So, your suggested value for $your_rest_base doesn’t actually work as a consequence.

What’s the purpose of this particular test?

In one case, the endpoint I access is like so:

/wp-json/wp/v2/politician?_embed=&_fie…

Where ‘politician’ is a custom post type.

So, do I need to test for all values of $your_rest_base that represent all my custom post types?

Thanks.

What’s the $this in that function? Keeping that in generates a fatal error.

If I change the contents of the function to the following, this appears to now work for me:

if ( $object_type !== 'unknown' ) {
    return $object_type;
}

if (count($data)) {
    if (count($data["data"])) {
        $first_object = $data["data"][0];
        $object_type = get_post_type($first_object->id);
    }
}

return $object_type;

What I don’t understand is this: I just installed WP REST Cache on another site, and there, the REST cache for custom post types are correctly identified, even though I don’t do anything differently, there.

I did not. I did not mark it as resolved.

Instead, I constructed a workaround, where I achieved a similar result by using a custom taxonomy. Not ideal.

Thanks, but I would not think this applies. I’m not trying to have translations of ACF fields. I just want these ACF fields to work. The ‘simple’ ACF fields work without a problem. But ACF fields that reference post objects do not.

Done.

thanks, and thanks for trying to replicate the problem, but I think you’re not completely understanding my situation.

in my example, both Mr. X and Mr. Y are users, not guest authors. And the incorrect title is showing in the author archives for both users.

so, the titles of the author archive for the user Mr. X, and the title for the author archive for Mr. Y are both “Mr. X, Mr. Y, Author at My Website””.
in both cases, the author archive is requested, so something like /author/mrx and /author/mry.

therefore, it’s very clear what author should be named in the title.

and so, this does appear like a bug in Yoast.

Any update on this?

I’m now encountering this same problem on another website. There, too, the post type is custom, and the ‘object type’ in the table of caches is listed as ‘unknown’.

Thanks Richard.

This is for a custom post type, so there’s that.

No, I do not strip out data from the endpoints. I do *add* data to the endpoints.

No, the correct post type is not showing in the list of caches. It says ‘unknown’.

Thanks.

That link is on wordpress.com, not jetpack.com. Good to know.

Thanks. That appears to have worked.

I could not find the option to disconnect my site on jetpack.com. Did I not look in the right places?