WordPressプラグイン審査で差し戻された全記録｜実体験

10日間、何の連絡もない時期がありました
朝のメールが「名前が一般的すぎる」から始まっていた
同じメールに、ほかにもたくさんのことが書かれていました
名前を直すには、コード全体を書き換える必要がありました
翌日、もう一通メールが来ました
「Ghostscript の exec() は外せない」と思い込んでいた
3バージョン目で、ようやく承認待ちの状態になりました
1月2日の深夜、承認メールが届きました
SVN を生まれて初めて触りました
振り返って思うこと
これから出す人に、いくつかメモしておきたいこと
参考にしたページ
関連記事

2025年12月16日の夜、私は自作のWordPressプラグインを初めて WordPress.org に提出しました。

プラグインの名前は「PDF Image Creator」。PDFをアップロードすると表紙のサムネイル画像を自動生成してくれる、というシンプルなものでした。Local by Flywheel で何度も動作確認をして、Plugin Check の ERROR もゼロにしてから出したので、当時の私は「ちょっとした手直しの指摘ぐらいは来るかもしれないけど、大筋では問題ないだろう」と思っていました。

結局、その「ちょっとした手直し」では済まず、自動レビューと手動レビューで2段階の差し戻しを受け、3バージョンの修正をはさんで、承認されたのは2026年1月2日の深夜でした。差し戻しから承認までの実作業時間を合計すると、15時間ぐらいだと思います。

この記事は、その約2週間半の記録です。これから WordPress.org に自作プラグインを提出する人が、私と同じところで詰まらないように、何が起きてどう直したのかを順番に書きます。

WordPress.org のプラグイン提出ページ。私は2025年12月16日にこの画面から ZIP をアップロードして、最初の応答が届くまで10日待ちました。

検証環境(本記事執筆時点)：WordPress 6.9.4 / PHP 8.3.21 / Plugin Check 1.9 / Xserver スタンダードプラン
審査体験：Rapls PDF Image Creator(2025年12月16日提出 → 2026年1月2日承認)
承認バージョン：1.0.6 ／本記事執筆時点：1.0.9.5

10日間、何の連絡もない時期がありました

提出した日の感触は、今でもよく覚えています。WordPress.org のサイトには、ZIPをアップロードすると即座に Plugin Check が走るしくみがあって、ERROR がなければ審査キューに入ります。「Submitted」のメッセージが画面に出たとき、なんとなく区切りがついた気がして、その夜はほっとして寝ました。

そこから10日間、何の連絡もありません。

調べてみると、WordPress.org のプラグインレビューチームは週に1,000件ほどのプラグインをさばいているようで、自分の番が回ってくるまで普通に1〜2週間はかかるのだと知りました。とはいえ、自分のメールボックスを開くたびに plugins@wordpress.org が来ていないか確認する、という日々が続きます。落ち着かないものでした。

連絡がきたのは、提出から10日経った12月26日の朝でした。私はそのとき自宅にいて、起き抜けにスマホでメールチェックをしていました。WordPress.org からのメールはタイトルに件名と日時が入った定型的なもので、本文を開いてざっと最初の段落を読みました。

そこに書かれていたのは、私が想像していたのとはまったく違う指摘でした。

朝のメールが「名前が一般的すぎる」から始まっていた

差し戻しメールの最初のセクションには、こう書かれていました。

✨ The display name is descriptive and accurate, but it’s also generic and closely describes a common PDF-thumbnail functionality. There is an existing plugin with a very similar purpose/name which increases the risk of user confusion.

「PDF Image Creator という名前は、機能を正確に表してはいるが、一般的すぎる。似た目的・名前のプラグインがすでにあり、ユーザーが混同しやすい」。要するに、コードを見る前のレベル、名前の段階で止められたわけです。

正直、これは予想していませんでした。脆弱性の指摘とか、コーディング規約の違反とか、そういう技術的な話で差し戻されると思っていたので、「名前」という、そもそも提出する前に気づくべき部分でつまずいていることが、ちょっと恥ずかしかったです。

