Files
2meet-data-optimizer/docs/INTEGRATION_PATTERN_DECISION.md
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

121 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
1. **Cookbook Tier 4 documents it as the standard** for new plugins (already published)
2. **Each plugin owns its own data contract** — no cross-plugin coupling in 2meet-data-optimizer
3. **Easier to ship** — partner plugin can update its registration without bumping 2meet-data-optimizer
4. **Simpler mental model** — "where do tables get registered? In the plugin that owns them"
### Why we're NOT migrating today
1. **Freeze**: Per `FREEZE_2026-04-25.md`, no risky refactors during freeze
2. **Working**: All 7 centralized integrations work; registry dedup handles the events double-pattern
3. **No vendor demand**: Nobody has reported confusion or bugs from the dual pattern
4. **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