ラベル ツール の投稿を表示しています。 すべての投稿を表示
ラベル ツール の投稿を表示しています。 すべての投稿を表示

2024年4月26日金曜日

Studio by WordPress.com - オープンソースの WordPress ローカル開発環境を試してみた!(なかなかよさそう)

Xのようで情報が流れてきたので試してみました。ローカル環境系はいろいろありますが、ネット上でサイトを一時的にシャアできる機能が無料で使えるのは重宝しそうです。ただし、Apacheなどは使われていないということ、シャアしたサイトは静的HTML化されているのか、あるいは制限されているようにみえるので、.htaccess によるパスワードロックも使えませんでした(test.php などをアップして、PHPコードを含むサイトを表示させようとしても表示できなかった)。また、HTTP Auth プラグインについても設定を保存できないなど使えませんでした。そのため、秘匿性の高いサイトでのシャアは現時点では使えないかもしれません(まだ私がやり方をしらないだけの可能性もあり)。

下記が公式アナウンスになります。

Studio by WordPress.com: 無料でオープンソースの WordPress ローカル開発環境 – WordPress.com 日本語ブログ
https://wordpress.com/ja/blog/2024/04/26/studio/

さて実際にインストールしてみましょう。


STEP 1. ダウンロードとインストール


ダウンロードサイト:https://developer.wordpress.com/studio/

2024年4月26日時点では Mac( macOS )のみの対応です。

ダウンロードしたファイルを開いて出てきた Studio アプリを、アプリケーションフォルダに移動してください。


シャア機能をつかうには、 WordPress.com のアカウント(無料でOK)が必要です。せっかくなのでもっていなければ下記を参考に作成しておくことをオススメします。

WordPress.org アカウントの作成とログイン – サポートフォーラム
https://ja.wordpress.org/support/article/wordpress-org-account/


STEP 2. サイトを作成する


Studio アプリを開くと、最初のサイト作成画面になります。
このアプリが保存する WordPress は、$HOME/Studio(Macintosh HD > ユーザー > ユーザー名 > Studio)フォルダに保存されます。下記では wordpress フォルダに保存されます。

すると下記の画面になり、こちらからサイトや管理画面、その他テーマのカスタマイズへ直接アクセスすることができます。「実行中」をクリックすると「開始」ボタンに変更されて、システムが停止します。「開始」ボタンを押すと「実行中」になります。アプリを終了すると、自動的にシステムは停止するようで、次回アプリを起動すると「開始」ボタンがでてくるので開始をクリックしてサイトにアクセスできるようにしてください。

下記にあるように、設定から具体的なローカルサイトへのアクセスURLなどがわかります。localhost:8881 のようですね。


STEP 3. サイトを共有(シェア)してみよう!


シェアより、WordPress.com にログインします。アカウントを作っていないなら作ってからログインしましょう。


最初の1度のみ、下記のようにアプリが WordPress.com にアクセスするための許可を求めてきますので、Approve ボタンをクリックして許可します。



すると下記のようにサイトの作成が始まります。
うまく作成できれば、下記のようにデモサイトのURLが表示されます。ドメイン wp.build のサブドメインが付与(ランダム生成にみえる)されます。7日間保持されるようですね。なお「デモサイトを削除」すると、実際に消えるまで5分ぐらいかかる(即時消えるわけではない)ようです。

またサイト更新は、「デモサイトを更新」から更新します。こちらも即時更新ではなく、しばらくまったら更新されているという感じでした。





付録. Studio アプリが利用している PHP やデータベースの種類は?


2024年4月26日時点では、PHP のバージョンは 8.0.30-dev でした。


データベースについては、 SQLite を使っていました。下記の右上に「Database: SQLite」と書かれています。




私自身は試したことがないのですが、下記などをみると SQLite を WordPress のデータベースとして使うように構築できるようですね!

WordPressをSQLiteで動かす方法|さくらサーバーライトでWordPressを動かす | 【2024年】おすすめアフィリエイトASP選び方!ブログ初心者おすすめ

2024年4月26日 @kimipooh

2020年12月11日金曜日

Travis-CI と GitHUB連携で WordPress プラグインの PHPUnit によるテストを実行する(PHP 7.4対応)

 もうすぐ PHP 8.0対応のWordPress 5.6がリリースされる(2020年12月8日予定)ということで手持ちの公式プラグインを Travis-CIにてチェックし始めました(WP CLI 2.4.0 の wp scaffold plugin-tests プラグイン名 で吐き出すてs)。ところが、いつの間にか PHP 7.3以上については Travis-CIが PHPUnit 8.x(PHP8.0.0-devは PHPUnit 9.x)を使うため、PHPUnit 7.x までしか対応していない ため、現行のWordPressでは下図のようにエラーがでて動かなくなっていました。1年前ぐらいは問題なかったのですけどね。WordPress 5.6からは PHPUnit 8.x をサポートするそうです。この記事は WordPress 5.6がでる前(WordPress 5.6 RC2〜RC3)のときに検証した結果です。 WordPress 5.6も検証していますが、PHPUnit 8.x は未検証です。

付録(後述)で、MAMPを使った PHPUnitテストも説明しています。
また GitHubとTravis-CI 連携はできているものとします。そのやり方は検索したらいろいろと情報がでてくるでしょう。



PHP 8.0.0-devはうまくいかず

また数日調べたり、試してみましたが PHP 8.0.0-dev については、うまくいきませんでした。というわけで、こちらは素直に WordPress 5.6が出てから考えることにしました。


