Custom Posts & Fields

SCOS ships recommended custom post types asl opt-in, all registered only when their module toggle is on.

Where to manage them: Site Essentials → Recommended Custom Posts & Fields (site-essentials-cpt).

Exception: Post Framing lives under the Social Amplification module, not the CPT toggle cards.

faq — FAQ System

Toggle: enable_faq (CPT module)
Tier: Basic

Description:
Reusable Q&A entries stored as a dedicated CPT. Used for FAQPage schema, Gutenberg FAQ Selector block, Breakdance FAQ elements, and as Search Intent Goals linked from Content Architecture meta.

Special customisations:

• Hierarchical — parent/child FAQ grouping
• Permalinks: /faq/{topic-slug}/{faq-slug}/ via %scos_topic% rewrite tag
• Topic taxonomy: uses site-wide scos_topic (shares CA vocabulary)
• Archive: off by default; optional /faq/ archive via scos_faq_archive_enabled
• Excluded from front-end search and Yoast sitemap
• Meta: scos_faq_schema_answer, scos_faq_enable_schema, scos_faq_is_intent_goal (legacy _faq_* dual-written)
• Outputs: [faqs] shortcode, brighter/faq-selector Gutenberg block, unified schema graph injection
• Two REST surfaces: editor-only site-essentials/v1/faqs* vs external brighter-core/v1/faqs (token auth)

projects — Customer Success Stories

Toggle: customer_success_stories (CPT module)
Tier: Pro
Post type slug is always projects — admin labels and URL slug are configurable.

Description:
Case studies / project portfolios. The standard SCOS proof-asset CPT for B2B and service businesses. Feeds social amplification, Airtable sync, and review relationships.

Special customisations:

• Configurable archive slug (archive_slug option, default projects) — labels auto-derive from slug
• Optional WP Categories and Tags on projects (separate toggles)
• Supports: title, editor, thumbnail, excerpt, revisions
• Author support added by brighter-core post-type-enhancements
• Full CAR + SEO meta boxes (registered before CA taxonomy cache at init priority 16)
• Social amplification: primary target for bw-social/v1/amplify and backfill
• API: GET /brighter-core/v1/project when CPT exists (GS sites)

bw_reviews — Review System

Toggle: enable_reviews (CPT module)
Tier: Basic
Slug: bw_reviews (legacy — migration to scos_review_* keys planned, not done)

Description:
Structured customer reviews as a queryable SSOT — no public URLs, no archive. Designed for Breakdance loops, shortcodes, aggregate widgets, and schema output. Title field = customer name.

Special customisations:

• public: true but rewrite: false — queryable in BDE/WP_Query, invisible to URLs
• Excluded from XML sitemaps via filter
• Taxonomy: bw_review_platform (Google, Facebook, Trustpilot seeded; per-term logo upload with SVG sanitisation)
• Meta: rating, date, date precision, verify URL, schema ID (auto-generated, stable), success outcome, customer detail, featured flag, review excerpt
• ACF relationship to projects (bidirectional if ACF Extended active)
• Shortcodes: [bw_review_card], [bw_aggregate_review], [bw_review_count], [bw_review_average], plus field-level [bw_review_*]
• CSV bulk import from CPT settings → Reviews tab
• Custom BDE elements: SCOS Review Card, Aggregate Review

scos_social_framing — Post Framing

Toggle: Social Amplification module (not a CPT module card)
Replaces legacy: bw_talking_point (one-time DB migration on module activation)

