ぃまだWordPressで消耗してるよっ!

2015年末の状況ですので、今現在は変更されている可能性が多分に含まれます。
VCCW(VirtualBox・Vagrant)・WP-CLI・Wordmove・Gulp などのそれぞれのインストールと基本的な使い方は他のサイトにて確認下さい。
および、内容に未確定な内容を多く含みます。

WP-CLI・Wordmove

WP-CLI

インストールはHomebrewを使わず1 curlで直接。
とりあえず、二つプラスαのステージにおいて有用だなぁと思った。

一つ目は、導入の初期段階の「入れては潰し入れては潰し」のステージで、「各種のユーザ名・パスワードなど、この命名は嫌だなぁ、よし、入れなおそ」みたいな状況。
さすがにシェルスクリプト(WP-CLIでの本体・テーマ・プラグインのインストール・活性化・非活性化とMySQLでのデータベース・ユーザ作成)までは組まなかったが、ある程度の段階までは「黒い窓」でできてしまうので楽になったなぁと。
その気になれば、WordPress本体やプラグインのオプション値も何とかできるみたいだけど、そこまでは対応せず。2

二つ目は、運用フェーズで、まだ実戦配備してないけど wp post コマンドかと。
例えばだけど、
「あなたは今自分のブログの全ての投稿のタイトルと更新日付をさくっと出力できますか?」
に対して3 、コマンドライン…あ、この場合、MySQLに入って wp_posts を、とかじゃなく…から簡単にできるので。

## wp-config.phpがあるディレクトリ、もしくは、--pathオプションで設定して
$ wp post list --post_type=post --fields=post_title,post_status,post_date --format=csv
  :
個人的な1995・2005,publish,"2015-06-30 23:59:56"
"WordPress メモ, 2014年大改修",publish,"2015-03-06 21:04:39"
アイマスPVで印象に残っているのをピックアップ,publish,"2015-01-12 11:08:52"
  :

うん、明示的な文字列にも関わらず、タイトルにカンマが含まれるのはダブルクォーテーションで囲んでいるな…4
それまではPHPで wp-load.phprequire_once して…だったのに比べると雲泥の差かと…シェルスクリプト万歳、夢が広がりんぐ。
今後WordPress以外の何かに移行する時、ページや投稿をフラットファイルに落とすのが簡単になるなぁと。
および、wp post update で記事の更新も可能っぽいので、YAML化した投稿データをWordPressの投稿画面を経由せず更新できそうな5 、気がする、が、それを使うかどうかは未定だけど。6

ただし、探し切れなかっただけかもしれないけど、ある投稿とその投稿に紐付いているタグやカテゴリをリスト化するのは、どうなのだろうか?
タグの一覧だけだと、wp term list post_tag あたりで何とかなるが、紐付けるとなると、もしかしたら wp_term_relationships を直接参照しか無いのかなぁといった状況。

他には、使わないと思うけど、wp scaffold _s で、Underscoresの雛形が作成される事か。
自分はそのスターターテーマを使ったテーマを更に子テーマとして使っているのだけど。

更に極めた使い方は、「え?まだMAMPで消耗してんの? via PHPのビルトインウェブサーバーを使ってMacに1分でWordPressを立ちあげる | Firegoby」あたりを参照。

一点、今後覚えていたらちょっと意識する、という事で。
これはWordPressのZIP解凍経由でのインストールでも同様かと思うが、WP-CLIを実行したユーザとApacheなどを実行するユーザが違う場合で、例えば、WordPressの管理画面でプラグインを導入する場合、例のFTP要求画面が出るかもしれないし、他にも何かあるかもしれない。
自分は wp-content/themes/ の自分のテーマディレクトリ・ファイル以外7 は一括でApacheなどを実行するユーザに chown した。
自分の場合は、_www ユーザに変更、グループは同一だった。

## ディレクトリのユーザ一括変更(rootユーザ権限)
$ find . -type d -print | sudo xargs chown _www
## ファイルのユーザ一括変更(rootユーザ権限)
$ find . -type f -print | sudo xargs chown _www

…で良いのかなぁ…もしかして権限エラーで怒られるかもだけど。
更には、厳密には chmod も必要だけど、ローカル環境に甘えて未対応。
ではあるが、後述の理由により、現在はログインユーザに戻している。

で、プラスαは、Wordmoveとの連携になるが、本番と同等の開発環境を作る時で、データベース・ユーザ作成、WP-CLIで基本的なWordPressの立ち上げ、wordmove pull --all で全データを取得、といったカンジで。