メールの後ろのほうには、AI による分析として代替案も書かれていました。

For example, for your plugin:
– An alternative name may be: ✨ Rapls PDF Image Creator
– An alternative slug may be: ✨ rapls-pdf-image-creator

WordPress.org の自動チェックには AI(おそらく ChatGPT 系のもの)が組み込まれていて、文面の中で ✨ マークが付いている部分は AI が出した提案でした。「Rapls」というのは私が普段ハンドルネームとして使っている文字列で、ブログのドメイン(raplsworks.com)にも使っています。それが私自身のものだと向こうは知らないはずなのに、AI が「あなたのユーザー名 rapls から取ってこれを頭につけたらどうか」と推測してきたのは、面白いというか、少し気味の悪さもありました。

とはいえ、提案自体には素直に納得しました。「Rapls PDF Image Creator」と置き直してみると、確かにほかの似たプラグインと混ざらないし、自分のブランドとしても収まりがいい。最初からそうしておけばよかったのです。

同じメールに、ほかにもたくさんのことが書かれていました

名前の話だけで折れている場合ではありませんでした。同じメールには、ほかにもいくつかの指摘が並んでいました。

1つは「所有権の確認」です。私のメールアドレスは @gmail.com ですが、当時のプラグインには Author URI として gift-by-gifted.com というブログのURLを書いていて、両者のドメインが一致していません。「メールが gmail.com、Author URI が別ドメイン、それで本当にあなたが所有者ですか?」というのが向こうの質問でした。これは個人開発者ならではの落とし穴で、複数のドメインを持っているとここで詰まります。私は返信で「私が単独の開発者で、rapls はWordPress.org のユーザー名、raplsworks.com は私の個人開発サイトです」と素直に説明し、それで通りました。

2つ目は、プレフィックスの話でした。当時のコードでは、関数名やフックに pic_ という3文字のプレフィックスを使っていました。「PDF Image Creator」の頭文字を取ったつもりだったのですが、メールには「プレフィックスは少なくとも4文字以上、ユニークで、アンダースコアまたはハイフンで区切ること」と明記されていて、自動レビューの提案として rapls_pic_ や rapls_pdf_ が例に挙げられていました。確かに pic_ は短すぎて、ほかのプラグインや WordPress コア側と衝突する可能性があります。

3つ目は、deprecated 関数の指摘です。当時の Ghostscript エンジン側のコードに imagedestroy() を呼んでいる行があって、ここを直接ファイル名と行番号で指摘されました。

includes/Engine/GhostScriptEngine.php:328 imagedestroy($image);
↳ Function imagedestroy() has been deprecated

PHP 8.0 から imagedestroy() は deprecated になっていて、ガベージコレクションで自動解放されるため明示呼び出しは不要、という変更が入っていたのを、私は知りませんでした。参考にしていたコード例が古かっただけなのですが、現役の WordPress.org に出すコードとしてはアウトです。

4つ目は、ZIPの中身に関する指摘でした。私はプラグイン本体の ZIP の中に、WordPress.org のプラグインページに表示するためのバナー画像やアイコン画像も一緒に入れて提出していました。「assets/banner-772×250.png」「assets/icon-128×128.png」など、具体的にファイル名がリストアップされていて、これらは「プラグインコードの一部ではない」と書かれていました。

We’ve detected WordPress.org directory plugin asset files in your submission. (…) these files (banners, icons, screenshots created for the directory plugin page) are not part of the plugin code and should not be included in your plugin zip file.

このとき初めて、WordPress.org のプラグインバナーやアイコンは、プラグイン本体とは別の場所、つまり SVN リポジトリの直下にある assets ディレクトリにアップロードする、という別ルートで扱われることを知りました。私はそれまで Git でしか開発したことがなく、SVN を触るのもこのときが最初です。差し戻しメールがなければ、この仕組みにしばらく気づかなかったかもしれません。

