WordPress.org にプラグインを出して、最初に止まるのは、コードの中身ではありませんでした。止まるのは、名前、プレフィックス、同梱物です。私は1本目で2回差し戻され、3バージョン直して、提出から承認まで約2週間半かかりました。ただ、そのとき指摘された8項目を手元に残しておいたら、2本目は初回で1発通過しました。だから先に、その8項目と直し方を渡します。経緯やコードは、その後ろに置きました。審査に通ったあとの SVN 公開作業は、別記事「WordPress.org の SVN で初めてプラグインを公開した話」にまとめています。
差し戻された8項目と、直し方
2段階の審査で指摘されたのは、この8つです。上から、後戻りしにくい名前まわりと、見落としやすく重い exec() を優先して対処しました。
| 指摘 | 直し方 |
|---|---|
| プラグイン名が一般的すぎる | ハンドルネームを頭に付けてユニークに（例: Rapls PDF Image Creator） |
| 所有権の確認（メールと Author URI のドメイン不一致） | 単独の開発者で両方とも自分のもの、と返信で説明。最初から1ドメインに統一すると楽 |
| プレフィックスが短い（pic_ の3文字） | 4文字以上・ユニーク・アンダースコア区切りに（例: rapls_pic_） |
| deprecated 関数 imagedestroy() | PHP 8.0 以降は不要なので削除 |
| ZIP にバナー・アイコンを同梱 | ZIP から除外。承認後に SVN リポジトリ直下の assets/ に置く |
| exec() / shell_exec() の使用（手動レビューで最重要） | 外部コマンド実行をやめる。私は Ghostscript を削除し Imagick 単体に絞った |
| エラー応答にファイルパスを含む | パスを応答から除去 |
| load_plugin_textdomain() の明示呼び出し | WordPress 4.6 以降は自動読み込みなので削除 |
長い英文メールに見えても、分解すればこの8項目に収まります。
提出前に、自分で潰せるもの
8項目のうち、提出前に自分でゼロにできるものがあります。先に潰しておくと、最初の差し戻しの量がかなり減ります。
まず Plugin Check を最低1回は回します。私の最初の実行では ERROR が15件ほど出ました。エスケープ・サニタイズ・出力エスケープが中心で、30分ほどでゼロにできます。ここを詰めたおかげで、エスケープ系は審査中に一度も指摘されませんでした。名前は、提出前に別の人の目で見てもらうか、WordPress.org の検索で類似名を調べて、ハンドルネームを頭に付けます。自分では機能を表す良い名前のつもりでも、客観的には一般名詞そのもの、ということが起きます。プレフィックスは1文字目から4文字以上で書きます。私は pic_ という3文字で始めてしまい、コードの隅から隅まで grep して置換する手戻りになりました。バナーとアイコンは ZIP に入れず、承認後に SVN の assets/ に置きます。
ただし、提出前のチェックだけでは潰せないものもあります。注意したいのが exec() です。Plugin Check では、これは ERROR ではなく WARNING 止まりでした。WARNING は目立たないので見落としがちですが、私の場合はこれが手動レビューで一番大きな差し戻し理由になりました。提出前は、WARNING 欄の外部コマンド実行を、ERROR と同じ重さで見てください。
exec() の指摘は、設計の作り直しになった
8項目のうち、コードを1行直して済まないのが exec() でした。手動レビューで指摘され、対処に一番時間がかかったので、ここだけ詳しく書きます。指摘は、私のプラグインの Ghostscript エンジンの3行に対してでした。
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.
困りました。Ghostscript は PDF を画像に変換するコマンドラインツールで、PHP から呼ぶには通常 exec() を使います。Ghostscript を使うけれど exec() は使わない、という方法は基本的にありません。proc_open() も同じ系統なので回避になりません。関数を一段ラップしても、レビューチームが見ているのはユーザーのサーバーで何が起きるかなので、本質は変わりません。多くの共有レンタルサーバーでは exec() がそもそも無効化されている、という現実もあります。結局、Ghostscript エンジンを丸ごと削除して、Imagick だけで処理する形に絞りました。ページ指定や解像度調整まで書いてあったので git rm した瞬間は少し寂しかったですが、切り替えは丸1日で動くものになりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
// 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; } } |
2エンジン構成から Imagick 単体へ。審査のための削除でしたが、共有サーバーで動く範囲に絞れたという意味では、結果的に良かったです。
提出前のチェックだけでは通らない理由
1本目で2回差し戻されたのは、WordPress.org の審査が2段階だからです。最初の差し戻しは、AI を含む自動チェックによる事前判定で、プラグイン名、所有権、プレフィックス、deprecated 関数、ZIP 同梱物といった、機械的に拾える項目を見ます。これを通過しないと、人間のレビュアーまで進みません。自動チェックを通過すると、次にボランティアの人間が手動でレビューし、自動チェックでは拾えないコードの中身まで踏み込みます。私の exec() は、この段階で出ました。だから最初のメールの指摘を全部直しても、それで承認とは限りません。Plugin Check の ERROR をゼロにして出しても、手動レビューで止まることがあるのは、この構造のためです。
exec() は WARNING 側にいました。目立たないぶん、ここを軽く見ると手動レビューで刺さります。
提出から承認までの、期間と手数
提出してから最初の応答まで、10日間ありました。レビューチームは週に約1,000件をボランティアで処理しているので、1〜2週間連絡がないのは普通です。催促は逆効果なので、待つしかありません。最初の応答で名前・所有権・プレフィックス・deprecated・ZIP 同梱の指摘が来て、直して再提出した翌日、手動レビューで exec() が来ました。Ghostscript を削除して再提出し、最後に load_plugin_textdomain() の明示呼び出しを自分で見つけて削除し、もう一度提出。承認はその数日後でした。差し戻しから承認までの実作業は、合計15時間ほどです。
再提出の連絡は、長文の説明より、何をどう直したかを箇条書きで簡潔に書くほうが歓迎されます。担当者は週に何百件も見ているからです。私はこの粒度で書きました。
|
1 2 3 4 5 6 7 8 9 |
Thank you for your review. I have addressed all the issues: 1. Plugin Name/Slug: "Rapls PDF Image Creator" / rapls-pdf-image-creator 2. Ownership: I am the sole developer. "rapls" is my WordPress.org username, and raplsworks.com is my development site. 3. Technical: namespace Rapls\PDFImageCreator / all globals use rapls_pic_ prefix (4+ chars) / removed deprecated imagedestroy() / removed file paths from error responses 4. Assets: removed from ZIP, will upload via SVN after approval. |
次の自分に渡すメモ
この経験のあと、2本目の Thanks Mail for Stripe は、最初から名前をユニークにし、プレフィックスを tmfs_（4文字以上）にし、外部コマンド実行を使わず、Plugin Check の ERROR と WARNING を両方ゼロにし、assets を分離して出しました。結果、初回審査で1発通過。1本目で1週間かかった工程が、ほぼ即日で済みました。早見表の8項目が、2本目では全部チェック済みの前提になっていた、ということです。
WordPress.org の差し戻しは、コーディングが下手だという話ではありません。世界中のサイトに配布されるコードとしての作法を教えてくれているだけで、個人サイトで動かすコードとは要求水準が違います。1本目で詰まっても、指摘を早見表のように残しておけば、2本目はずっと楽になります。次に出すときは、この8項目のうち、いくつを提出前に潰しておくか、から始めるのが良さそうです。
参考にしたページ
関連記事
- WordPress.org の SVN で初めてプラグインを公開した話｜Git しか知らなかった個人開発者の記録。レビューを通過したあとの SVN 作業の実例です。
- Thanks Mail for Stripe。8項目を潰して初回で通った2本目のプラグインです。
コメント