wpdev
b63ab46f54
Tests / Integration Tests (push) Successful in 1m11s
Tests / Unit Tests (push) Failing after 11m56s
Anti-EAV Lint + Quality Gate / anti-eav-lint (push) Failing after 12m7s
Tests / PHPStan (push) Failing after 14m37s
Tests / PHPCS (push) Failing after 14m46s
Tests / PHP Lint (push) Failing after 14m57s
- readme.txt（WP 外掛目錄格式，隨 ZIP 發佈）：Stable tag 對齊 1.0.0， changelog 補 1.0.0 條目 - CONTEXT.md（領域詞彙表）：Status 區塊改寫為 v1.0.0 實況； HPCT_INTERCEPTORS 與 HivePress Adapter 兩節標註「已搬到 AddOn，核心無此常數」 - docs/：ENTITY_ADAPTER_COOKBOOK、2 篇 ADR、INTEGRATION_PATTERN_DECISION、 anti-eav-lint.yml.template - cookbook 修掉兩個死連結（ANTI_EAV_PLAYBOOK 在來源外掛就不存在） - INTEGRATION_PATTERN_DECISION 加 v1.0.0 後記：結論已被 AddOn 拆分取代 - template 改 wpdev/2meet-data-optimizer + ref v1.0.0 + wp tmdo lint - README.md 文件索引補上以上 7 個檔案 前綴改寫刻意只動類別/函式/slug（WPDO_→TMDO_、wp-data-optimizer→2meet-...）， wpdo_ option/cron/hook/表名與 wpdo/v1 REST namespace 一律保留 —— 這是資料層 零遷移的前提。
119 lines
5.1 KiB
Markdown
119 lines
5.1 KiB
Markdown
# Integration Pattern Decision — 2026-04-25
|
||
|
||
> **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
|