Data Modeling
Custom Post Types (CPT)
The architecture leverages Custom Post Types to separate distinct content types from standard posts and pages. This ensures a clean separation of concerns and allows for specialized behavior across the platform.
Registering Content Types
To register a new content type within this framework, use the standardized configuration wrapper. This ensures that all CPTs inherit the correct REST API visibility and capability mappings.
// Example: Registering a 'Product' CPT with the internal framework
$args = [
'label' => 'Products',
'public' => true,
'show_in_rest' => true, // Required for Gutenberg and REST API usage
'supports' => ['title', 'editor', 'thumbnail', 'custom-fields'],
'has_archive' => true,
'rewrite' => ['slug' => 'products'],
];
register_post_type('ua_product', $args);
Supported Post Types
By default, the following post types are modeled:
portfolio: Used for showcasing MVP iterations.contribution: Tracks weekly WordPress contributions.documentation: Hierarchical content for internal and public guides.
Metadata Structures
Data modeling in this project relies heavily on structured metadata (Post Meta) to extend the core WordPress schema without bloating the global wp_posts table.
Accessing Meta Data
All custom fields are prefixed to prevent namespace collisions. It is recommended to use the core get_post_meta function or the provided helper methods for type-safe retrieval.
| Key | Type | Description |
| :--- | :--- | :--- |
| _ua_priority_level | string | Sets the display priority (low, medium, high). |
| _ua_contribution_date| date | The ISO 8601 date of the contribution. |
| _ua_version_ref | string | Semantic versioning tag (e.g., v1.0.4). |
Usage Example:
// Retrieve the priority level for a specific contribution
$priority = get_post_meta($post_id, '_ua_priority_level', true);
if ($priority === 'high') {
// Apply specialized logic
}
Internal Meta Validation
While meta storage is flexible, the repository includes an internal validation layer (located in includes/meta-validator.php) that checks data integrity before saving to the database. This layer is internal and requires no manual configuration, but users should ensure data types match the expected schema to avoid "Sanitization Rejected" errors.
Database Optimization Strategies
To maintain high performance as the data grows, the following optimization strategies are implemented at the data modeling layer.
Indexing and Querying
Avoid querying by meta_value whenever possible, as this leads to unindexed table scans.
Recommended Query Pattern:
When querying content, prioritize post_type and tax_query over meta_query. If a meta_query is necessary, ensure you are filtering by meta_key first.
$args = [
'post_type' => 'contribution',
'meta_query' => [
[
'key' => '_ua_priority_level',
'value' => 'high',
'compare' => '=',
],
],
];
$query = new WP_Query($args);
Object Caching
This project is configured to utilize Persistent Object Caching.
- Usage: Data retrieved via
get_post_metaorWP_Queryis automatically cached. - Bypassing: If you require fresh data from the database (bypassing the cache), use the
clean_post_cache($post_id)function before your call, though this is discouraged in production environments.
Lazy Loading Meta
By default, this implementation utilizes update_post_caches(). When a list of posts is retrieved, all associated metadata is fetched in a single, grouped database query rather than multiple individual queries, significantly reducing the I/O load on the wp_postmeta table.