WordPress.org にプラグインを提出する全手順｜Plugin Check の指摘3件と対応実録

自社プラグイン Frontierline Forms の無料版（Lite）を、WordPress.org 公式リポジトリへ提出しました。
本記事はその開発日記。
提出フローの全体像と、提出前の自己審査ツール Plugin Check で出た指摘3件をどう直したかを、実装目線で記録します。
これからプラグインを公式配布したい制作者の、最短ルートの地図になればと思います。

WordPress.org にプラグインを提出するまでの全体像

公式リポジトリ配布は、有料プラットフォーム経由の販売とは別物で、いくつか独自の作法があります。
最初に全体像を押さえておくと迷いません。

提出に必要な4点

公式配布のスタートラインは、次の4つが揃った状態。

• 動作するプラグイン本体: メインファイルのヘッダーコメント（Plugin Name、Version、License など）が正しく書かれていること
• WordPress.org アカウント: 提出フォームと、後述する SVN へのアクセスに使います
• 規約準拠の readme.txt: 専用フォーマット。Stable tag、Tested up to、ライセンス表記、スクリーンショット定義などを記述します
• GPL 互換ライセンス: リポジトリ配布は GPLv2 以降と互換であることが必須

提出から公開までの流れ

提出フォームから zip をアップロードすると、まず人手によるレビューが入ります。
承認されるとプラグイン専用の SVN リポジトリが割り当てられ、そこへコミットして初めて公式ディレクトリに公開されます。
Git に慣れていると SVN の trunk / tags / assets というディレクトリ構成に最初は戸惑うが、trunk が開発版、tags/バージョン番号 が配布される確定版、assets がアイコンやバナー画像、と役割が分かれているだけです。

ここで重要なのが、人手レビューに回る前に自分で潰せる指摘は潰しておくこと。
差し戻しは1往復ごとに数日のロスになります。
そのための公式ツールが Plugin Check です。

Plugin Check とは何か

Plugin Check（PCP） は WordPress.org が公式提供する自己審査用プラグイン。
自分のプラグインを管理画面から走らせると、リポジトリのガイドライン違反を Error と Warning で一覧表示してくれます。
レビュアーが見るポイントを、提出前に自分で先回りして確認できる、というもの。

Error が残っているとまず通りません。
今回 Frontierline Forms の Lite 版をかけたところ、実務でそのまま参考になる指摘が3件出ました。
順に、何が問題で、どう直したかを記録します。

指摘1：入力値のサニタイズと出力のエスケープ漏れ

最初に、そして最も多く出たのがこれ。
フォーム拡張プラグインという性質上、ユーザー入力を扱う箇所が多く、サニタイズとエスケープの網羅が甘いと一気に指摘が増えます。

何が問題か

$_POST や $_GET から受け取った値を、そのまま処理・保存・出力していると危険。
サニタイズ漏れは保存データの汚染や不正値の混入を招き、エスケープ漏れは画面出力時の XSS（クロスサイトスクリプティング）の温床になります。
Plugin Check はこの2系統を明確に分けて指摘してきます。

どう直したか

入力は「受け取った直後にサニタイズ」、出力は「画面に出す瞬間にエスケープ」という原則を全箇所に徹底しました。
具体的には、テキスト入力は sanitize_text_field、メールは sanitize_email、複数行は sanitize_textarea_field で受け、HTML として出す箇所は esc_html、属性値は esc_attr、URL は esc_url で囲みます。
送信ログを管理画面で一覧表示する機能があるため、保存値を表示する箇所のエスケープは特に丁寧に通しました。
「入口でサニタイズ、出口でエスケープ」を機械的に守るだけで、この種の指摘はほぼ消えます。

指摘2：nonce による CSRF 対策の不足

2件目はフォーム処理とAjaxエンドポイントのCSRF（クロスサイトリクエストフォージェリ）対策。

何が問題か

管理画面の設定保存やデータ操作で、リクエストが「正規の画面から、正規の利用者の操作で送られたものか」を検証していないと、外部サイトに仕込まれた偽リクエストで設定を書き換えられる恐れがあります。
Plugin Check は、入力処理の前に nonce 検証が見当たらない箇所を指摘してきます。

どう直したか