Wordmove

…をWeb検索すると、ほぼ全てVCCWと共に解説されているので、それが本筋なのだろうと思う。
自分も前のMBAでVirtualBoxVagrantでVCCWを導入したけど、如何せん、容量がが(私の今のMBAは128GB、メモリは4GBから8GBに拡張)、でちょっと怖気付いた。
なのでVCCWを使わず、Wordmoveだけを使っている…と言うかこれらは別のプロダクトだと思う…

気付いた点、つまづいた点を。

OSX謹製のRubyやRubyGemsでなく、別途インストールした方が面倒が無い…かも。
あるいは単にWordPressのパーミションの問題だったのかもしれない…
今更戻って確認できないけど、当初OSXのモノを使っていて、なのか、上記の様に無理矢理 _www ユーザに変更した影響なのか、sudo を要求された。
(参考:sudoを使わずにgem installできるようにする – 日々精進
とは言え要求されるだけだと面倒なだけで問題は無いかもだけど、Wordmoveでローカルのテーマ修正が本番環境に反映されない事もあり、rbenvに移行、ただし原因の追求は行っていないので言いがかりの可能性あり。
インストールはHomebrewを使わずgitにてruby-buildと共に。
wp-config.php$table_prefix を本番環境とローカル環境で合わせておく必要がある。
個人的に何故 Movefile にこのパラメータが無いのか良く分からない8 (が、世界中のハードコアな方々のレシピなので、それが正解なんだろうと)。
もしかして、見落としているだけかもしれない。
ローカルと本番環境との同期、その1
SSHにせよFTPにせよ(私はSSHが使えた)、各人トライ&エラーでお願いします…
何か…鬼門になりそうな気がして…
ローカルと本番環境との同期、その2
FTPとSSHでのパスの表現方?は違うと言うか何と言うかで、SSHの絶対パスが wordpress_path: になる。
あるいは、getcwd() で確認するなど。
ローカルと本番環境との同期、その3
SSHを使う場合、sshpassが必要かも。
(参考:sshpass – サーバにsshするときにパスワードをコマンドのオプションで渡したい – Qiita
自分の場合、sshpass未導入だと、随時SSHのパスワードを要求されて最終的には同期に成功せず終了9 した。
なお、普通にSSHする場合はsshpassを使わず、その都度パスワード入力している。
ローカルから本番環境への push
至極当たり前なのかもしれないけど、本番環境に仮にでもWordPressをインストールしておく必要がある。(その逆もまた真なり?未確認)
あるいは、本番環境にWordPressをインストールしていなくとも、Movefileexclude: 以外はアップロードされるので、これら、wp-config.php.htaccess を本番環境でどうにかすればどうにかなるのかもしれないけど未確認。10
.DS_Storeexclude: しておく
気にはなっていたのだが、記述が無いとそのまま同期対象になる模様。

未確認事項としては、本番環境のパーミションで、何となくだけど、何も考えていないと環境依存になるのではないかと。11

最新バージョンの確認とアップデート

Node.js関連でもだったけど、各プロダクトそのものの最新バージョンの確認方法やアップデート方法を確認する前に満足・力尽きてしまう場面が多々。

WP-CLIは wp cli check-update で確認して、wp cli update あたりか?
WordMoveはGemの作法に依存? gem outdated で該当する場合、sudo gem update wordmove

実際の運用

…と言っても、チーム運用ではなく、個人のブログレベルなので…

初期構想段階では、例えば静的サイトジェネレータ同様、データベース・PHPなどの各種ファイルとも、ローカルから本番環境への一方通行の予定だった。12
ところが、この方法で実際に運用、具体的には、wordmove push --all してみると、WordPress.comとJetpackとの連携が解除されてしまうというよろしくない…と言うよりも面倒な状況が。13
改めて wordmove help push で確認してみると…

  :
Options:
-w, [--wordpress], [--no-wordpress]
-u, [--uploads], [--no-uploads]
-t, [--themes], [--no-themes]
-p, [--plugins], [--no-plugins]
-l, [--languages], [--no-languages]
-d, [--db], [--no-db]
  :

…と、WordPress本体・アップロードディレクトリ・テーマ・プラグイン・言語ファイル・データベース単位では同期可能だが、投稿データ単位、つまり、wp_post などのテーブル単位では無理じゃないかと。14

となると…

  • 記事の投稿は試しにローカルで書くかもしれないけど15 、最終的には本番環境で確定させ、確定後にローカルへ wordmove pull --all もしくは wordmove pull --db など
  • テーマ修正などはローカルで行ない、確定後に本番環境へ wordmove push --themes
  • WordPress本体やプラグインなどの更新は、本番環境で行ない、確定後にローカルへ wordmove pull --all
  • WordPress・プラグインアップデート時は、理想としては、本番環境・ローカルとも同一な状態で、まず、ローカルをアップデートして稼働確認、その後、本番環境をアップデート…なんだが…気付かないうちに本番環境の自動アップデートが走ってしまい(機能を抑止していない)、現状何とも。現状「ほぼ」問題無く自動アップデートで問題が起こっていないので、最低限、本番環境とローカルの同一性を保つ様に努力する、程度か。

…というガイドラインで運用中。
FTPしなくて済むので楽になった、データベースの同期が非常に楽、といった恩恵を感じている。16

および、今回の様な事態は今後もあるだろうと想定して、こちらで作成した子テーマのファイルサイズをcronで定時チェックして、ファイルサイズが合致しない場合はメールを投げる仕組みをPHP以外の言語で実装、本番環境の公開Web領域以外に配置した。17

2015/12/28

Menu of this post

  1. 1. だらだらと
  2. 2. WP-CLI・Wordmove
  3. 3. 最もよく見られた投稿をJetpack APIから取得
  4. 4. 関連する投稿を実装してみる
  5. 5. その他の細々とした改修

Footnotes

  1. 1. 何故か良く分からないが、極力Homebrewを使用しない方針でMBAを運用している気がする。Homebrew Caskは、現在はQuick Lookのインストール程度しか使用していないが、何かの機会に使っていくと思う。

  2. 2. 調べるのが面倒なのと、プラグインのアップデートでオプション値の増減がありそうなので。と言うか、ここを突き止めれば完全に黒い窓だけで操作できるのだろうけど。

  3. 3. WordPress管理画面の投稿一覧で、公開・非公開の件数も見れるし、ページ送りすればタイトルなども確認できるし、ついでに投稿も更新できるし、だからそんなの要らないよ、だったら、まぁ、それはそれで良いです、ダメプログラマのオナニズムで良いですし、そもそもWP-CLI・Wordmove未導入の場合、インストールから始めないといけないので、黒い画面に不慣れな場合、かなりの労力を要するのは事実ですし。

  4. 4. 作例ではCSV出力だけど、当然ながらJSONなど他のフォーマットで出力可能。

  5. 5. 差し当たっては、wp search-replace で、Wikipediaへのリンクを一括して http:// から https:// に変更しないと気持ち悪くて…そのままでどの様な影響があるのか不明だけど。

  6. 6. この場合、WordPressに備わっている投稿のリビジョン管理がどうなるのか、今はプラグインで2世代しか管理していないけど、管理画面のプラグイン経由で削除する必要がありそうだけど。

  7. 7. これらは修正する度に管理者パスワードを要求されるのが面倒なので。

  8. 8. ダンプしたSQLファイルのテーブル名を置換するだけで済みそうな気がするけど…ダメなのか?

  9. 9. 何処かの段階でパスワード文字列が平文表示される箇所が存在。

  10. 10. 当然、先に本番環境にインストールしたユーザ&パスワードは、wordmove push したそれらに書き換わるなぁと。

  11. 11. ユーザはSSHユーザ、ファイルは0644、ディレクトリは0755みたいな。

  12. 12. これだと本番環境がどれ程書き換えられても即座に正常状態に戻す事が可能になるので。

  13. 13. さすがにこれを都度やり直すのは面倒で。そもそもローカルではこの連携ができない、選択肢に無いのではないかと。

  14. 14. 正直、アテが外れて、というよりも自分の思い込みの勘違いなのだが…今回に限らずこういうパターンが稀によくあって歳取ったなぁと、途方に暮れそうになった。

  15. 15. 通常はMarkdownエディタやAtomエディタで書いているが、ある程度書き溜めると実際の見え方を確認したくなるので。

  16. 16. まだ慣れていないので、pushpullで悩むけど。

  17. 17. および、SiteGuard WP Pluginでログインアラートを。ログインページ名変更はちょと面倒なので外しているが、導入時この機能がデフォルトになっているのに気付かず、ログイン出来ない状況に陥ったが、 wp plugin toggle siteguard でプラグインを非活性化、.htaccess を修正という、思わぬトコロでWP-CLIが役に立った。なお、画像認証機能は、GDライブラリの影響なのかうまく機能せず、Submitボタンが表示されない状態になり、前述のWP-CLIで事無きを得て機能させないようにした。