Adding Custom Fields to HivePress Listings With Code

HivePress attributes configured through the admin interface cover most custom field needs. Code-registered fields are appropriate when field options come from a dynamic source, validation requires custom logic, or the field should behave differently based on another field’s value. This guide covers the programmatic approach with working examples.

When to Use Code vs Admin Attributes

Use the admin interface for attributes when the field type is standard, options are static, and validation is simple. Use code when options come from a dynamic source like a taxonomy or external API, validation requires custom business logic, the field should show or hide based on another field’s value, or you are building reusable functionality across multiple HivePress sites.

Registering a Custom Field Programmatically

HivePress fields are registered by filtering the model definition. Add to your child theme’s functions.php or a custom plugin:

add_filter('hivepress/v1/models/listing/fields', function($fields) {

    $fields['certification'] = [
        'label'   => 'Certification Level',
        'type'    => 'select',
        'options' => [
            ''         => 'Select...',
            'basic'    => 'Basic',
            'advanced' => 'Advanced',
            'expert'   => 'Expert',
        ],
        'required' => false,
        '_order'   => 100,
        '_display' => [
            'form'   => true,   // show in submission form
            'blocks' => ['listing_view_block'],  // show in listing card
        ],
    ];

    return $fields;
});

The _order value controls field position relative to others. The _display array controls where the field renders – in the submission form, the listing card on archive pages, or the single listing page.

Need a developer to implement this? Describe your project and get a free estimate.

Dynamic Options From a Taxonomy

Pulling select options from a WordPress taxonomy means options are managed through the standard taxonomy admin rather than code changes:

// Register the taxonomy first
add_action('init', function() {
    register_taxonomy('hp_skill', 'hp_listing', [
        'label'    => 'Skills',
        'public'   => false,
        'show_ui'  => true,
    ]);
});

// Reference the taxonomy in the field registration
add_filter('hivepress/v1/models/listing/fields', function($fields) {
    $fields['skill'] = [
        'label'    => 'Primary Skill',
        'type'     => 'select',
        'options'  => 'terms',
        'taxonomy' => 'hp_skill',
        '_order'   => 90,
        '_display' => ['form' => true],
    ];
    return $fields;
});

Custom Validation Logic

Add validation beyond required or character limits by hooking into the form error filter:

add_filter('hivepress/v1/forms/listing_submit/errors', function($errors, $form) {
    $url = $form->get_value('portfolio_url');

    if ($url && !preg_match('/behance.net|dribbble.com/', $url)) {
        $errors[] = 'Portfolio URL must link to Behance or Dribbble.';
    }

    return $errors;
}, 10, 2);

Displaying Fields in Templates

Fields registered with _display settings render automatically. For manual display in a template override, HivePress stores custom field values in post meta with the hp_ prefix:

$certification = get_post_meta(get_the_ID(), 'hp_certification', true);

if ($certification) {
    echo '<div class="listing-certification">' . esc_html($certification) . '</div>';
}

A field registered with the key certification is stored as hp_certification. Use this consistently when reading field values outside of HivePress’s rendering system.

Conditional Field Display With JavaScript

Showing a field only when another field has a specific value requires both JavaScript (to show/hide the field on the frontend) and server-side validation (to enforce the conditional requirement on submission). The JavaScript part runs in the browser and provides the interactive experience. The server-side part prevents someone from bypassing the frontend check:

add_action('wp_footer', function() {
    if (!is_page('submit-listing')) return;
    ?>
    <script>
    document.addEventListener('DOMContentLoaded', function() {
        var type = document.querySelector('[name="listing_type"]');
        var salaryRow = document.querySelector('.hp-field--salary').closest('.hp-form__field');

        function toggle() {
            salaryRow.style.display = type && type.value === 'paid' ? 'block' : 'none';
        }
        if (type) { type.addEventListener('change', toggle); toggle(); }
    });
    </script>
    <?php
});

Auto-Populating Fields From User Profile

For directories where vendors submit multiple listings with the same contact details, auto-populating fields from their profile reduces repetitive data entry. Add a default callback to the field registration that reads from the current user’s meta:

add_filter('hivepress/v1/models/listing/fields', function($fields) {
    $fields['contact_phone'] = [
        'label'   => 'Contact Phone',
        'type'    => 'text',
        'default' => get_user_meta(get_current_user_id(), 'hp_vendor_phone', true),
        '_order'  => 50,
        '_display' => ['form' => true],
    ];
    return $fields;
});

The default value pre-fills the field when the vendor opens the submission form. They can change it per listing if needed. The vendor phone meta (hp_vendor_phone) is populated from their HivePress vendor profile.

Syncing Custom Fields to Post Meta for External Queries

HivePress stores all custom field values as post meta with the hp_ prefix. This means any WordPress function that reads post meta – WP_Query meta_query, get_post_meta(), ACF field retrieval if you map the keys – can access HivePress custom field data directly. Build custom listing queries filtering on your code-registered fields the same way you would filter on any WordPress post meta. No additional integration needed.