How to Add Custom Fields Automatically When Publishing WordPress Posts

Use one of three methods: register post metadata and send it in the REST API request, run a safe save_post handler that writes the value during a save, or configure a field plugin such as ACF. For block-editor and REST workflows, register the key with show_in_rest => true, make sure the post type supports custom-fields, and put API values inside the request’s meta object.

A custom field is post metadata: a key/value pair attached to a post. A key may have multiple values, so choose single-value and duplicate behavior deliberately. See WordPress’s explanation of assigning custom fields.

#	Preview	Product	Price
1		WordPress Bible	$25.59	Buy on Amazon
2		WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)	$24.99	Buy on Amazon

Choose the automation path that matches where the post comes from

Method 1: populate metadata through the REST API

Register the metadata before sending it. The registration defines its data type, whether it stores one value, and whether WordPress exposes it through REST. The Block Editor Handbook explicitly notes that the post type must support custom-fields for register_post_meta metadata to work: Meta Boxes – Block Editor Handbook.

Register a single string value

Put this in a site-specific plugin or a theme’s appropriately maintained bootstrap file. A plugin is generally safer when the metadata must continue working after a theme change.

#1 Best Overall

WordPress Bible

$25.59

Buy on Amazon

<?php
add_action( 'init', function () {
    register_post_meta( 'post', 'source_url', array(
        'type'              => 'string',
        'single'            => true,
        'show_in_rest'      => true,
        'sanitize_callback' => 'esc_url_raw',
        'auth_callback'     => function () {
            return current_user_can( 'edit_posts' );
        },
    ) );
} );

Replace post with your custom post type slug. That post type must support custom fields; add support when registering the type or with add_post_type_support( 'your_type', 'custom-fields' ). If the field is numeric, boolean or an array, register the matching type and validation/sanitization instead of treating it as a string.

Send the value in the post request

After registration and authentication, create or update the post with a meta object. Learn WordPress documents this request shape in its REST API custom fields tutorial:

{
  "title": "New Post Title",
  "content": "New Post Content",
  "status": "publish",
  "meta": {
    "source_url": "https://learn.wordpress.org"
  }
}

The example shows structure, not a complete authentication recipe. The account or application making the request must have permission to publish and edit the post and its metadata. The key will not be accepted as expected if it was not registered with REST visibility or if the post type lacks custom-fields.

Verify the result

1. Confirm the registration code loads without a PHP error.
2. Check the post type’s supports declaration for custom-fields.
3. Send an authenticated create or update request with the value under meta.
4. Retrieve the post and inspect its meta object, or inspect the value in WordPress after saving.

WordPress’s REST guidance for exposing and modifying metadata is at Modifying REST API responses.

Method 2: assign a value automatically while a post is saved

The save_post action runs during post saving and is suitable for deriving metadata from the post, its author, taxonomy, or another rule. The official reference also notes that plugins such as ACF and Pods use this hook: save_post.

Example: set a value once when a post is published

This example fills source_url only for standard posts, only when the status is publish, and only when the field is empty. It uses update_post_meta, which keeps one current value instead of appending another row on every save.

Rank #2

WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)

$24.99

Buy on Amazon

<?php
add_action( 'save_post', function ( $post_id, $post, $update ) {
    if ( 'post' !== $post->post_type ) {
        return;
    }

    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }

    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }

    if ( 'publish' !== $post->post_status ) {
        return;
    }

    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    if ( '' !== get_post_meta( $post_id, 'source_url', true ) ) {
        return;
    }

    update_post_meta( $post_id, 'source_url', esc_url_raw( 'https://example.com/source' ) );
}, 10, 3 );

Replace the example URL and rule with your actual source. If the value comes from a submitted form rather than a fixed rule, also validate the request’s nonce and sanitize the submitted value before writing it.

Why the guards matter

• Autosaves and revisions: WordPress can save temporary or revision records that should not receive the production value.
• Post type and status: Restrict the handler so pages, custom types, drafts or scheduled posts are not changed accidentally.
• Capability checks: Do not accept user-controlled metadata without verifying that the current user may edit the post.
• Repeated execution: Editors, autosaves and other plugins can trigger saves more than once. A test for an existing value or an idempotent update prevents unintended changes.

Prevent duplicate metadata

add_post_meta can create another value for a key that already exists. Its unique argument can prevent duplicates, but a single-value field is usually clearer when registered with single => true and written with update_post_meta.

• Use get_post_meta( $post_id, $key, true ) to test the current single value.
• Use update_post_meta when the key should always contain the latest value.
• Use add_post_meta( $post_id, $key, $value, true ) only when you intentionally want to add a value once and reject later additions.
• Allow multiple values only when the data model genuinely requires them, and document how readers of the metadata should interpret those rows.

Method 3: manage fields with ACF

Advanced Custom Fields provides a visual field-group interface for editors who should configure named fields without writing registration code. Its documentation explains that field groups can be exposed through the REST API and that REST visibility is controlled in field-group settings: ACF REST API Integration.

Use ACF when editors own the field definition

• Create a field group and assign it to the relevant post type.
• Define the field’s return format, required state and validation in the field-group settings.
• Enable REST visibility when an external publisher or headless front end must access the fields.
• Use the ACF field names consistently in the API payload and in any save-time rules.

ACF is an optional software route, not a requirement for WordPress metadata. A plugin does not remove the need to consider permissions, repeated saves or whether the field should hold one value.

Native Custom Fields: useful for manual entry, not automatic rules

WordPress’s built-in Custom Fields interface lets an editor assign arbitrary key/value metadata from the editor when the feature is available. The user documentation covers that manual process at Assign custom fields. It does not, by itself, derive a value when a post is submitted. Automatic population still requires a save-time integration, REST request, or field-management plugin.

Troubleshooting checklist

The value is missing from the REST response

• Confirm show_in_rest is true.
• Confirm the metadata is registered on the correct post type.
• Confirm that post type supports custom-fields.
• Check that the request is authenticated with permission to read the post and metadata.

The API request ignores the field

• Use the exact registered key inside meta; do not put it at the top level of the JSON body.
• Verify registration runs before the request is handled.
• Check the registered data type and send a value in that format.
• Ensure the authenticated user can edit the post.

The save handler creates several values

• Replace unconditional add_post_meta with an existence check and update_post_meta for a one-value field.
• Exclude autosaves and revisions.
• Check whether another plugin or callback writes the same key.

The handler never runs

• Confirm the plugin or theme code is active and free of PHP errors.
• Use the correct post type and hook arguments; the example registers three arguments with priority 10.
• Test with a normal save or publish after temporarily removing an overly restrictive status or capability condition.

Implementation decision

Use REST registration when another application owns publishing. Use a guarded save_post callback when WordPress should derive the value during an editor save. Use ACF when non-developers need to manage field groups. In every path, define whether the key is single or repeatable, expose it to REST only when needed, and make the write operation safe when WordPress saves the post more than once.

Quick Recap

Bestseller No. 1

WordPress Bible

$25.59

Bestseller No. 2

WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)

$24.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.