以前に「WordPressを使ったサイト制作標準フロー」の中でWordMoveを紹介しましたが、コマンド操作ミスで大事故になる危険性があります。 例えば、本番環境に修正したテーマを適用する際に下記のように行いますが
ローカルのvccwでphp7.2で検証したかった。 現在のvccwではphpのバージョンは変更出来ないのでどうしたものかと思っていたらFacebookでvccw開発者の宮内さんがドンピシャの答えをくれましたので忘れないようにメモ。 PHP7.2にしたいVCCWを起動して $ vagrant ssh $ sudo apt-get install python-software-properties $ sudo add-apt-repository ppa:ondrej/php $ sudo apt-get update $ sudo apt-get install -y php7.2 vagrant@vccw2:~$ php -v PHP 7.2.0-2+ubuntu16.04.1+deb.sury.org+2 (cli) (built: Dec 7 2017 20:14:31) ( NT
vccw-share というコマンドを作りました。 これを使用すると、コマンド一発で VCCW 上の WordPress サイトをインターネット経由で確認できるようになり、スマホで確認したり、クライアントに進捗状況を見せたりすることが簡単になります。 インストール方法 VCCW で構築したマシンに SSH で入ってください。
Wordpressの管理(デプロイ etc)にはvccwにお世話になっています。 ただ、最近データベースをデプロイする時に以下のエラーがよく発生します。 wordmove/sql_adapter.rb:44:in `gsub!': invalid byte sequence in UTF-8 (ArgumentError) vccw内でデプロイを行う場合、Wordmoveというライブラリを使用しています。 WordmoveではWordpressのデータベースに含まれているホスト名を自動で置換してくれる処理が含まれているのですが、この処理でエラーが発生しているようです。 対策としてvccw内のWordmoveをアップデートしてWordpress cli(wp search-replace)を使った置換方式に変更します。 なお、きちんと確認はしていませんが以下のようにエラーが発生しているようで
VCCW のバージョンが上がっているので、導入からあらためて復習。 以前に触った記事はこちらからたどれます。 VCCW | deadwood 本稿の VCCW と依存するパッケージのバージョンは以下の通りです。 vagrant / 1.9.2 virtualbox / 5.1.16-113841 VCCW / 3.1.4 WP-CLI / 1.1.0 Composer / 1.4.1 scaffold-vccw / 1.3.0
WordPressの開発環境を即座に用意したいのであれば、Vagrantが便利です。Vagrantを使用すれば、簡単に仮想マシンを構築できます。また、さらにWordPressの開発環境に特化した仮想マシンを簡単に構築したければ、VCCWを使用するのが便利です。 gulp.jsとBrowser Syncで快適なWordPress開発環境を手に入れる VCCWのインストールについては、上記リンクをご参照ください。さて、仮想マシンはOS再起動時に自動的にシャットダウンされてしまいます。再起動の都度、毎回仮想マシンを起動するのは手間がかかるため、今回はログイン時に自動起動するよう設定してみましょう。 http://vccw.cc/ ログイン時に仮想マシンを自動起動する Vagrantで構築した仮想マシンを起動することは非常に簡単です。Vagrantfileと呼ばれる仮想マシンの設定ファイルを記述し
昨日 「VCCW + WP-CLI で WordPress のユニットテスト」 という記事を書きました。 何回かに分けて、VCCW の少し高度な使い方について解説していきます。 WordPress のコーディングスタンダード WordPress にはいくつかのコーディングスタンダードが定められています。 主な規約はだいたい以下のような感じ。 インデントにはスペースではなく本物のタブを使用すること。 丸括弧の内側にはスペース。 変数を展開する等の理由がない限りシングルクォーテーションを使用すること。 などなど。 これらは WordPress-Coding-Standards というツールを使用すれば、皆さんのプラグインやテーマ内のコードをチェックすることができます。 VCCW にはこれがデフォルトでセットアップされていますので簡単にチェックを行うことができます。 wpcs コマンドを使ってコ
もう一ヶ月ほどになりますが、VCCW v3 をリリースしました。 変更点は Qiita のほうで一度書いてるのでそちらを見ていただければと思います。 http://qiita.com/miya0001/items/041e9363ff81695a2251 ディスク容量的に600MBほどやさしくなったのと、プロビジョニングが早くなったのがいちばんの改善点ですかね。 僕の環境ではおおむね5分ぐらいで起動します。 さて、ソーシャル等で VCCW についての言及をいろいろ見てると、いろいろ混乱してるみなさまも多いようなので、こいつとの上手な付き合い方について書いてみます。 ZIP アーカイブをダウンロードして使うのを強く推奨します! VCCW を使う際には、リポジトリを git clone するのではなく、ZIP アーカイブをダウンロードして使ってください。 https://github.com/
あとは、そのディレクトリに移動して vagrant up するだけ。 必要に応じて site.yml を編集してください。 コマンドラインオプション このコマンドにはいくつかのコマンドラインオプションがあります。 --host=<ホスト名> - ホスト名を指定してください。デフォルトは vccw.dev です。 --ip=<IP> - IPアドレスを指定してください。デフォルトは 192.168.33.10 です。 --lang=<language> - 言語を指定してください。デフォルトは en_US です。 --update - VCCWのファイルを最新版にアップデートします。 help wp help scaffold vccw でヘルプを見ることができます。 NAME wp scaffold vccw DESCRIPTION Generate a new VCCW environm
WP-CLI について VCCW v2 では、通常版の WP-CLI をインストールしていましたが、v3 では、nightly バージョンをインストールしています。 WP-CLI の nightly バージョンは、開発環境で使用するレベルでは問題がないよう十分にテストされており、最新の機能をいち早く使うことができます。 私自身が WP-CLI のチームメンバーであり、VCCW そのものを WP-CLI のドッグフーディングとして使用することにしました。 VCCW v3 のゴール VCCW のゴールは、単に開発環境を手っ取り早く用意できるようにするということだけではなく、WordPressが動作する環境そのものを、ワークフローも含めて共有することです。 従来の方法では、せいぜい WordPress のファイルやデータベース等の共有が限界で、開発チームのメンバーはそれらを入手後に、独自の開発環
VCCW 2.19.0 Linked Cloneに対応してディスク容量の大幅な節約ができるようになりました。 VCCW 2.19.0をリリースしました。 http://vccw.cc/ このアップデートでは、Vagrant 1.8の新機能Linked Cloneに対応しました。 あと、VCCW用のBoxもアップデートしました。 VCCWの最新版を使う前に vagrant box update でBoxを最新版にしておくことをおすすめします。 VagrantとVirtualBoxも最新版にしてください。 Linked Cloneとは 従来のVCCWは、複数の仮想マシンを起動するたびにOSを丸ごと複製していたため1GB近いディスクをマシンごとに占有していました。 Linked Cloneという機能を有効化すると従来のようにOS丸ごとコピーせずに、差分だけが増えていくようになります。 したがって
VCCWにかぎらずVagrant環境では、メールの送信に関連した確認作業が困難です。 また、仮にクラウド等を使って確認するにも、いちいちソースコードをアップロードするのはめんどくさいですし、ほんとにメールがでちゃうのも時には困りモノです。 そこでRuby製のツールのMailCatcherを使うととても便利なのでVCCW上でMailCatcherをセットアップしてメールの確認を行う手順を紹介します。 MailCatcherとは? MailCatcherとはRuby製のオープンソースのSMTPサーバーで、メール系の開発に便利な以下のような特徴を兼ね備えています。 簡単なコマンドで起動することが可能。 ウェブサーバーも同時に起動し、送信したメールをブラウザで確認することができる。 メールはMailCatcherから先には送信されない。 ウェブソケットを使用しており送信したメールはリアルタイムで表
今回は、午前中にWordCamp Kansai 2015の実行委員会合があったので、朝から会場入りしてます。白熱したやり取りがあり、結構お腹減りましたね.. 昼食は近場でメンバーの何名かと一緒に食べ、そこでもいろいろと話し合いました。 さて、今日はWordPressをどのような基盤ツールを使って構築するかについての話です。 これだけいうと、「今年のWordBench大阪はデザイナー中心でやるぜ〜」ってどっかでつぶやかれていた気がしますが、システム寄りじゃんって思うかもしれません。 でも実際WordPressをどのように構築するかは、デザイナーの方々にとっても切実な課題じゃないでしょうか。基盤系エンジニアなら「なんとでもなるよん!」ってことでも、デザイナーはそう簡単に自前で構築できるか、と問われると答えられないケースもあるんじゃないかなと思います。 今回の2つのツールの紹介バトルは、自前パソ
Posted 5月 18th, 2015 by codechord. 2 Comments Tweet Tweet 2015/05/18、個人的にどっぷりな、wordpressプラグイン本の著者さんがセッションするということもあり、第41回 WordBench 大阪 「VCCW vs Wocker」に行った議事録と感想。 結論からいって、Dockerについてかなり理解が深まった。 きっかけを与えてくれたWockerの作者のKiteさんにはただただ感謝。 触発されて、今日ずっとDockerfileの書き方しらべてた。 あとは、TDDの必要性だとか、CIの必要性だとかへの理解が深まり、ついでに、OSSの貢献の方法というか考え方だとか、いろいろと参考になった。 本題のテーマはvccw vs wocker。つまり仮想環境を利用しての開発環境についてのセッション。 そのまえに、まずDockerについ
ここ2〜3か月ほど、WordPressを使った企業内ナレッジ共有システムを構築しています。 「WordPressを使って企業システム」というのも、いずれ語りたいところなのですが、今日は開発環境の話にしようと思います。 WordPressでの開発で困るリリース作業 WordPressでシステム開発しようとすると、何らかのファイル編集や開発等が必要になるのは、下記の要素です。 テーマ プラグイン 言語ファイル アップロードファイル(画像などのメディアファイル) データベース(投稿データや設定データなど) wp-config.php(基本的な設定ファイル) 結構、多岐に渡るんですね。 それぞれが別のディレクトリに整理されているのですが、例えばプラグインディレクトリでは、WordPressに最初から入っているプラグイン、公開されているプラグイン、独自開発したプラグインと、様々な由来を持つファイル(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く