PHP 7.3/7.4 利用時に Travis CI に PHPUnit 7 を強制させる

PHPUnit 8.x対応の WordPress 5.6がでたら不要になるかもしれませんが、2020年12月1日現在は、WordPressが PHPUnit 7.x 以下しか対応しないため、やむを得ません。

変更するのは「.travis.xml」です。また composer.json がないと 「Composer could not find a composer.json file in XXX 」のようにエラーがでる場合があります。

したがって追加や変更点は

  • .travis.xml の変更
  • composer.json
  • phpunit.xml.dist の test-sample.php の除外設定をコメントアウトする
    (<!-<exclude>./tests/test-sample.php</exclude> -->)
の三点です。

詳細は
のコードを参考にしてみてください。

なお WP-CLIが吐き出す PHPUnit (wp scaffold plugin-tests)に含まれる .travis.xml は、2点古い書き方があります。

  1. matrix キーは、jobs キーへ変更(matrixはjobsへのエイリアス)したので、今後は jobs キーを使うこと
  2. sudo: は廃止キーだから削除推奨

また、PHP 7.3, 7.4 については、Travis CIで失敗しても許容するように、allow_failures キーを設定しておきます。ここで指定しておけば失敗しても Travis CIのジョブとしては失敗とはみなされないということになります。

まず jobに PHP 5.6〜 7.4を追加します。 PHP 7.4については WordPress 5.6(リリース候補)も含めておきます。

うまくすべてが成功していれば、下図のように allow_failures に含めた PHP 7.3と 7.4でもテストが成功していることがわかります。なお、ここでの WordPress nightlyバージョンとは、WordPress 5.6 RC2あるいは RC3を指します。

付録:MAMPを使った PHPUnitテスト方法

2020年12月9日時点(日本時間)においては、 WordPress 5.6の日本語版もリリースされました。ただ PHPUnit 8.5.13 を実行しようとすると

Error: Looks like you're using PHPUnit 8.5.13. WordPress requires at least PHPUnit 5.4 and is currently only compatible with PHPUnit up to 7.x.
Please use the latest PHPUnit version from the 7.x branch.
とでます。
をみる PHPUnit 9以降は PHP8以降のみサポート。PHPUnit8 は PHP7.1以降のサポートだとか。とりあえず、ここでは PHPUnit 7でのやり方を説明します。

検証環境

  • macOS Big Sur (11.0.1)
  • MAMP 5.7 (最新の6.2 は Apacheの80 ポート利用でコケるのでまだ使っていない)
    • PHP 7.4.2
  • zsh(シェル)
  • プラグインテストの準備
  • svn をインストールしておきます(Big Surには標準搭載されていない)
    • Xcodeには含まれなくなったため、Homebrew をインストールして、 brew install svn からインストールできます。

STEP 1.  MAMPの phpや mysql等コマンドを優先する PATHを通す

ターミナルが起動しているときのみの一時的な有効化になりますが、
ターミナルを起動して次の2つのコマンドを、順番に実行してください。
*bash/zsh 両シェル対応

export php_path="`ls -d /Applications/MAMP/bin/php/php* | tail -1`"
export PATH="${php_path}/bin:/Applications/MAMP/Library/bin:$PATH"

これによって、MAMP内の最新 PHPを php コマンドに一時的に割り当てます。
which php
でパスが /Applications/MAMP/bin/php/php7.4.2/bin/php (今回の場合)になっていることを確認しておくことが重要です。

STEP 2. wp scaffold plugin-tests が吐き出す bin/install-wp-tests.sh の変更

  • https://github.com/kimipooh/view-shortcodes/blob/master/bin/install-wp-tests.sh
のうち、下記の赤文字の部分を削除してください。
MySQL 5.6以降、コマンドラインから DBへのアクセスにパスワードを指定することは、セキュリティ上好ましくないので警告を出してできないようになっているようです。
  • mysqladmin: [Warning] Using a password on the command line interface can be insecure.
回避するためには、「パスワードを入れてmysqlコマンドを実行すると「Warning: Using a password on the command line interface can be insecure」が表示される」などの記事にあるようにファイルにパスワードを記載してそれをコマンドに読み込ませるという方法もありますが、ここでは素直にパスワードをキーボードから入力することにします。

変更前(bin/install-wp-tests.sh)
  • mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA

変更後(bin/install-wp-tests.sh)
  • mysqladmin create $DB_NAME --user="$DB_USER" --password $EXTRA

こうすることで MAMPの初期設定(MySQLポート 8889、ユーザー、パスワードともに root)であれば、

STEP 3. テスト用 WordPress のインストール

bash bin/install-wp-tests.sh view-shortcodes root 'root' 127.0.0.1:8889 latest

というコマンドを叩くことで、WordPress最新版(latest)が、 

/var/folders/_6/ユニークキー/T/wordpress/

あたりにインストールされるでしょう。

STEP 4. PHPUnit7 のダウンロードと実行

  • https://phar.phpunit.de/phpunit-7.phar
より PHPUnit 7の最新版をダウンロードします。
phpunit7 とリネームして
chmod 755 phpunit7 と実行権限を付与しておきましょう。
これをパスが通っている場所に移動しておきます。
MAMP限定なら、/Applications/MAMP/Library/bin にいれておけばよいです。
STEP 1 で上記へのパスは一時的に有効になっているはずです。

あとは、 テスト環境野整った プラグインフォルダで

phpunit7

と実行すれば

Installing...
...
...
OK (1 test, 1 assertion)

のようにテストされるはずです。

2020年12月11日 @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年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年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