フォーム出力時に wp_nonce_field（Ajax の場合は wp_create_nonce）でトークンを発行し、受信側の処理冒頭で check_admin_referer ないし wp_verify_nonce で検証してから本処理へ進むようにしました。
検証に失敗したリクエストは即座に弾きます。
あわせて、その操作を実行してよい権限かを current_user_can で確認します。
nonce（本人が出した操作か）と権限チェック（その操作をしてよい人か）はワンセットで、両方揃って初めて安全な処理になります。

指摘3：テキストドメインとスラッグの不一致

3件目は国際化（i18n）まわり。
Frontierline Forms は管理画面もエラーメッセージも完全日本語UIが売りで、翻訳の仕組みは作り込んでいたが、Plugin Check の規約観点では別の指摘が出ました。

何が問題か

翻訳関数 __() や _e() に渡すテキストドメインが、プラグインのスラッグと一致していない箇所がありました。
公式リポジトリでは、テキストドメインはプラグインのスラッグ（ディレクトリ名）と完全一致している必要があります。
ここがずれていると翻訳ファイルが正しく読み込まれず、せっかくの日本語化が効きません。
さらに、テキストドメインを変数で渡している箇所も指摘対象になります。
翻訳文字列の抽出ツールが静的に解析できるよう、ドメインは必ずリテラル文字列で書く決まりだからです。

どう直したか

全ファイルでテキストドメインをスラッグに統一し、変数渡しになっていた箇所をすべてリテラル文字列に書き換えました。
あわせて load_plugin_textdomain の呼び出しと languages ディレクトリの配置を見直し、翻訳ファイルが確実に読み込まれる状態にしました。
地味な作業だが、ここを通すと「日本語UIが規約準拠で、かつ将来の多言語展開にも耐える」土台になります。

3件を直して見えた「配布プラグインの品質基準」

受託案件の functions.php に書くコードと、世界中の未知の環境にインストールされる配布プラグインとでは、求められる品質基準が一段違います。
今回の3件はいずれも「自分のサイトでだけ動けばいい」なら見逃しがちな項目で、不特定多数に配るからこそ厳格に問われます。

逆に言えば、この基準を一度クリアしたコードベースは、受託案件にもそのまま転用できる資産になります。
Frontierline Forms で作り込んだサニタイズ・エスケープの徹底、nonce と権限のワンセット運用、規約準拠の i18n は、フォーム拡張という機能そのものとして製品に組み込んであります。
つまり、このプラグインを入れるだけで、ここまで書いてきた品質基準を満たしたフォーム実装が手に入ります。

まとめ

WordPress.org へのプラグイン提出は、「動くものを作る」だけでは終わりません。
提出前に Plugin Check をかけ、Error をゼロにしてから人手レビューに回すのが最短ルート。
そして頻出する指摘は、入力サニタイズと出力エスケープ、nonce による CSRF 対策、テキストドメインとスラッグの一致、というセキュリティと規約準拠の基本に集約されます。

この基準は配布プラグインだけのものではなく、受託でフォームや管理画面を作るすべての場面で効きます。
WordPress サイトのフォーム改修・プラグイン開発・公式リポジトリ提出のご相談は お問い合わせフォーム まで。

よくある質問

Q. WordPress.org にプラグインを提出するには何が必要ですか？

動作するプラグイン本体、WordPress.org のアカウント、規約に沿った readme.txt、GPL 互換ライセンスの4点。
提出フォームから zip をアップロードして人手レビューを待ち、承認後に割り当てられる SVN リポジトリへコミットすると公開されます。
提出前に Plugin Check で自己審査しておくと差し戻しを大幅に減らせます。

Q. Plugin Check とは何ですか？

WordPress.org が公式提供する自己審査用プラグイン。
サニタイズ・エスケープ漏れ、nonce 不足、テキストドメインの不一致、禁止関数の使用などを Error と Warning で一覧表示します。
提出前にローカルで実行し、Error をゼロにしてから出すのが定石。

Q. プラグイン審査でよく差し戻される原因は何ですか？

最多はセキュリティ関連。
入力値をサニタイズしていない、出力をエスケープしていない、フォーム処理に nonce 検証がない、$wpdb の直接クエリで prepare を使っていない、の4つが代表格。
次いでテキストドメインとスラッグの不一致が多いです。

Q. 提出から公開までどれくらいかかりますか？

初回は人手レビューが入るため、提出から数日〜2週間程度。
指摘があれば修正と再提出のぶん延びます。
承認後は SVN へコミットすれば数分〜十数分で公式ディレクトリに反映されます。