Files

T

wpdev 3d650eb848 docs(2meet-data-optimizer): partner self-registration guide and deprecated AddOn notice

- Add docs/PARTNER-REGISTRATION.md: TMDO_Anti_EAV_Aware bridge setup (plugins_loaded:3), table and entity-group registration with post_types scopes, frozen definitions, and the AddOn → self-registration migration checked with [COLLISION]/[ORPHAN]
- TMDO_Deprecated_Addons_Notice warns administrators while any of the 8 in-house partner AddOns is active (site or network)
- Trait register_entity_fields() forwards an optional $args (post_types) to the registry
- Verify: DeprecatedAddonsNoticeTest (4); core unit 645 / integration 449, HP 148, WC 10 OK
- PR: PR-021

2026-09-26 00:31:34 +08:00

5.3 KiB

Raw Permalink Blame History

Integration Pattern Decision — 2026-04-25

2026-09 更新： 2meet 自家外掛回到「partner 自行註冊」，做法見 PARTNER-REGISTRATION.md；對應的 8 個 AddOn 已淘汰。

v1.0.0 後記（2026-07-31）：本文結論已被架構拆分取代。 當時的兩個選項是「集中在核心」vs「各外掛自帶 bridge」。v1.0.0 走的是第三條路：每個夥伴外掛對應一個獨立 AddOn 外掛（2meet-data-optimizer-<partner>-addon，共 11 個），核心完全不認識夥伴外掛。下文的 class-tmdo-<partner>.php 一律已搬進對應 AddOn。本文保留是為了記錄「為什麼不選 per-plugin bridge 檔」這段推理 —— 該理由對 AddOn 邊界同樣適用。

Trigger: Step BB audit revealed two parallel patterns for partner plugin integration; need to commit to one.

What I found

Plugin	Centralized in 2meet-data-optimizer?	Own bridge file?
2meet-infocards	✅ `class-tmdo-infocards.php`	❌
2meet-bookings	✅ `class-tmdo-bookings.php`	❌
2meet-quotation	✅ `class-tmdo-quotation.php`	❌
2meet-events	✅ `class-tmdo-events.php`	✅ `class-tmevents-wpdo-bridge.php` (duplicate!)
2meet-collab	✅ `class-tmdo-collab.php`	❌
2meet-mobile-bridge	✅ `class-tmdo-mobile-bridge.php`	❌
2meet-playlist	✅ `class-tmdo-playlist.php`	❌
2meet-courses	❌	✅ `class-2meetic-courses-wpdo.php` (NEW today, P step)
2meet-inquiries	❌	✅ `class-tmqi-wpdo-integration.php` (NEW from scratch)

Inconsistency:

7 plugins are integrated centrally (legacy Wave 2 demo pattern)
2 new plugins (today) are integrated decentrally (cookbook Tier 4 pattern)
2meet-events has both (silent dedup by registry — works but smelly)

Decision: Decentralized (own bridge) is the canonical pattern

Rationale

Cookbook Tier 4 documents it as the standard for new plugins (already published)
Each plugin owns its own data contract — no cross-plugin coupling in 2meet-data-optimizer
Easier to ship — partner plugin can update its registration without bumping 2meet-data-optimizer
Simpler mental model — "where do tables get registered? In the plugin that owns them"

Why we're NOT migrating today

Freeze: Per FREEZE_2026-04-25.md, no risky refactors during freeze
Working: All 7 centralized integrations work; registry dedup handles the events double-pattern
No vendor demand: Nobody has reported confusion or bugs from the dual pattern
Risk > reward: Moving 7 classes touches 8 plugins, requires coordinated version bumps, breaks atomic rollback

Migration plan (when we DO migrate)

Trigger conditions (any one):

A new partner plugin can't ship cleanly because of the centralized pattern
A bug in the centralized integrations affects multiple plugins simultaneously
We hit 10+ partner plugins (currently 9) and the 2meet-data-optimizer integrations dir is too crowded

Steps (per plugin, ~0.5 day each)

1. Copy /2meet-data-optimizer/includes/integrations/class-tmdo-{slug}.php
   to /{plugin-slug}/includes/integrations/class-{prefix}-wpdo.php

2. Rename class:
   - TMDO_Bookings → TMB_WPDO
   - TMDO_Quotation → TMQUO_WPDO  (etc.)
   - Keep registration logic identical

3. Wire in {plugin-slug} bootstrap (after main classes load):
   require_once $dir . 'includes/integrations/class-{prefix}-wpdo.php';
   {prefix}_WPDO::register();

4. In 2meet-data-optimizer:
   - Remove require_once line
   - Remove class name from the partner array (line ~208 of main file)
   - Bump WPDO version (patch)

5. Verify:
   wp eval 'echo count(TMDO_Custom_Table_Registry::instance()->for_provider("{slug}"));'
   → should still match the original count

6. Bump partner plugin version (minor, since it now has new dependency)
   Update Requires Plugins header to mention 2meet-data-optimizer ≥ X.Y.Z

Special case: 2meet-events double-pattern

Already has both. Migration = remove the centralized class-tmdo-events.php (the bridge in 2meet-events stays). This is the simplest first migration because the partner plugin's own bridge is already proven.

What this means for tomorrow's reader

If you're writing a NEW 2meet-* plugin: follow Tier 4 pattern, put your integration class in your own plugin's includes/integrations/ directory.

If you're maintaining an EXISTING centralized integration in 2meet-data-optimizer: leave it alone unless one of the migration triggers fires.

If you see the dual pattern in 2meet-events and are confused: it's intentional, registry dedups, will be cleaned up later.

Anti-decisions (things explicitly NOT done)

❌ NOT moving 7 integrations today — too risky, freeze active
❌ NOT fixing the events double-pattern today — works fine, low priority
❌ NOT writing a "consolidation script" — premature optimization for a one-time migration
❌ NOT updating cookbook to mention the centralized pattern — would be confusing

When to revisit this decision

Same as freeze conditions (FREEZE_2026-04-25.md):

vendor reports confusion / bug
30 days passed with no action needed
New plugin (#10+) onboarded
Production critical event involves the pattern

5.3 KiB Raw Permalink Blame History Unescape Escape