WordPressプラグインディレクトリでのSubversionの使用
公開: 2012-07-24これらのステップバイステップの手順に従って、パブリックWordPressプラグインディレクトリにプラグインを追加および更新します。
ビデオからのこれらの重要なステップは以下の通りです：
- プラグイン入門
- WordPress.orgアカウントに登録する
- 新しいプラグインをWordPressプラグインディレクトリに配置するようにリクエストする
- マシンにSVNクライアントをインストールする
- プロジェクトのローカルディレクトリを選択します
- プラグインリクエストの承認メール
- この記事のディレクトリ用語
- 新しいサーバーディレクトリをローカルマシンにプルする
- プラグインの開発を完了します
- 最初のバージョンを一般に公開する
- プロジェクトディレクトリトランクの更新
- サーバー上の新しいバージョンにタグを付ける
- 新しいタグ付きバージョンでローカルプロジェクトディレクトリを更新する
- readme.txtの安定したタグを更新する
- プラグインの新開発
プラグイン入門
アイデアがあっただけでも、バージョン0.1がほぼ完成している場合でも、プラグインの名前と説明が必要です。 プラグインが何をするのかを理解できるように、名前を短くわかりやすいものにします。 「WaxonWaxoffPlugin」は良い名前ではありません。 「ドロップシャドウメーカー」ははるかに優れています。 実際のタイトルに「プラグイン」を追加する必要はありません。
タイトルに沿って、プラグインが提供するメリットを人々に伝える簡単な説明を書く必要があります。 この説明は150文字未満にすることをお勧めします。
WordPress.orgアカウントに登録する
サポートフォーラムなどでのやり取りに使用されるWordPress.orgアカウントをまだお持ちでない場合は、アカウントを取得する必要があります。 https://login.wordpress.org/registerにアクセスするだけです。
新しいプラグインをWordPressプラグインディレクトリに配置するようにリクエストする
互換性のあるライセンスで提供される最も合理的なプラグインは、WordPressプラグインディレクトリにスペースを確保できます。
- http://wordpress.org/extend/plugins/add/にアクセスします
- タイトルと説明を入力してください
（私はあなたがそれを必要とするだろうとあなたに言いました！） - プラグインの準備ができている場合でも、このフォームからプラグインのアップロードをスキップしてください。
プラグインディレクトリのリクエストは実際の人によって処理されるため、時間がかかる場合があります。
マシンにSVNクライアントをインストールする
プラグインディレクトリを操作するには、マシンにSubversionクライアントが必要です。
- Windowsの場合、TortoiseSVNをお勧めします。
- Macの場合、SCPluginは優れたパッケージのようです。
いずれかを選択してインストールしてください。 それについて言うことはあまりありません。
プロジェクトのローカルディレクトリを選択します
Subversionは、プラグインファイルのローカルコピーをWordPressプラグインディレクトリで最新の状態に保ちます。 Subversionで追跡されたすべてのプロジェクトを保持するローカルマシンに1つのディレクトリを作成することをお勧めします。 注意：ローカルマシンにWeb開発環境がある場合は、ローカルWebサーバーのWordPressプラグインディレクトリをプロジェクトディレクトリとして使用しようとしないでください。
たとえば、プラグインフォルダがあるマシンにローカルのWordPressをインストールしている場合：
documents/public_html/devdomain.com/wp-content/plugins/
…そのディレクトリを使用してWordPressプラグインディレクトリプロジェクトを同期できるとは思わないでください。 それはあなたに痛みを引き起こします。
代わりに、次の例のようなディレクトリを作成します。
documents/projects/wp-plugins-public/
各プラグインプロジェクトフォルダは「wp-plugins-public」内に配置されます。 このチュートリアルでは、「content-scheduler」という名前のプラグインフォルダーを使用します。 だから、私はそのようなディレクトリを作りました：
documents/projects/wp-plugins-public/content-scheduler
プラグインリクエストの承認メール
プラグインリクエストが承認されると、SVNリポジトリへのリンクが記載されたメールが届きます。 これは特にその1つのプラグイン用であり、Subversionの同期を続行するために必要です。
この記事のディレクトリ用語
この記事で言及されている非常に多くの異なるディレクトリ、プロジェクト、およびフォルダがあるため、混乱しやすい可能性があります。 このSubversionワークフローで作業するときは、3つの異なる場所について合意しましょう。
- 作業ディレクトリ
これは、変更およびテストしているコードの現在のコピーです。 これは、開発Webサーバーの「/ wp-content /plugins/」フォルダーにある必要があります。 私のマシンでは、たまたま次のようになっています。
documents/public_html/devdomain.com/wp-content/plugins/content-scheduler/ - プロジェクトディレクトリ
これは、SubversionクライアントがWordPressプラグインディレクトリと同期し続けるディレクトリです。 私のマシンでは、これは次のとおりです。
documents/projects/wp-plugins-public/content-scheduler/ - サーバーディレクトリ
これは、WordPressプラグインディレクトリに保存されているプロジェクトを指します。 これは、一般の人々がプラグインを入手できる場所です。 ルートの場所は「SVNリポジトリ」と呼ばれ、プラグインリクエストの承認メールで割り当てられます。 私の例では、これは次のとおりです。
http://plugins.svn.wordpress.org/content-scheduler
新しいサーバーディレクトリをローカルマシンにプルする
プラグインディレクトリの新しいプラグインの場所にファイルを配置していなくても、ディレクトリのそのコピーをマシンにプルダウンする必要があります。 そうすることで、Subversionクライアントが最新のものとそうでないものを認識できるように、舞台裏でいくつかのフラグを設定します。
- プロジェクトディレクトリプラグインフォルダを右クリックします。
- 「SVNチェックアウト」を選択します。
- WordPress SVNリポジトリのURL（承認メールから）を最初のフィールドに入力します。
- プロジェクトディレクトリプラグインフォルダは2番目のフィールドにあるはずです。
そのフォルダを右クリックしてこのプロセスを開始したので、このフィールドはすでに入力されているはずです。 - 「OK」をクリックします
プラグインの開発を完了します
プラグインを開発してテストします。 これには、適切な「readme.txt」ファイルの作成が含まれます。 「readme.txt」ファイルは、プラグインに関する単なるメモではありません。 WordPressプラグインディレクトリは、「readme.txt」ファイルの内容を使用して、プラグインのどのバージョンが最新であると見なされるかを理解し、ディレクトリにプラグインのページの内容を作成します。
- 適切な「readme.txt」ファイルの作成の詳細については、このWordPressのreadme.txtの例を参照してください。
「readme.txt」ファイルの重要な部分は「Stable」タグです。 プラグインを開発している間、このタグを「トランク」のままにしておきます。 公開用のバージョンをリリースすると、正しいバージョン番号で更新されます。
最初のバージョンを一般に公開する
プロジェクトディレクトリトランクの更新
- 作業ディレクトリの内容をプロジェクトディレクトリの「トランク」フォルダにコピーします。
私の場合、プラグインの内容全体を作業ディレクトリからコピーしています。
/documents/public_html/devdomain.com/wp-content/plugins/content-scheduler/
私のプロジェクトディレクトリへ：
/documents/projects/wp-plugins-public/content-scheduler/ - プロジェクトディレクトリの「content-scheduler」プラグインフォルダを右クリックし、「SVNCommit」を選択します。
- 必要に応じて、コミットのコメントを入力します。
- 新規と見なされ、サーバーにコピーされるファイルのリストを確認します。 このリストが正確に見える場合は、[OK]をクリックすると、ファイルがwordpress.orgのサーバーディレクトリにコピーされます。
サーバー上の新しいバージョンにタグを付ける
「トランク」内のファイルを更新しましたが、これは一般の人がダウンロードする必要があるものではありません。 「トランク」のコピーを作成するには、「タグ付け」を使用する必要があります。 このコピーはこれ以上変更されることはなく、一般に公開されます。 この例では、バージョン1.0を作成しましょう。
- プロジェクトディレクトリの「trunk」フォルダを右クリックし、「Branch/Tag」を選択します。
私にとって、これは次のとおりです。
/documents/projects/wp-plugins-public/content-scheduler/trunk/ - 「ToURL」の場所フィールドは「/trunk」で終わります。 バージョン1.0を作成するには、これを「/tags/1.0」に変更する必要があります。
- 必要に応じて、このタグ付け操作に関するメモを追加できます。
- 「OK」をクリックし、「このブランチに変更することが重要です…」に関するメッセージを無視します。
新しいタグ付きバージョンでローカルプロジェクトディレクトリを更新する
「/tags/1.0」ディレクトリにプロジェクトファイルの新しいコピーを作成するようにサーバーに指示しました。 次に、ローカルプロジェクトディレクトリをその新しいタグで最新の状態にする必要があります。
このプロセスは奇妙に思えるかもしれません。 ローカルの「/tags/1.0」ディレクトリに自分のコピーを作成できないのはなぜかと思うかもしれません。 これを行うと、サーバーディレクトリとプロジェクトディレクトリが乱雑になり、何が更新され、何が更新されないかについて混乱する可能性があります。
- プロジェクトディレクトリをもう一度右クリックし、「SVNアップデート」を選択します。
これにより、サーバーディレクトリからローカルプロジェクトディレクトリに変更がプルされます。 この場合、変更はファイルの「/tags/1.0」コピーの追加です。
readme.txtの安定したタグを更新しています
一般の人がプラグインを使用できるように、適切なファイルがすべて用意されています。 ただし、一般の人が使用するタグ付きバージョンをプラグインディレクトリに通知する必要があります。
- ローカルプロジェクトディレクトリの「trunk」フォルダにある「readme.txt」ファイルを編集します。
私にとって、これは次のとおりです。
/documents/projects/wp-plugins-public/content/scheduler/trunk/readme.txt - 「Stabletag」をリリースバージョン「1.0」に変更します
- ファイルを保存します
- 更新した「readme.txt」ファイルを右クリックして、「SVNCommit」を選択します。
それでおしまい！ 15分ほどで：
- WordPressプラグインディレクトリはプロジェクトリストを更新します
- 「1.0」は安定したタグとして表示されます
- 「/tags/1.0/readme.txt」の情報は、プロジェクトのページに入力するために使用されます。
プラグインの新開発
ほとんどの場合、プラグインを改善し、それらを公開する必要があります。 これがどのように機能するかです。
- 作業ディレクトリのプラグインに変更を加えます。
これらの変更には、変更ログエントリなど、必要に応じてreadme.txtファイルへの変更を含める必要があります。 - 作業ディレクトリからローカルプロジェクトディレクトリに変更をコピーします。
- readme.txtファイルに現在のパブリックバージョンの正しい「stable」タグが含まれていることを確認してください。
- プロジェクトディレクトリを右クリックし、「SVN Commit」を選択して、新しいトランクの変更をサーバーディレクトリに取得します。
- プロジェクトディレクトリの「trunk」ディレクトリを右クリックし、「Branch / Tag」を選択して、リリース用の新しいバージョンタグを作成します。 （「リポジトリ内にコピーを作成元：」が「作業コピー」に設定されていることを確認してください。）
- プロジェクトディレクトリを右クリックし、「SVN Update」を選択して、サーバーディレクトリからタグの変更をプルダウンします。
- プロジェクトディレクトリの「/trunk/readme.txt」ファイルの安定したタグを、作成した新しいリリースタグと一致するように更新します。
- プロジェクトディレクトリを右クリックし（はい、もう一度）、「SVN Commit」を選択して、更新されたreadme.txtファイルをサーバーに取得します。
ふぅ。 それで全部です！
タグ：