目次
WordPressのプラグインを作ってみた
ちゃんと自分のブログを書き続けなくちゃなぁと思いながら、WordPressの管理画面を整理していたのですが、そこで、こんなプラグイン欲しいなぁと思ってプラグイン検索をしてみたのですが、見つからず、、そこで自分でWordPressのプラグインを作ってみました。
作ってみた感想としては、なかなか大変でした、、
まず、かなり久しぶりにPHPを使ったということと、JS側もReactベースで作られているということで慣れていないので、かなり苦戦しました、、
作ったものは、記事作成時に使用するブロック部分のプラグインで、右側のブロックのところで、AmazonのAPIから商品検索と選択が出来るというものです。
環境構築
まず、環境を作るのになかなか苦戦しました。
というのも、いつもの如く、色々な情報をネットで見ているとnode系のversionが記載されておらず、大体ここで苦戦するというものです。案の定、今回も色々な情報を見て、入れて試してみては駄目というのを何回か繰り返しました。。
結局、今回使ったのは、以下の環境です。
$ php --version 7.4.23 $ node --version v14.17.6 $ npm --version 6.14.15
WordPressのcliでプラグインを作る?
色々なドキュメントを読んでいると、WordPressのcliを使ってプラグインのベースを作ることが出来るということが分かりました。
ただし、これで作られるのは、超ベースのベースです。
ですので、今回自分が作りたいものに対して、ここからは大変過ぎるので、現在のWordPressの記事作成基盤に使われているエディター、gutenbergのベースを使用して作ることにしました。
それがこちらのコマンドで、これを叩くとgutenbergのブロック開発に必要なものが全てダウンロード出来ます。
npx @wordpress/create-block [プロジェクト名]
nodeのモジュールをインストールする
gutenbergのブロック開発では、jsベースで開発を行うので、上記でダウンロードしたファイル内のpackage.jsonのあるディレクトリまで移動し、npm install
を済ませておきます。
中には、webpack、Babel、Sassに必要なものが全て含まれていますので、インストールが終わったら、npm run start
で、ファイルの変更を監視しつつ、開発を進めることが出来ます。
ここまで出来たら、一旦、動くようになります。プラグインを有効化して、記事の編集画面で確認してみましょう!
編集するファイルを理解する
いよいよ、実際に開発を行っていくのですが、ここで重要なのが各ファイルの役割です。少し、各ファイルがどのような役割かを理解しておきましょう。
npxで作成したプロジェクトの中身を見ると、以下のような構成になっていることが分かります。
プロジェクト名 ├ build/ ├ node_modules/ ├ src/ ├ プロジェクト.php ├ block.json ├ package.json └ readme.txt
node_modules
に関しては、上記nodeモジュールのところでインストールしたファイルが入っているだけで、触ることはありません。
build
に関しても、src
内のファイルをコンパイルしたものが出力されるところなので、触る必要はありません。
package.json
に関しても、追加したいモジュールがない場合は、特に触る必要はありません。
ということで、メインの書き換えが必要になるのは、その2つのディレクトリとpackage.json以外になります。
プロジェクト.php
これがメインのファイルになります。
自分の場合、この中で主にやっていることは以下の通りです。
メニュー画面の呼び出し
まず、メニュー画面の呼び出しについてですが、プラグインのメニュー画面を追加したい場合は、PHPでの作成となります。こちらは、他のプラグインのファイルを色々と参考にすることで、割と簡単に作ることが出来るのではないかと思います。
記事編集画面に追加するブロックのjs指定
こちらは作成されたファイル内にもデフォルトで入っていると思いますが、wp_enqueue_script
にキーを指定しつつ、edit.js
を指定することで、記事編集画面で、このjsが呼び出されます。
wp_enqueue_script('edit_key', plugin_dir_url(__FILE__) . 'src/edit.js');
問題なのが、この後で、edit.js
にPHPファイル側で定義したものや、メニュー画面で保存したデータを送りたい場合があります。そこで、上記のwp_enqueue_script
で定義したキーを使用し、wp_localize_script
という関数を使ってデータを送ります。
wp_localize_script('edit_key', 'init_data', [ 'nonce' => wp_create_nonce('nonce_key'), 'db_data' => get_option(self::PLUGIN_DB_PREFIX . "db_data") ]);
上記は一例ですが、edit_key
というキーを揃えます。そして、init_data
は、js側の受け取る際のキーになります。
API作成
プラグインでは、記事編集画面などからAjaxなどで呼び出すことの出来るAPIを作成することが出来ます。
方法は、知ってしまえば簡単で、wp_ajax_
というprefixを付けたactionを作成することで、以下のようなURLが有効になります。
/wp-admin/admin-ajax.php?action=sample <- wp_ajax_sampleとした場合
具体的なactionの指定方法は、以下のようにadd_actionという関数を使用します。
add_action('wp_ajax_sample', [$this, 'sample_func']); function sample_func() { check_ajax_referer('sample', 'security'); }
あとは、使用したいAPIをfunction内に作るだけです。
ただし、外部からのアクセスなど出来ないようにセキュリティには気を付けたいところです。
block.json
続いて重要なファイルが、block.jsonです。正直、最初はこのファイルがそれ程重要なファイルだとは思っていませんでした。しかし、ここで定義するattributesが、記事編集画面での保存と、実際に表側で表示する際に、とても大切になります。
まずは、こちらのドキュメントを確認して、attributesを定義していくことが必要です。
簡単に説明してしまうと、このattributesは、テーブルのモデルのようなものです。ここで定義したキーやタイプ、セレクタに沿っていないと正しく値が保存出来ないし、表示もされません。
最初、これを理解するのに時間が掛かりました。WordPressのブロックのデータというのは、色々なタイプのものがあるので、メタデータのような形でDBに保存されていくのですね。そこで、保存されたデータを元に戻していく際に、これらが必要になるようです。また、セレクタがあることで、どこのポジションに、どの値が入るということも、後々html側を書いていくことで分かっていきます。
src/index.js
記事編集画面と、表側の画面でブロック表示を行うのに必要なファイルを呼んでいます。
また、記事編集画面でアイコン表示したい場合には、このファイルで指定します。
src/edit.js
こちらが記事編集画面のブロックをコントロールするメインのファイルとなります。
block.jsonで定義した値を使用して、ブロックの編集部分を作っていきます。この部分は、最初はコツが必要かと思うので、既存のgutenbergのコードを参考にするのが一番の好材料かと思います。
こちらで、デフォルトで入っているプラグインのコードは全て見ることが出来るので、とても参考になります。
src/save.js
表側の画面でのブロック表示を行うファイルです。
基本的には、edit.jsのブロック部分に近いものになるかと思います。block.jsonで定義した値を使用して、js内でhtmlを書いて返すだけです。
readme.txt
WordPressのプラグインで注意が必要なのは、GPLライセンスでなくてはならないということです。GPLライセンスということを、readme.txtで明記しておく必要があります。
プラグインのホスティング申請
実際に動くようなったら、申請をしていましょう。
プラグインのホスティング申請はWordPress.orgに登録して、こちらから申請することが出来ます。大体、申請してから一週間くらいレビューに掛かりました。
申請する際はzipファイルにして、送らなければいけないのですが、この時に不要なファイルは取り除きましょう。主に不要なファイルは以下の通りですが、node_modulesは重いので、除かないとアップロード出来ないかと思います。
node_modules/ src/ package.json .babelrc
申請したが、レビューに落ちる
申請後は、レビューがあるのですが、2度程落ちました。。
メインの理由はreadme.txtが正しくないというもの。validatorを使ってチェックすることで、通るというのですが、自分の場合は、third partyのAPIを呼んでいた為、そのことや、third party側のプライバシーポリシーなどを記載しないと通りませんでした。
申請が通ったらsvnのrepositoryに上げる
申請が通ると、wordpress側からsvnのrepositoryのURLが送られてきます。↓のような感じの。
https://plugins.svn.wordpress.org/amzft
svnなんて久しぶりに使うなぁ。。
repositoryをcheckoutする
まずは、貰ったURLからcheckoutしてきます。
$ svn checkout http://plugins.svn.wordpress.org/amzft
ID/PWを求められるので、登録時のものを入力すると、以下のディレクトリが落ちてきます。
/assets /tags /trunk
trunk直下にプラグインの中身を置く
trunk直下に申請時に送ったプラグインの中身を置いて、コミットします。
svn commit -m "first commit"
これで、一旦はプラグインがpublicなrepositoryに置かれて、完了となります!プラグインの検索結果にも、暫くすると表示されるようになります。
アイコンやプラグインページの画像を置く
一旦、プラグインは使用できるようにはなりましたが、このままでは検索結果などは、デフォルトのアイコンのままです。
そこで、checkoutしてきた中にある、assetsにアイコンやプラグインページの画像を置いてアップロードすることで、表示されるようになります。
具体的なファイル名やサイズは以下の通りです。
icon-128×128.png icon-256×256.png banner-772×250.png banner-1544x500.png
試してないですが、svgファイルも指定出来るようです。svgの場合は、icon.svg、banner.svgで良さそう。
また、スクリーンショットを設定したい場合も、こちらにscreenshot-1.jpgなどとして置くことで、表示されるようになります。
プラグインをversioningする
プラグインを更新したい時は、checkoutしてきた中にある、tagsを使用します。
まずは、最初のtrunkのversion1.0.0のものをtagsにコピーしておきます。
svn cp trunk tags/1.0.0
続いて、trunk内のファイルを修正していきます。phpファイルや、readme.txtを書き換えることを忘れないように!
そして、修正し終わったら1.0.1などのversionをtagsに再度切ります。
svn cp trunk tags/1.0.1
そして、コミットをしたら、新しいversionのプラグインが表示されるようになります。
今回作ったもの
そして今回作ったものですが、Amazonの商品を記事の編集画面で、検索して、簡単に挿入出来るというものです。もし良かったら使ってみてください。
追加後は、↓のような感じ。
使用方法を固定ページに作成しました。
最後に
気軽に始めたのですが、イメージしたものを作るまで結構大変でした。。また、久しぶりにPHPも触りましたが、やっぱりPythonの方が好きだなぁと改めて思いました。
メニュー画面の呼び出し
記事編集画面に追加するブロックのjs指定。また、PHP側で定義、DBから取得した値のjsへの情報受け渡し
記事編集画面のブロックから呼び出す為のAPI作成