ワードプレスのプラグインを自作したら一度は公式ディレクトリに申請して、実際にプラグインがワードプレスで検索できたりすると嬉しいですよね。^-^）
ここでは「Ad Auto Insert H」（広告自動追加 H）という、アドセンス広告を記事内の見出し前に自動で追加するプラグインを公式ディレクトリに申請して、実際にアップロードして公開した過程を1つ1つ詳しく解説しています。
公式ディレクトリへ登録してみたい、という場合の参考になりましたら幸いです。
- 【参考】公式登録する3つの大きなメリット
- 自動アップデート機能: ユーザーに手動更新の手間をかけさせない。
- 信頼性の向上: 公式の厳しいコードレビューを通過した証になる。
- 露出の拡大: 全世界のWordPressユーザーの検索対象になる。
プラグイン開発のポイント
まずは公式ディレクトリに登録するプラグインの作成ポイントから。
ワードプレスの公式ディレクトへ登録する場合には、以下のワードプレス公式ドキュメントを参照して、規約などにのっとる形にしてきましょう。
公式ディレクトリに登録する、ということで、
個人で作って気ままに自分だけで使う、というのと比べ、対応が必要なのが以下のような点。
- １）プラグイン有効化、無効化時の処理：
- プラグインの有効化・無効化時に設定値の登録や削除を行うなど処理追加。
- プラグイン一覧で表示されたときに、プラグイン名の下に「設定」メニューが表示されるように色々追加。
- ２）接頭辞を付ける：
- 関数名、定義には、他のプラグインとバッティングしないようプラグイン固有の接頭辞を付ける
※ add_actionなどのフック名やDBに保存する設定名（オプション名）にも接頭辞を付けておくのが良い - 「Ad Auto Insert H」というプラグインでは、プラグインの頭文字「aaih」を接頭辞として以下のようにつけてます。
関数名：aaih__xxxx_xxx()
定義：AAIH__XXXX
※接頭辞（aaih）の後のアンダースコア（ _ ）は1つでも2つでも、一意であればOK
- 関数名、定義には、他のプラグインとバッティングしないようプラグイン固有の接頭辞を付ける
- ３）コーディング規約：
- ワードプレスにはコーディング規約があるので、その規約に従って、命名規則、タブやスペースの使い方などを合わせる
- php, javascript, html, css といったコーディング規約あり
- ４）セキュリティ関連：
- 外部から直接phpファイルにアクセスされないよう、
各ファイルの先頭に、
if ( ! defined( 'ABSPATH' ) ) exit;
を付ける。 - DBに保存するデータの無害化（サニタイズ）や、nonce を使ったり、セキュリティ面はしっかり考慮する。特に出力時のエスケープ（
esc_html()など）は、表示する直前で書く（Late Escaping）は鉄則。 - 公式ディレクトリに登録申請すると、レビューチームによってこのセキュリティ関連は特にチェックされる
- 以下は必ず読み、その内容に沿っていることが大きなポイント
- 外部から直接phpファイルにアクセスされないよう、
- ５）コードの整理：
- コードの見通しが良くなるよう、必要に応じて関数に分ける
- ６）コメントを付ける：
- php doc の使用したり、コードを読んでいる中で忘れそうなところにはすべてコメントを入れる
- php doc については「What is a DocBlock?」ざっと見て、
あとはいろいろ解説しているページがあるので検索して確認。
- ７）国際化：
- 日本語だけでなく、英語表記にも対応
- プラグインの国際化（英語-日本語対応）参照
※）プラグイン名に「WordPress」や「AdSense」などの商標を直接入れるのは規約で禁止されていますのでご注意を。
こうした過程の中で、
開発環境として途中から「Visual Studio Code（vs code）」を取り入れてます。
vs code（ Visual Studio Code ）とは Microsoft が提供している開発環境。
無料で使えるし、実際使って見ると、なぜ今まで使ってなかったのか、
と思ったぐらい超便利。
- （Xdebugなどの設定を組み合わせれば）変数の中身もステップで確認できるし、
- 参照している関数の定義もその場で見れるし、
- どこでその関数を参照しているかとか、その関数の定義されているところにすぐ飛べたりするし、
- php の関数の定義や、ワードプレスの関数の定義も参照できるようにしたりできたり、
（VS Code自体の機能を強化できる『拡張機能』がその場で検索、ダウンロードできる） - フォルダ内にあるファイル中のワード検索も簡単にでき、正規表現を使っての検索もできたりする
それまで echo や var_dump() を使っていろいろ苦労しながらある時点の変数の中身を確認したり、関数の定義を見るために関数名でネット検索してたりして、どれだけ時間を無駄にしていたことか．．．
このプラグイン開発時は一人でドキュメントと睨めっこしながら進めてましたが、今ではこのVS Codeに「GitHub Copilot」などAIを連携させることができます。AIによりコーディング規約に沿ったコードを自動生成したり、バグを指摘してもらったりすることも可能になってますね。
プログラム開発もすぐ隣にエキスパートがいるような感じで、とても楽になりました。
上の７つの中で特に重要なのが４のセキュリティ関連。
ここがワードプレスの規約に従った対応がされてないと、公式ディレクトリ登録のためのレビュー申請しても、問題あり、として、申請が通りません。
また一人で気ままな開発と比べて大切になってくるのは、５と６のコードの整理とコメント付け。
公式ディレクトリに登録する、ということは、
何かあれば対応してアップデートする、ということを意味します。
そうした時コードを改めて自分で見てすぐ分かる（1週間もたつともう他人のコードに見えて何を考えてそうしたのかが分からない（笑））、何か変更や修正するにしても見通しが良くて分かりやすい、という形にしておくことが大切になりますね。
これってなんだっけ？とか、ここは自分でも分かりづらい、実は良くわかってない（笑）なんて箇所は、兎に角後で読んですぐ分かるよう、未来のあたふたしている自分に向けて詳細なコメントを入れておきましょう。
（コメントは全て日本語でOK。レビュー担当者はコードのロジックを読み取るので、日本語の解説が審査に悪影響を及ぼすことはありません）
「7. 国際化」は必須ではありませんが、
世界中のユーザーに使ってもらうチャンスなので、ぜひ挑戦してみてください。
（グーグル翻訳を使えば、実はそれほど手間ではないし、最近はAIに『このPHPコードをWordPressの国際化ルールに合わせて翻訳関数化して』と頼めば、一瞬で書き換えてくれます。実はそれほど手間ではないんですね。）
Readme.txt の作成
readme.txt は必須
プラグインの本体コードが完成したら、
次に取りかかるのが readme.txt の作成です。
ネット情報を見ていると、「最初の申請時はコードだけでOK、readme.txtは後からで良い」という説明を見かけることがありますが、これは古い情報であり、現在では間違いです。
実際に readme.txtなしで申請画面からファイルを送信しようとすると、「readme.txtが含まれていない」というエラーメッセージが出て、先に進むことができません。
参考）プラグインのReadmes（by プラグイン開発ハンドブック）
提出前に「検証ツール」でチェックを
readme.txt には特定の書き方ルールがあります。
せっかく申請しても、ここが原因で差し戻されるのはもったいないですよね。
公式が提供している Readme Validator（検証ツール） を使えば、記述ミスがないか事前に確認できます。
私も初回申請時にはこのツールを使い、エラーが出ないことを確認してから提出しました。特に「Stable tag」やバージョンの整合性は、機械的に厳しくチェックされるポイントなので、ここでパスしておくと安心です。
英語が基本
readme.txt の作成では、
最低限形が整っていればOKですが、言語は英語です。
以前は日本語でも良かったけど
以前は日本語でも良かったと思いましたが、現在は英語で書いてね、と変わって来てるようです。
※）以前プラグインの申請では、英語にするのが手間に思えたので、中身は日本語で作成してレビュー提出、そしてして最後の承認まで行ってます。
ただ今ではAIによる翻訳も一瞬で出来ることから、プラグインを世界中の人に使ってもらうために最初から英語翻訳して出すのが良いですね。
関連）READMEは英語で記述する必要がある（ワードプレス公式）
文字コードには注意
readme.txtを保存する際の文字コードは、必ず 「UTF-8 (BOMなし)」 にします。
「Shift-JIS」などで保存してしまうことがありますが、WordPressのシステムはUTF-8が前提です。これ以外の文字コードだと、公式ディレクトリ上で文字化けしてしまうので注意しましょう。
参考までに、
プラグインが承認された時につけていた readme.txt はこちら
（私の場合、ヘッダ以外全て日本語で作成しました。上のファイルは実際の提出版から若干変えてます（含まれているリンクは全て xxxx に変更、文字化け回避から 文字コードは shift-jis に変換）実際のプラグインに含めるファイルは、必ず UTF-8 (BOMなし) で作成しましょう）
ライセンスの指定
ライセンスは、プラグイン開発ハンドブックでも指定されている「GPLv2 or later」を指定します。
これは『誰でも自由に使用・改変・再配布ができる』というWordPressの哲学に基づいたライセンスになります。
解説ページも作っておく？
readme.txt を作った時に、以下を含めてます。
（ readme.txt 内のリンクの書き方）
[Home](https://xxxxxxxxxxx) | [Documentation](https://xxxxxxxxxxx)
より詳しくは以下のページで説明しています。
[公式サイト](https://xxxxxxxxxxx)別に審査通過後に記載すれば良いんですけど、割と頭の中が結構一杯になって、勢いで書いた、みたいな感じですね（笑）
HOME はこのサイト（https://tabibitojin.com）としてそのURLをそのまま記載すればよいですが、Documentation というところは、未だ作ってない解説ページへのリンクを記載しています。
（https://tabibitojin.com/ad-auto-insert-h みたいな）
プラグインを申請する時、コードレビューでリンク切れがあったらダメなのかな、なんて考えて（心配性なのだ）、先に中身はほぼないページを作って公開し、リンク切れにならないようにしてました。
コードレビューを受けた感触から、readme.txt はヘッダ情報ぐらいしかチェックされないようですので、とりあえず余計なことは記載せずシンプルな形で作っておくのが良いと思います。
※ そうすれば私がやったように、未だ審査に通過してない時点で余計なページを作って公開する、なんて手間も省けますので
※ またタイトルや短い説明文に商標（WordPressなど）が含まれていないかは注意しましょう
実際に申請（ファイルの送信）
- プラグイン自体もできた、
- readme.txt も作ってフォルダーに含めた、
となったら、いよいよ公式ディレクトリへの申請です。
※）画像について：
私の場合、関連してスクリーンショットの画像も含めてますが、現在は含めないことが推奨されているようです。（承認後に「assets」という別フォルダにアップロードする）
プラグインの公式ディレクトリへの申請手順は
以下のように wordpress.org ：プラグイン開発者向け情報のページで案内されているので分かりやすいですね。
ここに書かれているように、
申請自体はzipファイルにして送るだけなので非常に簡単。
プラグインフォルダーをまとめてzipファイルにすればOK。
- ①：フォルダー上で右クリック
- ②、③：表示されるメニューから「圧縮」⇒「.zip」をクリック！
実際操作をしてみると、以下のような感じで プラグインの zipファイルができます。
（ここでは、ad-auto-insert-h.zip）
この zipファイル を送れば良いですが、
本当に zipですべてのファイルが圧縮されているのかな？（含まれているのかな？）と心配な場合には、ダブルクリックで一旦解凍＆中身を確認してみるのが良いですね。
（特にMacユーザーの方は）不要な隠しファイルが含まれないよう、クリーンなzip作成を心がけると、レビュー担当者に喜ばれるかもしれません。^-^;）
ますは最初の 1. WordPress.org のアカウント登録。
アカウント登録後ログインしたら、2にある「プラグインレビューを申請」のリンクをクリックし、実際にレビューの申請をします。
（プラグインファイルを zip にして送る）
このレビューの申請では、以下のような画面から行います。
- ①「ファイルを選択」ボタン：
プラグインフォルダーを zip で圧縮し、そのファイルを選択 - ② 誓約事項へのチェック：
- 規約に関するいくつかのチェック項目が表示されます。ここは「すべてにチェック」が必要です。
- 現在ではチェック項目の中に「外部サービスとの通信（APIなど）」や「サードパーティライブラリの使用」に関する厳しい確認が含まれるようになっています。
- 適当にチェックせず、自分のプラグインの動作と照らし合わせ、「規約をしっかり理解して同意した」というところでチェックをしていきましょう。
- ③ 最後は実際にアップロード：
この時、readme.txt が zip ファイルの中にないと、readme.txt がないので送信できない、とかのメッセージが表示されてファイルが送れない
以下、実際に「Ad Auto Insert H」（広告自動追加 H）というプラグインをレビュー申請に出した時表示された画面です。
黄色っぽい背景でメッセージが表示されたため、
え？何かエラーがあったのかな？
なんて思いましたが、内容的には、受け付けました、というものですね。
あくまで私の申請した当時ですが、
レビュー待ちのプラグインは25件、と表示されていたので、26件目にレビューが行われる、となったのだと思います。
現在は数百件以上の待ちが発生することも珍しくないようで（AIにより開発スピードが上がったことがその一因になるでしょうか）、レビュー開始まで2週間〜1ヶ月ほどかかる場合もあるようです。
「受付完了」のメールが届いていればしっかり列に並んでいるので、気長に待ちましょう。
申請後のレビュー経過と承認まで
レビューにかかった日数
プラグイン「Ad Auto Insert H」を実際に申請後、
承認までの経過は以下のような感じでした。
参考までに、
プラグイン「Ad Auto Insert H」の場合のコード量はざっくり以下の通り
- php：約6,700行（コメント行含む）
- その他、js、css, readme.txt
【レビュー経過と承認までの日数】
| 段階 | 日付 | 内容 |
| ① -１）初回提出 | 5月1日 | 審査待ち列に並ぶ |
| ① -２）レビュー結果（1回目） | 5月3日 | 指摘事項の通知 |
| ② -１）2回目提出 | 5月6日 | 修正して再アップロード |
| ② -２）レビュー結果（2回目） | 5月7日 | さらなる修正依頼 |
| ③ -１）3回目提出 | 6月3日 | 大幅な修正を経て再提出 |
| ③ -２） 最終承認 | 6月3日 | 祝・公式ディレクトリ登録！ |
ワードプレスのプラグイン開発ガイドラインなどに書かれてあったと思いますが、レビューは人の手で行われ、レビューチームも忙しい時があるようです。
しかもボランティアとして、世界中の有志や企業支援によるレビューチームが、膨大なコードを一行一行チェックしてくれてるのだとか。感謝しかありません。
今回の申請では、
初回提出から2日後には、まず第一回のレビュー結果が来ました。
※非常にラッキーな超特急コースだった：
2日後に1回目のレビュー結果が来たのは、現在から見れば非常にラッキーというか、超特急ぐらいの早さだったようです。現在は世界中からの申請が多いため、最初の返信まで2週間〜1ヶ月ほどかかるのが標準的とも言われてますので。
その後、修正＆再提出を行い、3回目で承認されてます。
ちなみに2回目のレビュー結果から3回目の提出まで約1か月も空いているのは、私自身がなかなか時間が取れなかった、というのと、2回目の指摘内容に結構大きな修正が必要となるものが含まれてていたため。
（一人で気ままに作っていた時には気づかなかった「公式の壁」にぶつかったって感じですね）
レビューで指摘された内容
レビューで指摘された具体的内容やその対処については以下にまとめてます。
【WordPress】プラグイン公式ディレクトリ申請時のコードレビューで指摘された点まとめ！
一番のポイントはセキュリティ関連の以下2点。
- データは必ずサニタイズ、検証、エスケープが必要
- 変数は、エコーされるときにエスケープする必要あり
加えて、「Ad Auto Insert H」というプラグインでは、
JavaScript（アドセンスの広告コード）をテキストエリアにコピペして保存できるようにしてましたが、「そもそも、そうしたことはしてはダメだ」と言われてしまった点。
- プラグイン内で
ユーザー独自のCSS、JavaScript、PHPを保存させてはいけない
私が「Ad Auto Insert H」を作った当時（2022年）、それ以前ではそうした「自由に入力・保存できる」プラグインも許可されていたようですが、セキュリティの観点から「今後は許可しない」と言われてしまいました。
大幅な作り変えを余儀なくされる
アドセンスの広告コード（JavaScript）をテキストエリアにペーストして保存する、という、広告表示プラグインとしては「当たり前」だと思っていた機能が、まさかの規約違反。
「え？じゃ、このプラグイン、ダメなの．．．？」
と、正直、この指摘には泣き崩れそうになりました（笑）。
でも、元々あきらめの悪い私は開き直り、
ではどうすれば規約を守りつつ、ユーザーが簡単に広告を貼れるようになるかを、改めて考えた結果、以下のような仕組みに作り変えました。
- 変更前：広告コード（JS）を丸ごと貼り付けて保存する
- 変更後：広告コードに含まれる「ユーザー個別のID（pub-IDなど）」のみを入力してもらう
つまり、セキュリティ的に問題となる（脆弱性の原因になる）「JavaScriptそのものの入力」ではなく、安全な「ID（英数字）」だけを保存する形に変更してます。
これなら、広告コード自体はプラグイン側が用意した安全なテンプレートが使われるため、セキュリティ上の問題はクリアできますよね。ただこれがかなりの大幅な修正になり、再提出まで1ヶ月という時間がかかってしまいました。
2回目以降のファイル送信について
指摘箇所の修正後、ファイルはどのようにして送れば良いかは、レビュー結果のメールの最後に書かれてます。
——–
Attach your corrected plugin as a zip file OR provide a link to a public location (Dropbox, Github, etc) from where we can download the code. A direct link to the zip is best.
——–
【意訳】
修正したプラグインをzip形式でメールに添付するか、DropboxやGitHubなどのダウンロード可能なリンクを教えてください。直接のダウンロードリンクが一番よいです。
1. メール添付よりも「共有リンク」がおすすめ
最初は「メールに添付して返信すればいいかな」と思いましたが、注意が必要です。
「Ad Auto Insert H」のようにJavaScriptが含まれるプラグインの場合、zipの中にJSファイルが入っていると、Gmailなどのメールサーバーが「危険なファイル」と判定して、送信をブロックしてしまうことがあります。
そのため、おすすめの送信方法は以下になりますね。
- DropboxやGoogleドライブなどにzipをアップする
- そのダウンロード用URLをメール本文に貼って返信する
※共有設定を「リンクを知っている人全員が閲覧（ダウンロード）可能」にするのを忘れないようにしましょう。
2. レビューチームへの返信メール
実際返信する際、
レビューチームには以下のように簡単な英文で大丈夫です。
（以下私が実際に行った返信内容の例）
【返信メールの例】
Dear WordPress Plugin Review Team,
I updated the code for "Ad Auto Insert H" and uploaded it to the link below.
https://www.dropbox.com/xxxxxx
[ここにDropboxなどのURL]
I would be very happy if you could re-review this.
Thank you !
こうしたやりとりを何度か諦めずに続けると、
ついに承認メールが届きます！
承認と公式ディレクトリへのアップロード
承認メールと今後の案内
レビューチームで無事プラグインが承認されると、以下のように2通のメールが来て、いよいよ公式ディレクトリへのアップロードです。
1通目：「コードレビューが無事終わったよ」メール
1通目には「successfully completed」（レビューは無事終わったよ）という内容と、「What to do next」（次にすること）が書かれてますのでまずその内容を確認。
（「メールアドレスを登録してね」とか「SVNというものにアップロードするんだよ」などが書かれてる）
2通目：「承認された！おめでとう！」メール
2通目には件名に「xxxx has been approved!」（承認されたよ！）と、本文には「Congratulations」（おめでとう）から始まるメールが来ます。（嬉しい ^-^））
このメールに「プラグインをアップロードする方法」などのリンクが案内されるので、それらを確認しつつ、承認されたプラグインのファイルを公式ディレクトリ―にアップロードします。
ちなみに、プラグインが承認された以降は、コード変更などしても「スキルがあるし信頼するし」ということでまた都度レビューを受ける、ということは必要なくなります。（とメール内で案内されます）
その分「セキュリティへの責任はすべて自分にある」という、何あ、頼りにしていた親から突然突き放されたような、身の引き締まる思いにもなりますね
実際アップロードしてみた手順
実際のアップロード手順は以下にまとめてます。
【WordPress】TortoiseSVNでプラグインを公式ディレクトリにアップロード！手順の詳細解説
アップロード先はワードプレスの公式ディレクトリの「SVNレポジトリ」と呼ばれるバージョン管理システム。
このSVNレポジトリ（ファイルの保管場所）へは SVNクライアントと呼ばれるソフトを使いますが、最初は難しく感じるかもしれません。
でも実際やってみてその操作が分かると、パソコン上でファイルのコピペをしているだけみたいな感じで、非常に簡単に行えます。
※ Windowsユーザーなら、エクスプローラー感覚で操作できる『TortoiseSVN』が断然おすすめ。Macの方は別のツール（SnailSVNなど）が必要ですが、基本的な考え方は同じです
アップロード後にしたこと
以上でプラグインの公式ディレクトリへの登録は一通り終わりですが、
公式ディレクトリに登録後に行ったことは以下４つ。
- １）ヘッダ画像、アイコン画像の作成とアップロード
- ２）readme.txt を日本語から英語へ
- ３）翻訳対応
- ４）プラグインの公式ページ（説明ページ）の作成
１）ヘッダ画像、アイコン画像の作成とアップロード
「ヘッダ画像」、「アイコン画像」の作成とアップロードを行ってます。
これらは公式ディレクトリのプラグインページに表示されるヘッダ画像であったり、プラグインの一覧に表示されるアイコン画像となりますね。
【プラグインの一覧】
アイコン画像が表示される
【プラグインページ】（Wordpress.org）
ヘッダ画像、アイコン画像が表示される
作成から実際のアップロード手順、注意点などは以下にまとめてますので
良かったらご参照ください。
【WordPress】公式ディレクトリへヘッダ画像とアイコンのアップロード
２）readme.txt を日本語から英語へ
審査を通った後は、より多くの人に使ってもらえるよう、readme.txtを英語に書き換えました。
今はAI（GeminiやChatGPT）を使えば、文脈を汲み取った自然な英語に一瞬で翻訳できるので、グーグル翻訳と組み合わせて効率よく進めましょう。
３）翻訳対応
readme.txt を英訳してアップロードすると（SVNレポジトリにコミットすると）すぐプラグインページに反映されます。
そこで今度は日本語へと翻訳し直しをしてみました。
（詳しくは以下にまとめてます）
【WordPress】翻訳を手伝いませんか？で readmeの日本語翻訳を追加してみる
- でも別に readme.txt は日本語のままで、それを wordpress.org 上で英語に翻訳すれば良くね？
- 大本を英語にしておくと、
他の言語に翻訳してくれる人ももしかしたら現れるかも．．．
などと後から思ったのでした。
※）大元が英語であれば、有志が他の言語（フランス語やドイツ語など）に翻訳しやすくなります。日本語ユーザーには、翻訳システム経由で日本語が表示されるので、まずは「英語を正解（ソース）」にするのが良いと思います。
４）プラグインの公式ページ（説明ページ）の作成
最後は、readme.txt 作成時、解説ページのリンクを入れて暫定的に公開していた「プラグインの説明ページのアップデート」。
【公式】Ad Auto Insert H（広告自動追加H）プラグイン
このプラグインは、もともとは自分が便利になるようにと作ったもの。
- それを他の人も使えると嬉しいかも、
- 更に国際化対応（英語対応）もやってみよう、
など、当初日本国内向けで公開のつもりが成り行き上、英語まで対応してしまったので、プラグインの説明ページも英語が必要？など、思いかけずどんどんと幅（というか手間）が広がっていきました．．．
時間もかなりかかりましたら、
その分、日本だけでなく世界でも活用していただけると嬉しいですね。
プラグイン開発を通して
はじめて公式ディレクトリにプラグインを登録する、ということをしましたが、特にレビューの指摘で、より深くワードプレスやプラグインのことが分かったような気がします。
自分だけで使うプラグインを作ってワードプレスをより便利にして使う、というのも良いですが、プラグインを自作したら公式サイトに申請してみると、さらに色々なことが分かって一層楽しくなりそうですね。^-^）
ブログの収益化については、以下の無料メルマガに登録して情報とってみてくださいね。
コメント