自分が作成したWordPressのプラグインを公式ディレクトリに登録するためには、WordPress.orgに申請を行い、審査に合格する必要があります。

申請が承認されると、WordPressの公式ディレクトリ内に専用のスペースが与えられ、そこへ自作プラグインを公開できるようになります。公開されたプラグインは、世界中のWordPressユーザーが管理画面から直接インストールして利用できるようになります。

世界中の誰でもが自分のプラグインを自由に使ってもらえるなんて、ちょっとワクワクしますよね。

プラグインの申請に挑戦する

以前の記事で、どうしてもバグが取れずにお蔵入りしていた簡単なWordPressスクリプトを、AIの力であっという間に修正できた件について書きました。

【WordPressカスタマイズ】コードブロックに「コピー」ボタンを追加する方法（横スクロール対応）

ブログに掲載されたプログラムのソースコードを利用したい時、「これ、ワンクリックでコピーできたら便利なのに…」と感じたことはありませんか？特に横に長いコードだとスクロールが必要で、コピーが少し面倒に感じますよね。この記事では、WordPres...

中途半端に作られたバグだらけのスクリプトをAIに見せ、💬「このスクリプトを修正してください」とお願いします。すると、これだけでバグが取り除かれ、エラー対処まで施されたスクリプトが完成しました。

そこで今回は、以前から挑戦したいと思いながらも「無理だ」と諦めていた自作プラグインのホスティング申請にAIの力を借りて挑戦することにしました。

再度説明しますと、この申請に合格すると、WordPressの正式なプラグインとして、メニューにある「プラグイン」→「プラグインの追加」から自分の作成したプラグインを誰でもが、検索してインストールできるようになります。

今回は、その過程を体験記として書いてみたいと思います。導入マニュアルではありませんので、ご了承ください。

プラグインの申請までにしたこと
いよいよ申請
再申請のためにしたこと
- Plugin Check、PHPCS + WPCS
そして合格
- ✅️ 公開のためのアイコン
おわりに
- 事後談：

プラグインの申請までにしたこと

✅️ スクリプトをプラグイン化

単にプラグインを作るだけならさほど難しいことではありません。WordPressで動くPHPスクリプトを、プラグインとして機能させるための定型文にはめ込んでいけばよいのです。

/**
 * Plugin Name: My Plugin
 * Description: This is a description of my plugin.
 * Version: 1.0.0
 * Author: My Name
 * Text Domain: my-plugin
 */

// セキュリティ対策：直接アクセスを禁止
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// ここに作成したPHPスクリプトのコードを転記

プラグイン化するために構文をはめていくだけでよいのでそれほど難しくはないのですが、試しにAIに、

お手伝いできることはありますか？

「このスクリプトをプラグイン化してください」

とお願いしたところ、すぐにプラグイン化してくれました。

驚いたことに、設定画面も勝手に作成し、私がやりたいと思っていたパラメータ設定を自動で実装してくれたのです。

私は何も指示をしていません。それなのに、まるで経験豊富なプログラマーが仕上げたかのような形で完成しました。

ここまでなら、私も時間をかければできるでしょう。調整を含めれば数時間はかかるかもしれません。それがわずか10秒です。しかも指示はたったの一文だけでした。

この後、欲が出てプラグインに色々と機能を追加しましたが、それも私がプログラムするのではなく、ただAIにお願いするだけでした。

こうして、私が理想としたプラグインが完成しました。これをAIなしで作れたかと考えると、できなかっただろうなと思います（途中で面倒になって、放棄していたと思います）。実際にWordPressにアップロードして、動作確認を行いました。

審査のための修正

しかし、ここからが難しいのです。公開するためには、いくつかの厳しい基準に沿った形でプラグインを整える必要があります。

国際化（i18n）
- すべてのユーザー向け文字列を翻訳可能にすること。
  - __や_e、_xなどのWordPress国際化関数で文字列をラップして実現します。
サニタイズとエスケープ
- ユーザー入力やデータベースからのデータを必ずサニタイズしてから処理し、画面にエスケープしてから出力すること。
  - これにより、XSSなどのセキュリティ脆弱性を防ぎます。
WordPressのコーディング規約
- 公式のコーディング規約に準拠すること。
  - コードの可読性とメンテナンス性が向上します。
デバッグモードでのテスト
- wp-config.phpでWP_DEBUGをtrueにし、警告やエラーが出ないか確認すること。

これらの4つの基準に基づいて、自作のプラグインに修正を加えていかなければなりません。

以前にマニュアルを見て、そのあまりの面倒さに「これは無理だ」と諦めた経験があります。

✅️ 国際化（i18n）

さて、ここから公開に向けての修正を加えていかなければなりません。プラグイン公開で私が面倒だと感じていたことの一つが「国際化」です。

基本的にプラグインのメニューやテキストは英語で作成し、日本語などの表示は翻訳ファイルで行えるようにします。この対応を国際化と呼びます。

