そんなにGeekじゃないエンジニアブログ

[WordPressプラグイン開発]公式ディレクトリに公開してリリース!ホスティング申請の流れ

calendar

こんにちは。でんすけ(@notgeek_densuke)です。

これまで、WordPressのプラグイン開発、スニペットの紹介や、多言語化の対応について紹介してきました。

WordPressプラグイン開発!スニペットから始めるカンタン開発・処理のフック~アンインストール時の処理まで

[WordPressプラグイン開発]翻訳ファイル.poファイル、.moファイルで多言語化したプラグインを作ろう

で、今回は、作ったプラグインを公式にリリースしよう!という話です。

スポンサーリンク

WordPress.org公式にリリースする、とは?

WordPressのプラグインのリリース方法は主に2つ。

・WordPress.orgの公式ディレクトリに登録する
・zipにまとめて適当なサーバにアップロードしておく

です。

zipにしてサーバに上げる方が簡単ではありますが、ユーザーとしては手間になります。zipをダウンロードして、解凍して、FTPでプラグインフォルダに配置する、という手間。

反面、WordPress.orgの公式ディレクトリに登録すれば、
WordPressのプラグイン検索から探せるようになりますし、
「インストール」ボタンひとつでインストールできるようになります。

プラグイン製作者側が作らなければならないファイルや、守るべきルールが少し増えるのですが、せっかく作ったので広く使ってもらいたい!ということであれば、公式にリリースしちゃいましょう。
慣れれば意外と簡単。

WordPressプラグイン公式リリースの流れ

リリースの流れは、こちらの公式ページにも書いてあります。

ざっくりいうと

・まずはプラグインを作成する
 ↓
・WordPress.orgのアカウントを作る
 ↓
・readmeをつくる
 ↓
・プラグインレビュー申請
 ↓
・assetsファイルを作る
 ↓
・svnでプラグインをコミット

という感じです。

プラグイン本体は制作できたとして、そのあとの流れを見ていきたいと思います。

WordPress.orgのアカウントを作る

まずは、WordPress.orgのアカウントを作るところから。

こちらからアカウントを新規作成できます。
既にアカウントがある人は、この手順は飛ばしてください。

ちなみに、WordPressの公式ページには
WordPress.orgと、WordPress.comの2種類があります。

WordPress.comの方は、ブログの中身を管理したりするサービス。
プラグインのJetpackなどと連携して、ブログ記事を管理したり、アクセス統計を見たりできます。
あるいは、他の人のブログを購読して更新通知してもらうなど。

対して、今回使うのはWordPress.orgの方。
こちらは、どちらかというとWorpPress開発者が使うサービス。
テーマやプラグインが管理されており、開発したモノをアプロードしたり、開発のためのドキュメントが載っていたりします。

WordPress.orgとWordPress.comは別々のサービスなので、間違えないように注意です。
今回必要なのはWordPress.orgのアカウントです。

readme.txtをつくる

アカウントが作成できたら、今度はreadme.txtを作ります。

readme.txtは、プラグインに必須のファイルです。これがないと審査も受けさせてもらえません。始めは戸惑うかもしれませんが、きちんと作っておきましょう。

ちなみに、公式の標準書式はこちらにあります。

基本は英語です。全世界に公開されるので。
もう完全に日本人だけに向けて作る!という場合であれば日本語でもいいみたいですが、せっかく公開するなら基本は英語でやりましょう。

readme.txtをざっくり日本語訳してみました。

=== Plugin Name <!-- プラグインの名前 --> ===
Contributors: 
<!-- 制作者名。wordpress.org のuserIDを使いましょう -->

Donate link: 
<!-- 寄付をもらいたい場合はこちらにリンクを貼りましょう -->

Tags: 
<!-- タグ。自由に。 -->

Requires at least: 4.6 
<!-- プラグインが動くために必要なWordPressのバージョン -->

