Files
nexus/wiki/concepts/CodeOverConfiguration.md
weishen 8525e8e6da ingest: CMS Developer Agent Personality (engineering-cms-developer.md)
- Source: sources/engineering-cms-developer.md
- Entities: WordPress, Drupal
- Concepts: ContentModel-first, CodeOverConfiguration
- Updated: index.md (Sources/Entities/Concepts), overview.md, log.md
2026-05-01 15:21:22 +08:00

2.5 KiB

title, type, tags, last_updated
title type tags last_updated
CodeOverConfiguration concept
cms
development
best-practices
2026-05-01

Definition

CodeOverConfiguration is a CMS development principle requiring that all structural changes — custom post types, taxonomies, fields, blocks, and behavioral settings — be registered in code rather than created through the admin UI. Configuration that affects behavior is also stored in code (not the database).

Core Principle

"Custom post types, taxonomies, fields, and blocks are registered in code — never created through the admin UI alone."

WordPress Application

What Where to register
Custom post types functions.phpregister_post_type()
Custom taxonomies functions.phpregister_taxonomy()
ACF field groups acf-json/ directory (synced)
ACF blocks functions.phpacf_register_block_type()
Gutenberg blocks block.json + JS registration
Theme settings wp-config.php or functions.php

Example: Post type in code

add_action( 'init', function () {
    register_post_type( 'case_study', [
        'public'        => true,
        'show_in_rest'  => true,
        'supports'      => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
    ] );
} );

Drupal Application

What Where to store
Content types YAML config export (drush cex)
Field definitions YAML config in config/install/
Custom modules PHP code + YAML routing/permissions
Blocks PHP attribute-based plugins (Drupal 10+)
Views YAML config export

Why It Matters

  • Version control: All structural changes are tracked in Git
  • Reproducibility: A fresh environment gets the same structure from a deploy script
  • Team consistency: No one accidentally changes a field label in production
  • Deployment safety: Config changes go through CI/CD, not manual admin actions

Anti-patterns

  • Creating post types via the WordPress admin UI without code equivalent
  • Storing CMS settings that affect behavior in the database instead of code
  • Modifying contrib module/theme files directly instead of using hooks/overrides
  • ContentModel-first — the companion principle: define the model first, then implement
  • GitWorkflow — version control makes code-as-config viable
  • WordPress — WordPress-specific code registration patterns
  • Drupal — Drupal-specific YAML configuration export workflow

Sources