Browsersync とローカルサーバーを連携させて自動リロードさせる。

おかんが喜ぶらしいので書きます。

Browsersync という node.js 製の開発ツールがあります。これを使うと、開発用のサーバーが(通常 localhost:3000)で立ち上がって、ファイルの変更時にブラウザを自動リロードしてくれたり、CSSとかを自動で差し替えてくれたり、 見ている全てのブラウザでスクロールの位置などを同期してくれたりととにかくいろいろ便利なツールです。Sass や Babel 等と組み合わせるととても便利だったりします。

VCCWWocker や PHP のビルトインサーバーで WordPress や PHP の開発を行ったりしますが、そのときにも Browsersync 出来たら便利ですよね。(というか別にWordPressやPHP以外でも便利です)

こんな感じで出来ます。何はともあれ、Browsersync をインストールします。

$ npm install -D browser-sync

そして、こんな感じで、server.js のようなファイルを、開発中のテーマの中に作ります。

var browserSync = require("browser-sync");
browserSync({
  proxy: 'vccw.dev',
  files: [
	"./dist/styles/**/*.css",
	"./dist/scripts/**/*.js",
	"./**/*.php",
  ]
});

proxy に設定するのは、ローカルサーバーの hostname です。WP-CLI でローカルWEBサーバーを立てて開発などをしているときは、localhost:8080 等にします。

files には、監視するファイルを入れます。指定したファイルに変更があったときにブラウザが自動でリロードしたり、CSSファイルの場合は、動的に差し替えてくれます。JS や CSS をビルドしたりする際は、出力されたものだけを指定しておくのがベターです。

そして、server.js を起動すると、Browsersync が起動して、いろいろ便利にやってくれます。

$ node server.js

package.json に

{
  "scripts": {
    "serve": "node ./server.js"
  }
}

等と書いておくと、

$ npm run serve

みたいな感じで使えるので、よりスマートかなーと思います。

glup と組み合わせる場合

gulp を使っている場合はこんな感じになります。

var browserSync = require("browser-sync");
var gulp = require('gulp');
var sass = require('gulp-sass');

gulp.task('sass', function(){
  gulp.src('./src/styles/*.scss')
    .pipe(sass())
    .pipe(gulp.dest('./dist/styles'));
});

gulp.task('browserSync', function () {
  browserSync({
    proxy: 'vccw.dev',
    files: [
	    "./dist/styles/**/*.css",
	    "./dist/scripts/**/*.js",
	    "./**/*.php",
    ]
  });
});

gulp.task('watch', function(){
  gulp.watch('./src/styles/*.scss', ['sass']);
});

gulp.task('default', ['browserSync', 'sass', 'watch']);

gulp で sass の自動ビルドをやってる場合などは、こんな感じで使えば良いんじゃ無いかなと思います。

WordBench 長野 vol.7 を開催します。#wbnagano

今年は頻繁に開催出来たら良いなと思っています、WordBench 長野。

というわけで、第7回目の勉強会を3月11日(土)に開催します。

WordBench 長野 vol.7 WordPress 勉強会@松本 – connpass

によるセッションを等を予定してます。

LT等も随時受付中です!また、本編終了後に、会場での懇親会も予定しています。

ぜひご参加下さいませ。

Vanilla が WordPress の公式ディレクトリに公開されました。

WordPressのテーマを作ったので公開しました。

去年の10月にWordPressのテーマ作ったので、Github上で公開しましたが、それがWordPress.org の公式テーマディレクトリで公開されました。

Vanilla — Free WordPress Themes

Vanilla

テーマの動作はこのサイトや、デモサイトにて確認できますので、ダウンロードしていじって頂ければとおもいます。

また、テーマを作るにあたって、Twenty Seventeen や Twenty Sixteen 、そして _s のコードがかなり参考にしました。特にアクセシビリティへの配慮の部分などは、やっぱりデフォルトテーマって良く練ってあるなと感じることが多かったです。

