Build separate extensions using the plugin’s documented lifecycle and integration contracts.
How it works
CYBERMAPS is a complete standalone WordPress plugin. Its Extension API 2.0 exposes:
- endpoint metadata registration;
- read-only access to the final publication-eligibility service; and
- read-only access to saved content report runs.
Extensions implement and route their own capabilities; CYBERMAPS retains ownership of its settings, tables, files, lifecycle, and public namespace.
Proxy integrations may use cybermaps_client_ip_resolution after validating
their own trust boundary. The filter receives a bounded, sanitized context
containing only supported peer and forwarding-header values, never the complete
server environment. A filtered address is revalidated before use.
Activation provisions Core runtime storage, schedules cleanup, adds rewrite rules, and initializes publication state. Relevant settings changes invalidate caches and schedule ownership-safe static reconciliation. Static publication is disabled on multisite; each site continues to use dynamic delivery.
Deactivation clears scheduled events and rewrite rules and makes a bounded attempt to remove unchanged Cybermaps-owned output. Edited files, lock contention, storage failures, or the cleanup deadline can leave files in place. No purge continuation is left scheduled after deactivation or uninstall. Reactivation schedules restoration for the selected static mode where it is supported.
Uninstall also attempts ownership-safe file cleanup. Persistent Core options, tables, and metadata are removed only when Uninstall Cleanup was enabled beforehand; this data cleanup does not depend on every static file being removed. Non-sensitive cache-generation fences remain to prevent reuse of stale external cache data. Edited and pre-existing files are retained.
MCP upgrade cleanup runs per site and deletes retired configuration keys, credential tables and scheduled tasks, then reconciles discovery publications. The old server implementation and empty OAuth upgrade step are deleted. Cleanup preserves unrelated settings and converts explicit 8.0 adapter consent to the new boolean setting. Optional MCP cannot be enabled until cleanup finishes; 7.x clients must reconnect through WordPress MCP Adapter.
Data upgrades run as idempotent, resumable steps with a renewable owner lock, persisted progress, retry backoff, and post-write verification. New installations are stamped before defaults are created; existing configuration is normalized without overwriting a newer value observed during the upgrade. Static ownership uses a per-path database inventory with bounded migration of legacy options and shards. An unavailable ownership migration remains visible and retryable while dynamic publication and unrelated Core upgrades continue. The four structured configuration roots and operational coordination options are non-autoloaded.