Tested up to: 4.7 
<!-- テストしたときのWordPressのバージョン -->

Stable tag: 4.3 
<!-- プラグインのバージョン -->

Requires PHP: 5.2.4 
<!-- プラグインが動くために必要なPHPのバージョン -->

License: GPLv2 or later
<!-- ライセンス。基本はGPLv2のままでOKのはず。 -->

License URI: https://www.gnu.org/licenses/gpl-2.0.html
<!-- ライセンスURL。GPLv2ならそのままで。 -->

Here is a short description of the plugin.  This should be no more than 150 characters.  No markup here.
<!-- プラグインの説明。150字以内で短くどうぞ。マークアップはしないで。 -->

== Description <!-- プラグインの説明 --> ==

This is the long description.  No limit, and you can use Markdown (as well as in the following sections).
<!-- プラグインの説明。文字数制限なし。マークダウンできます(マークダウンは後で説明します) -->

For backwards compatibility, if this section is missing, the full length of the short description will be used, and
Markdown parsed.
<!-- 下位互換のために、この項目がない場合はさっきの短い説明が使われます。マークダウンもされます。 -->

A few notes about the sections above:
<!-- 上のセクションの説明をちょっとばかり。 -->

*   "Contributors" is a comma separated list of wordpress.org usernames
*   "Tags" is a comma separated list of tags that apply to the plugin
*   "Requires at least" is the lowest version that the plugin will work on
*   "Tested up to" is the highest version that you've *successfully used to test the plugin*. Note that it might work on
higher versions... this is just the highest one you've verified.
*   Stable tag should indicate the Subversion "tag" of the latest stable version, or "trunk," if you use `/trunk/` for
stable.
<!-- 
・制作者名、複数の場合はwordpress.org のユーザーネームを、カンマ区切りで書いてね。
・タグもカンマ区切りで。
・"Requires at least" はプラグインが動くために必要最低限のWordPressバージョンだよ。
・"Tested up to" はプラグインのテストが成功した時点の最新WordPressバージョンを書いてね。 より最新のバージョンでも動くかもしれないけど、あくまでテスト成功時のバージョンです。
・"Stable tag"は、最新の安定バージョンのSubversionタグを書いてね。安定版として trunk を使う場合は"trunk"と書いてね。
-->

    Note that the `readme.txt` of the stable tag is the one that is considered the defining one for the plugin, so
if the `/trunk/readme.txt` file says that the stable tag is `4.3`, then it is `/tags/4.3/readme.txt` that'll be used
for displaying information about the plugin.  In this situation, the only thing considered from the trunk `readme.txt`
is the stable tag pointer.  Thus, if you develop in trunk, you can update the trunk `readme.txt` to reflect changes in
your in-development version, without having that information incorrectly disclosed about the current stable version
that lacks those changes -- as long as the trunk's `readme.txt` points to the correct stable tag.

    If no stable tag is provided, it is assumed that trunk is stable, but you should specify "trunk" if that's where
you put the stable version, in order to eliminate any doubt.

<!-- 
"readme.txt"のstable tagは、プラグインの定義であることに注意してください。
/trunk/readme.txtファイルのstable tagが"4.3"と書いてあれば、/tags/4.3/readme.txtがプラグインに関する情報を表示するために使われます。
このような場合、trunkのreadme.txtファイルから考慮されるのはstable tagだけです。
したがって、トランクで開発をする場合、トランクのreadme.txtを更新して開発中の情報を反映することができます。
トランクのreadme.txtが正しい安定したタグを指している限り、開発内容が間違って反映されて開示されることはありません。

もしstable tagがなければ、trunkが安定バージョンとみなされます。
ただし、間違いが起こらないよう"trunk"を定義するべきです。
-->

== Installation <!-- インストール方法 --> ==

This section describes how to install the plugin and get it working.
<!-- このセクションではプラグインのインストール方法を記載します -->

e.g.

