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

2017年12月16日土曜日

第71回 WordBench大阪 2017年振り返り座談会&年忘れLT に参加して #wbosaka

会場のファーストサーバーのある建物おクリスマス風に変わってますね!



今回は飛び入り LT を募集するなど、かなり流動的なプログラムでした。
また会場での懇親会は、いつも食べ物余ったりするので飲み物だけになりました!
ちょうど昼は近くのガストで1200カロリーぐらいのハンバーガー定食を食べてしまい、有力は抑えようと思っていたのでちょうど良かったです!



プログラム



座談会


簡単な自己紹介


今年の WordBench 大阪のテーマを振り返って





WordBench 大阪で来年やってほしいテーマ

  • 公式プラグインの作り方をやってほしい
  • WordPress の動く仕組みについて知りたい
  • WP-CLIの使い方を知りたい
  • アンカンファレンスをやってほしい
    ※特定テーマについていろいろなタイプの人たちと話し合ってみたい
また近々 Google フォームあたりで募集するかも。

2017年の印象的だったこと

  • WordPress の REST API 脆弱性(2017年2月)- WordPress 4.7/4.7.1が問題だった
    • アップデートを止めていた(アップデートでコケたときの責任が取れない、予算が取れない等)
    • FTP経由でしかアップデートできない(頻度が低いと・・・)
    • 発表された瞬間ぐらいで不正アクセスされて間に合わなかった
  • どこからのアタックが多い?
    • ウクライナとか...(2名ぐらいの声が...)
      ただ攻撃者は大体身元がわからないように迂回するので、必ずしもウクライナから攻撃されているわけではない。
      ※ 第42回 WordBench大阪「WordPress とリスク管理」(スライド)で筆者が少し説明している。

など話はつきないが時間切れ。

LT(ライトニング・トーク)


WordPress のテーマ開発フローをブログに書いたお話(YAT)



を作った(6万文字!!)。
50時間ぐらいかかった。。書籍ぐらいの分量がある....
  • テーマの作り方をしっかり知りたい人
  • 安全なテーマを作りたい人
  • 100% GPL で公開してます!
  • Local by Flywheel を使ったローカル環境構築から説明してます!

WordPress プラグイン「UpdraftPlus」の紹介(覆面くんさん)一本目