テーマレビュー自体は割とすんなりと終わった感です。Theme Check プラグインと、PHP_CodeSniffer でテストしながら開発するのはやっぱり大事だなぁと。

また、Github と Travis CI を使ってリリース用のZIPファイルを自動作成するようにしたのですが、こういうちょっとしたところを自動化しておくのはかなりストレスを減らしてくれるなぁと思った次第です。

今回はかなり引き算しながらテーマを作ったので、次はもう少し凝ったものを機会があればやってみたいなぁと。

フィードバックやプルリクエストお待ちしています!

WordPress に貼った SpeakerDeck をレスポンシブ対応するプラグインを作りました。

WordPress は Speaker Deck の埋め込みをサポートしていて、スライドのURLを貼ると、自動的に、埋め込み用の iframe に変換してくれます。便利。

便利なんですけど、ちょっとイラッとくるポイントがありまして、レスポンシブに対応していないんですよね。スマホでみたらはみ出たり、縦にスキマが出来てしまったり。 iframe の宿命といえばそうなんですが・・・・。

またそれがレスポンシブ対応になっていないブログを見たりして、いい加減になんとかならないかな…と思ったわけです。「チッて思ったらプラグインのネタ」と教わってきたので、プラグインにしました

Responsive Slide – Plugin Directory — WordPress

Github : torounit/responsive-slide

デモ

現在 Speaker Deck にのみ対応しています。他のサービスは要望があったらやるかもしれません。

プルリクエストとかお待ちしてます。

WordBench Nagano vol.6 “WBNagano Special!!!” を開催しました!#wbnagano

WordBench Nagano vol.6 “WBNagano Special!!!” のほう、無事終了しました。

たくさんの方にご参加頂き、本当にありがとうございました。スタッフ・スピーカーの方々、本当にありがとうございました。

イベントページに資料の方を追加していきますのでそちらも振り返りなどに役立ててもらえればと思います。

全体の振り返りは WordBench.org の方にまた書こうと思いますので、とりあえず感想やら自分のことについて。

Get involved in WordPress !!

「Get involved in WordPress !!」というテーマで、セッションをさせて頂きました。オープンソースでコードを公開したり、開発に参加すると楽だし楽しいよって話と、コミュニティに参加すると楽だし楽しいよって話をしました。

特に業務でWordPressやプラグイン、それらに限らずOSSを使うということは、昨今のほとんど全てのWEB制作に当てはまることだと思います。それらともっと上手に、効率的に、そして楽しく付き合っていくためのヒントになれば幸いです。

WordCamp Kansai 2016 でプラグイン開発やらコアコントリビュートの話のセッションもしたので、それもあわせて見て頂ければと思います。そのときの動画もあります。

また、今回の話をするにあたっていろいろと参考になった資料です。

感想とか

なんだかどのセッションもめちゃめちゃに濃い内容だったような気がします。懇親会も本当に楽しかったです!

ブログを書くまでがWordBenchです。楽しく読ませて頂きますので、よろしくお願いします。

WCT2015の忘年会のLTでWordBench長野盛り上げる!とLTしてからまるまる一年。とりあえず何でも良いから続けることというのは去年のテーマでしたが、その結果として、一つ大きな形として出来たのは良かったなと思います。

また、登壇者から暴露されたりLTで自分でも話しましたが、とりあえずやりたい!と声を上げることは重要なんだなということをほんとに感じました。ダメ元でも言ってみるモノですね。

当日は県内の方も多数参加して頂きました。これをきっかけに松本や飯田以外でも何かがはじまれば良いなと思っています。また、大雪で残念ながら参加できなかった方などもいたので、定期的に何かしらイベントを開催出来ればなと思います。またWordPress以外のコミュニティと合同で何かをやれたりしても楽しいかもしれませんね。

とりあえず、2/1にもくもく勉強会を開催しますので、もしお時間ある人はお気軽にご参加下さい!