実際に届いた差し戻しメール(個人情報部分は伏せ字加工済み)。一見すると圧倒される長さですが、指摘内容を分解すると合計8項目で、修正作業は15時間ほどで終わりました。

名前を直すには、コード全体を書き換える必要がありました

朝のメールを読み終えてコーヒーを淹れたあと、Cursor を立ち上げました。

名前を変えるという作業は、聞こえほど単純ではありません。プラグインのスラッグ、メインPHPファイルの名前、プラグインヘッダーの「Plugin Name」、テキストドメイン、関数名のプレフィックス、定数名のプレフィックス、languages フォルダ内の .po/.mo ファイル名、readme.txt の見出し。これら全部を整合させる必要があります。

手作業でやるとどこかで取りこぼすので、Cursor の Composer 機能と Claude Code を併用して、grep で pdf_image_creator、PDFImageCreator、pic_ といった文字列を全部洗い出して一括で置換していきました。AI 支援ツールがなかったら、この修正だけで丸一日は溶かしていたと思います。

名前空間とプレフィックスは、最終的にこういう形に落ち着きました。クラスは Rapls\PDFImageCreator という名前空間に閉じる。テーマから直接呼び出してもらうテンプレートヘルパー関数だけはグローバルに置いて rapls_pic_ もしくは rapls_pdf_ で始める。フック名は rapls_pdf_image_creator_*、ショートコードは rapls_pdf_thumbnail、オプション名は rapls_pic_settings、投稿メタキーは _rapls_pic_*。粒度が違っていますが、名前空間に閉じられるものは閉じて、グローバルに残さざるを得ないものはプレフィックスでガードする、という分け方です。

imagedestroy() の指摘は、後述する exec() の対応で Ghostscript エンジンを丸ごと削除したため、結果的に問題ごと消えました。assets 同梱の指摘は、ZIP から画像ディレクトリを除外する設定を作って解決しました。

その日の夕方、修正を反映したv1.0.4をアップロードして、WordPress.org に「修正完了の連絡」を送信しました。長文で経緯を説明しても読まれにくいと思ったので、何をどう直したかを箇条書きで簡潔に書きました。

Hi Plugin Review Team,

Thank you for your review. I have addressed all the issues:

1. Plugin Name/Slug
- New name: "Rapls PDF Image Creator"
- Requested slug: rapls-pdf-image-creator

2. Ownership Verification
I am the sole developer. "rapls" is my WordPress.org username,
and raplsworks.com is my personal development site.
Both are owned by me.

3. Technical Fixes
- Namespace: Rapls\PDFImageCreator
- All globals use rapls_pic_ or rapls_pdf_ prefix (4+ chars)
- Removed deprecated imagedestroy()
- Removed file paths from error responses

4. Assets
Removed from ZIP. Will upload via SVN after approval.

Best regards,
Yoshiaki Miyaguchi
Rapls Works

Hi Plugin Review Team,

Thank you for your review. I have addressed all the issues:

1. Plugin Name/Slug

- New name: "Rapls PDF Image Creator"

- Requested slug: rapls-pdf-image-creator

2. Ownership Verification

I am the sole developer. "rapls" is my WordPress.org username,

and raplsworks.com is my personal development site.

Both are owned by me.

3. Technical Fixes

- Namespace: Rapls\PDFImageCreator

- All globals use rapls_pic_ or rapls_pdf_ prefix (4+ chars)

- Removed deprecated imagedestroy()

- Removed file paths from error responses

4. Assets

Removed from ZIP. Will upload via SVN after approval.

Best regards,

Yoshiaki Miyaguchi

Rapls Works

これで一段落だ、と思っていました。

翌日、もう一通メールが来ました

WordPress.org の審査の構造を、私はこのとき初めて理解しました。