WordPress のバックアッププラグイン です。
WordCamp Tokyo 2017 のアンカンファレンスでバックアッププラグインとして UpdraftPlus が上がってきた。(筆者もそのアンカンファレンスに参加した / 筆者ブログ参照

  • このプラグインは、本体とデータベース両方のバックアップができる。
    # ついでにプラグインやテーマなど個別に復元も出来る。
  • Google ドライブ等クラウドサービスへのバックアップが可能
    # バックアップ先に応じて費用が必要(拡張機能を拡張するプラグインが有料という感じ。Googleドライブは無料)
  • デフォルト保存先
      wp-content/updraftplus フォルダ内に入る

未経験から Web デザイナーを目指して、WordPress サイトを作った話(西村さん)


未経験だったころの話。
マークアップエンジニア。
2015年にデジタルハリウッド大阪校に入学するまで全くWebに関する知識は無かった。

小学校のお便りを作りたいときいて、そういったことをどうやればいいのだろうと思ったら、ピンクの髪の人が WordPress いいんじゃないと言われて CMS関連の情報を初めてチェックした。

  • とにかく調べる
  • とりあえず動かす
  • よく知っている人に聞けばいい
どうやってきく。。。。WordBench にいったらいい!!って気づいた!

しょーたさん


宣言がしたい!

18歳のときに吉本興業の門を叩く...
月収1万円以下だった...

アメリカへ...いったり、サービス業関連のマネージャーをしたり、ECサイトを使った物販してみたりしていたら、コンチ師匠...に出会って、 WordPress についてより深く知ってWeb構築についてを仕事にしたいと思った。。。あと海外との仕事をしたいと思っているから、来年海外に移住するぜ!!

という宣言。

# なかなか異色な方でした。喋るのがとても上手かった!

WordBench 京都への関わりと何を得たか(KONISHIさん)一本目


座談会やモブプログラムなどが盛り上がった。
勉強会とかコミュニティで発表していると、お誘いがくることがある。
登壇することで、登壇駆動でいろいろな勉強ができる。

なので参加するだけでなく、登壇もしてみましょう!!

WordBench 京都 怖い(KONISHIさん)二本目


迂闊なことをやると登壇させられるぞ!!

と聞いたけれど、そんなのは気のせいだよ!!

何故そのような噂が出てきたのか。

登壇に関して、巻き込み、狩り、拉致とかいう言葉を使って登壇者とやり取りをしているからかもしれない。

しかし巻き込まれた人からは、すごく勉強になってよかったという実感の声を聞く。
  • 100回の参加より1回の登壇の方が勉強になる!!
WordBench 京都は、一歩踏み出したい人をサポートするコミュニティです!
是非参加を〜

Quiita 版 WordPress - Advent Calendar  2017 の紹介(覆面くんさん)二本目


クリスマスまで一ヶ月間毎日ブログをアップするイベントのこと。
割りと沢山の種類の Adbent Calendar がある。


これまでの 15日間の記事内容を紹介。

WlrdCamp Osaka 2018 について(GOTENさん)


2017年6月2日-3日あたりを予定(まだ予定)

キックオフミーティングをしたよ!

# WordCamp とは WordPress に関する 公式イベント。

興味があれば実行委員になってみませんか!!


2017年12月16日 @kimipooh

2017年11月16日木曜日

LogBook プラグインを使って WordPress の重要操作ログを手軽に取ってみよう

LogBook プラグインは、WordPressの操作をログとして保存するプラグイン LogBook をリリースしました(TaroSky)で紹介されている通り、ログ関連のプラグインです。

開発した宮内氏は、筆者も WordPress 管理運用をする上で欠かすことのできないコマンドラインツール WP-CLI チームの日本唯一のコミッターです。WP-CLIのコミッターになってからの4週間でやったことと感じたこと(Capital P)での宮内氏の発言をみるだけでも、ものすごく沢山のコミットを積極的にされているのが伺えます(というか GitHUBみたら、最近の1年間は少なくても毎日なにかの更新されてます @@!)。

また見逃していましたが、「WP-CLIをつかってWordPressのDBをコマンド1回で別のサーバーに引っ越す」ってのは、すごすぎですよね!

また WP-CLI で引っかかるメモリ問題に関してもしっかり記事「WP-CLI でメモリ不足のエラーが出る時の対処法(Quiita)」をかいていて、これも活用させてもらってます。

さらには、最近 Google Analytics を埋め込むプラグインが Jetpack と相性が悪いのが動作しなくなったサイトがあったときに、宮内氏が開発されている WP Total Hacks にもお世話になってます。

その宮内氏が、サイトの重要なイベントに対して負荷をあまりかけずにログを記録するというプラグインを開発したとなれば、これはもう使ってみなくちゃいけません!

WP-CLI からプラグインのアップデートしたら





フムフム、サーバー上(127.0.0.1)から、WP-CLI にてプラグインを2度アップデートしたと記録に入っていますネ!その通り!

管理画面からプラグインを停止・有効化してみたら




ホウホウ、筆者端末のIPアドレスから、ユーザー kitani (筆者)で Antivirus プラグインを停止したと。

あれ、「なし」が入っているのはバグかな (^^; って思ったら、こちらの特定1サイトのみの現象でした。これはこのプラグインではなく別の何かに原因がありそうですね。

WP-CLI から バックアップ > プラグイン更新 > コア更新 > 翻訳更新 > プラグイン更新 をしてみたら




むむ、コア更新 > 翻訳更新しか記録されていませんね。
なぜかを検証してみましょう。

まずバックアップから翻訳更新までは、ちょっと特殊な更新方法をしています。
(wp は /usr/local/bin/wp)

  1. wp backwpup --jobid=ID番号
  2. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh 

という流れになっていて、赤文字のところだけが記録されています。

これを次のコマンドに変更して実行してみました。
  1. wp backwpup --jobid=ID番号
  2. wp plugin --all 
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin --all 
するとプラグインも認識しました。
6番目は更新プラグインがないのでログには記録されていません。
※2度目のプラグイン更新の意味は、時々 WordPress の新バージョンのみ更新可能なプラグイン(プラグイン新バージョンが新しい WordPress を求めている場合)があり、新バージョンにしてから更新リストに出てくる時があるため。



個別のプラグイン更新(wp plugin update ◯◯)はちゃんと登録できているので書き方なんですかねぇ。まぁもうcut を使ってアクティブプラグインだけ更新するのはやめたのでいいんですけどね。
※なお cut などを間に挟むようなことをしていたのは、特定プラグインを除くなどの目的だったのだが、wp plugin update --all --exclude=logbook などで logbook 以外のプラグインすべてをアップデートとかできちゃうので、もう不要なのですよね。

2,3のサイトで数日テストして問題ないようなら、
【備忘録】WP-CLI エイリアスを利用したリモートサーバーの WordPress 管理 #wckyoto2017
を参考に、
wp @all plugin install logbook
wp @all plugin activate logbook
で手持ち端末から WordPress やサーバーにログインせずに、一括インストールと有効化するかなー

ってことで終わりにしようと思いましたが、このプラグイン、日本語化されていないのですよねぇ。個人的には翻訳不要なのですが、翻訳する分量が 70ぐらいなので翻訳してみるかぁと思ってやってみました。

LogBook プラグインの翻訳




最近の WordPress プラグイン翻訳は、https://translate.wordpress.org より手軽にすることができます。自分のプラグインならどのような場面でその言葉を使っているかわかっていますが、他人が開発したプラグインは、その利用場面によって翻訳内容が変わるときがあります。
また翻訳するにあたっては、


を参考に、長音文字、受動態はできるだけ能動態へ変換する、半角文字と全角文字の間には、半角文字1字分のスペースを入れる、などのよくあるものに特に注意を払いながら訳していくことになります。
翻訳(実際には提案)が完了したら、日本語版 WordPress Slack の #requests チャネルで翻訳の承認を依頼します。そうすれば、翻訳の達人の皆さんがチェックをしてくださることでしょう、きっと。最終的には、承認権限をもっている方によって承認されれば、めでたくみんなが使えるようになるってことです。

各プラグインの翻訳トップページに移動するには、各プラグインのダウンロードページにアクセスし、下記のように出てくれば、まだ日本語翻訳されていないことになります。


下図のように表示されれば、少なくても一度は翻訳済みになります。
ただし、プラグインが更新されていくなかで、翻訳が不十分になっているケースもあります。「Help translate it!」あるいは「翻訳の改善のご協力ください」のいずれかのリンクをクリックすることでそのプラグインの翻訳トップに移動します。


LogBook は翻訳して承認待ちなので、Waiting に入っています。



すでに 100%翻訳されていて、承認済みの場合には下記のように 100% の表示になります。



確か 95% を超えて、これが承認されればプラグイン本体に翻訳が反映されるようですね!


2017年11月16日 @kimipooh

2017年10月31日火曜日

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

筆者は、長らく MAMP を利用してきました。
しかし WordCamp Kyoto 2017 を契機に、 valet というツールも積極的に使うようになりました。この valet のいいところは、VCCW, Wocker などの優れたツール同様、WordPress をインストールしたり削除したりする機能が盛り込まれているので、テスト環境を作成しやすいことです。また標準で 下図のように自己証明書エラーにならない常時SSL(https://◯◯.dev) が利用できます!



【Virtual Host 対応】コマンドツールで MAMP を SSL 対応しよう! - macOS High Sierra 編 - も公開(2018年2月9日)

valet では .htaccess が使えない


valet は Apache ではなく Nginx が利用されているので、 .htaccess が利用できません。WordPress を動作させるだけなら、それでも十分なのですが、SiteGurad プラグインなど、.htaccess が利用できることを前提に作成されたプラグインのテストが出来ません。また WordPress にかぎらず、Apache でテストしたいこともあるでしょう。

そういった場合には他のツールを利用する必要があります。

MAMP に欠けているもの


  1. WordPress の自動インストールと削除
  2. 常時SSL対応
MAMP PRO だとSSLには対応していたと思いますが、それもコマンドでできるわけではありません。コマンド一発でできることが重要なのです!

なお SSL化した場合、しなかった場合、いずれにおいても WordPress の自動インストールと削除ができるツールを
に置いてます。
詳しくはそちらをチェックしてみて下さい。

また MAMP で SSL を利用するためには、 Apache Port を 80 にしなければなりません。macOS の MAMP はデフォルトで 8888 なので、これを変更することになります。


そうするとこれまで http://localhost:8888 にアクセスしていたのが、 http://localhost になり、WordPress をインストールしていたら引っ越ししないと動かなくなります。

まぁそういう場合には、 アプリケーション > MAMP を別名にしておいて、再度 MAMPをインストールし、 2つの MAMPフォルダをつかいわけるとよいかと思います。
アプリケーション > MAMP とフォルダが決め打ちになっているので、利用したいMAMPフォルダをこのフォルダにもっていきます。

MAMP を SSL 対応するコマンドツール 「mamp-enable-ssl.csh」


にある mamp-enable-ssl.csh になります。

なんでそこまでやるのかという問いには、
  • 開発環境を変えるよりは簡単だから
と答えておきましょう。まぁ半分は趣味です。
Chomre 58 以降で必須になった SAN (SubjectAltName) にも対応してみました。

どうやって利用するの?


MAMPがインストールされていることが条件になります。
また openssl がインストールされている必要があります。
HomeBrew か Macports であらかじめインストールしておいてください。

mamp-enable-ssl.csh を仮にデスクトップに置いたとします。

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

$HOME/Desktop/mamp-enable-ssl.csh

※それで下記がでなければ、
csh -f $HOME/Desktop/mamp-enable-ssl.csh をタイプしてみてください。

をタイプすると、

Generating a 2048 bit RSA private key
......+++
.......+++
writing new private key to 'private/ssl.key'
Enter PEM pass phrase:

とパスフレーズを聞いてきます。
これは CA認証局用のパスワードです。
まぁ自分しか使わないのでなんでもいいです。入力したら Enter を押して下さい。

Verifying - Enter PEM pass phrase:

と今入力したパスワードの確認が必要になりますので、入力して Enter を押します。

-----
Country Name (2 letter code) [JP]:

次に、CA認証局用の情報入力画面が出てきます。
予め openssl.cnf にて入力済みなので、7回 Enter を押してそのままにしましょう。

State or Province Name (full name [LOCAL]:
Locality Name (eg, city) [LOCAL]:
Organization Name (eg, company) [MAMP]:
Organizational Unit Name [MAMP]:
Common Name (eg, YOUR name) [localhost]:
Email Address []:
Generating a 2048 bit RSA private key
.....................................+++
..............+++
writing new private key to 'server.key'
Enter PEM pass phrase:

すると、またパスフレーズ入力画面で止まります。
先程入力したパスフレーズを入力して Enter を押してください。

Verifying - Enter PEM pass phrase:

と今入力したパスワードの確認が必要になりますので、入力して Enter を押します。

-----
Country Name (2 letter code) [JP]:

次に、SSL証明書のための情報入力画面が出てきます。
予め openssl.cnf にて入力済みなので、9回 Enter を押してそのままにしましょう。

State or Province Name (full name [LOCAL]:
Locality Name (eg, city) [LOCAL]:
Organization Name (eg, company) [MAMP]:
Organizational Unit Name [MAMP]:
Common Name (eg, YOUR name) [localhost]:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from openssl.cnf
Enter pass phrase for ./private/ssl.key:

すると、またパスフレーズ入力画面で止まります。
※これによって、作成した SSL証明書にCA証明局による署名をします。
先程入力したパスフレーズを入力して Enter を押してください。

Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'JP'
stateOrProvinceName   :ASN.1 12:'LOCAL'
localityName          :ASN.1 12:'LOCAL'
organizationName      :ASN.1 12:'MAMP'
organizationalUnitName:ASN.1 12:'MAMP'
commonName            :ASN.1 12:'localhost'
Certificate is to be certified until Oct 29 08:13:51 2027 GMT (3650 days)
Sign the certificate? [y/n]:

すると、署名をしてよいかどうか聞いてくるので、y をタイプして Enter を押してください。

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

すると、署名を有効にしてよいかどうか聞いてくるので、y をタイプして Enter を押してください。

Write out database with 1 new entries
Data Base Updated
Enter pass phrase for server.key:

これで署名完了です。
最後にまたパスフレーズを聞いてきます。先程入力したパスフレーズを入力して Enter を押してください。

※これは、Apache に埋め込む証明書のパスワードを削除するためです。
そうしておかないと Apache を起動しようとしたときに、最初にいれたパスフレーズを毎回いれなければなりません。それを回避するためです。

writing RSA key

これで設定は完了です。

次に、CA証明書ファイル「MAMPフォルダ > conf > apache > ssl > ssl.crt 」 を macOS のキーチェーンに登録します。

CA証明書ファイル「MAMPフォルダ > conf > apache > ssl > ssl.crt 」を開いて下さい
下図のような画面になりますので、そのまま「追加」してください。
次に追加した CA証明書ファイルを「信頼」する設定をします。
アプリケーション > ユーティリティ > キーチェーンアクセス を開いて下さい。

そして「localhost」で検索すると先程インストールした「証明書」があると思います。
この時点では証明書は信頼されていません。


これをダブルクリックして設定を開いて下さい。
そして「信頼」にある SSL (Secure Sockets Layer) を「常に信頼」に変更してください。


すると、今 macOS にログインしているユーザーのみ、この証明書を信頼したことになります。



MAMPを起動してみよう!


問題なく起動したら、 https://localhost にアクセスしてみてください。


と出てきたら成功です。


と出てきたら、Cookieやキャッシュが残っている可能性があるので、それらを削除した上でブラウザを起動しなおしてみてください。あるいはそれが面倒なら、ゲストモードやプライベートモードを利用してみてください。

もし下記のようなエラーが出た場合には、「キーチェーンアクセス」にインストールした自己証明書が存在しないか、「常に信頼」設定をしていないことになります。再度チェックしてみてください。


もし途中でパスフレーズを忘れてしまった場合


再度

$HOME/Desktop/mamp-enable-ssl.csh

をしてやり直せばよいです。
初期化してやり直してくれます。

SSL 対応をやめたい場合にどうすれば?


いくつか方法があります。

  1. MAMPフォルダ > conf > apache > httpd.conf の下記をコメントする
     # Include /Applications/MAMP/conf/apache/httpd-ssl.conf
     と先頭に # を入れる。そして MAMPを再起動
  2. MAMP設定で nginx に変更する
     ※ nginx は SSL非対応
  3. MAMPを再インストールする
    1. MAMPフォルダの db と htdocs フォルダをバックアップし、 MAMPフォルダをまるごと削除
    2. MAMPをインストールし、バックアップした db と htdocs を戻す

Appendix. このツールはどういう動作をするの?


大まかな流れを説明します。
  1. openssl がインストールされていることを確認(Homebrew or MacPorts or /usr/local/bin/openssl が存在するかどうか)
  2. MAMP の conf/apache/httpd.conf を書き換え、conf/apache/httpd-ssl.conf を読み込むようにする
  3. conf/apache/extra/httpd-ssl.conf --> conf/apache/httpd-ssl.conf にコピーし、必要な置換を行う
    1. 証明書関連
    2. ログ関連
  4. CA 認証局 & SSL 証明書を発行(sha256, 2048bit)
    1. conf/apache/ssl フォルダを作成(存在したら削除し、作成)、サブフォルダ等作成
    2. conf/apache/ssl/openssl.cnf を生成
      ※中身は、本スクリプト内に埋め込み
      ※ここの localhost を別の名前にしたら、独自ドメインなども利用可能です。もちろん別途 /etc/hosts に 127.0.0.1 に対して 独自ドメインを有効にする設定が必要です。
    3. 各種証明書の発行

2017年10月31日 @kimipooh

2017年10月15日日曜日

第69 回 WordBench 大阪「WordPress ログインに Google 認証を使ってみよう」で登壇して #wbosaka #wordpress #google


今回は登壇者として参加しました。
セッションとハンズオン合わせて 3時間ほど時間をもらっていましたが、みんな優秀で 1時間強でセッションとハンズオンが終わってしました @@!
ハンズオン自体はおかげさまで好評だったようで、それぞれの実環境やクライアント環境で導入するというと言ってくださった方々がいたのでやったよかったかなと思います。

雨が降る中、会場となるファーストサーバー大阪本社へ、参加登録していただいた19名(内メンターが2名)について、全員参加していただきました。ありがとうございます!




登壇者って凄いのって思われるかもしれませんが、WordBench 勉強会に関してはそうでもありません。発表することでより深く WordPress について勉強することができるので、◯◯についてもっと詳しくなりたいな!と思ったら、発表者になってみるのもよいですよ!昔、「1週間後にクライアントに納品する WordPress はあるけれど、手持ちには 静的HTMLで作ったデータしかない、どうやって WordPress にしたらいいですか」を参加者に聞くために登壇者になった強者もいました。実際その場で逆ハンズオン(参加者が登壇者に教えていく)をしたわけですが、そういうのもありじゃないかなーと思います。

今回の反省点はこれだけ時間的余裕があるなら、「WordPress のローカル環境を手軽に作成してみよう!」なんてのを合わせてやってもよかったなぁと思いました。人によっては vagrant 環境を以前入れていたが、久しぶりに動作させようとすると動かなかったりした方もおられました。ので、そういうのを合わせてやるといい感じかなと。また機会があれば、WordCamp 等でやってみたいですね。

特に今回のために、 MAMP にコマンド一発で WordPress をインストールしたり、削除したりするツール(GitHUBで公開)を作成したので、MAMPとツールを使ったハンズオンもよいかなと思いました。ただMacしか試してないので、今回のように参加者全員が Mac ユーザーでないかぎり、Windows のことを考えないといけないので、そこはいろいろ試さないといけませんよね。

スライド




セッションとハンズオンの内容もすべて網羅しています。
これを見れば問題なく導入可能かと思います。
ただ2,3戸惑った方がおられたので、そのケースについて下記の紹介しておきます。

スライド19〜21において、Google Developer Console (Google Cloud Console内)のAPI設定におけるいろいろなケースについて紹介しています。
そこで漏れていたのが、ポート指定されたURLです。

http://localhost:8888/demo/  の場合にはどういう指定がしたらよいか


認証済みのJavaScript生成元:http://localhost
認証済みのリダイレクト URI:http://localhost:8888/wp-login.php


となります。
認証済みのJavaScript生成元については、 http://localhost:8888 をいれて保存すると自動的に、http://localhost に修正されます。

Appendix. WP-CLI コマンドで WordPress の自動メンテナンス


時間が余ったので何名かとこの話題について話しました。
ssh ログインが出来るサーバー なら出来る可能性があります。
実際には、WP-CLIコマンドをインストールできて(パスのある場所にダウンロードした WP-CLIを置くだけでいい)、cronが使えたら完璧です。当方は AMIMOTO のマネージドホスティングを使ったりします。ssh でログインできれば大抵のところはインストールできるんじゃないでしょうか。
それができれば上記のように、コマンド一発で、WordPressのバックアップ > プラグイン更新 > 本体更新を自動化できるので、多数の WordPress のメンテナンスを抱えている方々にとっては管理がとても楽になります。

wp @all  core version

なんてのを手持ちの Mac なんかでターミナルから叩くだけで、設定した全サイトの WordPress のバージョン情報が出てきます。これって深刻なセキュリティ脆弱性が報告された際、メンテナンスが必要な WordPress にログインしなくても、それぞれの現在のバージョンが一括で表示できるので超便利ですよ!

これもハンズオンしたら面白いかもしれませんね!

昼食&懇親会


昼食は会場であるファーストサーバー大阪本社から近い所にあるガストで肉を食べました。

ちょっと肉がかたい感じがしましたが、まぁやすいのでそれもまたよし。

懇親会は、GOTENさんが音頭を取って開始!懇親会費は1000円なり〜


結構はやくおわったせいで、ピザがなかなか届かずに、お菓子と飲み物で楽しく歓談できました!


2017年10月15日 @kimipooh