1. Upload the plugin files to the `/wp-content/plugins/plugin-name` directory, or install the plugin through the WordPress plugins screen directly.
1. Activate the plugin through the 'Plugins' screen in WordPress
1. Use the Settings->Plugin Name screen to configure the plugin
1. (Make your instructions match the desired user flow for activating and installing your plugin. Include any steps that might be needed for explanatory purposes)


== Frequently Asked Questions <!-- FAQ --> ==

= A question that someone might have =

An answer to that question.

= What about foo bar? =

Answer to foo bar dilemma.

== Screenshots <!-- スクリーンショット -->  ==

1. This screen shot description corresponds to screenshot-1.(png|jpg|jpeg|gif). Note that the screenshot is taken from
the /assets directory or the directory that contains the stable readme.txt (tags or trunk). Screenshots in the /assets
directory take precedence. For example, `/assets/screenshot-1.png` would win over `/tags/4.3/screenshot-1.png`
(or jpg, jpeg, gif).
2. This is the second screen shot

<!-- 
1. この説明は"screenshot-1.(png|jpg|jpeg|gif)"というファイルに対応します。
安定したreadme.txtのあるディレクトリ、もしくは/assetsディレクトリの中からスクリーンショットのファイルを読み込みます。
/assets内のスクリーンショットが優先されます。
例えば、"/assets/screenshot-1.png" が "/tags/4.3/screenshot-1.png"よりも優先されます。
2. これは2枚目のスクリーンショットです
 -->

== Changelog <!-- 変更履歴 --> ==

= 1.0 =
* A change since the previous version.
* Another change.

= 0.5 =
* List versions from most recent at top to oldest at bottom.

<!-- 古いバージョンを下に、新しいバージョンを上に書きます --> 

== Upgrade Notice ==

= 1.0 =
Upgrade notices describe the reason a user should upgrade.  No more than 300 characters.

= 0.5 =
This version fixes a security related bug.  Upgrade immediately.

== Arbitrary section <!-- 任意のセクション --> ==

You may provide arbitrary sections, in the same format as the ones above.  This may be of use for extremely complicated
plugins where more information needs to be conveyed that doesn't fit into the categories of "description" or
"installation."  Arbitrary sections will be shown below the built-in sections outlined above.

== A brief Markdown Example <!-- マークダウンの記述例 -->  ==

Ordered list:

1. Some feature
1. Another feature
1. Something else about the plugin

Unordered list:

* something
* something else
* third thing

Here's a link to [WordPress](http://wordpress.org/ "Your favorite software") and one to [Markdown's Syntax Documentation][markdown syntax].
Titles are optional, naturally.

[markdown syntax]: http://daringfireball.net/projects/markdown/syntax
            "Markdown is what the parser uses to process much of the readme file"

Markdown uses email style notation for blockquotes and I've been told:
> Asterisks for *emphasis*. Double it up  for **strong**.

`<?php code(); // goes in backticks ?>`

ちょっと長く感じますが・・・
Descriptionまでの項目を埋めれば、だいたい必要最小限っぽいです。

 

readme.txtの作成例

例として、僕が作ったプラグインのreadmeを載せておきます。

=== Control panel for SoundCloud(SoundCloud再生パネル) ===
Contributors: densuke
Tags: SoundCloud, player
Donate link: https://www.amazon.co.jp/hz/wishlist/ls/395GOI706MZLO
Requires at least: 4.9
Tested up to: 4.9
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Add control panel for SoundCloud embed widget on your website.

== Description ==
Add control panel for SoundCloud embed widget on your website.

Play, Pause and jump to next/prev widget.

Control panel position on screen can be changed by setting, upper/bottom/left/right.
Use the 'Tools'->'Control panel for SoundCloud' screen to configure this plugin.

== Installation ==

1. Upload the plugin files to the `/wp-content/plugins/speech-balloon-maker` directory, or install the plugin through the WordPress plugins screen directly.
2. Activate the plugin through the 'Plugins' screen in WordPress
3. Use the 'Tools'->'Control panel for SoundCloud' screen to configure the plugin