具体的には、プラグインの中にある文字列に対して、国際化対応のためのWordPress関数を当てていきます。

__や_e()などの関数で文字列をラップする作業は、文字列の特性をよく理解し、属性に応じて使い分ける必要があるため、習得するのにそれなりの勉強が必要です。つまり、非常に大変なのです。

そこで、ダメ元でAIに、

お手伝いできることはありますか？

「このプラグインを国際化してください」

とお願いしたら、数秒でラップしてくれました。

しかも、スクリプト内で使用しているメッセージなども全て英語に翻訳して置き換えてくれました。

✅️ サニタイズとエスケープ

次に大変なのがセキュリティ対策です。

公開するプラグインには、セキュリティ対策が施されていなければなりません。そこで必要なのが、サニタイズとエスケープです。

WordPressでは、入力時にはサニタイズを、出力時にはエスケープを行うことがセキュリティの最善策とされています。

これにより、データベースに保存されるデータはクリーンに保たれ、表示される際にも安全性が確保されます。

そしてそのための修正が非常に面倒です。

以前にマニュアルでサニタイズするための関数を見ましたが、国際化以上に面倒だと感じました。

普段普通に使用している入力コードも、プラグインで公開するためには、セキュリティを考慮して、WordPressで用意されたsanitize_関数でラップしなければなりません。

サニタイズ前のコード：

<p>こんにちは、<?php echo $_POST['user_name']; ?>さん</p>

サニタイズ後の安全なコード：

<p>こんにちは、<?php echo sanitize_text_field($_POST['user_name']); ?>さん</p>

そこでまたAIにお願いです。

お手伝いできることはありますか？

「このプラグインをサニタイズとエスケープに対応してください」

何も考えていないような質問でお願いしたら、数秒で的確にラップしてくれました。

✅️ WordPressのコーディング規約

プラグインが公開されると、そのソースコードはオープンソースとなり、誰でも参照・修正が可能になります。そのため、コードはWordPressのコーディング規約に準拠して記述する必要があります。

具体的には、{}や()の位置、インデントの統一など、一貫したコードスタイルが求められます。これは、コードの可読性を高め、他の開発者が理解しやすいようにするためです。

一応、AIにお願いしておきます。

お手伝いできることはありますか？

「このプラグインをWordPressのコーディング規約に準拠して記述してください」

大きな変化はありませんが、これで規約に準拠されたはずです。

デバッグモードでのテストは常に行っていますので、これで、公開のために申請するプラグインが完成しました。

✅️ 翻訳ファイル

申請するプラグインは国際化対応のため、英語を基準としています。このままでも申請には問題ありませんが、すぐに日本語表示を利用できるよう、日本語の翻訳ファイルも用意します。

簡単に説明すると、日本語表示のためにはコード内の英語の文字列と翻訳した日本語を参照するためのテキストファイルであるPOファイルが必要です。正確には、そのPOファイルをコンパイルしたMOファイルが必要です。

AIに完成したプラグインを見せて、

お手伝いできることはありますか？

「このプラグインを翻訳してPOファイルを作ってください」

とお願いしたところ、本当に作ってくれました。

正直、できたらいいなぁと半分は冗談だったのですが…驚きです。

試しに、

お手伝いできることはありますか？

「POファイルをコンパイルして、MOファイルを作ってください」

とお願いしたら、

「POファイルからMOファイルを直接生成することはできません。MOファイルは、コンピューターが読み取れるバイナリ形式のファイルであり、この変換（コンパイル）には専用のツールが必要です。以下に、POファイルからMOファイルを生成するための一般的な方法を説明します。」

という返答でした。

それはそうですよね。ここまでAIだけでできてしまったら、アプリが必要なくなってしまいます。少し安心しました。

コンパイルする方法は、PCアプリのPoeditなどいくつかあります。私はアプリのPoeditを使ってコンパイルしました。

✅️ readme.txt

次に申請に必ず必要なのが、readme.txtファイルです。

readme.txtファイルはプラグインが公開されたときに、プラグインの情報提供元となるとても大切なファイルです。

=== Plugin Name ===
Contributors: User Name(WordPress.orgアカウント)
Tags: keyword1, keyword2, keyword3
Requires at least: 5.0
Requires PHP: 7.4
Tested up to: 6.6
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

== Description ==
ここにプラグインの説明文を書きます。（1～2段落程度）

== Installation ==

WordPress 管理画面の「プラグイン」→「プラグインを追加」からプラグインを検索

「今すぐインストール」の後、プラグインを有効化

設定ページから必要な設定を行う

== Frequently Asked Questions ==
= Q1: プラグインの使い方は？ =
A1: 有効化後、管理画面のメニューに「○○設定」が追加されます。

= Q2: このプラグインは無料ですか？ =
A2: はい、GPLv2 以降のライセンスで無料公開されています。