最初の差し戻しは、AI を含む自動チェックによる事前判定です。プラグイン名、所有権、プレフィックス、deprecated 関数、ZIP 同梱物といった「機械的に拾える項目」を、AI と既存ツールが一通り見ます。これを通過しないと、人間のレビュアーまで行きません。

この自動チェックを通過すると、次はボランティアの人間が手動でレビューします。手動レビューは時間がかかりますが、自動チェックでは拾えないコードの中身まで踏み込みます。

そういうわけで、最初のメールに書かれていた指摘を全部直したからといって、それで承認されるわけではありません。手動レビューの段階で、また別の指摘が来ます。私は12月27日、つまりv1.0.4を出した翌日に、まさにそれを経験しました。

「Ghostscript の exec() は外せない」と思い込んでいた

2通目のメールで指摘されたのは、PHP の exec() の使用でした。

## Using exec()/shell_exec() in PHP is considered dangerous

exec commands send code to the server, and can be used for remote code execution actions. In addition, many hosts block the use. At this time, for your users’ safety, we need the calls to be removed.

具体的に指摘されたのは、私のプラグインの中の includes/Engine/GhostScriptEngine.php という1ファイルの中の3行で、ファイル名と行番号、コードの抜粋まで丁寧に書かれていました。

includes/Engine/GhostScriptEngine.php:158
exec($command, $output, $returnCode);

includes/Engine/GhostScriptEngine.php:243
exec(escapeshellarg($path) . ' --version 2>&1', $output, $returnCode);

includes/Engine/GhostScriptEngine.php:258
exec(escapeshellarg($gsPath) . ' --version 2>&1', $output, $returnCode);

includes/Engine/GhostScriptEngine.php:158

exec($command, $output, $returnCode);

includes/Engine/GhostScriptEngine.php:243

exec(escapeshellarg($path) . ' --version 2>&1', $output, $returnCode);

includes/Engine/GhostScriptEngine.php:258

exec(escapeshellarg($gsPath) . ' --version 2>&1', $output, $returnCode);

このとき、私は本気で困りました。Ghostscript というのは、PDFを画像に変換するためのコマンドラインツールで、PHPからこれを呼ぶには通常 exec() や shell_exec() を使います。「Ghostscript を使うけれど exec() は使わない」という方法は、基本的にありません。proc_open() も同じ系統なので、回避策にはなりません。

かといって、Ghostscript なしで PDF をラスタライズする方法は、私の頭の中ではすぐに浮かびませんでした。Ghostscript 以外で PDF を扱える PHP 拡張といえば、ImageMagick(Imagick PHP拡張)があるのは知っていましたが、当時のうちのプラグインは「Ghostscript エンジン」と「ImageMagick エンジン」の2つを並列で持っていて、ImageMagick のほうは補助的な位置づけでした。Ghostscript のほうがレンダリングが速くて、サーバー環境を選ばずに動く、という認識があったからです。

少しの間、迷いました。「Ghostscriptエンジンを残したまま、exec を別の何かでラップして審査を通せないか」と考えましたが、これは無理です。レビューチームが見ているのは「ユーザーのサーバーで何が起きるか」なので、関数を一段ラップしたところで本質は変わりません。多くの共有レンタルサーバーでは exec() がそもそも無効化されている、という現実もあります。

結局、Ghostscript エンジンを丸ごと削除して、Imagick だけで PDF を処理する形に絞ることにしました。

「丸ごと削除」と書くと、潔く判断したように聞こえますが、内心は結構つらかったです。Ghostscript エンジン側のコードは、PDFのページ指定、解像度の調整、JPEG/PNG の出力切り替え、エラーハンドリング、ロギング、ぜんぶ書いてありました。何時間もかけて積み上げてきた処理が、審査のために消えていく感覚です。git rm でファイルを消した瞬間、Cursor のサイドバーから GhostScriptEngine.php という見慣れた行が消えるのを見て、ちょっと寂しい気分になりました。

