作ったというか昔作っていたものを公開しただけではある。
もともとはあまり公開する気がなかったのだけど世の中ではまだWPは人気だし実際に仕事で使われているっぽいし、Local by Flywheelのユーザーも増えてきているっぽいので公開することにした。
これはなに
めっちゃ雑に言うと、ローカル環境のWPにくっつけてすばやくテーマ開発するやつです。プラグインとかそういう類ではない。
既存のテーマをベースにカスタマイズして納品したり公開したりするときにパフォーマンスよく開発ができるようになる。といってもやってることはgulpベースでアセット類を対象のテーマフォルダ内に流し込むだけなので、別に新しいことなどやってない。
詳しく
Local by FlywheelとかVCCWみたいなWPの仮想開発環境と合わせて使う。たぶんMAMPとかXAMPPとかでもいけると思うけど試してはいない。ようするにローカル内でWPの管理画面にログインできる状況であればなんでもいいはず。
名前のとおりアタッチメントなので、.php
ファイルはベースにするテーマのものを利用する。Twentyseventeenならそれだし、_sみたいなスターターキットでもなんでもいい。お手持ちの自家製WPテーマでもいい。ようするに既存のテーマをベースにアセット類をくっつけて開発していくスタイル。
動作に必要な環境は
なにかしらのWP開発環境 npm node: ^7.4.0
という具合。
機能としては、
.php
,.css
,.js
, イメージ類のライブリロード- webpack+babel
- Sass
- 画像圧縮
などなど。ホームページ手づくりに必要なものを入れている。ちなみにgulpは3.9.1
なので安心(?)
.scss
のコンパイルは対応しているので、自分の.scss
キットがあるひとはそれに入れ替えて使って欲しい。
使いかた
この記事ではLocal by Flywheelの使用を例に書いていく
1. 開発したいサイトをプロビジョニングする
2. プロビジョニングしたサイトのディレクトリに『wp-attach-dev』をgit clone
する
$ cd ~/Local\ Sites/<your-develop-site> $ git clone https://github.com/1natsu172/wp-attach-dev.git
cd
する場所は各自プロビジョニングしたWPが動いているディレクトリ。Local by Flywheelの場合だとだいたいルート直下に"Local Site"フォルダがあってその中にサイトがポンポン出来上がっていく感じだと思う。
Local by Flywheelだとcloneした段階でこういう感じになっている気がする。
3. wp-attach-devの環境を設定をする
なにはともあれwp-attach-devの環境も必要。
$ cd wp-attach-dev
$ npm install
dependenciesのインストールが終わったら開発環境の情報を入力していく。
~/Local Sites/<your-develop-site>/wp-attach-dev/configs/dirSets.js
ここがディレクトリの設定なので、エディタで開くと
//// ディレクトリ構成定義しましょう let DIRBASE = { domain: 'wp-testsite.dev', //サイトのドメインを適宜定義しましょう:'http://'はナシ wordpressThemesFolder: '../app/public/wp-content/themes', // WordPressの(wp-content内にある)'themes'フォルダまでのパスを定義しましょう:ルートディレクトリ(gulpfile.jsなどがあるディレクトリ)から相対パスで記述 developThemeName: 'twentyseventeen', // 開発を行なっていきたいWordPressのテーマフォルダ名を指定しましょう:twentyseventeenなら'twentyseventeen' buildFolder: 'build', // 本開発キット同梱のビルドフォルダを指定しましょう。特別変更する必要なければデフォルトのままでOKです srcAssets: 'customizingAssets', // 本開発キット同梱のビルドフォルダ内にあるアセットフォルダの名前を指定します。特別変更する必要なければデフォルトのままでOKです。 destAssets: 'customizedAssets', // テーマフォルダ内に吐き出されるコンパイル後のアセットフォルダの名前を指定しましょう。特別変更する必要なければデフォルトのままでOKです。 };
みたいなオブジェクトがあるので、コメントを読んで入力していく。
DIRBASE.domain
はローカルでプロビジョニングしたサイトのドメインを入れる- この記事例でいくとサイト名が"testsite"なので『testsite.dev』
DIRBASE.wordpressThemesFolder
はWPのコアファイル内にある'themes'フォルダまでのpath- Local by Flywheelを使うなら変更の必要はないはず、VCCW使うならVCCWのフォルダpathに変える
DIRBASE.developThemeName
は開発したいテーマフォルダ名- 例ではデフォルトの'twentyseventeen'に指定してるので適宜変更する
4. 開発しましょう
npm run dev
うまくいってればブラウザでlocalhost:3000
的なのが立ち上がってWPのフロントページが表示される。
5. 👏🏻
FinderでWPのthemesフォルダ見にいってcustomizedAssets
というフォルダが出来上がっていて中になんか生成されたファイルがあったら成功。
あとは<head>
タグで愚直に生成したcssファイルやjsファイルを読み込んだり、丁寧にfunctions.php
からwp_enqueue_scriptとかで読み込んだりすればOK。すばやく開発していって納品しましょう。
プロジェクトフォルダまるごとgit管理したいなら
例になるgitignore用意してあるので参照してください。
たいていの場合git cloneしたディレクトリに置くことになる(Local by Flywheelなら~/Local Sites/<your-develop-site>
直下に置く)
思想です
なんでアタッチメントの思想か
ぶっちゃけWPのテーマを0ベースで開発するという案件は現場レベルではあまりない気がしていて、たいてい既存の自社フレームワークか、改変許可のある無償・有償のテーマをベースにカスタマイズするパターンが多い気がしている。なのでWPをインストール→カスタマイズしたいテーマを適用→テーマファイルを編集という流れになると思う。
ここで問題になるのが各ファイルをどこに置いてどう管理するのかということで、WPのコアファイルの中のthemes
フォルダ中のテーマの中に開発環境を置いていいのかという問題がある。WP本体の中に公式提供でない自前の開発環境を置くのはなんとなく気持ち悪いしリスクがある気がする。WPのアップデートやテーマのアップデートに巻き込まれて自前のフロント開発環境が壊れることがあるかもしれない。
- WPのコアファイル
- LocalとかVCCWで担う
- コアファイルの中に入れるテーマファイル
- Twentyseventeenとか自前のテーマとか
- WPのフロント開発環境
- 『wp-attach-dev』
こういう風にそれぞれの役割ごとに分かれているとわかりやすいし責任の所在もはっきりしやすくていいだろう、という思想なのでアタッチメントの思想で開発するのがよい気がしている。
とにかく小さいサイトを無償テーマベースでシュッといじって納品するとか、WPのコアファイルのアップデート切るとか、子テーマを使うとか使わないとか、色んな条件下があると思うけど、どんな条件下でも表面の加工は『wp-attach-dev』で担って管理できていれば品質の担保がしやすいと考えている。
httpリクエストリスク
基本的にアタッチメントの思想でファイルをガンガン追加してCSSは既存テーマを上書いていくため、テーマファイルが肥大化するとか読み込むファイルが増えてhttpリクエストが増えるかもしれないとう懸念がある。でもWP自体がcssのimport使ったりもしてその辺の考慮がされて設計されているわけでもないし、プラグイン入れるとプラグインに付随するアセットによって多量のhttpリクエストが発生したりするので『wp-attach-dev』が起こすhttpリクエストはそんなに影響ないだろうという気持ちがある。
こちらからは以上です
正直に告白しますがPHPもWPもわかったためしがない、よくわからないでやっている。
WPで仕事している人は使ったりシェアしたりしてください!!!