2018年6月24日日曜日

WordBench 大阪 6月(2018-06-23)に登壇して #wbosaka #wordpress

筆者調べでは、第77回にあたる今回、WP-CLIのハンズオンをすることにしました。少し前に開催された WordCamp Osaka 2018 で、WP-CLIのセッション(「WP-CLI を活用したメンテナンスフリーな WordPress の管理運用」)をしたのですが、その資料を作成しているとき、これは言葉だけでは凄さがあまりわからないので、是非体験してほしいなぁと思ったこと、そのセッションに出られないのが残念だというメッセージをもらったことがきっかけでした。WordCamp Osaka 2018 で宣言したとおり、本日開催することができました。




当初定員15名に対して即時に定員オーバーしてしまって、25枠に増やし、それでもオーバーしたので、直前には30名まで拡充しました。最終的に、当日25名(+メンター、運営メンバー)の参加登録がありました。これもメンターそして運営の皆様をあわせて 9名もの方々のフォローがあってこそです!

当日も8テーブルありましたが、ほぼ埋まるぐらい盛況でした、ありがたいことです!

プログラム




セッション



セッション内容は、WordCamp Osaka 2018で発表した内容をベースに、ハンズオンを見据え修正しました。。ハンズオン資料をみて事前にハンズオンしてみたメンターから指摘があった、Macが古すぎると WP-CLIのPHP 5.3.29 を満たさない PHPがあって躓くよ〜ってのことに対する注意をすることにしました。実際には php -v をしてもらって、 5.3.29 未満なら、MAMPや homebrew など、仮想環境ではない Mac上で動作することのできる php をセッション中にいれてもらっておくという感じです。こういうのはメンターいないと難しいですよね。メンターの皆様ありがとうございます。


ハンズオン