切り替えそのものは、思ったより速く済みました。Imagick での書き直しは、丸1日で動くものになりました。最終的なサムネイル生成のコードは、今こんな形になっています。

// Rapls PDF Image Creator のサムネイル生成処理(抜粋)
namespace Rapls\PDFImageCreator;

class Thumbnail_Generator {
    public function generate( $pdf_path, $output_path, $page = 0 ) {
        if ( ! extension_loaded( 'imagick' ) ) {
            return new \WP_Error(
                'rapls_pic_no_imagick',
                __( 'Imagick PHP extension is required.', 'rapls-pdf-image-creator' )
            );
        }

        try {
            $imagick = new \Imagick();
            $imagick->setResolution( 150, 150 );
            $imagick->readImage( $pdf_path . '[' . absint( $page ) . ']' );
            $imagick->setImageBackgroundColor( 'white' );
            $imagick->setImageAlphaChannel( \Imagick::ALPHACHANNEL_REMOVE );
            $imagick->mergeImageLayers( \Imagick::LAYERMETHOD_FLATTEN );
            $imagick->setImageFormat( 'jpeg' );
            $imagick->writeImage( $output_path );
            $imagick->clear();
        } catch ( \ImagickException $e ) {
            if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
                error_log( 'Rapls PDF Image Creator: ' . $e->getMessage() );
            }
            return new \WP_Error( 'rapls_pic_imagick_error', $e->getMessage() );
        }

        return $output_path;
    }
}

// Rapls PDF Image Creator のサムネイル生成処理(抜粋)

namespace Rapls\PDFImageCreator;

