WordPressのテーマ変更

これまで、このサイトのテーマは初めてWordPressを使った際に選んだテーマをPHPのバージョンアップに伴う不具合とかを手直ししつつ使ってきたのですが、さすがに今の世の中、スマホやタブレットでサイトを見る機会が増えてきていて、レスポンシブデザインへの対応をしたいなー、と思うようになりました。

しかし、元のデザインを自力でレスポンシブデザイン対応させるようなスキルもないので、ついにテーマ変更することにしました。で、新しいテーマはできるだけ長くサポートされるであろう、標準のテーマのうち、レスポンシブデザインに対応しているもの・・・ということで、TwentySeventeenにしました・・・が、TwentySeventeenはそのままだとアクセスするとどどーんと画像が表示されてしまうので、こちらのサイトを参考に控えめに表示されるようにしました。

変更箇所は、テーマの中のfunctions.phpの最後に、以下の記述を追加して UTF-8 で保存しました。もう少しデザインはカスタマイズすると思いますが、とりあえずレスポンシブデザインになったのでよしとします。

・・・が、何も考えずにテーマ自体のfunctions.phpを編集してしまうと、テーマがバージョンアップしたときに元に戻ってしまうようです。なので、子テーマを作って、そちらの funcions.php を編集しました。

子テーマは、サーバ上のテーマディレクトリと同じ階層に子テーマのディレクトリ(twentyseventeen-child)を作って、そこに必要なファイルを置きます。

一つは、functions.php で、以下の内容です。実際には、上記の内容も後ろに書き足して、UTF-8で保存しました。

もう一つは、style.css で、以下の内容です。

ここに、こちらのサイトの記事の内容そのまま(ありがとうございます!)ですが、

を後ろに書き足して元のテーマでは狭くて読みにくい記事の幅を広げてみました。

さらに、記事の見出しと記事内の見出しがともにh3で同じサイズで表示されてして醜いところがありましたので、あちこち参考にさせてもらいながら、style.css に

を追加して記事のタイトルに装飾をつけてみました。

今しばらくはデザインがいろいろ変わるかもしれませんが、ご容赦を(笑)

サイトのSSL対応化

さくらのレンタルサーバの資料をみていたら、Let’s Encryptを使ったSSL化が簡単にできることがわかりました。

・・・といっても、本当に簡単で、マニュアルに沿って作業するだけです。CLIも必要なく、GUIだけで適用できました。

1.SSL設定の有効化と確認

マニュアル(『【無料SSL】サーバコントロールパネルからの導入手順』)に沿って作業するだけです。気をつけるとすると、マニュアル内にも書いてありますが、発行完了のメールが来るのに多少時間がかかります。15分くらいかかったでしょうか。ま、そんなレベルです。

2.WordPressでの常時SSL有効化プラグインの導入

さくらのレンタルサーバ専用の常時SSL有効化プラグインを導入して有効化します。これも、マニュアル(『【WordPress】常時SSL化プラグインの使い方』)に沿って作業するだけです。
これだけでサイトがSSL対応できちゃいました。

サーバのPHPのバージョンを推奨バージョンに戻す

WordPressの引っ越しを行った際に、PHPのVer7系だと記事が表示されない現象があり、Ver5系に変更したのですが、その後調べてみるとWordPress自体はPHPのVer7系に対応していることがわかりました。さらに調べていくと、テーマやプラグインがPHPのVer7系に対応していないケースで発生することがわかってきました。

セキュリティ面では最新のバージョンを使うに越したことはないので、なんとかならないか調べていたところ、PHP Compatibility ChekerというWordPressのプラグインを使うと問題点のチェックができることがわかったので、インストールして確認してみました。

その結果、やはりテーマやプラグインに問題があるものが見つかりました。プラグインの出力するレポートにどのファイルの何行目がNGが記載されていますので、これを順に見ていくことにします。

テーマについては、式の評価の部分がPHPのバージョンによって差があるところが検知されましたので、これをPHPのバージョンに関わらず同じ評価になるように{}を追加しました。具体的には、

という記述をすると、PHP5では、

と解釈されるのですが、PHP7では、