== Screenshots ==

プラグインが表示される画面の例

管理画面の設定ページ

== Changelog ==
= 1.0.0 =

初回リリース

== Upgrade Notice ==
= 1.0.0 =
初回リリース版です。

これもAIに、

お手伝いできることはありますか？

「このプラグインのreadme.txtを作ってください」

とお願いしたら、作ってくれました。

公開申請のため、言語は英語で作ります。AIが作ったreadme.txtは最低限の文章なので、これをテンプレートとして自分なりにかなり添削を必要としました。

それでもゼロからreadme.txtを自分で作るのとテンプレートを修正するのでは大変さが違います。添削も一時間ほどで終了です。

申請前に、次のサイトでreadme.txtをチェックするとより確実です。

Readme Validator | WordPress.org 日本語

いよいよ申請

そして、出来上がった2つのファイル（プラグイン.phpとreadme.txt）をフォルダにまとめてZIPし、申請に提出しました。

Add your Plugin | WordPress.org 日本語

6日後、修正が必要な旨のメールが届きました。

It's time to move forward with the plugin review "kasuga"!

Your plugin is not yet ready to be approved, you are receiving this email because the volunteers have manually checked it and have found some issues in the code / functionality of your plugin.

Please check this email thoroughly, address any issues listed, test your changes, and upload a corrected version of your code if all is well.

……

かなり細かく修正点が指摘されています。

これを修正して再度提出する必要があるのですが、提出前にもっと厳格にコードを修正する必要があるようです。

再申請のためにしたこと

Plugin Check、PHPCS + WPCS

メールには「Plugin Check、PHPCS + WPCS、または同様のユーティリティなどのツールを活用して、コード内の問題を特定してください。」と記されていました。

Plugin Checkはプラグインです。WordPressのダッシュボードからインストールして使います。これは公開申請と同時にチェックされるので、このチェックは問題ないはずです。

そこで、PHPCS（PHP_CodeSniffer）＋ WPCS（WordPress Coding Standards）を使ったチェックを行うことにしました。しかし、このWordPressのコマンドを実行するためにはWordPressのサーバーが必要です。

私の契約しているサーバーはSSHなどのリモートシェルが使えないので、WordPressのコマンドを使うことができません。自前でWordPressサーバーを構築しなければならないのでしょうか？

これには困りました。私はもはやサーバーを使った管理や開発には関わらないようにしていたため、最低限のブログ投稿だけができる環境だけを残していました。手元にあるPCもミニPCで、ここにサーバーを構築する気にはなれません。無料でWordPressをインストールできるサーバーを見つけるしかないのでしょうか？

そう思って色々と検索していると、Localというとても良いアプリを見つけました。このアプリは、Windows上にローカルなWordPress環境を与えてくれます。WordPressのコマンド（WP-CLI）もシェル画面のプロンプトから使え、PHPCSも利用できます。まさにプラグイン開発にぴったりのアプリです。処理も重くなく、ミニPCでも問題なく稼働します。とても便利なアプリなので、今度紹介文を書いてみたくなりました。

Local

このアプリを使ってプラグインのチェックを行うと、警告やエラーが大量に出ました。

このエラーを一度にAIに頼んで修復してもらいたかったのですが、質問の仕方がうまくいかず、一度の修正でエラーを回避することはできませんでした。

一つずつAIのアドバイスを受けながら修正を加えていきました。ここはやはりそれなりの手間が必要でした。

ワーニングに関しては、ほとんどがWordPress公式のコーディング規約に厳格に準拠（WPCS）させる作業でした。

タブが揃っていないところや、余計な空白が入っているところなど、非常に細かい作業となりました。

PHPCS + WPCSのチェックで警告もエラーもなくなりましたので、再度申請に提出しました。

最初の申請から、AIだけのチェックだけでなく、PHPCS + WPCSのチェックを行うべきでした。

そして合格

そして3日後、プラグインのホスティング申請が無事に承認されました。

これにより、自作プラグインを公開するためのWordPress.orgの公式プラグインディレクトリ内に、専用のリポジトリ（ホスティングスペース）が用意されたことになります。

Congratulations, the plugin hosting request for Sticky Copy Button for Code Blocks has been approved.

Within one (1) hour your account (kasuga) will be granted commit access to your Subversion (SVN) repository.

SVN URL: https://plugins.svn.wordpress.org/stick-copy-button-codeblock

Public URL: https://wordpress.org/plugins/stick-copy-button-codeblock

Once your account access has been activated, you may upload your code using a SVN client of your choice. If you are new to SVN (or the Plugin Directory) make sure to review all the links in this email.

……

この承認を受けて、割り当てられたリポジトリへプラグインの関連ファイルをアップロードする作業に進みます。

ファイルアップロードには定番アプリのTortoiseSVN（トータスSVN）を使います。