YOKOTA’s diary

最近はドローン関連が多いですが…ECやデータ解析、3Dプリンタなども。

初めてのgit-flowの使い方

git flowを初めて使った時のお作法や主なコマンド等などの共有用にメモ。

基本前提：gitのローカルリポジトリとリモートリポジトリ

svnはひとつのリモートリポジトリにcommit, merge, updateなどを行うことが多いのに対して、gitはリモートリポジトリから取得したソースをローカルリポジトリと作業ファイルに取得してまずはローカルリポジトリにコミットし、後でまとめてリモートリポジトリにプッシュする。

git flow

git flowとはあるgit運用方法をやりやすくするプラグイン。
developブランチを作成して、新規機能はfeatureごとに作成して後でdevelopにマージし、リリースタイミングでmasterブランチを利用してリリースする。

詳細は下記ご参照。
git-flow cheatsheet

名前・登場人物

  • origin：リポジトリ
  • branch：ブランチ
  • master：メインブランチ
  • develop：開発ブランチ
  • feature：新機能用ブランチ

私はこのfeatureが初めてだった（元々SVNユーザ）のですが、どういう単位で使われるか（使うことにしたか）というと、ticket単位≒機能単位でバシバシfeatureきってタスクを消化するという感じです。

origin, masterがデフォルト

origin, masterはデフォルトのリモートリポジトリとメインブランチ。
そのため、通常コマンドでは省略されている。

git pull // == git pull origin master  
git config --list //masterなどがどこを指しているか確認、変更が可能

最初にリポジトリを設定する際に利用するコマンド

リポジトリをチェックアウトする

git clone http://hohohohogeee.git

ブランチをすべて取得する

git pull --all

git flowを初期化する

git flow init

ここでmasterやdevelop、featureといった名前を決める。デフォルトを利用。

新規機能を作りたいのでfeatureする

「display-pankuzu」の新規機能を開発したい

git flow feature start display-pankuzu

ここでリモートリポジトリとローカルリポジトリに差分があると、正しくfeatureを切れない場合があるため、git pull origin develop （featureはdevelopブランチを元にするので）などでリポジトリを綺麗にしてあげる。

日々の作業で利用するコマンド

現在どのブランチにいるか（どのブランチで作業するのか）を確認する

git branch

develop
* feature/display-pankuzu
master

ブランチを切り替えたい場合

git checkout <branch>

現在の修正状況などを確認する

git status

リポジトリにファイルを追加したり、ファイルを修正、削除した場合などの変更ファイルが確認可能

コミット非対称のファイルを無視させる

開発に便利なプラグインやメモファイルなどがリポジトリ内に作成されている場合に、.gitignoreファイルを作成しファイル名・ディレクトリ名を記載することで変更内容として無視させることができる

vi [リポジトリホーム]/.gitignore
a.txt

↑これでa.txtは修正の対象から除外

変更内容の具体的な修正内容を確認する

git diff

一部のファイルを間違えて修正していたので元々のファイル状態に戻す

functions.phpを本に戻す例

git checkout HEAD functions.php

リポジトリの内容を更新する

git pull origin develop

あくまで更新するのはブランチなので、featureではなくdevelopを指定する。 つまり、複数のfeatureを切って作業してもdevelopは同じ。 なるべくfeatureは1つずつ終わらせる（終わるとdevelopにマージされる）のが良いのかな

ローカルリポジトリにコミットする

対象ファイルをaddしてコミット

git add --all
git commit -m "message"

git statusでadd/commit状況は確認することが可能

リモートリポジトリにプッシュする

git push

マージなどは随時。

featureが終了したら

git flow feature finish display-pankuzu

で終わり！

WordPressプラグイン開発に参考となりそうな書籍3冊

プラグイン開発があるので改めて書籍でWordPressプラグイン周りを確認。

どのようなプラグインがもてはやされていて、どのようなお作法や注意点があるのかなどひと通りの確認をしたいと思い以下3冊を選択。

「プロが選ぶ WordPress優良プラグイン事典」ササッとどのようなプラグインがあるかを眺めてから、「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル」でガッツリとプラグイン開発のイロハをしり、比較や抜け漏れ確認のために、「WordPressによるWebアプリケーション開発」のオライリー本で締めるという想定でした。が、、

プロが選ぶ WordPress優良プラグイン事典

プロが選ぶ WordPress優良プラグイン事典

プロが選ぶ WordPress優良プラグイン事典

2013年の本ですが、知らなかったプラグインも多く有用な物があり参考になりました。
今回は開発目線で色々見たかったので下記ソースを今後参考にさせていただこうと思います。

まずは、「シンプル」「自動」「テンプレート変数埋込」「一括アップロード」「カスタムフィールド」を中心にチェックしたいと思います。

AddQuicktag

https://github.com/bueltge/AddQuicktag functionにざっと書いてしまいそうな内容をGUIのわかりやすい管理画面にしているとてもシンプルなプラグイン。 エクスポート・インポートもあり、とっかかりによいのかと思いました。

Broken Link Checker

72時間などの自動チェックのタイミングがあるので監視方法の参考に。 にしても超高機能だな、これ…

CSV Importer

