The Data Layer provides the foundation for storing, retrieving, and managing multilingual content relationships across WordPress multisite blogs. It consists of three primary subsystems:
MslsOptions subclasses that store language mappings and generate content-type-specific permalinksMslsContentTypes abstraction that handles WordPress post types and taxonomies with access controlMslsLanguageArray, MslsGetSet, MslsJson) and the MslsSqlCacher performance layerThis page provides an architectural overview of how these systems interact. For admin configuration details, see Settings and Configuration Pages. For how data flows into frontend display, see Language Switcher Output.
The Data Layer coordinates three major subsystems that work together to manage multilingual content relationships:
Sources: includes/MslsContentTypes.php includes/MslsPostType.php includes/MslsTaxonomy.php includes/MslsOptions.php includes/MslsOptionsPost.php includes/MslsOptionsTax.php includes/MslsOptionsQuery.php includes/MslsRegistry.php includes/MslsGetSet.php includes/MslsLanguageArray.php includes/MslsJson.php includes/MslsSqlCacher.php
The Data Layer employs several design patterns for extensibility and performance:
| Pattern | Implementation | Purpose |
|---|---|---|
| Factory | MslsOptions::create(), MslsOptionsQuery::create() | Context-aware instantiation of correct options subclass |
| Registry | MslsRegistry singleton | Centralized object storage avoiding multiple singletons |
| Template Method | MslsOptions abstract base with get_postlink() | Standardized interface with content-type-specific implementations |
| Caching Proxy | MslsSqlCacher wrapping WordPress cache | Transparent query result caching |
| Property Overloading | MslsGetSet magic methods | Dynamic property access with automatic cleanup |
Sources: includes/MslsOptions.php includes/MslsOptionsQuery.php44-64 includes/MslsRegistry.php52-58 includes/MslsSqlCacher.php includes/MslsGetSet.php20-64
The MslsContentTypes abstraction layer distinguishes between post types and taxonomies, providing unified access control and type detection. Detailed documentation is available in Content Type Management.
Sources: includes/MslsContentTypes.php31-35 includes/MslsTaxonomy.php31-43 includes/MslsPostType.php24-36 includes/MslsTaxonomy.php77-88
| Class | Method | Returns | Purpose |
|---|---|---|---|
MslsPostType | get() | ['post', 'page', ...] | All public post types |
MslsPostType | get_request() | 'post' or 'page' etc | Current post type from request |
MslsPostType | is_post_type() | true | Type identification |
MslsTaxonomy | get() | ['category', 'post_tag', ...] | All public taxonomies |
MslsTaxonomy | get_request() | 'category' or 'post_tag' etc | Current taxonomy from request |
MslsTaxonomy | get_post_type() | 'post' or custom | Associated post type |
MslsTaxonomy | is_taxonomy() | true | Type identification |
Sources: includes/MslsPostType.php24-56 includes/MslsTaxonomy.php31-98
The MslsOptions class hierarchy provides specialized handlers for different WordPress content types. Each subclass stores language relationships and generates appropriate permalinks. Full details in Options and URL Generation.
Sources: includes/MslsOptionsTax.php24-40 includes/MslsOptionsTax.php47-53 includes/MslsOptionsQuery.php44-64
| Options Class | Separator | Storage Key | Permalink Method | Special Features |
|---|---|---|---|---|
MslsOptionsPost | _ | msls_{post_id} | get_permalink() | Checks post status |
MslsOptionsTax | _term_ | msls_{term_id} | get_term_link() | WooCommerce aware |
MslsOptionsTaxTerm | _term_ | msls_{term_id} | get_term_link() | Tag base rewriting |
MslsOptionsTaxTermCategory | _term_ | msls_{term_id} | get_term_link() | Category base rewriting |
MslsOptionsQuery* | N/A | Query params | Archive links | SQL caching via MslsSqlCacher |
Sources: includes/MslsOptionsPost.php12 includes/MslsOptionsTax.php12 includes/MslsOptionsTaxTerm.php includes/MslsOptionsQuery.php
The plugin includes several utility classes that support data operations. Complete documentation is in Data Utilities and Caching.
MslsLanguageArray stores language-to-ID mappings with automatic validation:
Validation Rules:
'en', 'de')Sources: includes/MslsLanguageArray.php39-46 includes/MslsLanguageArray.php56-75
MslsGetSet extends MslsRegistryInstance to provide dynamic property access with automatic cleanup:
| Magic Method | Behavior | Line |
|---|---|---|
__set($key, $value) | Store value; unset if empty | includes/MslsGetSet.php25-31 |
__get($key) | Return value or null | includes/MslsGetSet.php40-42 |
__isset($key) | Check if property exists | includes/MslsGetSet.php51-53 |
__unset($key) | Remove property | includes/MslsGetSet.php60-64 |
has_value($key) | Check non-empty property | includes/MslsGetSet.php95-97 |
reset() | Clear all properties | includes/MslsGetSet.php71-75 |
Sources: includes/MslsGetSet.php
MslsJson constructs sorted JSON arrays for AJAX autocomplete responses:
Usage Pattern:
Sources: includes/MslsJson.php26-33 includes/MslsJson.php43-45 includes/MslsJson.php52-58
MslsRegistry implements a singleton registry pattern to avoid multiple singleton instances:
Key Methods:
MslsRegistry::set_object($key, $instance) - Store object by keyMslsRegistry::get_object($key) - Retrieve object or nullMslsRegistry::instance() - Get singleton registry instanceSources: includes/MslsRegistry.php52-79
The plugin uses WordPress's native storage mechanisms with specific naming conventions for organizing multilingual relationships:
msls_{post_id} stores language mappings as {language_code} => {target_post_id}msls_{term_id}_term_{taxonomy} for taxonomy relationshipsMslsOptionsPost::SEPARATOR = '_' for post relationshipsMslsOptionsTax::SEPARATOR = '_term_' for taxonomy relationshipsSources: includes/MslsOptionsPost.php12 includes/MslsOptionsTax.php12 includes/MslsOptions.php
Refresh this wiki