updatePostType
Update a post type's settings, such as renaming, toggling active status, or changing search results display. Automatically refreshes cache after changes.
Instructions
Update a post type - Update a post type. PATCH semantics (except per Rule: Post-type code fields). Writes live data.
Cache refresh is automatic. Response includes auto_cache_refreshed: true after successful writes; no manual refreshSiteCache call needed. If auto_cache_refreshed: false, check auto_cache_refresh_error and retry refreshSiteCache once.
Required: data_id.
Picking the right post type — disambiguation. Apply Rule: Resource disambiguation before editing. "Edit my classifieds page" is layer-ambiguous (a WebPage vs. the post type's code group vs. Member Listings UI vs. a category landing) — confirm WHICH layer even when only one record string-matches. Resolve to data_id via listPostTypes first; never proceed on semantic similarity alone.
Use when: toggling a post type active/inactive, renaming, changing per-page display counts, editing search-results UI or profile-page code. For Member Listings specifically: tuning keyword-search, pagination, sidebar, sort order. Custom field DEFINITIONS live in BD admin UI, not API.
Universal structural safety - NEVER mutate these fields on ANY post type: data_type, system_name, data_name, data_active, data_filename, form_name, software_version, display_order. BD system-seeds them; changes break rendering site-wide.
MEMBER LISTINGS SPECIAL CASE (data_type=10). Every BD site has exactly one post type with data_type=10 (system_name=member_listings) - it controls the Member Search Results page UI/UX. No profile/detail page of its own - members render via the normal profile system. data_id varies per site; discover via listPostTypes property=data_type property_value=10 property_operator==. Cache the data_id for the session - it never changes.
Member Listings cheat-sheet (12 commonly-edited UI/UX settings + 3 search-code fields - NOT a limit, any real column is writable per schema-is-documentation): h1, h2, per_page, keyword_search_filter, enableLazyLoad, category_order_by, category_ignore_search_priority, post_type_cache_system, category_sidebar, sidebar_search_module, sidebar_position_mobile, enable_search_results_map, category_header, search_results_div, category_footer.
Member Listings guardrails (apply ONLY to data_type=10):
profile_header/profile_results_layout/profile_footer/search_results_layouthave NO effect on Member Listings - skip them.data_activemust stay1; no legitimate reason to disable via API.On other post types (blog, event, coupon, property, product), these ARE legitimate rendering fields - write freely.
CODE FIELDS - master-fallback on GET + all-or-nothing save per group. Up to 8 code-template fields begin life backed by BD's MASTER post-type template; they only persist locally when saved. GET returns master value for un-customized fields (agent sees real rendered code, not empty string). Writing ANY field in a group requires sending ALL fields in that group (unchanged fields copied verbatim from prior GET); omitting group-mates causes them to drift back to master on next render.
Groups:
Search-results (every post type INCLUDING Member Listings):
category_header+search_results_div+category_footer. Send all 3.Profile/detail (post types WITH detail pages - NOT Member Listings):
profile_header+profile_results_layout+profile_footer. Send all 3. DO NOT send on Member Listings.Standalone (post types WITH detail pages - NOT Member Listings):
search_results_layout(single.php analogue - misleading name) andcomments_code(auxiliary footer, embeds/schema/pixels). Both save independently, no group rule. Master-fallback applies. DO NOT send on Member Listings.
Code-edit workflow:
getPostType(data_id)- returns current values with master fallback.Identify target group.
Build payload: changed field(s) + other group-mates copied verbatim from GET.
updatePostTypewithdata_id+ full group. (Cache flush is automatic post-write.)
Code-field trust level: all 8 code fields are widget-equivalent - accept arbitrary HTML/CSS/JS/iframes/PHP (BD evaluates PHP server-side at render). XSS/SQLi sanitization rules do NOT apply - anyone editing post-type code already has full site code control. Supports PHP variables (<?php echo $user_data['full_name']; ?>) and BD text-label tokens (%%%text_label%%%).
Member Listings code edits affect every member-search page on the site - confirm intent with user before editing Member Listings code fields.
See also: getPostType, listPostTypes (filter by data_type), deletePostType (NOT for Member Listings - system-required).
Returns: { status: "success", message: {...updatedRecord}, auto_cache_refreshed: true|false, auto_cache_refresh_error?: "..." }.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data_id | Yes | Post type primary key. Required. For the Member Listings post type (`data_type=10`, singleton per site), discover via `listPostTypes` filtered by `property=data_type&property_value=10&property_operator==` - `data_id` varies per site. | |
| category_tab | No | Admin-UI label for the post-type tab. | |
| feature_categories | No | Comma-separated category list for this post type's `post_category` dropdown. Sending REPLACES the entire CSV (no per-item PATCH). Existing posts using categories not in the new CSV become orphans — pre-audit via `listSingleImagePosts property=post_category` before pruning. | |
| per_page | No | Number of results per search results page. Default 9 (Member Listings). Recommended max 500 for site-speed reasons. | |
| h1 | No | Search Results page H1 heading. | |
| h2 | No | Search Results page H2 sub-heading. | |
| keyword_search_filter | No | Post Keyword Search Options. `level_2` = default fields only (faster). `level_3` = default + custom fields (slower; sites with many posts/custom fields can be significantly slower). Default on Member Listings: `level_3`. | |
| enableLazyLoad | No | Pagination Display Options. `1` = Insta-Load Search Results (default on Member Listings), `0` = Standard Pagination, `2` = Hide Pagination. | |
| category_order_by | No | Display order of results. `alphabet-asc` (Member Name A-Z, default) / `alphabet-desc` / `userid-asc` (Member ID Oldest First) / `userid-desc` (Newest First) / `last_name_asc` / `last_name_desc` / `reviews` (Most Reviews First) / `random`. | |
| category_ignore_search_priority | No | When sorting members, respect Membership Plan 'Search Priority'? `0` = Yes (respect plan priority, default), `1` = No (ignore plan priority). | |
| post_type_cache_system | No | Enable search-results cache. `1` = Yes (recommended; subsequent matching searches load faster). `0` = No (always query DB). **Cannot be `1` when `category_order_by=random`** - admin UI disables cache in that case; sending `post_type_cache_system=1` with `category_order_by=random` is an invalid combination. | |
| category_sidebar | No | Sidebar to display on search-results pages. Valid values: `""` (no sidebar), a Master Default Sidebar, or a custom sidebar `name` from `listSidebars`. See **Rule: Sidebars** for the canonical Master Default list and selection workflow. **Semantic equivalent of `form_name` on WebPages** - different variable name, same value set. Default on Member Listings: `Member Search Result`. | |
| sidebar_search_module | No | Widget name for the search module inside the sidebar. Must match an existing widget on the site - not server-enforced, BD ships new ones in core releases. Common values: `Bootstrap Theme - Search Module - Keyword_Location` (Member Listings default), `No Search Module - None` (disables), `Bootstrap Theme - Search Module - Keyword Only`, `Bootstrap Theme - Search Module - Local Radius Search`, `Bootstrap Theme - Search Module - Top Category Only`, `Bootstrap Theme - Search Module - Top_Category_Location`, `Bootstrap Theme - Search Module - Top_Sub_Category`, plus Dynamic Category Filter set and post-search variants. If unsure which is valid on THIS site, enumerate via `listWidgets` and match by `widget_name`. Also: the `category_sidebar` chosen must contain the `Bootstrap Theme - Search Module - Dynamic Sidebar Search` host widget for the module to render. | |
| sidebar_position_mobile | No | Sidebar position on mobile devices ONLY (desktop uses `menu_layout`/page-level defaults). `top` = above results, `bottom` = below results (default), `hide` = do not render sidebar on mobile. | |
| enable_search_results_map | No | Display Google Map option at top of search results pages. `1` = Yes, show the map pin icon (default on Member Listings). `0` = No. Requires the Google Maps site feature to be enabled for the map itself to load. | |
| category_header | No | **CODE FIELD - search results HEADER** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust; no input sanitization). Renders ABOVE the member-search results loop. Supports PHP variables (`<?php echo $user_data['full_name']; ?>`) and `%%%text_label%%%` tokens. Part of the search-results code group - master-fallback on read + all-or-nothing save — see **Rule: Post-type code fields**. | |
| search_results_div | No | **CODE FIELD - search results LOOP** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust; no input sanitization). Renders ONCE PER matching member in the results list. Supports PHP variables and `%%%text_label%%%` tokens. Part of the search-results code group (`category_header` + `search_results_div` + `category_footer`) - master-fallback on read + all-or-nothing save — see **Rule: Post-type code fields**. | |
| category_footer | No | **CODE FIELD - search results FOOTER** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust; no input sanitization). Renders BELOW the member-search results loop. Supports PHP variables and `%%%text_label%%%` tokens. Part of the search-results code group (`category_header` + `search_results_div` + `category_footer`) - master-fallback on read + all-or-nothing save — see **Rule: Post-type code fields**. | |
| profile_header | No | **CODE FIELD - profile/detail page HEADER** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust). Renders ABOVE main content on the single-record detail page for post types with per-record detail pages (blog, event, coupon, property, product, etc.). Part of the profile code group (`profile_header` + `profile_results_layout` + `profile_footer`) - all-or-nothing save rule applies — see **Rule: Post-type code fields**. **NOT applicable to Member Listings (`data_type=10`)** - members render via BD's core profile system, not a post-type template. Field stores but has no rendering effect; do not send on Member Listings updates. | |
| profile_results_layout | No | **CODE FIELD - profile/detail page BODY** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust). Main detail-page template - BD's equivalent of WordPress `single.php`. **Misleading name** - NOT search-results layout; this is the DETAIL page for a single record. For Member Listings, this drives the member profile page. **Part of the profile code group** with `profile_header` + `profile_footer` - all-or-nothing save rule applies (send all three together when editing any of them) — see **Rule: Post-type code fields**. | |
| profile_footer | No | **CODE FIELD - profile/detail page FOOTER** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust). Renders BELOW the main content on the single-record detail page. **Part of the profile code group** with `profile_header` + `profile_results_layout` — see **Rule: Post-type code fields**. | |
| search_results_layout | No | **CODE FIELD - single-record detail page code** (HTML/CSS/JS/iframe/PHP; widget-equivalent trust). **Misleading name** - despite the `search_results_` prefix, this is the DETAIL page code for a single post record (BD's equivalent of WordPress `single.php`). Applies ONLY to post types with per-record detail pages (blog, event, coupon, property, product, etc.). **NOT applicable to Member Listings (`data_type=10`)** - members render via BD's core member profile system, not a post-type template. Do not send on Member Listings updates. Standalone - NOT in the profile triplet; saves independently. Uses master-fallback-on-read like other code fields. | |
| comments_code | No | **CODE FIELD** - additional detail-page footer/embed code (HTML/CSS/JS/iframe/PHP; widget-equivalent trust). Renders directly AFTER `search_results_layout` on the single-record detail page - for embed widgets, schema markup, analytics pixels, structured data, auxiliary footer code. Applies ONLY to post types with per-record detail pages (blog, event, coupon, property, product, etc.). **NOT applicable to Member Listings (`data_type=10`)** - no post-type-driven detail page; do not send on Member Listings updates. Standalone - NOT in the profile triplet or search-results group; saves independently. Uses master-fallback-on-read like other code fields. | |
| _clear_fields | No | Column names to clear to empty string. Available on every `update*` operation. Works on base columns AND EAV/`users_meta` rows (rows preserved with `value=""`). To actually clear a field you MUST use this parameter — sending the field with `""` alone is a no-op (BD drops empty values). To remove a `users_meta` row entirely, use `deleteUserMeta`. See **Rule: Clearing fields**. Example: `_clear_fields: ["h2", "hero_link_url"]`. |