記事の一括アップロード投稿

Advanced Custom Field

カスタムフィールドのプラグイン

他にもプラグイン開発の参考になりそうなものがたくさんありました。（実際に使えそうなものももちろん）

サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル

サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル

サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル

WordPressプラグイン開発のイロハを教えていただきたくチョイスした一冊。
プラグインとは？からビジネスモデルなども含め幅広く取り揃えてありましたが、私が気になるのは開発時のお作法や環境やツール、保守観点での注意事項などです。

WordPressプラグイン開発の基本となるフックという仕組み

htmlは構造的に上から下に順番に読んでいきますが、WordPressではその至るところで「フック」というポイントが用意されていて、このフックのある場所に機能を追加したり、あるいは、機能を自分の定義する関数に置き換えてあげることが可能です。このアクションフックとフィルターフックという仕組みがプラグイン開発の肝であり、フックについて実例を元にわかりやすく説明されていました。

VCCWでのWordPressプラグイン開発環境構築

本書ではvagrantでLAMP環境を簡単に構築する手段として、著者が手がけるVCCWを利用されていました。超簡単に環境構築できてとても便利でした。

一点困ったのは、default.ymlをコピーしてVagrantFileと同じフォルダにsite.ymlを作成し、langをjaに変えたところ正しく起動せず。。一旦vagrant destroyしてからvagrant upし直すとか色々情報は散らばっているもののうまくいかず管理画面から直接言語変更しました。

==> cv.dev: STDERR: Error: The requested locale (ja) was not found.
==> cv.dev: ---- End output of "bash" "/tmp/chef-script20150727-18885-j56vvo" ----
==> cv.dev: Ran "bash" "/tmp/chef-script20150727-18885-j56vvo" returned 1
==> cv.dev: [2015-07-27T07:44:58+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Chef never successfully completed! Any errors should be visible in the
output above. Please fix your recipes so that they properly complete.

WordPressプラグインのお作法や注意点

  • プラグイン名に同名の物がないようにする
  • 関数や変数名に同名の物がないようにプレフィックスをつける
  • プラグイン名をハイフンでつないでプラグインのディレクトリにする
  • プラグインの場合はプラグインヘッダに「Plugin Name:」を記載する必要あり（コロンとの間にスペースがあるとNG）★例
  • Readme.txtは書きましょう（公開するなら基本英語）
  • PHP, html, CSS, javascript、それぞれのコーディングスタンダードがある [PHP]インデントはタブ、縦位置調整はスペース。if文中と同行に開始括弧{。括弧()の間や演算子の前後には全てスペースを入れる（配列は例外） [PHP]関数名は小文字でヘビ型、クラス名の始まりは大文字、ファイル名は小文字ハイフンつなぎ。 [HTML]W3CのValidationに則る。インデントはタブ。 [CSS]インデントはタブ。セレクタは1行ずつ記載。属性値は小文字、ハイフンつなぎ。 [js]インデントはタブ。JSHintを通してほしい。オブジェクトは短いなら1行で、長いなら行ごとに要素記載。 [js]配列や関数の括弧の間にはスペース。セミコロンは必ず付ける。ifなどのブロックはPHPと同じ ** [js]チェーンメソッドは行ごと

WordPressによるWebアプリケーション開発

WordPressによるWebアプリケーション開発

WordPressによるWebアプリケーション開発

頭に入りにくくちょっと小難しい…。
ある程度、WordPressを用いた開発を行った経験がある方が読むほうが良いと思われます。
が、私が気になっていたのは、「5章のプラガブルなモジュールを開発する」です。

5.プラガブルなモジュールを開発する

「開放/閉鎖原則」コードの設計、実装は、既存のコードにシア証言の変更を加えるだけで新しい機能を追加できるようにしなければならないという原則。既存のコードに変更を加えず、例えば、クラスの継承という形で新機能を追加できるような設計が求められる。

www.oodesign.com

WordPressプラグインは、アクション、フィルター、プラガブル関数により、新機能に対して開かれ、変更に対して閉じた形で開発ができるように思想設計がされているということです。

そのため追加機能は、別個のプラグインで実装すれば、既存のコードに悪影響を及ぼさずに有効化・無効化できると。これをファイルアップロード処理を自動化処理を実例に説明されていました。

しかーし、正直うまく理解できていません。 例えば、元々あるプラグインに追加機能を開発するときにどのように書くのが既存コードに影響を少ないのかなどが本書を読んでも私は理解できませんでした。もう一回読む必要がありそうです。

そこでもう一冊：詳解 WordPress

詳解 WordPress

詳解 WordPress

より良いプラグイン開発のお作法がもやっとした理解になってしまい不完全燃焼のため、さらにもう一冊。
2015年の書籍であり、180ページのオライリー本ということでさっと読み物として読めました。

HTTPリクエストからテーマ、プラグイン、WPコアなどの基本の説明、フックなどの重要概念、管理画面とサイトの違い、などがわかりやすく説明されていました。

「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル」と近しい内容ですが、WordPress全体についてサッと知るのには最も適している書籍だと思います。

以上、合計4冊のWordPressプラグイン開発本でした〜