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

      投稿者 時刻: 0 件のコメント:
      ラベル:

      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

      投稿者 時刻: 0 件のコメント:

      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 の概要


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

      HTTP2_PUSH で動作確認


      まずは WordPress 内の１ファイルを対応してみましょう。
      別に 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 は出てきませんね。 

      ということで、１ファイルごとの設定は使えたので 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を読み込ませていると、「１」には引っかからないので、「２」で個別指定する必要があります。

      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

      投稿者 時刻: 0 件のコメント:
      ラベル: , ,

      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
      投稿者 時刻: 0 件のコメント:
      ラベル: ,

      2018年2月9日金曜日

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

      前に「コマンドツールで MAMP を SSL 対応しよう！ - macOS High Sierra 編 -」にて、MAMP で SSL対応するぜぃってやったのですが、このときは１サイト限定でした。まぁ一時的にテストするだけだし、問題ないでしょって思ってたら、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 の２つを追加したいとします。

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

      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. 「１」で入力したパスワードを入力（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
      コマンドを実行して「１」からやりなおそう。

      Write out database with 1 new entries
      Data Base Updated

      5. 「１」で入力したパスワードを入力（SSL証明書からパスワードを抜く）
      Enter pass phrase for vhosts/subdomain.example.com.key:
      writing RSA key

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

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

      フォルダ構成

      /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

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

      Step 2. Virtual Host 設定（httpd-ssl.conf）


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

      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
      の２つのフォルダを作成しておいてください。
      また 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
      投稿者 時刻: 0 件のコメント:
      ラベル: ,

      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経由でしかアップデートできない（頻度が低いと・・・）
        • 発表された瞬間ぐらいで不正アクセスされて間に合わなかった
      • どこからのアタックが多い？
        • ウクライナとか...（２名ぐらいの声が...）
          ただ攻撃者は大体身元がわからないように迂回するので、必ずしもウクライナから攻撃されているわけではない。
          ※ 第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歳のときに吉本興業の門を叩く...
      月収１万円以下だった...

      アメリカへ...いったり、サービス業関連のマネージャーをしたり、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

      投稿者 時刻: 0 件のコメント:
      ラベル:

      2017年11月16日木曜日

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

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

      開発した宮内氏は、筆者も WordPress 管理運用をする上で欠かすことのできないコマンドラインツール WP-CLI チームの日本唯一のコミッターです。WP-CLIのコミッターになってからの４週間でやったことと感じたこと（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 にてプラグインを２度アップデートしたと記録に入っていますネ！その通り！

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




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

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

      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番目は更新プラグインがないのでログには記録されていません。
      ※２度目のプラグイン更新の意味は、時々 WordPress の新バージョンのみ更新可能なプラグイン（プラグイン新バージョンが新しい WordPress を求めている場合）があり、新バージョンにしてから更新リストに出てくる時があるため。



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

      ２，３のサイトで数日テストして問題ないようなら、
      【備忘録】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

      投稿者 時刻: 0 件のコメント:
      ラベル: , ,
      登録: 投稿 (Atom)