これまたメンターから「当日」の直前にいろいろ指摘をもらいました。
それぞれ、なるほどーと思いました。WordPress のハンズオンって、WordPress が入っていることを前提に進めることが基本だったので、今回ガチに WordPressをインストールするところをするので、各端末の個別問題なんかの影響をもろに受けるんですよね。パソコンは生き物ではないですけど、生き物のように十人十色は反応を示すこともあります。そういうところも面白いのですが、ハンズオンでは大変ですね (^^;

基本的にスライドを見ながらやってもらえれば、出来る内容にしています。
もちろん、事前にメンターがスライドを見ながらハンズオンされた結果、出来たけどひっかかったところもあったということでした。また、ハンズオン中、およびその後から様々な指摘を受けました。

さらにMAMP(Mac)の利用者ごめんなさい。
mysql の Path設定をうっかり(筆者は /usr/local/bin/mysql を別途いれてた)忘れていて、wp-installer.sh がうまく実行できないことがありました。

これらすべての指摘と回答については、


のコメント欄にまとめています!

P. S.
SpeakerDesk ってスライド修正してアップしても、ダウンロードは反映されていますが、スライド表示は修正されないんですよね。。仕様なのかなぁ。なので一度スライド消して新規アップしなおしました。もし23日の時点でスライドへのリンクをはったり、スライドを埋め込んだりしている場合には、変更してくださいませー。


2018年6月24日 @kimipooh

2018年6月3日日曜日

WordCamp Osaka 2018 に参加・登壇して #wcosaka2018 #wordcamp #wordpress

今回は、スピーカー&実行委員として参加しました。



 
実行委員としては、広報チームで英訳担当をし、ブログの英語翻訳、海外スポンサーや問い合わせなどに対する主に英語での返信の英文チェックや作成をしていました。

ウェブサイト


英語情報はほぼすべて(1記事以外)担当するなど、昔に比べて英訳のスキルも上がったなぁと思いました。

関連情報(後付け)


あとで見直して備忘録として残しておきたいリンクをまとめておきます。



前夜祭にて


スピーカーと前日準備した実行委員が集まって前夜祭をしました。梅田ダンジョンに少しハマってしまい、抜け出すのに20分ぐらい右往左往してしまいました。方向音痴にとって夜は鬼門ですね...20時開始で、22時過ぎに帰りの電車がやばくなってきたので、先に帰りましたー。いろいろ話をきけて楽しかったです。

6月2日 DAY 1 (セッション)





さて、さすがに前夜祭で土地勘がついたので、梅田ダンジョンを抜けるのは一瞬でした。また前夜祭の時点で500枚のチケットが完売したという話をきいて、「おおおーー」とテンションがあがっていたのですが、当日朝から沢山の人が来て盛り上がっていました。多くのセッションで「部屋に入れません」「部屋から出られません」というすし詰め状態になるほどの盛況ぶり!



この日は、朝8:15 に集合し、当日スタッフとして撮影とタイムキーパーを若干手伝いつつ、登壇しました!WordCamp としては2年ぶりの登壇です。

登壇:WP-CLI を活用したメンテナンスフリーな WordPress の管理運用




WP-CLI との出会いは、2014年1月8日の自身がメモったブログあたりから使い始めたのかなぁと思います。大抵新しいシステムを利用するときは、技術的なメモを備忘録としてブログにして残すようにしているためです。それから、2014年8月24日の WordBench 大阪でコマンドから「DBの置換ができるじゃん!!」と衝撃をうけて、本格的に使い始めたのは覚えています。

それからずいぶん立ち、WP-CLI は WordPress をメンテナンスする上で無くてはならないツールとなりました。そこで今回持っている知識を伝えたいなと思って登壇したのでした。

  • プログラム:https://2018.osaka.wordcamp.org/session/wp-cli-maintenance-free/
  • ツッコミ(2018-06-08)
     Facebookのつぶやきで、更新手順は「本体更新→プラグイン更新」じゃないと危ないよっと WP-CLI コミッターの一人である宮内氏からツッコミを受けてなるほど~なーと思ったので修正。セキュリティソフトなど先に周辺ソフトから更新してからOSのアップデートをすることが日常的になっているので、プラグイン→本体の順にしていたのですが、むしろプラグインなどがWordPressの最新機能を使っていて、本体が古いままプラグインを先に更新すると、コケてしまうことがよくあるそうな。。。
  • スライド:




40名の部屋になんと60名が来てくれて大盛況でした!!
WP-CLI を知っている人が半数に満たないぐらい、使ったことがある人は10数名ぐらいな感じでした。デモを含めて話すこと 36分ぐらいで何とか収める事ができました。



このハンズオンを、6月の WordBench 大阪でやりたいなーと計画してます。

閉会式



多くの人が集まって、実行委員長の話に耳を傾けた後、実行委員、参加者のみんなで記念撮影をとりました!!!

撮影:WordCamp Osaka 2018 実行委員会
画像ソース:https://twitter.com/Next_Season/status/1002835799342104576


懇親会




閉会式後に同会場にて、懇親会が開催されました。250人ぐらいが登録していて、参加できなかった人たちもいるぐらいの盛況ぶりでした。

6月3日 DAY 2 (コントリビューターデイ)


※下記で顔が鮮明に写っている方々は、公開の許可を得てます。実行委員、許可を得ている方々以外は、顔をぼかしています。




テーマ・プラグイン翻訳(世話人:筆者)



Contact Form 7 で有名な三好氏と世話人をする予定が、三好氏のご都合で急遽一人世話人となり、あたふたしながらアドリブで対応しました。ちょうど 2016年の WordBench 大阪で発表した「WordPress の新しい翻訳システム「GlotPress」を使ってみよう!」というハンズオンの資料があったので、これを参考に、「UI 変わっているぞー」とツッコミを受けながらも、冒頭20分ぐらいやり方、注意点を説明。途中、質問を受けたり、難しい訳を一緒に考えたり、しながら一日を過ごしました。

始まる20分ぐらい前に急遽用意したリンク集


あとは、WordSlack (Slackを使ったチャット)の #translate チャネルで追加資料を提示してもったりしました。
=== こんな感じで ===
そちらにどのような方がいるのか分かりませんけど、どちらかというと取り組みが容易なのはテーマのほうでしょう。

どのテーマでも似たようなフレーズが使われるので、Twenty Seventeen などを流用して翻訳を進めることができます。
---
WordPress Translation Day 2016 日本語翻訳
---
人気プラグインTOP120の未翻訳情報です: 
Plugin Top120
================

などなど。


運良く、日本語のプラグイン翻訳を承認できる権限をもっている @hinaloe さんが参加してくださっていたので、実際に GlotPress で翻訳したものについて、その場でチェックしてもらって承認、拒否をした上で、参加者とともに「何故拒否したのか」を含めての説明と、どうしたらよいのかも含めてディスカッションをするなど、私も含めて参加者にとってとても有意義で刺激的な一日になったのじゃないかなと思います。
またチームを結成して1つの翻訳を分担したり、途中から来た人に自分が知り得た情報をもってやり方を教えてみたりなど、自主的にコミュニケーションを取りながら進めていたのも印象的でした。はじまったときは、20数名あつまったうち、翻訳経験をもっている人は3名でしたが、全員何らかのコントリビュートができたようで、よかったです!

活動内容(WordSlack から抜粋)


WordSlackは誰でも自由に参加できます。きになるようなら参加してみてください!!

==== テーマとプラグインの翻訳チームの活動 ====
katsushi-kawamori [12:51 PM]
以下のプラグインがアップデートで30くらい訳が追加されたので追加翻訳しました。本日は帰ります。あとはよろしくお願いいたします。 https://translate.wordpress.org/locale/ja/default/wp-plugins/wp-gdpr-compliance

kosgis [1:52 PM]
All-in-One WP Migration の本体翻訳しましたー!承認お願いします!(/・ω・)/
https://translate.wordpress.org/projects/wp-plugins/all-in-one-wp-migration/stable/ja/default?filters%5Btranslated%5D=yes&filters%5Bstatus%5D=waiting

kitakado_h [2:10 PM]
Debug bar の Readme を翻訳しました。よろしくお願いいたします。 
https://translate.wordpress.org/projects/wp-plugins/debug-bar/stable-readme/ja/default

kosgis [2:20 PM]
Duplicate Post の本体翻訳しました。よろしくお願いします!
https://translate.wordpress.org/projects/wp-plugins/duplicate-post/stable/ja/default?filters%5Btranslated%5D=yes&filters%5Bstatus%5D=waiting

sinack [2:43 PM]
Better Admin Bar の翻訳しました。宜しくお願いいたします。
https://translate.wordpress.org/projects/wp-plugins/better-admin-bar/stable-readme/ja/default

J.Sugiyama [3:02 PM]
Hello Dollyのプラグイン、埋まってなかったので翻訳埋めました
https://translate.wordpress.org/projects/wp-plugins/hello-dolly/stable/ja/default

Kana.K [3:06 PM]
Nuptialというテーマの翻訳をしました。よろしくお願いいたします。
https://translate.wordpress.org/projects/wp-themes/nuptial/ja/default

Yukinobu Asakawa [4:06 PM]
wp-simple-booking-calendarの翻訳をしました。よろしくお願い致します。
https://translate.wordpress.org/projects/wp-plugins/wp-simple-booking-calendar/dev-readme/ja/default

shintaro.m [4:20 PM]
basicstoreというテーマの翻訳をしました。よろしくお願い致します。
https://translate.wordpress.org/projects/wp-themes/basicstore

sinack [4:39 PM]
Better Admin Barの翻訳しました。承認お願いいたします。
https://translate.wordpress.org/projects/wp-plugins/better-admin-bar/stable-readme/ja/default

shuto0125 [4:40 PM]
All-in-One WP Migrationというプラグインの Stable Readme (latest release)を翻訳しました。
URLに関する(?)warningが出ていますが、確認よろしくお願いいたします。
https://translate.wordpress.org/projects/wp-plugins/all-in-one-wp-migration/stable-readme

kosgis [5:07 PM]
WP-PageNavi の翻訳もしました。よろしくお願いします!

Shu Kobuchi [5:08 PM]
Bitcoin Addressの翻訳を行いました。
https://translate.wordpress.org/projects/wp-plugins/bitcoin-address/dev/ja/default

kosgis [5:08 PM]
本体:https://translate.wordpress.org/projects/wp-plugins/wp-pagenavi/stable/ja/default?filters%5Btranslated%5D=yes&filters%5Bstatus%5D=waiting

========

他のチームの発表をきくと、数名のテーマレビュアーが誕生したり、Coreにマージされたり、WP-CLIのマージをしてもらったりなど皆さん結構真面目ですごい!と思いました。
他のチームもホットですね!!!

WordBench 行動規範について



WordSlack で議論されてる WordBench の行動規範についてのディスカッションが行われました。

どういうことか


※以下、筆者が感じ取ったことを言葉にしたものです。

WordBenchの裾野は現在かなり広がっている。現在の行動規範は、いくつかトラブルが起こりそうなことがでてきて、ちゃんとガイドラインを明示したほうがいいだろうというスタンスで公開された。しかし、その周知や認識が必ずしもうまくいっていない現状がある。そのため、今後どうしていきたいのか、どうしたほうがいいのかはみんなで話ってより良くしていったらいいんじゃないかという声が出てきているということ。

筆者も意見をいいましたが、総じて言えることは「今後どうしたら良くなるのか」という点でした。今後議論が深まっていくことでしょう。筆者も今後注目して、なにがしかの関わりをもてたらいいなと思いました。

昼食


何人かと高架下あたりの店をみてたら、なんとかなりのメンバーが集まっていた店があったので、合流しました。WordCamp Osaka 2018 のブログ「うめだランチマップ」で紹介されていた店「BARBARA market place」でした。

結構お腹がいっぱいになりました!



最後に!


最後に参加者とともに記念撮影!!みんなお疲れ様でした!!!でもブログを書くまでが WordCamp!!みんなもう少し頑張れ〜

撮影:WordCamp Osaka 2018 実行委員会

2018年6月3日 @kimipooh

2018年5月31日木曜日

ローカル開発環境で構築したウェブサイトを一時的に外部公開する方法(zuidoコマンド編 + ngrokも)

WP-CLI のコミッターとして活躍され、Vagrant を使ったWordPress の開発環境 VCCW の開発者をされるなど、WordPress 界隈でも有名な宮内氏が、また便利なツールを出したというつぶやきをみて使ってみました。

これを使えば、セミナー参加者へローカル開発環境においた WordPress あるいはサイトを見てもらうとか、一時的に公開してみてもらうに便利だよなぁと思います。

ただし無料アカウントでは、リクエスト数に 40回/分 という厳しめの制限がかかっているようで、2, 3人にみてもらうならともかく、何十人単位なら有料契約しないと使えないよね、、とは思います。このあたりも含めて、下記に紹介した宮内氏のブログを参考にしたらよいと思います!

ローカル環境のウェブサイトを外部公開ってなんだ?


宮内氏のブログ
で説明されています。要するに次のことができるってことです。

  • ローカル開発環境のウェブサイト:http://localhost/demo
  • 公開ウェブサイト:http://******.ngrok.io

この特徴は、「ローカル開発環境のウェブサイトはネットからアクセスできなくてよい」といいう点です。
ちゃんと調べていません。直感的には次のような動作をしているのかなぁと思います
(※ちょっと今多忙で調べている時間なし...以下、とりあえず動くまでを備忘録を込めてメモしておきます。)

ローカルで立ち上げた ngrok が http://****.ngrok.io と常に一定間隔で通信していて

http://******.ngrok.io

にアクセスがあれば、ローカルで立ち上げた ngrok のリバースプロキシを介して実際のローカル環境のウェブサイトにデータを取りに行って表示するように「直感」として見える。


zuido 動作に必要なもの


https://github.com/miya0001/zuido にかかれている条件(手持ちの macOS 10.13.4で試したところ)に加えて、 ngrok の設定ファイルが必要です(そのうち修正されるかもしれません)

  • $HOME/.ngrok2/ngrok.yml (空ファイルでもいい)
  • Node 8.x or later
  • macOS, Unix/Linux

インストール方法


以下、macOS 10.13.4 での説明です。

STEP 1.  $HOME/.ngrok2/ngrok.yml の作成


ターミナルアプリを立ち上げて




  • mkdir -p  $HOME/.ngrok2
  • touch $HOME/.ngrok2/ngrok.yml

  • として、zuido がチェックする設定ファイルを作成しておきます。空ファイルでOKです。

    STEP 2. Node のインストール


    筆者は 10.3.x のほうをインストールしました。
    よりダウンロードしてインストール。ターミナルから npm コマンドが使えるようになります。

    STEP 3. zuido のインストール


    ターミナルアプリを立ち上げて
    • npm install -g zuido
    とタイプすることで /usr/local/bin/zuido にインストールされます。

    STEP 4. /usr/local/bin にPATHが通っていることを確認する


    ターミナルアプリを立ち上げて
      • echo $PATH
      ****:/usr/local/bin:****
      のようにどこかに「/usr/local/bin」があればPATHが通っています。
      その状態なら、
      • which zuido 
      とコマンドの場所を探すと、
      /usr/local/bin/zuido
      と返事が返ってきます。
      PATHが通っていなければ、

      • touch $HOME/.bash_profile

      として、もしホームディレクトリに .bash_profileがなければ作成した上でこのファイルを開き
      • open -a textedit  $HOME/.bash_profile
      とコマンドをうてば、テキストエディタで、.bash_profile(隠しファイル)が開きます。
      ファイルの末尾に
      export PATH="/usr/local/bin:$PATH"
      を追加しておきましょう。
      次にターミナルを起動したときに、PATHに追加されているはずです。再度 echo $PATHや、 which zuido コマンドにて、PATHが通っていることを確認しましょう。

      zuido の動作確認をしてみる


      さて準備はうまくいきましたか。では実際に動作確認をしてみましょう。

      なお詳細は
      に詳しく書かれていますので参考にしてみてはと思います。

      http://localhost/demo 以下に WordPress をインストールしておきます。
      そしてブラウザから正しくアクセスできることを確認してください。



      さて、「ターミナル」アプリより
      • zuido  http://localhost/demo
      とタイプしてください。

      zuido v0.1.10 by Takayuki Miyauchi (@miya0001)
      Web Interface: http://localhost:4040
      Forwarding: https://◯◯.ngrok.io -> http://localhost
      Config Path: /Users/kitani/.ngrok2/ngrok.yml
      (Ctrl+C to quit)

      のようなメッセージが出てきて、https://◯◯.ngrok.io/demo がブラウザで開きます。
      そこで他の端末から、https://◯◯.ngrok.io/demo にアクセスできるかチェックしてみてください。



      のように出ましたか。ならば成功です。

      zuido の終了


      zuido が動いている画面で Control + c を押して強制終了してください。

      注意点


      http://localhost 以下が、https://◯◯.ngrok.io として公開されます。
      ので Virtual Host で http://◯◯.** としてしかアクセスできない場合は大丈夫ですが、http://localhost/*** でアクセスできる場合は全部見えちゃうのでお気をつけを!


      404 Not found が出た!?


      あれ。。。。。。でも他の端末だと動く何故!ってのをSNSで宮内氏につぶやいたら、修正くださいました!! zuido 0.1.10 では直ってます。さすがに対応はやい!
      どうやら、npm のバージョン違いだそうです。

      zuido をタイプしても無反応


      STEP 1.  $HOME/.ngrok2/ngrok.yml の作成

      が存在しないとそうなります。存在するか確認してなければ作成してください。中身は空でOKです。

      付録A.  https://localhost/demo (HTTPS サイト)の場合


      私の利用している MAMP は、https対応しています。毎回対応するのが面倒なので、下記にツールとやり方を公開してます。ツールでさっくりMAMPを SSL化できるでしょう。
      を参考にすれば ツールも公開しているので手軽に MAMP で HTTPS 通信(Chrome等ブラウザで信頼できると判断される状況で)できるでしょう。

      そうしておけば
      • zuido https://localhost/demo 

      などで何らエラーなく、 httpsサイトも利用することができます。

      付録B. ngrok を使ってみよう!


      zuido はうまく動きましたか。
      ついでに ngrok も試してみたいと思います。
      ただし ngrok でローカル開発環境の WordPress へ外部からアクセスすると、CSSや画像のリンクがおかしいらしく、ちゃんと出ませんでした。

      STEP 1.  ngrok のインストール


      Homebrew をインストールしているなら
      • brew cask install ngrok
      インストールしていないなら、
      • https://ngrok.com/ よりダウンロードして展開(解凍)==> ngrok
      • ngrok をパスのある場所におく /usr/local/bin 等

      STEP 2.  ngrok の動作確認


      ターミナルより
      • ngrok http 80

      とすると、
      • http://乱数.ngrok.io ==> http://localhost
      • https://乱数.ngrok.io ==> https://localhost
      へのフォワーディングが設定されました。
      ※乱数を固定のサブドメインにするには、ngrokの有料版が必要なようです。
      で、手持ちの MAMP で Apacheを 80/tcp 設定した上で起動すると

      http://乱数.ngrok.io/demo/

      でアクセスすると、http://localhost/demo のデータが表示されるということですね。
      この demo は WordPress で構築されていて、同じ端末だと問題なかったのですが、別ネットワークの別端末では確かにアクセスできたのですが、CSSや画像が読み込めていない感じです。

      ちなみに MAMPでHTTPS通信できるようにしているので、

      https://乱数.ngrok.io/demo/

      でもアクセスできます。ただしオレオレ証明書では駄目みたいなので、そのあたりはちゃんとしないといけません。そのあたりは筆者が公開してる
      を参考にすれば ツールも公開しているので手軽に MAMP で HTTPS 通信(Chrome等ブラウザで信頼できると判断される状況で)できるでしょう。

      とりあえずこれで動いたので ngrok を終了します。

      ngrok の終了


      ngrok が動いている画面で Control + c を押して強制終了してください。

      2018年5月31日 @kimipooh

      2018年5月19日土曜日

      【備忘録】WordPress 4.9.6 で GDPR 対応機能が追加

      どのようなものが追加されたかについては、

      を参考にすれば利用方法も含めて十分に分かると思います。

      私も微力ながら、GDPR関連の翻訳(WordPress コアの翻訳)の一旦を担うことができました。GDPR絡みのプラグインも出てきていますよね。この翻訳とかを6月頭にある WordCamp Osaka 2018コントリビューション DAY とかでやって、GDPRについて少し知識を増やそうかなぁ。
      (ちなみに筆者は、「WP-CLI を活用したメンテナンスフリーな WordPress の管理運用」で登壇&実行委員をしているので、WordCamp Osaka には両日とも参加予定)

      2018年5月19日 @kimipooh

      2018年3月13日火曜日

      【備忘録】nginx 1.13.9 で実装された http2_push_preload を WordPress で使ってみよう!

      WP-CLI チームメンバーとして有名な宮内氏が作成した

      についての情報をキャッチしたので、実際に試してみました。
      ちょっと戸惑った点もあったので、本ブログにて備忘録として残しておきます。

      準備


      • nginx 1.13.9(CHANGE LOG
      • PHP 7 以降
      • WordPress 4.9 以降
      • https://◯◯ なサイト
      です。準備については割愛します。
      また、macOS のターミナルからチェックする方法として、Homebrew をインストールしているなら
      • brew install nghttp2 
      として nghttp コマンドをインストールしておくと便利です。

      Server PUSH の概要


      情報は古いですが、
      にわかりやすく解説されているかなぁと思います。
      また、
      も分かりやすいかも。ようするに、リクエストされたファイル内で別ファイルを読み込んでいると、1ファイルずつやりとりせずに、一括でやってしまえという考え方。

      HTTP2_PUSH で動作確認


      まずは WordPress 内の1ファイルを対応してみましょう。
      別に WordPress 内である必要はありません。

      server{
          listen 443 ssl http2;
          ...

          location / {
            ...
            ...
            proxy_buffer_size   128k;
            proxy_buffers   4 256k;
            proxy_busy_buffers_size   256k;
            http2_push_preload on;

            http2_push /wp-content/themes/△△/top_bg.jpg;
            ...
           }
      }

      nginx の server 直下か、location 内に、ファイルごとに http2_push で指定します。
      ※ この技術は https かつ HTTP/2.0 を有効にしたサイトじゃないとダメです。
      ※ WordPress だと管理画面だけ https の場合もあるので、サイトまるごとでなくてもいけるとは思います。

      いずれも Chrome の Developer Toolsを開いて、Networkにて確認しています。
      その際、キャッシュを無効にするために「Disable cache」にチェックをいれています。


      設定前
      Intiator = (index)

      設定後
      Intiator = Push / (index)


      もし nghttp をインストールしてしているなら
      nghttp  -nv  https://◯◯/  | grep PUSH_PROMISE
      のように、サイトトップで読み込まれる https://◯◯/wp-content/themes/△△/top_bg.jpg について、Server Push に対応している表示がされます。

      なおディスクキャッシュが優先されるようで、キャッシュされていたら Push は出てきませんね。 

      ということで、1ファイルごとの設定は使えたので Server Push は使えてるということになります。あとは、 http2_push_preload のほうを利用できるように WordPress に組み込みます。http2_push_preload のほうは、適切な Link ヘッダーを出せばいいので、それをやってくれるプラグイン「HTTP/2 Server Push」(宮内氏作成)をインストールします。

      HTTP/2 Server Push プラグインの概要


      このプラグインは、ソースlib/function.php を見てみると
      1. wp_enqueue_style と wp_enqueue_script で読み込まれた CSS と JavaScript を読み取って Link ヘッダーを出す
      2. フィルタフック「http2_server_preload_items」で指定したファイル
        ※ https://github.com/tarosky/http2-server-push-preload の Customizing 参照
      を読み取って LINK ヘッダーを吐き出すようです。
      なので、テーマによって style.css に @import とかで CSSを読み込ませていると、「1」には引っかからないので、「2」で個別指定する必要があります。

      HTTP/2 Server Push プラグインのインストール


      1. https://github.com/tarosky/http2-server-push-preload/releases より  http2-server-push-preload.zip をダウンロードする
      2. 展開したフォルダを、WordPress のプラグインフォルダへ入れる
      3. WordPress 管理画面より、「Http2 Server Push」 プラグインを「有効化」する

      とまぁこれが一般的かと思いますが、composer と WP-CLI が導入されているサーバーだと(※注意:下記の方法だと、 nightly バージョンになりました。管理画面のプラグインやテーマの更新から安定版への更新 0.5.0 が出来ました)

      cd WordPressのインストールフォルダ
      cd wp-content/plugins
      git clone https://github.com/tarosky/http2-server-push-preload
      cd http2-server-push-preload
      composer install
      cd ../../../
      wp plugin activate http2-server-push-preload

      なんかで、ソースをダウンロードしてインストールして WP-CLI でプラグインを有効化するまでをコマンドラインで出来ます。

      動作確認


      ※ここでは、macOS 10.13.3 にいれた valet 環境を使って WordPress をインストールし、試しています( https://demo.test )。

      brew upgrade nginx
      sudo brew services restart nginx 

      として、nginx 1.13.9 をインストールして nginx を再起動しておいてください。
      そして、 $HOME/.valet/Nginx/demo.test の server セクションに
        
      のように、 
            proxy_buffer_size   128k;
            proxy_buffers   4 256k;
            proxy_busy_buffers_size   256k;
            http2_push_preload on;  
      を追加しておきます。
      そして
      sudo brew services restart nginx 
      をして nginx を再起動しておきます。
      ※ valet については【備忘録】 wp valet new コマンドで Error establishing a database connection が出る あたりを参考にしてみてください。


      Chromeで サイトにアクセスして、Developer Tools を開きます。
      Network タグで「Disable cache」にチェックをいれて、サイトを読み込み直します(Command+r)。
      すると、下図のように CSSやJavaScript ファイルの Intiator が「Push」となっていたらOK。


      そして、http2-server-push-preload プラグインを無効にすると下図のように、Push ではないことが確認できるはずです。


      ただし、テーマによって style.css に直書きとか、@import を使ってCSSを読み込んでいると、このプラグインの対象外になります。その場合には、管理画面で試してみて下さい。大抵のプラグインは、CSSやJavaScriptを読み込む時に、正しい手順をしていると思うので、うまくいくはずです。まぁ最悪サイトそのものには適用できなくても、管理画面は適用できて速くなる!ってことはあるかもしれませんね。

      2018年3月13日 @kimipooh

      2018年3月12日月曜日

      【備忘録】 wp valet new コマンドで Error establishing a database connection が出る

      WordCamp Kyoto 2017 に参加して #wckyoto2017 で Valet + WP-CLI によって、手軽に手持ち macOS に WordPress のテストサイトを立ち上げる環境を構築したのですが、

      wp valet new demo

      などと https://demo.dev を作成しようとすると、

      Error: Error establishing a database connection. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `localhost`. This could mean your host’s database server is down.

      というエラーがでてまともにインストールできなくなってしまいました。筆者だけの環境でそんなようなことが起こる可能性もありますが、何かのトラブルシューティングに使えるかもしれませんので、どういう対策をしたのか備忘録として残します。

      準備


      macOS に Valet や WP-CLI を導入する方法は割愛します
      WordCamp Kyoto 2017 に参加して #wckyoto2017 あたりや他のサイトをチェックしてみてください。

      .dev ドメインのままなら、 .test ドメインに変更しておくこと
      • valet domain test
      すると
      $HOME/.valet/config.json 
      "domain": "test" 
      $HOME/.valet/dnsmasq.conf 
      address=/.test/127.0.0.1

      と変更されているはず。

      wp-config.php の DB_HOST の値を 127.0.0.1 にする


      define( 'DB_HOST', 'localhost' );

      だとエラーがでて、

      define( 'DB_HOST', '127.0.0.1' );

      だとうまくいくので、これを直して WordPress をインストールするといけるということ。wp valet new では、DB_HOSTの設定はいじれないので、ちょっと工夫が必要。

      https://demo.test の作成手順


      便宜上、Valet のインストールフォルダは、$HOME/valet とする

      cd $HOME/valet
      valet park
      valet secure demo
      wp valet new demo
      cd demo
      rm -f  wp-config.php
      wp core config --dbhost="127.0.0.1" --dbname="wp_demo" --dbuser="root" --dbpass=""
      wp core install --url="https://demo.test" --admin_user="admin" --admin_password="admin" --admin_email="sample@example.com" --title="demo"



      という一連のコマンドでもって、 https://demo.test に WordPress を導入できます。
      wp valet new コマンドで、WordPress 本体のダウンロードまでは出来るけれど、WordPress のインストールでエラーになります。そこで、valet によって作成された wp-config.php を削除して、wpコマンドで改めて作成し、WordPressをインストールするとうことです。
      valet は、データベースのパスワードはなし(初期)なので、同じようにしてます。
      また説明上、WordPressのログイン ユーザー名とパスワードは共に admin にしてます。

      2018年3月12日 @kimipooh

      2018年2月9日金曜日

      【Virtual Host 対応】コマンドツールで MAMP を SSL 対応しよう! - macOS High Sierra 編 -

      前に「コマンドツールで MAMP を SSL 対応しよう! - macOS High Sierra 編 -」にて、MAMP で SSL対応するぜぃってやったのですが、このときは1サイト限定でした。まぁ一時的にテストするだけだし、問題ないでしょって思ってたら、Virtual Host で本格的なテスト環境を使いたいなんて人が出てきたのです!

      そこまでやる気なかったのですが、乗りかかった船ですし、まぁやってみようということで対応しました。

      ※なお Firefox については、例外設定をしないと何をどうしても自己証明書(オレオレ証明書)の場合にはエラーでます。中間証明書やそれを使った署名、サーバー証明書+中間証明書を作ったり、中間証明書も Mac 側で信頼できるように設定してもダメじゃーって感じなので、「MAMP にそこまで労力かける意味があるのか」と思い直しました。そのうちまた試すかもしれませんが、Firefox は無視します。動作チェックは SafariとChromeです。



      準備


      MAMP で SSL を起動するまでの準備は、コマンドツールで MAMP を SSL 対応しよう! - macOS High Sierra 編 - をチェックしてください。

      これを最後まですることで、 https://localhost については SSL 対応になります。

      Chorme 58 から必須になった SAN (SubjectAltName) には対応していますが、ワイルドカードには対応していません。ドメイン、サブドメインごとに実行してください。

      Step 1. example.com と subdomain.example.com の SSL 証明書作成



      上記より、「mamp-create-ssl-for-vhosts.csh」をダウンロードして、デスクトップにおいたと仮定します。また Virtual Host として、 example.com と subdomain.example.com の2つを追加したいとします。

      ターミナルアプリを起動して

      cd $HOME/Desktop
      csh -f mamp-create-ssl-for-vhosts.csh  example.com
      csh -f mamp-create-ssl-for-vhosts.csh  subdomain.example.com

      として証明書を作成してください。
      途中確認やパスワードの入力を求めてきます。パスワードはなんでもいいですが、入力したパスワードを何度かいれる必要があるので一時的には覚えておいてください。忘れたら、また同じコマンドを実行すると前の設定を消して再登録します。

      1. パスワード(パスフレーズ入力)

      writing new private key to 'vhosts/subdomain.example.com.key'
      Enter PEM pass phrase:

      2. 証明書情報の入力

      Country Name (2 letter code) [JP]:
      から始まる。全部なにも変更せずに Enterのみを押す。

      3. 「1」で入力したパスワードを入力(SSL証明書の発行)

      Enter pass phrase for ./private/ssl.key:

      4.  y を入力して Enter、確認画面が出るので y を入力して Enter(署名)


      Sign the certificate? [y/n]: y

      1 out of 1 certificate requests certified, commit? [y/n] y

      下記のようになったらOK。ここで fail になる場合にはうまくいっていないので、再度
      csh -f mamp-create-ssl-for-vhosts.csh  subdomain.example.com
      コマンドを実行して「1」からやりなおそう。

      Write out database with 1 new entries
      Data Base Updated

      5. 「1」で入力したパスワードを入力(SSL証明書からパスワードを抜く)


      Enter pass phrase for vhosts/subdomain.example.com.key:
      writing RSA key

      Apache起動時にSSL証明書のパスワード入力を不要するための措置。

      以上、今回は2つのドメインなので、2回やることになります。

      フォルダ構成

      /Applications/MAMP/conf/apache/ssl フォルダ以下に
      example.com.crt
      example.com.csr
      example.com.key
      example.com_nopass.key
      subdomain.example.com.crt
      subdomain.example.com.csr
      subdomain.example.com.key
      subdomain.example.com_nopass.key

      というファイルが出来ているはず。
      そのうち使うのは「青」の4つのファイルです。

      Step 2. Virtual Host 設定(httpd-ssl.conf)


      /Applications/MAMP/conf/apache/httpd-ssl.conf ファイルに下記の2つを追加します。

      1. NameVirtualHost *:443


      <VirtualHost> より前に設定しておいてください。


      2. example.com と subdomain.example.com 用の Virtual Hostの設定を追加

      末尾あたりに

      <VirtualHost *:443>
           DocumentRoot "/Applications/MAMP/htdocs/example.com"
           ServerName example.com
           SSLEngine on
           SSLCertificateFile /Applications/MAMP/conf/apache/ssl/vhosts/example.com.crt
           SSLCertificateKeyFile /Applications/MAMP/conf/apache/ssl/vhosts/example.com_nopass.key
      </VirtualHost>
      <VirtualHost *:443>
           DocumentRoot "/Applications/MAMP/htdocs/subdomain.example.com"
           ServerName subdomain.example.com
           SSLEngine on
           SSLCertificateFile /Applications/MAMP/conf/apache/ssl/vhosts/subdomain.example.com.crt
           SSLCertificateKeyFile /Applications/MAMP/conf/apache/ssl/vhosts/subdomain.example.com_nopass.key
      </VirtualHost>

      を追加。
      MAMPを再起動(サーバー停止 > サーバーを起動でOK)しておいてください。

      3. フォルダの作成


      アプリケーションフォルダ > MAMP > htdocs フォルダ以下に
      • example.com
      • subdomain.example.com
      の2つのフォルダを作成しておいてください。
      また index.html (HTML)をいれておくと確認しやすいでしょう。

      コマンドでやるなら

      mkdir /Applications/MAMP/htdocs/example.com
      mkdir /Applications/MAMP/htdocs/subdomain.example.com

      STEP 3.  /etc/hosts を編集して、 example.com, subdomain.example.com を名乗ろう!


      直接編集するのは
      sudo vi /etc/hosts 
      とかで出来ます。ただ vi の使い方がーってなるかもしれないので、 Hosts ってアプリをつかうのがオススメです。インストールすると「システム環境設定」にアイコンがでます。


      そして開くとグレーアウトして編集できないので左下にある「鍵」アイコンをクリックして、管理者モードにします。
      で 「+」ボタンを押して、下図のように example.com と subdomain.example.com に対して、 127.0.0.1 という自分自身を示すIPアドレスを指定してください。




      これで準備は整いました。
      後はブラウザから

      https://example.com


      https://subdomain.example.com


      にアクセスして安全と出れば成功です!

      注意!


      Hosts (/etc/hosts)にて、ウェブサイト(URL)の宛先を一時的に変えてしまうことで
      実環境のテストや、移行前のテストとかに活用できます。ただテストが終わったら、「チェック」を外して無効化しておかないと、/etc/hosts は DNSよりも優先されるので、いつまでたっても /etc/hosts で設定した宛先のままになるので注意!

      2018年2月9日 @kimipooh