と解釈されるようです。(参考:http://php.net/manual/en/migration70.incompatible.php)
そこで、この$$が2つ続く箇所については{}を追加して、常にPHP5と同じ解釈になるように修正しました。

他には、

  • Throws SPAM Awayというプラグイン
    セキュリティ上の課題で変更になった関数(spilt() ⇒ preg_split())の単純な置き換え
  • WP SyntaxHighlighterというプラグイン
    MySQLサーバのバージョン取得の関数(mysql_get_server_info() ⇒ mysqli_get_server_info())の単純な置き換え

を行いました。
また、使用していないプラグインについては停止・削除を行いました。

一通りの整理を行った後、再度チェックをかけるとエラーはなくなったので、PHPのバージョンをさくらのレンタルサーバで標準の7系にしたところ、それでもきちんと表示できるようになりました。

これとは別に、Crayon Syntax Highlighterというコードをきれいに表示してくれるプラグインが入っていたのですが、停止していました。その理由は、記号が化けてしまうからだったのですが、今回、ぐぐってみたところ、Crayon Syntax HighlighterのSettingの中のCodeのセクションにある「Decode HTML entities in code」にチェックを入れると治ったので、逆に有効化してあります。

WordPressの引っ越し&ドメイン変更作業

これまでドメインキングとさくらのVPSの組み合わせで運用してきた当ページですが、元々VPSの運用が面倒臭くなっていたし、CentOS6.5もサポート終了があと2年半くらいまで迫っていたのでどうしようかなー、と思っていたところにドメインキングの大幅値上げ(確か100円/月⇒500円/月)の話が来たので、この機に環境を一新することにしました。ドメインキングの値上げは Plesk の一方的な値上げという話だったと思いますが、さすがに5倍となると看過できません。12月の次回支払い時期の前に移行することにしました。

で、元の構成はドメインキングでドメイン(+Webサーバもあるけど使ってない)取得、サーバはさくらのVPS(1Gプラン)上にCentOS6.5という組み合わせでした。

移行後の構成は、新しいドメインを .tokyo ドメインで取得、サーバはアップデート管理の手間を省きたいので共用レンタルサーバ(さくらのレンタルサーバスタンダード)としました。まあ、CentOS6.5でも自動アップデートを有効にしていたので、それほど手間ではなかったのですが、移行後の構築の手間も考えるとレンタルサーバでいいか、ということにしました。

で、移行自体は半日くらいで終わったのですが、せっかくなので作業手順のメモを残しておきたいと思います。

1.Wordpressのデータバックアップ

旧サーバー(VPS)上でWordPressのデータのバックアップを取ります。

2.データベースのバックアップ

次に、phpMyAdminを使ってデータベースのバックアップを行います。バックアップの方法は『【WordPress】さくらインターネットに移転(引越し)する方法』を参考にさせていただきました。

3.さくらのレンタルサーバ(スタンダード)の契約

契約できたら、サーバパスワードの変更を行います。メールで仮パスワードが送られてくるので、これを変更。変更後は、初期ドメイン名でsshログインできるようになります。

4.お名前.com で新ドメインの契約

手順は・・・・省略。whois代行があるのがいいですよね。あと、インフレ気味ですが、いろんなドメインがあるとことか。

5.お名前.comで取得したドメインをさくらのレンタルサーバで使用する設定を行う

基本的な流れとしては、さくらのレンタルサーバのサーバコントロールパネルで、「新しいドメインの追加」を行い、新しいドメインとレンタルサーバ上のディレクトリとの紐付けを行います。紐付けるディレクトリは別途作成が必要です。
その後で、お名前.com側のドメインNaviで対象のドメインで使用するネームサーバーをさくらインターネット側で指定されたネームサーバに変更します。
実施にあたっては『お名前.comで取得したドメインをさくらサーバーで使用する』を参考にさせていただきました。

6.さくら上でデータベースの復元

データベースの復元はサーバにログインしてシェル上で行いました。シェルが使えるなら、その方がずっと楽で簡単で一瞬で終わります。

方法は、『MySQL/MariaDB コマンドを使った復元』を参考にさせていただきました。

7.ドメイン変更に伴うデータベースの修正

今回はドメインの変更を伴っていますので、WordPressの中のデータも修正しないといけません。そのためのツールがあるようで、『WordPressのサーバー移行_ドメイン変更の手順』を参考に、Search and Replace for WordPress Databases を使って新サーバー上でURLの置き換えを行いました。

8.PHPのバージョンを5系に下げた

アクセスしてみると、記事の本文が表示されない現象に悩まされました。ぐぐってみると、PHPのバージョンによって起きることあるらしいことが判明。確かに旧サーバは5系、新サーバーはデフォルトでは7系になっていました。さくらのサーバコントロールパネルでバージョンを7系から5系に下げたところ、本文が表示されるようになり、一通りの問題は解決したようです。

9.バックアップ用のシェルスクリプトの作成

データとデータベースのバックアップをするスクリプトを書いておきました。時々走らせようと思います。

10.旧サーバーからのリダイレクトの設定

旧サーバーはドメインキングのDNSサーバー設定でさくらのVPSのIPアドレスを返していました。
できれば、さっさとさくらのVPSは解約したいので、ドメインキングのサーバ上に .htaccess を置いて、リダイレクトさせることにしました。

<.htaccessの内容>

.htaccessを設置したら、DNSの設定を変更します。設定の中から

のレコードを削除します。

あとは、DNS情報が行き渡るのを待ちます。

MongoDBについて調べてみた

いろいろあって、MongoDBについて調べてます。

調べた結果をメモしておきます。

WordPressでログインできなくなった!

WordPressでログイン認証のセキュリティ強化にCAPTCHAを入れようと、プラグインから「SI CAPTCHA Anti-Spam」をインストールしてみました。

設定でログイン画面にキャプチャを入れて、ログアウトしてログインしなおしたらCAPTCHAが表示されていません(!)。

しかも、ログインできない!!

で、調べてみると、「SI CAPTCHA Anti-Spam」には、GDというライブラリが必要なので、

としてインストールを試みるも、さくらのVPSにインストールしたPHPのバージョンが合わずphp-gdがインストールができません。

で、四苦八苦した挙句の解決方法は、「プラグインディレクトリの名前を一時的に変更する」という方法でした。

/home/(ユーザー名)/public_html/wordpress/wp-contents/plugins にカレントディレクトリを変更して、プラグインの名前の付いたディレクトリの名前を一時的に変更してやると、無事にログインできました。

ログインしたら、ディレクトリの名前を元に戻して、プラグインを停止・削除しました。

いや、焦りました・・(^^;

安価なVPSを調査してみました

最近、激安VPSがまた増えている気がします。概ね、月額500円あたりが最下限で、1日使うだけでも500円を切ることができなかったのですが、日割り、時間課金のタイプもでてきているので、改めて調べてみます。あ、企業で契約するようなVPSはそもそも調べてませんw。ローエンドのVPSだけです。あしからず。

  • さくらのVPS
    ローエンドのVPSの代表といえばさくらのVPSでしょう。いまご覧頂いているページもさくらのVPSの1Gプラン(ただしHDD100GB)で動いてます。そんなにトラフィックないので、512プランでも十分だと思いますが。
    ちなみに、1Gプランが『CPU仮想2Core/SSD30GB/メモリ1GB』で月額972円/年額10,692円/初期費用1,620円(税込み)、512プランが『CPU仮想1Core/SSD20GB/メモリ512MB』で月額685円/年額7,543円/初期費用1,620円(税込み)です。
  • カゴヤ・クラウド
    ここは早くから日額課金があったところになります。SSDタイプAが『CPU仮想3Core/SSD80GB/メモリ保証1GB最大2GB』で日額31円/月額864円/初期費用無料(税込み)です。日額課金は実験や短期間のサーバ設置に便利だったので使ったことがあるのですが、去年の11月にクレジットカード番号を含めて漏洩する事件を起こしたので信用できません。支払いシステムを変更したので大丈夫とか言ってるのですが、生理的に受け付けられません。もしも、バーチャルカードで払えるならもう一度登録してもいいかとは思いますが。
  • ConoHa
    時間課金をやり始めたところです。512MBプランが『CPU仮想1Core/SSD20GB/メモリ512MB』で1時間1円/月額630円/初期費用無料、最低利用期間なし、といったところ。OSはいろいろ選べる。
  • WebARENA
    ポイント制というちょっと変わった課金体型。一番安い条件だと512M-SSDタイプで『CPU仮想1Core/SSD20GB/メモリ512MB』で10ポイントで、その10ポイントの月額基本料金が360円(税別、税込みだと388円)。課金はスタート時は日割り+月末締め。ちょっと変わっているのが、支払いは翌月分を先払い、というところ。OSはCentOS6のみ。
    NTT系なので、クレジットカードのセキュリティとかはまともにやってくれると期待できる・・・と思うので、試してみても良いかもしれない。
  • ServerMan@VPS
    メモリ1GB/HDD50GBで月額467円(税別)、ただしコンテナ型なのでカーネルを共有する形になるらしい。
  • ABLENET
    V0プランで『CPU仮想1Core/SSD30GB/メモリ512MB』で月額648円/年払い5,486円(税別)/初期費用934円だそうです。
  • FC2 VPS
    バリュープランで『CPU1Core✕13%/HDD80GB/メモリ1GB』で月額780円/初期費用なし。OSはCentOS6.3。
  • お名前.com VPS
    メモリ1GBプランで『CPU仮想2Core/HDD100GB/メモリ1GB』で月額896円/初期費用無し(税別)。

着目すべきは、WebARENAの月額360円+消費税と、ConoHaの1時間1円でしょうか。

ESP8266でjumpwire.ioを試してみた

ESP8266についてググっていたら、広告欄に何やら「jumpwire.io」なるものが出てました。確か、ESP8266を使ったクラウドサーバーなんちゃらとか(細かい内容は忘れました)。

とりあえずクリックしてみたら「MakerのためのIoTプラットフォーム」「Arduinoを5分でクラウドにつないで、あなたのIoTプロジェクトを成功に導きます。」だそうです。なんでも無料でお試しができるようなので、試してみることにしました。環境はUbuntu14.10LTS 64bit版 + ArduinoIDE1.6.5 + esp8266 version 1.6.5-947-g39819f0(ボードパッケージ)です。ボードパッケージのインストールまでの方法はこちらの記事を参照。

無料サインアップ・・・から先は英語ですが、めげずに登録してみます。よくある「ユーザーIDはメールアドレス」ってやつです。ユーザーIDと設定するパスワードを打ち込むと、メールアドレス宛にアクティベート用のメールが届くので、そこにあるリンクをクリックするとサインアップ完了です。
で、改めてログインし直します。(これもよくあるパターン)

ログインすると、いきなり秘密のトークン(Secret token)が表示されます。この画面をコンソールと呼ぶようです。プロジェクトは無料で5つ作れて、A〜Eというアルファベットになるようです。で、プロジェクトごとにKEYが26個(A〜Z)セットできるようです。

ここで一旦中断し、ローカル側(クライアント側)のプログラミングに戻ります。今回はgithubにライブラリとサンプルがあるようなので、これを動かしてみます。

まず、gitでライブラリを持ってきます。

これで~/Arduino/libraries/JWIO_ESP8266_ArduinoIDEの下にサンプルスケッチ(Sample_Sketch.ino)までコピーされますので、これをスケッチが保存されるべき場所にコピーします。

これで「スケッチを開く」で、~/Arduino/JWIO_ESP8266_ArduinoIDE/ の下のSample_Sketch.inoを開きます。

サンプルスケッチの冒頭に、

という箇所がありますので、ここにWiFiの設定と、さっき出たSecret tokenをセットします。4つ目のAは多分プロジェクト名でしょうか、そのままにしておきます。

下の方に

という箇所があります。自分はGPIO2を使うので、ここを5から2に変更しておきます。後の方のdigitalWrite()のところも同様に修正しました。
修正後のソースはこんな感じです。(開示できない箇所はxxxxxxxxxxxxxになってます)

さて、ここで「マイコンに書き込み」とすると、コンパイルエラーが発生しました。

だそうです。そこでサンプルソースの冒頭の

とすることで、ビルド&書き込み、実行ができました。
ログを見ていると、ところどころでなにやらWebSocket関連でエラーが発生しているっぽい感じもしますが、先に開いたjumpwire.ioのログインコンソール上にKey BとしてESP8266側から経過時間が設定されているのがわかります。(下記画面だと418秒経過後)

Screenshot0001

さらに、Webコンソールの下の方にはData logとしてログが表示されています。

ArduinoIDEのシリアルコンソールにはラウンドトリップタイムも表示されていますが、自分の環境からだと150msくらいかかっているようです。

そして、ブラウザ上で「Value」のところに1をセットして「Throw」を押すと、点灯していたLEDが消灯しました。0をセットして「Throw」を押すと、消灯していたLEDが点灯しました。ソースのコメントとは逆の動作ですが、これは回路の差によるものでしょう。

サンプルソースを修正して以下のようにしてみました。

GPIO0についているスイッチの状態が変化した場合にKey-Cの値をスイッチの状態に応じて0/1に変化させるように修正してみました。(無事動きました)

公式サイトに日本語版の説明もない状態で動かしているため?)ログを見ていると途中でWebsocketが切れるみたいで、安定性に若干不安を感じないでもないですが、jumpwire.ioはシンプルに動くので、確かに手早くクライアント(ESP8266)の状態をブラウザで確認できるようにしておきたい、とにかく短期間でクラウドでデータ収集できるようにしたい、という場合には簡単でいいと思います。

ちなみに、サインアップしてからこの記事を書きつつサンプルを改造したもの(ボタンの状態がアップロードされるように修正したもの)を動かすまでに要した時間は約1.5時間です。5分はちょっと眉唾ものとしても、ArduinoIDEでESP8266が動く状態からなら動かすだけなら30分もあれば十分動かせるでしょう。確かに非常にお手軽ですので、知っておいて損はないと思います。

ESP8266にWebSocketを喋らせてみる

世の中、同じようなことを考える方はいるようで、すでにESP8266+ArduinoIDEでWebSocketライブラリが存在しています。WebSocketが扱えるようになれば、(プログラミングスキルがあれば)クラウド側から好きなタイミングでESP8266に指示をおくることができるようになるはずです。(が、世の中そんなに甘くないんですねぇ〜)

で、今回見つけたWebSocketライブラリは ESP8266-Websocket です。

今回の記事はこれのサンプルを動かしてみよう、と苦戦した記録です。作業PCのOSはUbuntu14.10 LTS 64bit、ArduinoIDEのバージョンは1.6.5です。なお、Ubuntuで動かすにあたっては、

として、/dev/ttyUSB0のアクセス権をユーザーにつけた後、再ログインしないと/dev/ttyUSB0へアクセスできないとしてエラーになります。

Arduinoのライブラリは ~/Arduino/librariesの下に置けばいいようですので、そこにgitでライブラリを引っ張ってきます。

その後、ArduinoIDEで「スケッチ」→「Include Library」→「Manage Libraries」で右上の「Filter your search」で「ESP8266-Websocket」と入力して「INSTALLED」になっていることを確認します。

scrn1

次に、WebSocketClientのデモを動かしてみます。

「ファイル」→「スケッチの例」→「ESP8266-Websocket」→「WebSocketClient_Demo」を選択します。

scren2

ソースの冒頭の

の部分に自分の無線LANのESSIDとパスキーを入力してから、名前を付けて保存します。

このライブラリはおそらくWindows環境で作成されたのでしょう。Linux環境でビルドしようとすると、ファイル名の大文字小文字で失敗します。そのため、ライブラリの中の以下の部分を修正します。

WebSocketClient.h と WebSocketServer.h の

に、

WebSocketServer.cpp と WebSocketClient.cppの

とします。

これでビルドが通るようになりましたが、それでもコネクションに失敗します。禁断のgoto文で接続しに行く部分のみを繰り返すと、何回目か以降は通るようです。ライブラリのWebSocketClient.cppの冒頭にデバッグのための#define文があるので、ここをコメントを外すとデバッグメッセージが出るのですが、これでもハンドシェークの途中で止まっていることはわかるものの、それ以上はなんともわかりません。
これ以上は間にLANアナライザを入れてみてパケット解析しつつ、RFCを読んで何かおかしいのか調べるしかなさそうです。

以下は、現時点でのサンプルプログラムを改造したものです。

WebSocketClient.cppをみると、サーバ側からのヘッダの解釈の実装がまだまだであることがわかります。ひとつの可能性として、どうやらここで止まっていそうです。もうひとつは、パケットの受信バッファの処理がどうも変な感じがします。

いずれにせよ、このライブラリはまだそのままでは使えるものではなさそうな感じです。(ま、よくみると色々と制約があるよ、って書いてあるんですけどね)