Description:
Admin-only library of AI framing templates for social caption generation. Each “Post Frame” defines tone, hooks, CTAs, and word-count targets per content type. Consumed by Make.com via brighter-core/v1/social-amplification/* endpoints.

Special customisations:

• public: false — admin UI only, no front-end URLs
• Meta: scos_sma_pf_content_type, scos_sma_pf_context, scos_sma_pf_example, scos_sma_pf_cta, scos_sma_pf_words_min/max (dual-reads legacy _bw_tp_*)
• Hidden taxonomy: bw_content_type (kept for Make.com / REST backward compat)
• Content type options map to BW_Content_Type_Helper slugs (article, service, case-study, guide, news, etc.)
• Legacy BW_Talking_Points in brighter-core skips registration when SCOS_SA_ACTIVE is defined

Related toggle — not a CPT

Author Extension

Toggle: enable_author_extension (same CPT settings page)
Not a post type — extends WP user profiles with scos_author_* meta (job title, works_for, social links, etc.) for Person schema / E-E-A-T. Lives in brighter-core/includes/class-author-extension.php.

Legacy per-site CPTs — not SCOS-recommended

These are not registered by site-essentials but brighter-core still knows about them on specific client sites:

Registered elsewhere (historically per-site). SCOS endpoints auto-expose them only if the post type exists on that install.

Technical info for dev & super users

1. Opt-in model — all recommended CPTs default off; toggling on is what registers the CPT. No toggle = post type does not exist.
2. Slug vs label split on projects — post type is always projects; archive_slug only changes URLs and admin labels.
3. bw_reviews URL paradox — public: true + rewrite: false is intentional; (so BDE is queryability without crawlable URLs and so can be included in the sitemap exclusion filter.
4. Legacy key migration status — Reviews (bw_*), FAQ (dual _faq_* / scos_faq_*), Post Framing (_bw_tp_* / scos_sma_pf_*). MCP/CLI should query scos_faq_*.
5. FAQ dual REST architecture — site-essentials/v1 (editor) vs brighter-core/v1 (external token). Stale entries in settings-api.php (/faqs/search, /faqs/export under brighter-core) need correction – issue is logged.
6. CPT ↔ CA integration — faq must register at init priority 16 (before CA taxonomy association at 20) or it misses CAR/SEO meta boxes.
7. Per-site legacy CPTs (folio, kb, news) — document as “client-specific, not SCOS-delivered” so agents don’t expect them on GS/OTC sites.
8. bw-social/v1 whitelist gap — if REST API restriction tweak is on, amplify/backfill loopback is not whitelisted (only brighter-core is). Super-user doc should call this out.

Usage guides (general users / clients)

Worth covering in plain language:

1. When to enable which CPT — FAQ for schema + intent goals; Projects for case studies; Reviews for trust widgets (not standalone pages); Post Framing only if using social amplification.
2. FAQ workflow — standalone FAQ vs embedded via block vs intent-goal stub creation from CA meta box.
3. Projects naming — “Success Stories” on one site might be /work/ on another; explain the rename field affects menu labels and URLs.
4. Reviews are not pages — no URLs, no sitemap; used in loops/widgets only. CSV import path and required columns.
5. Featured reviews + platform logos — how aggregate widget and review cards pull data.
6. Post Framing for non-technical users — what a “frame” is, how content type selection affects Make.com output, don’t edit unless running social automation.
7. Author Extension — when to enable (multi-author publishing, E-E-A-T), where fields appear (Users → Profile), link to schema Person output.

Other notes.

• All recommended CPTs get CAR + SEO meta boxes when CA/SEO modules are active
• Sitemap behaviour differs per CPT (FAQ excluded, Reviews excluded, Projects included when public)
• Breakdance integration points — FAQ block filter, Review Card element, project loops

What CPT SCOS does not provide + Why

Services CPT

Instead recommended approach is to use Standard WP Pages (for small to med service or or productised services (non-WooCommerce) services/service-name or just service-name and set intent as commercial/decision support and purpose (scos_ca_purpose) as service (term slug is service-page)

SCOS uses post meta for purpose/intent rather than taxonomies or CPTs — this keeps the data model flat and portable. The tradeoff is Breakdance’s UI taxonomy condition won’t see it directly, so use Custom PHP condition instead.

Use Breakdances Custom PHP condition. (or you could match on post title if you only have a few and not likely to want to add more service pages),

php

global $post;
if (!$post) return false;

$purpose = get_post_meta($post->ID, 'scos_ca_purpose', true);
return $purpose === 'service-page';

For product-page template, same pattern:

php

global $post;
if (!$post) return false;

$purpose = get_post_meta($post->ID, 'scos_ca_purpose', true);
return $purpose === 'product-page';

Location setting — set it to “Single / Pages” not “Single / All Singles” so the PHP condition only fires against standard pages, not every post type on the site.

Priority — if you have multiple page templates, the service-page template should have a lower priority number than your generic page fallback so it takes precedence when the condition matches.

Portfolio

Rename use the rewrite options in success stories/projects

Others:

KB/News for site-specific builds use ACF