WordPressとComposerと独自ライブラリの上手な付き合い方

ComposerはPHPパッケージツールであり、事実上の標準となっている。しかし、WordPressプラグインそれ自体とかぶる機能が多いため、WP-CLIなどの一部プロジェクトを除いてあまり使われていない印象だ。この記事では、composerのライブラリを使う場合と、composerをパッケージ管理ツールとして利用する場合の2つについて説明しよう。

composerのライブラリを利用する

composer経由のライブラリとして、たとえば次のようなものを利用することができる。

• CssToInlineStyles CSSファイルをHTML内にインラインCSSとして展開できる。HTMLメールを送信するときに便利。
• ramsey/uuid ランダムバイトを生成し、そこからユニークな文字列を作ることができる。PHPの uniqid より強力。Webフック用のトークンなどの予測不能な文字列を生成するときに使える。

プラグインやテーマを作っているときに、上記のような拡張機能があれば便利だろう。また、Facebook SDKやStripe SDKのように、外部サービスと連携するときにcomposer経由でライブラリが配布されている場合もある。

この場合、プラグインなりテーマなりに composer.json を配置すればよい。筆者の作成するGianismが書いている通りだ。

{
    "require": {
        "php": ">=5.4.0",
        "facebook/graph-sdk": "^5.4",
        "abraham/twitteroauth": "^0.6.6",
        "google/apiclient": "^2.0"
    },
}

このように記載することで、関連するライブラリが読み込まれる。

プラグインのバッティングはどうなるか？

さて、composerは依存解決ツールでもあるのだが、WordPressのプラグインのように「1つのサイトに複数のプラグインがある」という状況だと、すべてのプラグインがcomposerを利用していた場合、バッティングする可能性がある。

しかしながら、composer のPSR準拠オートローダー実装では、複数のクラスがあったからといってエラーになることはなく、単に読み込み順で優先度が高いものが利用されるので、クラス2重定義によるエラーは発生しない。

もちろん、それでエラーが起きないかというと、そんなことはない。たとえば筆者はGianismにおいてFacebook SDKを利用していたのだが、あるときJetpackがカスタマイズしたFacebook SDKをまったく同じ名前（ class Facebook\Facebook ）にしてオートローダーなしでrequireしたため、画面が真っ白になったことがある。

残念ながら、いまのところこうした事故を防ぐ方法はなく、Tracで何度か議論になったことはあるが、WordPressのプラグインシステムと相性が悪いのか、まだ実現には至っていない。

しがたって、現時点の結論としてはバッティングしないようお祈りするのが唯一の解決策である。地雷を踏んだらサヨウナラ、というわけだ。

composerをライブラリ管理ツールとして使う

さて、ここからが本題である。

packagistにライブラリを公開する

composerはpackagistというリポジトリ（WordPress.orgのプラグインリポジトリのようなもの）に公開することができる。Githubとの相性がよく、公開しても構わないライブラリであれば、登録は簡単だ。宮内が昔に書いたブログ記事を参照のこと。

composerはデフォルトの設定、たとえば hametuha/wpametu とした場合、packagistを探しに行くようになっているので、オープンソースにするのであれば、packagistへの登録がオススメだ。

Capital Pも採用しているメディア向けテーマSnow Monkey作者の北島氏もパンくずやカスタマイザー用フレームワークなどを大量に登録している。

{
  "require": {
    "php": ">=5.6",
    "inc2734/wp-breadcrumbs": ">=0.3.2",
    "inc2734/wp-oembed-blog-card": ">=1.0.4",
    "inc2734/wp-view-controller": ">=2.1.4",
    "inc2734/wp-basis": ">=0.7.0",
    "inc2734/wp-customizer-framework": ">=2.3.0",
    "inc2734/wp-github-theme-updater": ">=0.2.5",
    "inc2734/wp-share-buttons": ">=0.5.9",
    "inc2734/wp-seo": ">=0.6.0",
    "inc2734/wp-like-me-box": ">=0.1.2",
    "inc2734/wp-pure-css-gallery": ">=0.1.4",
    "inc2734/wp-awesome-widgets": ">=1.3.3",
    "inc2734/wp-awesome-components": ">=0.4.3",
    "inc2734/wp-contents-outline": ">=0.3.2",
    "inc2734/wp-profile-box": ">=0.1.1"
  },
}

このようにして作れば、テーマを作成する際に再利用が可能になるだろう。参考にしてほしい。

さて、ここから先は有料会員向けに次の記事を公開しよう。

• 非公開なオレオレライブラリの管理
• packagistに公開する予定のライブラリをローカルで開発しながら管理するには

前者は受託業務を営む人にとって参考になるかもしれない。後者は説明している記事があまりないので、参考になるだろう。具体的には次のような構成での使い方である。

wp-content/themes
theme-c（theme-pの子テーマ）
theme-p（親テーマ）
├すごいメタボックス（自作公開ライブラリ）
├すごいパンくず（自作プライベートライブラリ）
└破滅カスタマイザー（サードパーティ制の公開ライブラリ）

後者については、ついでに解説動画（筆者が画面を操作しながら概念的な説明をする動画）がダウンロードできる。