How to Add a Custom Field in WordPress

How to add a custom field in WordPress with the built-in panel

A custom field is a name and a value stored on one post, page or product. WordPress keeps it in post meta. The box is hidden in the block editor until you ask for it.

1. Edit the post. Open the options menu in the top bar and choose Preferences.
2. Open the Panels section and enable Custom fields. The editor reloads.
3. Under the content, choose Enter new. Type a key such as source_url and a value. Click Add Custom Field.
4. Update the post. The pair is saved even though the public page does not show it yet.

What a custom field stores in the WordPress database

Each field becomes one row in the postmeta table: the post id, the meta key and the meta value, plus a unique meta_id. A key that starts with an underscore is hidden from the editor panel, which is how plugins keep internal settings out of sight.

The same idea powers user meta and term meta, so a field on a user profile lands in usermeta rather than postmeta. If a value looks empty after saving, check which table the code is actually querying.

How to show a custom field on the front end

Fetch the value with get_post_meta for the current post id, then escape it before printing. Escape as text with esc_html, as a link with esc_url, and as markup with wp_kses_post, so a stored value can never inject script into the page.

$source = get_post_meta( get_the_ID(), 'source_url', true );
if ( $source ) {
    echo '<p>Source: <a href="' . esc_url( $source ) . '">link</a></p>';
}

Put that in a child-theme template or a small site-specific plugin, and test on a copy: a syntax error in a template file returns a white screen. In a block theme you can skip the PHP and bind a block to the same key through the plugin's dynamic field, but the value still has to exist first.

How to save a custom field safely in PHP

Save inside a handler that checks a nonce, confirms the user can edit that post, sanitises the value, and only then calls update_post_meta. A save routine that skips the nonce lets any visitor with a crafted request overwrite your field.

add_action( 'save_post', function ( $post_id ) {
    if ( ! isset( $_POST['source_nonce'] ) ||
         ! wp_verify_nonce( $_POST['source_nonce'], 'save_source' ) ) {
        return;
    }
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }
    if ( isset( $_POST['source_url'] ) ) {
        update_post_meta( $post_id, 'source_url',
            esc_url_raw( wp_unslash( $_POST['source_url'] ) ) );
    }
} );

Register the key with register_post_meta when the value should also be available through the REST API, and set show_in_rest to true for block editor access. The WordPress database guide explains how postmeta sits beside the posts table if you want the storage model in more detail.

Native custom fields vs ACF vs Meta Box

Use the built-in panel for one or two text notes, Advanced Custom Fields for typed field groups with location rules, and Meta Box when the project needs many field types without a page-builder dependency. All three save to the same postmeta table.

Do not drive the same key from the built-in panel and a plugin at once. Pick one writer, or the value is saved twice under two names and the template reads whichever one it was told to read.

How to add custom fields with the ACF plugin

Install Advanced Custom Fields, open Field Groups and add a group, then add each field and set a location rule such as Post Type is equal to Post. The group appears under the editor for matching posts, and each field gets a key that get_field() can read.

1. Go to Plugins → Add New, search for Advanced Custom Fields, install and activate.
2. Open ACF → Field Groups → Add New and give the group a name that describes its content.
3. Click Add Field, set the label, the field name and the type (text, image, date picker), then close the field.
4. Add a location rule so the group only shows where it belongs, for example Post Type is equal to Post.
5. Publish the group, edit a post, fill the fields and update. Read the values later with get_field( 'field_name' ).

How to check that a custom field saved and displays

Reopen the post and confirm the value is still in the panel; if it vanished, the save handler returned early or the key was misspelled. Then load the public page in a private window, because a cached copy hides fresh output.

When the panel holds a value but the page prints nothing, check the template runs for that post type and that the key in the code matches the key in the database exactly. A quick var_dump of get_post_meta for the post id shows what WordPress actually stored.

None of this depends on the hosting account: the field and the code travel with the site. On WebJi® WordPress hosting the database is reachable from cPanel when you need to inspect postmeta directly.