次回は、3月か4月くらいにイベントを開催しようかなとも思っています。そのときはまたぜひよろしくお願いします!またこんなこと聞いてみたい!喋りたい!等もあればFBグループwordbench.orgの長野ページにてご相談下さいませませ。

WordBench 長野 vol.6 “WBNagano Special!!!” を開催します。#wbnagano

2017年、明けましておめでとうございます。今年もみなさまよろしくお願いします。

9月頃から所々で噂をして来ましたが、1月21日に松本で WordBench 長野 vol.6 「WBNagano Special!!!」を開催します!

今回は、何があったか北海道の札幌市から香川県の男木島まで、日本の至る所から WordPress な方々が長野県松本市に集まって頂けることになりました。気がつけば、至る所の WordBench のモデレーターや、過去の WordCamp の実行委員長などがわらわらと。いやぁ、言ってみるもんですね。

こんな感じのセッションを行う予定です。

  1. 長谷川 広武 (´°ム°`)(@h2ham)「実演!jQuery以外でデザイナーも触れておきたいフレームワーク」
  2. Kite(@ixkaito)「What’s New in Twenty Seventeen」
  3. 岡本秀高(@motchi0214)「WordCamp US 2016 とWordPress 4.7から、これからのweb制作について考えてみた」
  4. ながとみちはる(@luchino__)「WordPressのコミュニティに関わって楽しかったりした話。」
  5. 額賀順子(@nukaga)「フリーランスWebデザイナーのイマドキ WordPress 案件ワークフローとお見積り」
  6. Toro_Unit(@Toro_Unit)「Get involved in WordPress !! 」

東京、愛知、宮城からも参加して頂ける方もいらっしゃるので、楽しい会になるんじゃないかなとは思っております。

会場で終了後懇親会も行う予定ですのでぜひお越し下さい!

参加登録はこちらからどうぞ: WordBench Nagano vol.6 “WBNagano Special!!!” – connpass

2016年の振り返り。

大晦日なので今年1年の振り返りでも。

なんだかずーっと WordCamp や WordBench してた気がします。

フリーランスになりました

フリーランスとして活動し始めました。半ば勢いでフリーランスになってみたところもあるのですが、なんだかんだ1年暮らせました。来年も細々と暮らしていけたらと思います。

WordCamp Kansai 2016 / Tokyo 2016

今更ですが、初めて WordCamp のスタッフをやらせてもらいました。

特に Kansai のほうは、昨年の12月末から始まってセッションチームとしてその企画をやったりハードではありましたが、いろいろとつながりが深まったり良い機会だったと思います。こういう機会があることで、いろいろいい刺激になりました。

また機会があればなんかやります。

WordBench 長野 のリスタート

WordBench 長野をリスタートできました。今年の WordBench 長野の活動のまとめという記事を書いたのでそちらに長々と。

今年の WordBench 長野の活動のまとめ

新年も 1/21にやるので、よろしくお願いします!

県外の WordBench / WordBash /  WordWine

WordBench 山梨で LT やらせてもらったり、WordBench 京都でキレ芸認定されたりしました。

そのほか、WordBash Kyoto や、WordBash@JUSO でいろいろ飲んで喋ったりしました。

WordWine では僕だけお酒も飲めず、セッションだけして来たりいろいろと切ない思いを味わいました。

WordPress 以外のイベントでの登壇

WP-D Week や 秋のJavaScript祭 in mixi にお誘い頂いて喋らせて頂きました。

WP-D Week で CSS の話をしました。そして CSS 設計と部屋の掃除について。

JavaScript 祭りでキレてきました。#jsfes

WordPress 以外のこういった会にも来年は積極的に出て行きたいなと思います。

WordPress のテーマを作った

WordPressのテーマを作ったので公開しました。

WordPress とフロントエンドが得意とか言っておいてテーマを作ってないっていうのはなんだかなと思っていたので、作る作る詐欺でしたがようやく重い腰を上げました。

ここ最近カスタムヘッダーにも対応させたり、いろいろ機能追加してみたので、遊んでみてください。

Vanilla – Vanilla is the simple theme for blogging. And for single column modern websites.

Basis にプルリクエストを送りまくった。

https://2inc.org/blog/2016/02/29/5181/

モンキーレンチのキタジマさんが作ってる CSS フレームワークの Basis にいろいろとプルリクエストを送りつけました。なんか気がつけばめちゃくちゃ進化してますが。

ソースコードを公開していることでこういうコミュニケーションがとれるんだなと改めて気付かされました。

VCCW 3.0 Release !!!

VCCW の 3.0 の開発をいろいろとお手伝いさせて頂きました。

VCCW 3.0.0 beta 1 がリリースされました。

自分の普段使いしているモノを自分の手で変えていけるのは面白いなとは思いました。

Serverspec にプルリクエストを送ったのもなかなか楽しかったです。もう少し Ruby 力も高めていかねば。

あ、放置してるブランチがあるのでこれもプルリクエストせねば。

WordPress 4.7 コア貢献者

WordPress 4.7 でまたコア貢献者になりました。自分のプラグインをWordPress 4.7 のベータ版でテストしていたところ、バグを見つけたという経緯がありました。テストをすること、それにかかるコストを自動化などで下げることの重要性に改めて気付きました。

まとめと来年の抱負

今年はフリーランス1年目でしたが、仕事よりもコミュニティ活動に軸足を置いてやってきた気がします。それでもなんとか1年過ごせるもんですね。

来年はそういった活動やオープンソースな活動と、仕事との距離をもう少し縮めていけるといいなと思います。長野県の他の IT コミュニティにも来年はもう少し出没できるようになりたい。

海外のイベントにも行ってみたりしたいので、来年はもう少し仕事周りのことをちゃんとしないとなと思います。もうすぐ30才ですし。

というわけでお仕事お待ちしてますー。

今年の WordBench 長野の活動のまとめ

なぜかGTOのドラマ(反町隆史の奴)を見ながらこれ書いてます。

WordPress Advent Calendar 2016 ということで、昨日の川井さんの記事に引き続き、23日目の記事になります。というわけで、今年のWordBench 長野の活動の総まとめをしようと思います。

WordBench 長野にも藩ができました

昨年まで WordBench 長野で勉強会を開催しようとする際に毎回問題になっていたことなんですが、長野県めちゃくちゃ広いんですよね。

昔からモデレーターをして頂いているファーストエレメントの宮澤さんが住んでる飯田市と、僕の住んでる松本市ってだいたい 100km くらいの距離があるんです。ついでに言うと県庁所在地の長野市と松本市の間で 80km くらい。おまけに昨年 WordBench 山梨が立ち上がったワケなんですが、正直飯田より甲府のほうが電車のアクセスとか良いんですよね。

てなわけで、毎回毎回長野県と銘打ってやるってのがそもそも大変なんじゃ無いかということに気付いたわけです。じゃぁ WordBench 松本 とか立ち上げるのか?となるわけですが、WordBench 長野市 とかできたらスッゴい面倒くさい名前になるなぁと。長野(県)がすでにあるのに。

かと言って、北信・中信・東信・南信(福島県で言うところの浜通り・中通り・会津地方、群馬で言うところの中毛・西毛・北毛・東毛みたいな奴)って分け方するのも県外の人からはどこそれってなるわけで。

そんな折に、去年のアドベントカレンダーでコスギスさんがこんな記事とを書いてました。

2016年のWordBench新潟(長岡藩)は、毎月初心者向け勉強会をやります宣言

「藩」。

これだ!ってなりましたよね。

え?解りづらい?大河ドラマ見ましょう。ついこないだまで真田丸やってましたし。

というわけで、各藩ごとの活動がスタートしました。

松本藩の活動。

月に1度ペースくらいで、もくもく勉強会を開催しました。なんとか今月までで11回開催できました。

ちゃんとした勉強会というよりは、とにかく月に1回でもWordPressについて話す場所とかがあると良いのかなということで続けることを目標にゆるーくやったのが良かったのか、なんだかんだ続けることができました。

ゴールは長野県内のWordPressコミュニティの活性化みたいなところにあるので、散発的にちょっと大きな勉強会をやるより小まめに集まったりするような場があるのが重要なのかなと実感しました。

飯田藩の活動。

飯田藩のほうでももくもく会が今年3回ほど行われたようです。最近は、コワーキングスペース とよテラスさんという泊まれるコワーキングという場所が豊岡村にできたらしく、そこでやっていたりするようです。

来年は開発合宿とか開催出来たら良いなと思っています。

WordBench 長野全体としての活動

WordBench 長野 Vol.5 を10月8日に開催しました。もくもく勉強会に参加していた人に声をかけてスピーカーをやってもらったり、運営を手伝ってもらったり、以前のWordBench 長野とはまた毛色の違う雰囲気でできたのは面白かったです。

僕以外のスピーカーの2名がエンジニアではなく、しかも1名はブロガーというのは、ちょっと今まで無かったことかなと。エンジニア以外の目線って言うのは結構興味深かったですし、いろいろ参考になりました。

WordBench 長野のこれから

もくもく勉強会などは定期的にこれからも行っていくつもりですし、いわゆる普通の勉強会みたいなのももう少しペースを増やしてやれたら楽しいのかなと思います。コントリビューターウィークエンドとかもやりたいなとも。

藩とかも増えたら良いなーと思うのでそちらにお住まいの方はぜひ。お手伝いできることがあれば何なりとご相談下さいませませ。

というわけで、2017年1月21日(土)に「WordBench Nagano vol.6 “WBNagano Special !”(仮) 」と題して松本で勉強会を開催します!!!内容は絶賛調整中ですが、県外の方もスピーカーとして何人かお呼びする予定です。北の方から西の方まで・・・。関係者のみなさま、全然連絡して無くてほんとすみません。

そんなわけで皆様ぜひ今のうちから予定を空けておいて頂けると幸いです。

県外の方はスノーボードとか担いで来れば良いんじゃ無いかと思います。もしくは、国宝松本城 氷彫フェスティバル2017とか見に来て天守閣に登ってそばでも食って帰れば良いんじゃ無いでしょうか?

ではまた、どこかの WordCamp か WordBench か WordWine か WordBash あたりでお会いしましょう。(飲んでばっかりじゃねーか)

 

WordPress テーマ制作のワークフロー考察

WordCamp Tokyo 2016 でもテーマ作成についての疑問をぶつけたけど、みんなどうやって構築してますか?

なんかハムさんと会うたびにこの話をしている気がします。とろゆにです。というわけで便乗エントリーします。

基本的にはいきなりテーマを作り始める派でした。既存のテーマをベースにすると言うことはほとんどやってきませんでした。ですが今年1年を振り返ってみると案件によってまちまちで、WordPress のスターターテーマ _s をベースにした開発もやりましたし、 HTMLを作成してから WordPress というフローもありました。それを踏まえてそれぞれに思うことをつらつらと。まぁ思うところや結論はハムさんとだいたい一緒ですが、プラスアルファということで。

いきなりテーマを作る? or 静的HTML作る ?

いきなりテーマを作る場合

僕の WordPress テーマ制作のワークフロー ( 仕事編 ) – Habakiri でもキタジマさんが言っていることですが、静的 HTML と WordPress テーマのテンプレートが同じようなコードになります。それならば最初から WordPress テーマを作った方が WordPress と矛盾したモノを作りづらくなる、ソースコードの管理が煩雑にならないというのは大きなメリットです。

テーマユニットテストを突っ込んだ状態の WordPress を用意してそこからスクラッチで書いていくというのが僕の基本的なフローです。基本的には ビジュアルエディタで完結できるような作りを目指して実装していくという格好です。自動挿入される p タグや、ビジュアルエディタで消えてしまうHTMLの書き方などもあるので、そこら辺への対応を最初の段階でケアできるのは楽だったりします。

静的HTMLを作った方が良さそうな場合

運用する人があまり固定ページを編集することが想定されていない or HTML や CSS を固定ページごとに書くような運用を想定しているケース等は静的HTMLを作った方が良いのかなと思いました。HTMLのサイトがあってそこにニュースなどの一部コンテンツのみ更新したいという要件ですかね。

そもそもそんなモノを WordPress の固定ページになぜ載せるのかというのはあるのですが、サイト内検索、お問い合わせフォーム等、WordPress の一部機能を使いたいなど理由は様々。ただその場合は WordPress を無理矢理使っている感も否めないなというのもあって悩みどころです。

「WordPress のテーマの実装に入ってからの手戻りとかがあった場合どうするの?」ってWCT2016のセッションのときに聞いたんですが、「そんな手戻り無い」って言われたのは結構大きな衝撃でした。ワークフロー次第だとは思いますが、HTMLをちゃんと作りきってしまえばそんなモノなのかもしれないです。

比較して思うこと

結論としてはどっちも有るなぁと言う感じです。「WordPress のテーマを作ること」と「デザインをコーディングすること」のどちらの比重が高いのかで最適なやり方は違うのかなと思いました。特にテーマとしての運用性よりもデザインの再現が重視されるような場合は、HTML作った方が良いのかなとも。

また普通に静的なHTMLとして作成して、サイト内検索は Google のカスタム検索などで実現するというほうが有用なケースも多々ありそうです。

既存のテーマをベースしたテーマ作成

  • とりあえず、最初からある程度の機能がそろってる。Jetpackの無限スクロールなどもサクッと対応できた。(_sの場合)
  • ベースにするテーマそのものへの理解が必要。(主に独自のテンプレートタグとはき出すHTMLへの理解)

というのがやってみて感じたことです。ブログなどががっつりメインコンテンツになるケースなどは _s 等をベースにすると割と便利な気がしました。

ただ、ベースにする以上はあまりPHPやHTML部分に関しては弄りたくないなというのがありました。というよりそこを弄りまくるならまっさらな状態から作った方が楽というか、ベースにするテーマに対する学習コストが無駄になるなという感じです。テーマごとにカスタマイズの流儀みたいなモノもだいぶ違うので基本的に HTML の構造への編集は最小限に抑えたいなという印象です。この学習コストというのが結構馬鹿にならないとは思っています。

そうなっていくと結構CSS力などが問われる場面も多かったような記憶があります。テーマには当然リセットやHTMLタグに対するベースのスタイルなども含まれているのでそこら辺をちゃんと踏まえないといけない部分は多い気がします。そういう意味では habakirilightning 等は Bootstrap ベースなのでそこら辺の知見が役に立ちやすいのかなと。

ハムさんの疑問への解答

Web上の投稿エディタでマークアップを入れなければ再現できないような場合…みなさんどうしています?

僕はショートコードを作成して対処することが比較的多いです。Shortcake を使うとビジュアルエディタへの対応もそこそこ簡単なのでそれが一番スムーズなのかなと思っています。

functions.phpでできることでもプラグインだけでできることはプラグイン優先で構築するべきかどうか

functions.php できることというよりは functions.php でやって良いことかどうかは基準です。自分で書く場合もテーマに乗せるべきモノはそっちに書きますが、カスタム投稿タイプやショートコード、アクセス解析のコードなど、テーマが変わっても機能するべきところはテーマでは無くプラグインで実装します。

ここら辺は、WordCamp Tokyo 2016 で Mignon Style さんがお話しされていた、「ノンプログラマーのためのWordPressテーマ作成ステップアップ術」が詳しいです。

サイト用のプラグインを作ったり、mu-plugins にそのサイト用のコードを置いておくのが多いです。3行とかのコードでも別々のプラグインにしたりとかもやったりします。

ただ、全ての機能を自分で作るなんて言うことは無く、公式ディレクトリにあるプラグインで済むモノは積極的に利用しています。自分で作ったからといって、それが積極的にメンテナンスされるという保証も無いですし。

プラグインの選定基準は機能が要求に合っているかどうかは当然ですが、作者の人が積極的にメンテナンスやサポートをしているかどうかを割と重視して選んでます。コミットメントがあまり活発でないものはあまり使わないですね。

またテストとかがないものや、あまりにもコードが読みづらいモノは避けたいとも。バグを踏んだり足りない機能があったらそれはプルリクエストなりパッチを送ろうぜ!と思っているので、それがやりづらいプロダクトは避けたいなという感じです。

さいごに

去年のハムさんの記事を読んで便乗エントリーをしようと思っていたら1年経ってしまいました。WCT2015で初めてハムさんとお会いしてからと言うもの、毎度毎度この話をしてる気がします。(主に懇親会で飲みながら延々と)

デザインから WordPress のテーマ作成までの自分のワークフローを見直す

仕事の進め方、チーム、仕様など様々な理由で最適解は違うなぁというのがこの1年の僕の感想です。ただそれによって設計や求められるスキルも変わってくるのでどう対応していこうかなというのは悩みどころです。REST API も 4.7 で本体にマージされたので、ここら辺の話はますます変わっていくのかなというところです。そうはいってもテーマをいきなり作る派であることは変わらないので、またハムさんとお酒を飲んだときにでも決着を付けようと思っていますのでよろしくお願いします!

 

WordPress 4.7 に更新したときに管理画面が突然英語になってしまったら

注: WordPress 5.0 に 更新した際に、一部環境で管理画面の翻訳がロードされない不具合があるようです。それについては、WordPress 5.0にしたらGutenberg(グーテンベルク)の一部が翻訳されない現象と対策 – More Publishing をご覧下さい。

 また、5.0.1 で修正される見込みです。#45528 (load_script_textdomain() doesn’t load translations when WP installed in a subdirectory with custom content dir) – WordPress Trac

追記終わり

WordPress 4.7 がついにリリースされました!詳しい変更内容は、Version 4.7 – WordPress Codex 日本語版 を読んで頂ければと思います。

今回の変更の一つに、ユーザー管理用言語およびロケールのスイッチ というものがあります。これの初期値がうまく設定されていないのか、WordPress 4.7 にアップデートした際に突然管理画面が英語になるという問題が起きました。僕の手元だけっぽいですが。

とりあえずそうなってしまった場合は、管理画面の 「Users」->「Profile」 URLで言うと、/wp-admin/profile.php 、マルチサイトの場合は、wp-admin/network/profile.php で自分の言語を変更出来ます。

Language という項目があるので、ここを日本語にセットしてあげれば管理画面が日本語になります。

複数のユーザーがいる場合は、各ユーザーのプロフィールページにて、「サイトデフォルト」もしくは、「日本語」に設定してあげて下さい。

Vue + Vuex を使ってみた感想と、Redux との比較

いいにくの日ですね。肉食べたいです。

React + Redux にはよくお世話になっている昨今なのですが、React 以外も扱いたいなと思ったこと、そもそも Flux に対する理解が浅いんじゃ無いか?ということで、Vue.js + Vuex をちょっと勉強してみました。

つくったもの:https://github.com/torounit/vuex-todo

ここら辺をいろいろ参考にしました。

Redux と Vuex の違い。Reducer と Mutation の違い。

flow

両方とも Flux パターンであるため、基本的な考え方は変わりません。ただ、Redux で Reducer が担って役割が、Mutation というモノが処理することになります。

Redux では ActionType に応じて Reducer が State を変更という流れですが、Vuex の場合は Action 側から MutationType を指定して値を投げるという流れになります。

複数の State の変更が同時に変化するような場合だと、Action から 複数の Mutation をそれぞれ呼び出すということになります。Redux だと、ある Action に対して複数の Reducer が紐付くという格好になるので、ここら辺の考え方が逆転しています。

Vuexのドキュメントを参照すると結構解りやすいです。 Actions · GitBook

actions: {
  checkout ({ commit, state }, products) {
    // save the items currently in the cart
    const savedCartItems = [...state.cart.added]
    // send out checkout request, and optimistically
    // clear the cart
    commit(types.CHECKOUT_REQUEST)
    // the shop API accepts a success callback and a failure callback
    shop.buyProducts(
      products,
      // handle success
      () => commit(types.CHECKOUT_SUCCESS),
      // handle failure
      () => commit(types.CHECKOUT_FAILURE, savedCartItems)
    )
  }
}

一つの Action がどういった変更を起こすのか等が局所的になるので、結構解りやすい気がします。

また、Mutation に渡される state ですが、単純に、現在の State オブジェクトそのものです。なので当然参照渡しです。これを直接弄ります。

mutations: {
  increment (state, n) {
    state.count += n
  }
}

テストの書きやすさ等には結構影響してきそうです。

Vue.js の デバッガーが強力

Chrome の拡張機能で Vue.js devtools がかなり強力でした。

Vuex にも対応していて、過去の State の状態に戻したりなどシンプルながら必要な機能がそろっている感じです。GIF アニメを撮ったので、そちらをどうぞ。
vue-debugger

 

感想

正直、Flux への理解が浅いまま Redux を触っていたので、いろいろと Vuex を触る上で逆に苦労したりしましたが、なんとなく Flux ってこういうモノかというのがつかめてきた気がします。

最初は、Riot.js + RiotControl をやってみようと思ったのですが、RiotControl のソースコードがめちゃくちゃシンプル(20行)で、逆にどうして良いか解らなかったんですが、さっき改めて読んでみたら解った気になってきたのでこっちでも遊んで見ようと思います。

Vue.js 自体は、ドキュメントが整備されていてローカライズもされているので割と取っつきやすいですし、デザイナーさんとかと組んだときとかに結構便利そうな気がしました。特にCSS周りは React だとお世辞にも良いとは言いがたい状況なので、なかなか良い感じです。また、公式のデバッグツールや vue-cli 等のツールがそろってるのも結構便利ですね。

やっぱり自分で手を動かしていろいろ書いていくのは学びがあって良いですね。

VCCW 3.0.0 beta 1 がリリースされました。

VCCW 3.0.0 のベータ版がリリースされました。僕もいろいろプルリクエストを送ったりしたので触ってみてもらえると嬉しいです。

  • CentOSからUbuntuに変更。
  • ChefからAnsibleに変更

等を行いました。VCCWのC2つが消えてしまったのでこのままVCCWと呼び続けて良いのかは疑問ある感じですね。かなり大規模な変更を行いました。起動も速くなったりしました。

でも使い勝手は基本的に今まで通りのはずです。

大規模な変更するために役に立ったこと

OSや構成管理ツールが大きく変わったわけですが、使い勝手がほぼ変わらないままというのはなかなかすごいことです。そのときにめちゃめちゃ威力を発揮したのがServerspecです。

Serverspec

serverspec

サーバーの構成や設定ををテスト出来るツールです。詳しい説明は、「Serverspec」を使ってサーバー環境を自動テストしよう – さくらのナレッジ 等を参照してください。

VCCWにはServerspecが導入されていたので、基本的にはこのテストが通ればOK!ということでかなり思い切った変更が出来ました。テストって本当に偉大です。

そしてVCCWの作業中にServerspecにもプルリクエストを送ったらマージされました。めちゃくちゃ嬉しいです。こうやってRuby力も徐々に鍛えられていくのですね。

それにしても「オープンソースはワークフロー」とはよくいったものです。

 

というわけで、新しいVCCWをお楽しみ下さいませ。