wordpress-plugin-to-emdash

WordPress プラグインを EmDash に移植する

PHP を一行ずつ翻訳するのではなく、プラグインのユーザーから見える動作とデータモデルを維持してください。WordPress と EmDash では責務の分担が異なるため、各機能をサイトスキーマ、Astro コード、サンドボックス化されたプラグイン、信頼されたネイティブプラグインのどこに置くかを、まず判断してください。

プラグインコードを実装する前に、creating-plugins を読み込んでください。移植によってコレクション、シード、クエリ、またはフロントエンドテンプレートが変更される場合は、building-emdash-site も読み込んでください。これらのスキルでは現行の API を定義しています。このスキルでは移行に関する判断を扱います。

ソースを理解する

プラグインのソース、インストール時の動作、データベースの変更、フック、REST エンドポイント、スケジュールされた処理、管理画面、ショートコードやブロック、フロントエンドの出力、権限、外部サービスを調べてください。ユーザーが依存している動作と、WordPress 固有の実装を分けて特定してください。

以下を記録してください。

• 必要なコンテンツと設定データ；
• データを変更または公開する操作；
• 認可と信頼境界；
• バックグラウンド処理や再試行の動作；
• フロントエンドと管理者の操作；
• インポート、移行、ロールバックの要件；
• コピーしたアセットやコードに関するライセンス上の義務。

ソース、想定される動作、または移行先の EmDash 環境が不足している場合は、同等のものをでっち上げず、不足していることを報告してください。

それぞれの責務の割り当て

WordPress の責務	EmDash での移行先
カスタム投稿タイプ、タクソノミー、またはメタデータ	サイトスキーマまたはシードを通じて作成するコレクション、タクソノミー、フィールド
サイト全体の表示設定	Astro テンプレートが読み取るサイト設定
プラグインが所有するユーザー設定	ctx.settings。認証情報は暗号化された secret フィールドとして宣言します
プラグインが所有するカーソル、キャッシュ、内部状態	プラグインスコープの ctx.kv
プラグインが所有するクエリ可能なレコード	宣言済みの ctx.storage.<collection> ストレージ
コンテンツの発見、翻訳、公開	機能でゲートされた ctx.content と ctx.schema。ポリシーフックとアクションには、それぞれ別の権限が必要です
ランタイムのタクソノミーまたはリダイレクトの管理	読み取り／書き込み権限を絞った ctx.taxonomies または ctx.redirects
コメントの管理	ctx.comments。読み取りでは個人データが公開され、モデレーションでは想定されるステータスを使用します
WordPress REST エンドポイント	メソッド、入力、ヘッダー、レスポンスモードを明示したプラグインルート
スケジュール済みイベント	cron フックと ctx.cron によるスケジューリング
管理ページまたはフォーム	サンドボックス化されたプラグインには Block Kit、信頼されたネイティブプラグインに限り React を使用します
投稿エディターのメタボックスまたは保存済みエントリーのアクション	プライベートルート上の admin.editorPanels または admin.editorActions
ユーザーまたは投稿者の検索	users:read 権限を持つ ctx.users
外部への HTTP リクエスト	network:request と allowedHosts エントリーを伴う ctx.http.fetch()
メディア操作	メタデータ、バイトデータの読み取り、メタデータの書き込み、アップロード／削除の権限を個別に設定します
WP_Query またはテンプレートタグ	Astro のサイトコードにおける EmDash コンテンツ API
ショートコードまたはエディターブロック	可能な場合は既存の Portable Text コンテンツを使用します。カスタム Portable Text ブロックには信頼されたネイティブプラグインが必要です
生の head マークアップまたはスクリプト	信頼されたネイティブの page:fragments。レジストリにインストールされたプラグインが追加できるのは、検証済みの page:metadata のみです

EmDash のシステムテーブルにアクセスして、コレクションやタクソノミーを作成しないでください。公開スキーマ、シード、CLI、または管理境界を使用してください。存在しないサンドボックス API を模倣するために、内部 REST ルートを使用しないでください。

権限は分離してください。メディアメタデータの読み取りはバイトデータへのアクセスを許可しません。モデレーションは削除を許可しません。公開ポリシーは公開アクションを許可しません。コンテンツの復元は通常のコンテンツ読み取りを許可しません。

プラグイン形式を選択する

デフォルトでは、サンドボックス化されたプラグインを使用してください。インストール時の信頼契約を通じて、移植可能なフック、ルート、宣言型ストレージ、メディア、ネットワークアクセス、MCP ツール、Block Kit 管理 UI をサポートします。

ホストプロセスへのアクセス、React 管理コード、Astro のレンダリングコンポーネント、生のページ断片、またはカスタム Portable Text ブロック定義が必要な機能に限り、信頼されたネイティブプラグインを使用してください。移行計画では、追加の権限と配布上の制限を明記してください。

WordPress プラグインの中には、EmDash プラグインを必要としないものもあります。カスタム投稿タイプとフロントエンドテンプレートは、スキーマ、シードデータ、Astro ページだけで実現できる場合があります。静的サイト構造で動作をカバーできる場合は、ランタイム拡張を追加しないでください。

データの移行を計画する

ランタイムコードを記述する前に、既存の WordPress データがどのように対応するかを説明してください。

• 投稿 ID、スラッグ、ロケール、作成者、ステータス、リビジョン、公開日を対応付けます。
• 投稿、ターム、メディア、プラグインが所有するレコード間の関連を維持します。
• 一度限りのインポートと、継続的な同期が必要なデータを区別します。
• インポートを再実行可能にし、重複の検出方法を定義します。
• 照合やリダイレクトに必要な場合は、ソース識別子を保持します。
• プロダクト上の判断なしには表現できないコンテンツを特定します。

新しいサイトの初期スキーマとサンプルコンテンツには、シードデータを使用してください。既存サイトの本番データには、インポーターまたは移行手順を使用してください。シードはバックアップでも継続的な同期の仕組みでもありません。

同等の動作を検証する

ユーザーとランタイムが利用する境界を通じてテストしてください。

• コンテンツモデルの変更について、スキーマとインポート済みデータを検証します。
• サンドボックスのフック、ルート、ストレージ、権限について、本番環境の境界でプラグインをテストします。
• 管理画面とフロントエンドのユーザーフローをブラウザーで検証します。
• 元の機能が依存する場合は、再起動、重複配信、認可、障害のケースをテストします。

内部構造ではなく、観測可能な動作を比較してください。意図的な差異と、サポートされないままの WordPress 機能を文書化してください。

移植を納品する

以下を提供してください。

1. WordPress の動作とデータの簡潔な一覧。
2. 責任の対応表と、サンドボックス化／ネイティブの選択。
3. データ移行またはシード計画。
4. プラグインとサイトコードにまたがる実装。
5. 検証結果の証拠と既知の不足点。
6. 再利用したコードやアセットの帰属表示とライセンス表記。