class Thumbnail_Generator {

public function generate( $pdf_path, $output_path, $page = 0 ) {

if ( ! extension_loaded( 'imagick' ) ) {

return new \WP_Error(

'rapls_pic_no_imagick',

__( 'Imagick PHP extension is required.', 'rapls-pdf-image-creator' )

);

}

try {

$imagick = new \Imagick();

$imagick->setResolution( 150, 150 );

$imagick->readImage( $pdf_path . '[' . absint( $page ) . ']' );

$imagick->setImageBackgroundColor( 'white' );

$imagick->setImageAlphaChannel( \Imagick::ALPHACHANNEL_REMOVE );

$imagick->mergeImageLayers( \Imagick::LAYERMETHOD_FLATTEN );

$imagick->setImageFormat( 'jpeg' );

$imagick->writeImage( $output_path );

$imagick->clear();

} catch ( \ImagickException $e ) {

if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {

error_log( 'Rapls PDF Image Creator: ' . $e->getMessage() );

}

return new \WP_Error( 'rapls_pic_imagick_error', $e->getMessage() );

}

return $output_path;

}

余談ですが、印刷用の PDF(PDF/X-1:2001 のような CMYK の PDF)を扱うと、このコードでもサムネイルが真っ黒になるという別の問題があります。transformImageColorspace を間にはさむ必要があるのですが、私がこれに気づいたのは 承認されたあと、しばらく運用してからのことでした。審査の段階では、印刷用 PDF をテストデータに使っていなかったので、このバグは隠れたまま通っています。CMYK の話はこの記事の本筋ではないので、別記事に書きました。

v1.0.5 として再アップロードしたのが、12月28日の昼です。

3バージョン目で、ようやく承認待ちの状態になりました

v1.0.5 を出した後、Plugin Check を再度走らせて、コードを最後にもう一度見直しました。

このとき、自分から先回りして直しておいたほうが良さそうな箇所が1つ見つかりました。load_plugin_textdomain() の明示的な呼び出しです。

WordPress 4.6 以降、WordPress.org にホストされているプラグインの翻訳ファイルは、WordPress 側のシステムが自動的に読み込んでくれます。だから、昔よく書かれていた「初期化フックの中で load_plugin_textdomain() を呼ぶ」というコードは、現在の WordPress.org のプラグインでは不要、というよりむしろ書かないほうが推奨されます。私は古い実装例を参考にしてこれを書いていたのですが、再提出時に Plugin Check のフィードバックを見て気づきました。

これを削除して、改めて v1.0.6 として12月31日にアップロード。年末ぎりぎりのタイミングでした。

Plugin Check の実行結果。ERROR をゼロにしてから提出しても、それで通るとは限りません。私の場合も Plugin Check 通過後に手動レビューで exec() の指摘を受けました。とはいえ、最初の差し戻しの確率と再修正の量は確実に減らせます。

このあたりで、自分のプラグインに対する見方が少し変わってきていました。提出した直後は「これはもう完成形だ」と思っていたのですが、レビューチームから次々に指摘を受けるうちに、「公開用のプラグイン」として求められる水準は、自分のサイトで動かすだけのコードとは別物だ、という感覚が育ってきました。プラグインを審査に出すという行為は、単にコードを公開するだけでなく、自分のコードの常識を WordPress.org の常識にすり合わせる作業でもあります。

1月2日の深夜、承認メールが届きました

2026年が明けて、1月2日の0時を過ぎたあたりで、プラグインレビューチームからメールが届きました。本文の最初の1行はとてもシンプルでした。

Your review has been successfully completed. Details on how to access your SVN repository will be emailed within 24 hours to the address from which you submitted your plugin.

「あなたのレビューは無事完了しました。SVN リポジトリへのアクセス方法は、24時間以内に登録メールアドレスに送られます」。これだけです。

差し戻しのメールはあれだけ長文だったのに、承認のメールは拍子抜けするほど短い。それでも、約1週間ぶり(自動レビュー差し戻しから数えて)に肩の力が抜けた瞬間でした。家族には正月から「プラグインのことばかりやっている」と言われていたので、ようやく報告できる、と思いました。

本文の続きには、SVN は Git のような「ブランチで開発するバージョン管理」ではなく、「リリースシステム」として使うこと、trunk には常にリリース可能なコードを置くこと、Plugin Check や PHPCS で継続的にチェックすること、などが書かれていました。SVN を使うのは初めてだった私にとって、この案内は本当に助かりました。

SVN を生まれて初めて触りました

承認メールの翌日、別途届いた SVN 認証情報を使って、リポジトリにアクセスしました。

WordPress.org の SVN リポジトリは、こういう構造になっています。

rapls-pdf-image-creator/
├── trunk/         ← 最新の開発版
├── tags/
│   └── 1.0.6/    ← 各リリースの固定版
├── branches/      ← 通常使わない
└── assets/        ← バナー・アイコン・スクリーンショット

rapls-pdf-image-creator/

├── trunk/ ← 最新の開発版

├── tags/

│ └── 1.0.6/ ← 各リリースの固定版

├── branches/ ← 通常使わない

└── assets/ ← バナー・アイコン・スクリーンショット

ここで一番大事なのが assets ディレクトリの位置です。リポジトリの直下にあって、trunk/assets/ ではありません。プラグインページに表示されるバナーやアイコンは、ここに置きます。

私は最初、これを間違えました。何回コミットしても、プラグインページにバナーが反映されないのです。半時間ほど「なぜ反映されない?」と悩んで、改めて公式の Plugin Assets ドキュメントを読み直して、ようやく「リポジトリ直下の assets/ にコミットする」という意味を理解しました。差し戻しメールで「ZIPに入れるな、SVNに上げろ」と書かれていたのが、ここでようやく具体的な手順とつながった、という感じです。

具体的なコマンドの流れは、こんな感じでした。

svn checkout https://plugins.svn.wordpress.org/rapls-pdf-image-creator/ wporg-svn
cd wporg-svn

cp -r /path/to/your-plugin/* trunk/
svn add trunk/* --force

cp /path/to/banner-772x250.png assets/
cp /path/to/banner-1544x500.png assets/
cp /path/to/icon-128x128.png assets/
cp /path/to/icon-256x256.png assets/
svn add assets/* --force

svn ci -m "Initial release: version 1.0.6"

svn cp trunk tags/1.0.6
svn ci -m "Tag version 1.0.6"

svn checkout https://plugins.svn.wordpress.org/rapls-pdf-image-creator/ wporg-svn

cd wporg-svn

cp -r /path/to/your-plugin/* trunk/

svn add trunk/* --force

cp /path/to/banner-772x250.png assets/

cp /path/to/banner-1544x500.png assets/

cp /path/to/icon-128x128.png assets/

cp /path/to/icon-256x256.png assets/

svn add assets/* --force

svn ci -m "Initial release: version 1.0.6"

svn cp trunk tags/1.0.6

svn ci -m "Tag version 1.0.6"

コミットしてから、プラグインページに行ってリロード。すぐには反映されません。私の場合は、コミットから30分ほど経ってからバナーが表示されました。「assets が反映されない!」と慌てる人がいるかもしれませんが、しばらく待つのが正解です。

公開後の Rapls PDF Image Creator のプラグインページ。SVN コミットから30分ほどでバナーが反映されました。すぐに見えなくても焦らなくて大丈夫です。

振り返って思うこと

Rapls PDF Image Creator は、本記事執筆の時点でアクティブインストール数が70以上、評価は★5が1件、サポートフォーラムへの問い合わせはまだ0件、という状態です。商業的に「成功」と呼べる規模ではありませんが、まったく無名の個人開発者が初めて出したプラグインがゼロから70サイトに使われている、というのは私にとっては意味のある数字です。

このプラグインを公開してから、私は WordPress.org の PTE(Plugin Translation Editor)に申請して、日本語ロケールの翻訳承認権限をもらいました。自分のプラグインだけでなく、ほかの人のプラグインの日本語翻訳も承認できる役割です。PTE 申請のときに、私は初めて WordPress 日本語コミュニティの「翻訳スタイルガイド」をきちんと読みました。英数字の前後に半角スペースを入れる、全角の括弧は半角＋スペースに置き換える(「（」を「 (」にする)、といった細かいルールが整理されていて、これを知らなかったのは個人開発者として恥ずかしいぐらいです。プラグインの審査時に「翻訳スタイルにも修正が必要」と指摘されていたのは、こういうルールを踏まえたものだったのか、と後から腑に落ちました。

Rapls PDF Image Creator の経験を踏まえて、私はこのあと2本目の自作プラグインThanks Mail for Stripeを WordPress.org に提出しました。今度は、最初から名前にユニークな表現を入れ、プレフィックスは tmfs_(Thanks Mail for Stripe の頭文字、4文字以上)、外部コマンド実行は使わず、Plugin Check で ERROR と WARNING の両方をゼロにしてから提出しました。assets は ZIP に入れず、承認後に SVN に置く前提でファイルを分離しておきました。

結果として、Thanks Mail for Stripe は初回審査で1発通過しました。1本目で1週間かかった工程が、ほぼ即日で済んだ、というだけのことなのですが、自分にとっては「あの差し戻し経験は無駄ではなかった」と確認できた瞬間でもありました。

これから出す人に、いくつかメモしておきたいこと

差し戻しの体験を踏まえて、これから WordPress.org に自作プラグインを提出する人がいたら、いくつか伝えておきたいことがあります。チェックリストにしてしまうと味気ないので、自分の作業記録のメモを書き残すような形で書きます。

提出前に Plugin Check を最低1回は回しておいてください、というのは絶対条件です。私の場合、Plugin Check の最初の実行で ERROR が15件くらい出ました。エスケープ・サニタイズ・出力時のエスケープが中心で、これを30分ほどでゼロにしました。エスケープやサニタイズに関しては、Plugin Check で詰めておいたおかげで審査中に1度も指摘されませんでした。逆に、exec() や shell_exec() は Plugin Check では ERROR ではなく WARNING 止まりだったことは覚えておいてください。WARNING は ERROR より目立たないので、つい見逃しがちなのですが、私の場合はこれが手動レビューで一番大きな差し戻し理由になりました。WARNING 欄に外部コマンド実行系のものがあったら、ERROR と同じ重さで対処してください。

名前については、提出前にいったん別の人の目で見てもらうのがいいです。自分一人で「PDF Image Creator」と決めたときは「機能を表していてわかりやすい」としか思いませんでしたが、客観的に見れば一般名詞そのものです。WordPress.org のプラグイン検索で類似の名前があるかどうか調べておくだけで、自動レビュー段階での差し戻しはかなり減ります。「自分のハンドルネームを頭につける」というのは、シンプルですが効きます。

所有権については、個人開発でも引っかかります。提出に使うメールアドレスのドメインと、プラグインの Author URI のドメインが違うと、「あなたが所有者である根拠は?」と聞かれます。会社のプラグインを個人 Gmail で出すような場合は、特に注意が必要ですが、個人開発でも複数ドメインを持っていると同じ問題が起きます。私のように、メールで「個人開発者で、両方とも自分のものです」と説明すれば通る場合が多いですが、最初から1つのドメインに統一しておくほうが楽です。

プレフィックスは、4文字以上、ユニーク、アンダースコアまたはハイフン区切り、というルールを最初の1文字目から守ってください。私のように pic_ という3文字でスタートしてしまうと、コードの隅から隅まで grep して置換することになります。AI 支援ツールが普及した今でも、こういう作業はバグの温床になります。

WordPress.org のバナーやアイコンは、絶対に ZIP に入れない。承認後に SVN の assets/ ディレクトリ(リポジトリ直下、trunk/assets/ ではない)にアップロードします。私はこれを最初知らずに ZIP に同梱して提出して指摘されました。

そして、提出後に長期間連絡がなくても焦らないでください。WordPress.org のレビューチームは週に約1,000件をボランティアで処理しています。1〜2週間連絡がないのは普通です。私の場合は10日でしたが、もっとかかる人もいます。催促のメールを送ると逆効果なので、待つしかありません。

差し戻しが来たときは、メールの長さに圧倒されないでください。英文で長く見えますが、実際の指摘は箇条書きで分解できる範囲です。私は最初、メールをコピーして翻訳ツールにかけて、指摘ごとに番号を振ったメモを作りました。それから、セキュリティ系(自分の場合は exec の話、これは2回目で出ましたが)を最優先、次に名前のような後戻りしにくい変更、最後にプレフィックスや細かい修正、という順序で対応しました。レビュー担当者は週に何百件のプラグインを見ているので、再提出時のメールは 長文の説明より、何をどう直したかを箇条書きで簡潔に 書いたほうが歓迎されます。

そして1番大事なのは、差し戻しを受けても落ち込みすぎないことです。WordPress.org の差し戻しは、コーディングが下手だとか、開発者として失格だとかいう話ではありません。「世界中のサイトに配布されるコードとしての作法」を教えてくれているだけで、これは個人サイトで動くコードとは要求水準が違って当然です。1本目で詰まっても、2本目はずっと楽になります。私が Thanks Mail for Stripe で1発通過できたのは、純粋に1本目の差し戻しから学んだことの蓄積です。

参考にしたページ

審査で迷ったとき、私は WordPress 公式のドキュメントをかなり読み返しました。個人ブログだけで判断すると、古い情報を踏んでしまうことがあります。

初めての WordPress.org への提出は、多くの人にとって緊張するイベントです。私もそうでした。でも、終わってみれば、差し戻しメールに書かれていた指摘の一つ一つは、公開用のプラグインとして必要なものばかりでした。差し戻しを受けて落ち込むのではなく、「学習機会のメッセージが届いた」と捉え直すことができれば、次の提出はずっと楽になります。この記事が、そのきっかけになれば嬉しいです。