Rename plugin to Open Trust Center by Ettic and migrate internal namespace to ettic_

[r00bbert]

Context

WordPress.org plugin review flagged the OpenTrust name as a trademark conflict (DocuSign holds registered "OpenTrust" word marks in classes 9 and 42 in France and the UK). After back-and-forth, the reviewer approved the new name "Open Trust Center by Ettic" and asked us to migrate the internal namespace away from the trademarked term.

Reviewer guidance:

• Required: plugin name, slug, readme, all user-facing references
• Strongly recommended: internal opentrust_ / OpenTrust_ prefixes and text domain

Decision: do the full rename, including internals. We're pre-launch on wp.org with no real install base to migrate, and leaving opentrust as the internal namespace would keep this issue alive for every future review and dispute.

Scope

User-facing (required)

• Plugin display name: OpenTrust → Open Trust Center by Ettic
• Plugin slug / folder: opentrust → open-trust-center-by-ettic
• Plugin main file: opentrust.php → open-trust-center-by-ettic.php
• Text domain: opentrust → open-trust-center-by-ettic
• readme.txt header and all copy
• All translated strings referencing "OpenTrust" as the product name
• Admin menu labels, settings page titles, all visible UI strings
• Regenerate .pot and rebuild nl_NL translation

Internal (proposed: ettic_ / Ettic_)

• PHP classes: OpenTrust_* → Ettic_* across includes/ and providers
• Functions and hooks: opentrust_* → ettic_*
• Constants: OPENTRUST_* → ETTIC_*
• Option names: opentrust_settings, opentrust_provider_keys, opentrust_db_version, opentrust_cache_version, opentrust_flush_rewrite, opentrust_site_salt → ettic_*
• DB table: wp_opentrust_chat_log → wp_ettic_chat_log
• CPT slugs: opentr_policy, opentr_certification, opentr_subprocessor, opentr_data_practice, opentr_faq → ettic_*
• Postmeta keys: _ot_*, _opentrust_* → _ettic_*
• CSS layer and class prefix: @layer opentrust and .ot-* → @layer ettic and .ettic-*
• JS globals
• WPML config file
• wp-cron event names: opentrust_chat_log_purge → ettic_chat_log_purge
• REST namespace: opentrust/v1 → ettic/v1
• Rewrite query vars: opentrust, ot_policy_slug, ot_version → ettic_*

Documentation

• CLAUDE.md — update file manifest, class names, table names, option names
• Any inline references in code comments

Migration policy: no in-place migration

The plugin is technically at DB schema v5 with five existing upgrade paths (v1 → v5). Since we're shipping the first version intended for public distribution, those migrations were only ever exercised against local development databases. They are no longer load-bearing.

Plan:

• Delete the entire migration chain in OpenTrust::maybe_upgrade()
• Set the new plugin's initial DB schema version to 1 (fresh start)
• Activation creates tables and seeds defaults as if the plugin had never existed before
• No attempt to detect or read data from a previous opentrust installation

Why no migration?

1. Zero distribution footprint. The plugin was never published to wp.org. Anyone running it pulled directly from this repo for testing.
2. Identifier collision. The old plugin used opentrust_ everywhere — options, tables, postmeta, CPTs. A migration would mean reading from the old namespace and writing to the new one across every storage surface. The complexity is much larger than the value it delivers to the (effectively zero) install base.
3. Maintenance debt. Every future feature that touches storage would have to know about the old namespace. Skipping the migration sheds permanent baggage on day one.
4. Clean review story. Wp.org reviewers (and future trademark queries) see a plugin whose codebase contains zero references to opentrust outside changelog notes. Strongest possible signal.

Path for anyone running the old version

Anyone with an existing install of the opentrust plugin (developers, early testers, ourselves) should:

1. On the old plugin: use OpenTrust → Settings → Import & Export to export both content and settings ZIPs.
2. Deactivate and delete the old plugin (or leave it running on a parallel site; both work).
3. Install the new open-trust-center-by-ettic plugin.
4. On the new plugin: use Import & Export to import the ZIPs.

This works because the existing Import/Export feature already uses UUID-based identity for posts and is fully self-contained (manifest + media + artifacts).

Import/Export compatibility requirement

The new plugin must accept import archives generated by the old opentrust plugin. This is the path off the deprecated version, so it cannot break.

Concrete asks for the rename PR:

• Keep the import manifest schema field names compatible (e.g., opentrust_version field in manifest)
• Validation in OpenTrust_IO::validate_manifest (now Ettic_IO::validate_manifest) should accept manifests with either opentrust_version or the new equivalent
• Cross-reference resolution (__media_ref, __post_ref) is namespace-agnostic, no changes expected
• Add an integration test that imports a fixture ZIP exported from the old version

Sequencing

1. New branch: rename/ettic-namespace
2. Mechanical search/replace pass (class names, function names, constants, options, hooks, text domain)
3. Schema reset: delete migration code, set initial DB version to 1
4. Import/Export back-compat check + test fixture
5. Translation rebuild (.pot + nl_NL .po/.mo)
6. Full smoke test on a fresh WP install
7. Submit to wp.org under the new slug

Out of scope

• Migrating data from old to new in place (covered by Import/Export instead)
• Renaming the GitHub repo (separate decision; can stay opentrust for now)
• opentrust.com domain plans (separate marketing decision)