Custom Fields are Empty after Crossposting

Support articles → Simple WordPress Crossposting

You need to configure the plugin. Please go to “Settings > Crosspost”, then “Metadata” tab, and copy and paste the code snippet to all the websites you’re going to crosspost to.

Even if you are not planning to use custom fields, so many plugins rely on them. If a crossposted post doesn’t look the way it should make sure metadata is configured.

Unfortunately the metadata should always be configured this way and there is no other simpler way of doing that, it is just how WordPress REST API works by design.

Explained in detail in this video:

The snippet is not required if your target site is hosted on wordpress.com. However, for wordpress.com sites, all the protected custom fields you want to sync must be exposed for the REST API with a filter hook rest_api_allowed_public_metadata.

Custom fields for ACF (Advanced Custom Fields)

This part is easy as pie, for custom fields created with the ACF plugin all you need to do is to install and activate an add-on for ACF from this page (and make sure that your custom fields are allowed for REST API in settings) that’s all.

No extra configuration is needed.

Custom fields for JetEngine

In case you are using the JetEngine plugin to create custom fields, there is also no need to use the snippet from the “Metadata” tab (just make sure that every one of your custom fields is allowed for REST API).

More about JetEngine configuration you can read here.

Custom fields for Custom Post Types

If you’ve configured everything perfectly but you still don’t see the values of custom fields on subsite(s) and those are the custom fields for a custom post type, then probably there is one more thing to check.

When registering a custom post type please make sure custom-fields flag is included in supports parameter. Especially on subsite(s) where you’re about to crosspost to.

When registering a custom post type in the code:

register_post_type(
	'articles',
	array(
		
		...
		
		'supports' => array( 'title', 'editor', 'custom-fields' )
	)
);

When using CPT UI plugin:

When using Pods plugin (edit pod and then switch to Advanced Options tab).

configure custom post type in Pods plugin — Do not worry about what they are saying about slow performance. If you care about site performance, you’d better register custom post types in `functions.php`

When using JetEngine plugin (you can find this option in Advanced Settings).

the custom fields option should be added to the supports parameter in jetengine cpt settings

When a custom post type is registered with another plugin (or a theme)

Sometimes a custom post type is registered not by you and you can not easily change its registration parameters. But it is still possible with a filter hook register_post_type_args.

Here is how to do it:

add_filter( 'register_post_type_args', function( $args, $post_type ) {
	
	if( 'articles' === $post_type ) { // replace 'articles' with a CPT name
		// add 'custom-fields'
		$args[ 'supports' ][] = 'custom-fields';
	}
	return $args;
	
}, 99, 2 );

How to Fix a Custom Field Error?

Ok, but what to do if you’ve done everything mentioned in this guide but still getting an error like that?

First of all, there is an easy way to fix that error – you can just exclude this specific custom field from syncing:

Exclude a specific meta key from syncing

But if it is important for you to crosspost the value of that custom field, please read below.

Check for Inconsistent Values in the Database

This error usually happens when a specific meta field is incorrectly configured in the snippet we inserted into the second site before. Why did the plugin provid you with the incorrect metadata config? I am sorry to bring it to you but there is a mess in your database. I will explain.

For example, you’ve created a specific custom field on your website and decided that its value will be an object just like that:

meta value of an object type — We have a serialized object as a custom field value here.

But then you changed your mind and decided – why not simplify the whole thing a little bit and make the field a simple text string instead? It resulted in the inconsistency in the database:

different types of meta values at the same time — The custom field with the same “meta_key” has values of different types!

But my plugin just takes the latest created field value from the database (ordered by meta_id) and uses its type in the snippet, so we have this in the snippet:

register_meta( 'post', 'youtube_link', array( 'type' => 'object', 'single' => true, 'show_in_rest' => array( 'schema' => array( 'type' => 'object', 'additionalProperties' => true ) ) ) );

But it should be like this:

register_meta( 'post', 'youtube_link', array( 'type' => 'string', 'single' => true, 'show_in_rest' => true ) );

What to do?

The most proper way is to clean up your database from “incorrect” old entries and then go to plugin settings and copy the updated version of the snippet to the subsites one more time.

There is also an easy way though – just rename your custom field and then update the snippet.