== Changelog ==

= 1.0 =
* New release.

== Upgrade Notice ==

= 1.0 =
* New release.

== Screenshots ==

プラグインの「詳細を表示」で表示される画面とは、こんな感じで対応しています。

プラグインレビュー申請をする!

readme.txtを作ったら、プラグインのディレクトリトップに置きましょう。
で、プラグインのディレクトリをzipで固めます。

公式のレビュー申請にて、zipファイルを送信すれば申請完了です。

readme.txtが無かったり、readme.txtの内容に不備があったりするとその場でエラーが出てきます。

問題なければ、WordPressの中の人が、中身を確認してくれます。

数日待つと、こんなメールが返ってきます。
(今までの実績では、早ければ1日、遅くても2、3日でした)

(plugin) has been approved!というタイトルと共に、svnのリポジトリが連絡されてきます。
このリポジトリにプラグインをコミットすればリリース完了です!

assetsをつくる

審査を待っている間にでも、assetsファイルを作っておくと良いでしょう。
アイコン画像、ヘッダー画像などのことです。

必須ではないんですが、あった方が見栄えがよくなります。

詳細は公式のページにも載っていますが、

・banner-772×250.(jpg|png)
・banner-1544×500.(jpg|png)
・icon-128×128.(png|jpg)
・icon-256×256.(png|jpg)

というファイル名の画像を用意しておけば、アイコン、ヘッダー画像として使ってもらえます。

ヘッダー画像(banner-*)はこんな感じで。

アイコン画像(icon-*)はこんな感じでそれぞれ使われます。

プラグイン審査時にはなくても通るので、待ち時間に作ればいいかな、という感じです。

SVNにコミットする!

で、審査が通れば、いよいよリリースの時。
メールで通知されたSVNのリポジトリにコミットしましょう!

WindowsであればTortoiseSVNが便利です。

まずは、通知されたSVNのリポジトリをチェックアウト!
すると、こんなディレクトリ構成になっているかと。

assetsに、アイコンやバナーの画像を格納、
trunkにソース一式をそのまま格納します。

tagディレクトリには、バージョン番号のディレクトリを作って、その中にそのバージョンのソースを入れます
「1.0」ディレクトリを作ってソースを入れる、みたいな感じ。

格納が終わったら、SVNの追加を忘れないようにしつつ、コミット

これでリリースが完了です。

余談:新しすぎるPHPに注意

WordPressのSVNでは、コミットする際にPHPのエラーチェックをしてもらえます。
エラーがあれば、コミットが拒否されます。

このとき、少し古いバージョンのPHPでチェックをされる、ように見受けられます。
実際、新しいバージョンでの書き方をしたPHPファイルをコミットしようとするとエラーで拒否されたことがあります。

こちらの記事にまとめました。

PHPは動作環境のバージョンを確認すべし!private constが使えなくてWordPressプラグインのsvnコミットでエラーが出た話

同様のエラーなどで引っ掛かった場合は、参考にしてみてください。

リリースされたか確認してみる

では、ちゃんとリリースされたかどうか確認してみましょう。
WordPressの管理画面から、プラグインの検索ができるので、プラグイン名で検索してみてください。

こんな感じで出てくるはず!フォー!

まとめ

ということで、プラグインを公式リリースする手順でした。

・まずはプラグインを作成する
 ↓
・WordPress.orgのアカウントを作る
 ↓
・readmeをつくる
 ↓
・プラグインレビュー申請
 ↓
・assetsファイルを作る
 ↓
・svnでプラグインをコミット

という感じです。
慣れればそんなに難しくない!
レビューを数日待つのがちょっと長いかなーぐらいです。
お試しあれ。

それではまたー。

この記事をシェアする

コメント

コメントはありません。

down コメントを残す




CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください