中年男のぼんやり生活

ぼんやり生活おっさんのブログ

天然石の位牌という選択肢・「いしぶみ」

ウェブな作業 生活

今回ご縁があり、Wordpressでの制作を担当したウェブサイトが公開になりました。
墓石や記念碑に使用する天然石で制作された位牌、または個人向けの小型の石碑とも言える「いしぶみ」の商品ウェブサイトです。

f:id:kamomewa_kamome:20180820142435p:plain

構築作業内容としては、基本的には実績あるデザインテーマに各種コンテンツを登録しデザインを多少カスタマイズしたのみという域を出ないものですが、関心を持ったのはその商品そのものです。

「いしぶみ」は、茨城県にある、石碑や墓石に字を彫る字彫り屋さん やまと字彫工業さんが手がける天然石で出来た位牌です。天然石製のミニ記念碑、とも言えます。

中年以降の年齢になってくると、家族との別れも何度か経験したりして、そうした亡くなった家族やお墓との今後の関わり方を考え直すようになります。ましてや自分の場合、未婚で現在は家族もおらず遠方に住む既婚の兄がいるのみ。何れにしても次の世代は生まれておらず予定もないので、（実際にそうなりかけたように）自分が死んだ後の地元に残る墓のその後のこと（例えば墓じまい）も考えておかなければなりません。

父や母の世代と違い家に仏壇を置いていないので、亡くなった家族の存在と目に見えるカタチで付き合うようなことも今はありません。でも心のどこかでは思ったり思い出したりしている。

こんなことを頭のどこかで考えている中で見ると、この「いしぶみ」という商品や、位牌のような存在をより現代のあり方に寄り添ったカタチにしたジャンルの商品は、存在が知られるほどしっかりニーズがあるのだろうと思えます。
このいしぶみのような生活の中での丁度いい存在感、というのもすごく大事に思います。
何かの宗教に即した振る舞いは望むわけじゃない、でも亡き家族のことは思っているし、思いを込める付き合いやすい対象は手元に欲しい、そんな感覚です。

一生に一度程度購入する機会があるかどうかのモノでしょうけど、自分が思うことのために買って所有するならば、変わらずいつまでも残ってくれる品物で、かつ処分にも困らないものというのは重要な気がします。（処分に困らないというのは実家の始末の経験からも痛感します）

「いしぶみ」、ぜひ一度ウェブサイトを覗いて見て下さいませ。

wordpressのサーバー移転作業まとめ さくら→Xサーバー

ウェブな作業

wordpressで運用中のウェブサイトをサーバー移転したので作業の流れと使用したツールについてざっくりまとめておきます。
間違いや非効率な箇所があるかも知れませんが、これも経験のひとつということで。

移転元はさくらインターネットのスタンダード、移転先はXserverのX10プラン。
今回は、主にデータベース（以下DB）関連のレスポンスアップに期待しての移転試行です。移転後、DBのレスポンスアップは概ねかなったと思います。
（ちなみに、私自身は各種プログラム言語のコードは書けないしサーバーとコマンドで会話も出来ないので、そういうレベルでの作業メモと思って下さい）

基本的な作業の流れは

  1. 移転先サーバーの準備
  2. 移転用ファイルの準備
  3. ファイルアップロード
  4. ツールの準備、DBインポートと書き換え
  5. 表示・Wordpress動作確認
  6. 仕上げ
  7. サーバー切替

な感じです。
なお、以下の説明は2017/5時点の作業に関連したものです。その後の各サーバー会社側の仕様変更やツールの変更によっては食い違いが出ると思います。

1.移転先サーバーの準備

作業項目

まず、移転予定のドメインをXサーバーの管理画面から登録します。ドメインを登録するとそのドメイン専用の領域が一式作られます。（さくらインターネットではドキュメント領域内をただディレクトリで自由に仕切りそれぞれのウェブサイトデータを自由に収容しドメイン設定するので、ココが大きく違う点です）このままではドメインをXサーバーに向ける（切り替える）までアクセスができないので、動作確認URLも取得しておきます。
またXサーバーの場合、サブドメインで収容する場合は領域が分けられず、登録したドメインのpublic_html下にサブドメイン文字列と同じディレクトリが作られその中に収容することになります。このあたりはさくらインターネットと違って自由が利かず、また、動作確認用URLもこのディレクトリ自体には設定できないので、ウェブサイト内でのパスの持ち方など状況によっては動作確認に苦労するかも知れません。これについてはまだスッキリした解決方法が見つかりません。（同じく、仮URLとして管理画面からこのサブドメイン用ディレクトリに別のドメインやサブドメインを当てるというような柔軟な運用も出来ないようです。DNSレコード編集うんぬんは不慣れで担当外なので未調査。考慮せず）

DBは管理画面からすべて作成・管理できます。他からの移転作業の流れの中だと、さくらインターネットとだいたい同じような感じと思ってOKです。
希望するDB（とアクセスを許可するDBユーザー。ここはさくらと違うところ）を管理画面から作っておきます。

2.移転用ファイルの準備

作業項目

  • 現ファイル一式をFTPダウンロード
  • 移転先に合わせて一部ファイル内を書き換え
  • 現DBデータをエクスポート

ウェブサイトのデータを準備

現行のウェブサイトのファイルを全てFTPでダウンロードします。（スキルのある方で別の方法が取れる方はそちらを採用するほうがいい場合も）
WordPressへのアップロードファイルが大量にある場合など運営期間や内容次第でダウンロードに予想外に時間がかかる場合も多いので、余裕を持って作業時間を確保しておきます。

wp-config.phpの書き換え

FTPでダウンロードしたwp-config.php内のDB関連の記述を用意したXサーバーのDB用の内容に書き換えます。XサーバーでのサーバーIDがhoge、ドメインがhogehoge.comとして、適当な例は

/** WordPress のためのデータベース名 */
define('DB_NAME', 'hoge_hogehoge');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'hoge_hogeuser1');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password');

/** MySQL のホスト名 */
define('DB_HOST', 'mysql0000.xserver.jp');

になります。
マルチサイト化している場合、同じwp-config.php内にドメインについての記述もあると思うので、移転までの間は管理画面で取得した動作確認用URLに変更しておきます。

define('DOMAIN_CURRENT_SITE', 'hogehoge-com.check-xserver.jp');

※その他何か書き忘れがあれば後日追記します。

データベースのエクスポート

DBのデータはphpmyadminからエクスポートしておきます。エクスポートの際「作成するクエリの最大長」はいつも300にしてます。

.htaccessの記述書き換えなど

ウェブサイトディレクトリ直下の.htaccessなどでアレコレやっている場合は関連する記述がないかチェックして必要に応じて書き換えておきます。
ドキュメントルートはさくらインターネットとXサーバーは以下のようにパス構成が異なります。（プランや時期によって違う可能性もあります）

BASIC認証を利用している場合、管理画面から設定する関係で.htpasswdの場所や管理手法が違い、ドメイン・サブドメインごとに独立して保存されるので、そのあたりのパスの書き換えや運用後の管理方法も含め一考が必要です。

さくらで通用してXサーバーで通用しない記述法に遭遇

また、BASIC認証に関してさくらインターネットで通用していた書き方がXサーバーではエラーになってしまう症状に遭遇したので、ここらへんも事前の動作確認が必要のようです。
（.htaccess内の他の記述と関連してエラーになったのかどうかは未検証です）

例）さくらインターネットで使っていた書き方。Xサーバーではエラー？

AuthUserFile “/home/hoge/任意ディレクトリなど/.htpasswd”
AuthName staffarea
AuthType Basic
<Files wp-login.php>
require valid-user
</Files>

例）Xサーバー用に変更した書き方
（.htpasswdパスはXサーバーで設定した例）

<Files wp-login.php>
AuthUserFile “/home/hoge/hogehoge.com/htpasswd/.htpasswd”
AuthName staffarea
AuthType Basic
require valid-user
</Files>

さくらでの書き方は、以前に参考にできる記事やサーバー会社提供のドキュメントをいくつか見ながら記述したものですが、BASIC認証として正しくはどう書くべきだったかは調べていません。

3.ファイルアップロード

作業項目

  • 全ファイルFTPアップロード
  • 移転作業を秘匿するためのBASIC認証設定

ダウンロードしておいたウェブサイトのファイル一式、書き換えたファイルをXサーバーに用意したウェブサイト用ディレクトリに丸ごとFTPでアップロードします。ドメイン運用なら該当内のpublic_html、サブドメインならその下のサブドメイン文字列のディレクトリです。

また、非公開で各種設定作業や動作確認をするなら（そのほうがいいですが）このウェブサイト用ディレクトリにアクセス制限をかけます。管理画面から設定を行うと直下の.htaccessを書き換えてしまうので、都合がよくない場合は少しやりくりが必要です。
（今回は、ユーザー管理のみ管理画面から行い、制限のON/OFFを含む.htaccess内の記述変更は自分で行いました）

4.ツールの準備、データベースインポートと書き換え

作業項目

  • DBにデータをインポート
  • DB内データを新環境に合わせて編集

DBのインポート、DB内の書き換えに以下の2つのツールを使います。

bigdumpは大きなサイズのDBデータもさっくりインポートしてくれるので素人レベルな自分には大助かりのツール。大きくないDBデータなら管理画面からphpmyadminを使ったインポートでいいと思います。
Database Search and Replace Script in PHPはwordpressのDBデータ書き換えでは有名なツールなので説明省きます。（いつもお世話になってます）

bigdumpはbigdump.php内のDB関連の設定を書き換えてbigdumpディレクトリを作ってそこにアップロード、Database Search and Replace Script in PHPはダウンロードして解凍したディレクトリごと、wp-config.phpと同階層にアップロード。
これらのツールのパスは頻繁に攻撃や無用なアクセス試行を受けるので、作業中、直下からアクセス制限しないならば、当初からそれぞれのディレクトリにはBASIC認証やIP制限など明確なアクセス制限をかけておくことを強くオススメします。（特にDatabase Search and Replace Script in PHPは外部に自由にアクセスされたら悪夢です）Xサーバーでは仮画面からサクサクとアクセス制限（BASIC認証）が管理できるので便利です。

bigdumpからインポートする際はエクスポートしておいたDBのファイルをbigbumpのディレクトリに入れ、bigdump.phpにアクセス。「Start import」というリンクを選択するとインポートが始まります。アクセス段階でエラーが出ている場合はbigdump.php内のDB関連の記述を見直します。

無事インポートが完了したらDatabase Search and Replace Script in PHPにアクセス。（画面が出ない場合やエラーが出た場合はwp-config.phpのDB関連を見直します）
Database Search and Replace Script in PHPでは、実際の置換処理の前に「dry run」が出来るので、置換結果がどうなるか確認してから実施してもいいと思います。

Database Search and Replace Script in PHPにアクセスできたら、公開に使っていたドメイン文字列を動作確認URLの文字列に置換

replace:hogehoge.com
width:hogehoge-com.check-xserver.jp

次いでディレクトリパスをXサーバーに合わせたパスに置換

replace:/home/さくら契約アカウント/www/（+運用次第で任意のディレクトリ/）
width:/home/サーバーID/ドメイン/public_html/

上記はウェブサイトのルートパス置換値の一例ですが、特にさくら側は運用者によってパスが違うと思います。

これでDB内のデータの書き換えはとりあえず終了です。

（置換した動作確認URLは、動作確認が終了したら公開（サーバー切替）の前に公開用ドメインの文字列に置換しなおします。よってDatabase Search and Replace Script in PHPもまだそのまま置いておきます）

5.表示・Wordpress動作確認

作業項目

  • 表示確認（一般ユーザーとしてアクセス）
  • ログイン、管理画面へのアクセスと各種動作確認

動作確認URLからXサーバー側の各コンテンツにアクセスし表示内容に間違いがないか確認します。念のため読み込んでいる画像ファイルのパスやHTMLソース内のCSSなど各ファイルのパスもいくつかの画面で確認しておきます。

ログイン画面からログインし、各機能が正しく動作しているか見た目と試用で確認します。ダッシュボードや各プラグイン関連の画面でエラーメッセージが出ていないか、テスト用ダミーエントリーを投稿してみたり、ファイルのアップロード・編集・削除が正しく出来るか、既存投稿の編集が出来るか、など、軽い動作確認を済ませます。

問題が無ければ、テスト書き込みを消すなど状態を元に戻して、本番を想定した各所の変更とサーバー切替へ。

6.仕上げ

作業項目

  • DB内の動作確認URL文字列を公開用URLに書き換え
  • wp-config.php内を書き換え（マルチサイト化している場合）
  • 不要ファイル（ツール）を削除
  • 本番を想定したBASIC認証設定

ここまでの段階でXサーバーへ移したWordpressと各ファイルを使ったウェブサイトは正しく動作する状態になっているはずです。

続いて仕上げ。
サーバー切替に備えて、動作確認URLに書き換えたDB内の文字列を公開URLに書き換えます。
書き換えには準備で使用したDatabase Search and Replace Script in PHPを使用します。
作業自体は準備段階で行ったことを逆にする。例として

replace:hogehoge-com.check-xserver.jp
width:hogehoge.com

続いてwp-config.php内に書いた動作確認URLの文字列も、公開用のURL文字列に変更しておきます。

ここまでくると、Xサーバーに移したウェブサイトへはサーバーを切替えるまでアクセスできないはずです。

次に不要ファイルを削除します。DBインポートに使用したbigdumpとその.sqlファイルをディレクトリごと削除、Database Search and Replace Script in PHPもディレクトリごと削除するか、後でも使いたいなら最低限BASIC認証をかけておきます（が、用が済んだら即ディレクトリごと削除）。

次いで公開に向けたBASIC認証設定。普段Wordpressで運用するサイトのセキュリティ強化にBASIC認証を用いていなければ不要な作業です。
Xサーバーでは管理画面から各ディレクトリのBASIC認証ユーザー（.htpasswdファイル）をディレクトリごとに別々で管理しますが、今回のケースでは何かと面倒なのでひとつの.htpasswdファイルを使いまわすことにします。各所に配置する.htaccessのBASIC認証の記述の.htpasswdパスを、今回の例なら「/home/hoge/hogehoge.com/htpasswd/.htpasswd」に統一するだけです。
代償として、Xサーバーの管理画面から各ディレクトリのアクセス制限ON/OFFが、.htaccess内の記述が混在してしまうため使えなくなります。よって、頻繁にアクセス制限のON/OFFを行うディレクトリではこの方法は用いません。また、このことを忘れて（引き継がず）後からXサーバーの管理機能で認証ユーザー管理がうまくいかないと悩むことがないよう、他に関係者がいれば忘れずに引き継いでおきましょう。
（さくらインターネットのスタンダードではBASIC認証の管理に関わる機能はないので、Xサーバーに移して新たに増える引継ぎ項目になります）

7.サーバー切替

サーバーを切り替えはwhois情報のDNSサーバー指定をさくらインターネット用からXサーバー用に変更するだけです。
変更を行ったら反映するのを待ちます。Xサーバーに移したページのHTMLのどこかにXサーバー側とわかるコメントタグでも入れておいてもいいと思います。

DNS指定変更がネット上に行き渡り、Xサーバー上でのウェブサイトの表示やWordpress関連の正常動作を確認したら、ひとまずサーバー切替完了です。

サーバー切替実施からしばらくしたら、移転元サーバーへのアクセスが無くなったのを管理画面のアクセスログ解析やリソース情報画面などで確認し、移転元サーバーのウェブサイトデータを必要に応じて処置したら移転作業完了です。
お疲れ様でした。

扱いやすそうなWordpress用キャッシュプラグイン YASAKANI Cache を試用（経過観察中）

ウェブな作業

さくらインターネットのレンタルサーバーにWordpressを入れて運用していると、10000pv/月程度のサイトでもWordpressの拡張次第で503エラーが日に何度も出たりすることがあって、軽症のうちに何か対策をとアレコレ調べたり試したりしている。

キャッシュプラグインを使うことはサーバー負荷軽減策の有力な方法のひとつなので、とりあえず有名なWP Super CasheをWordpressの一つに入れ、比較ということでもう一つ他のWordpressで試そうということで選んだのがYASAKANI Cache。
設定項目が少ないところからくる扱い易さと、キャッシュ管理にSQLiteを使っているのが特徴。ホントに扱い簡単です。開発が日本の方ということで開発元のサイト、関連ドキュメントが日本語というのが正直ありがたいところ。

評価メモ 2017/5/23

YASAKANI Cache

  • 効果は体感出来ている。継続して使いたい。
  • GTmetrixの測定などでWP Super Casheとの大差はない。
  • カスタムフィールド内容の表示ができないのがかなり残念。
  • ショートコード関連は試してない。

WP Super Cashe

  • 効果は体感できている。
  • GTmetrixの測定などでYASAKANI Cacheとの大差はない。
  • 設定項目が多く、ひとつひとつの変更結果への評価がめんどう。
  • キャッシュが有効でも「WP-PostViews」はPVをカウントしている。

使用環境

早速下記の条件のWordpressに入れてみて使い始めて現在経過観察中。503エラーがはっきり減ったり、GTmetrixの数値が改善するようになればいいなぁと思いながら。

今のところ、キャッシュを4時間、除外ページなしで使用。キャッシュ有効とそうでないので明確に表示レスポンスに違いがあるので、ファーストインプレッションとしては効果ありそうです。

疑問と不満

  • 設定画面に「ページキャッシュ」「キャッシュ有効期間」「除外するページ」以外項目がない。こういうもんか。開発元の解説だとログ関連とかもっといろいろ出てるようだが。サーバー環境によって選択肢が異なるのは想像できるが。
    →各項目が出ない理由が理解できた。
  • さくらのレンタルサーバーだとAPC/APCuが使えないらしいこと。残念。プラグインへの不満じゃなく。
  • 最も大きな不満というか、即本格導入にしない一番の理由はカスタムフィールド関連が表示されなくなること。Smart Custom Fieldsで用意して入力した項目をテーマのテンプレにif文やら何やらで入れているけどこれらはキャッシュに含んでくれないようだ。

そもそも、最近Wordpress管理コンテンツでサーバー負荷を気にしているのは、このSmart Custom Fieldsで多数の項目追加を行った魔改造コンテンツの表示レスポンス改善・サーバー負荷軽減をするには、DBアクセス回数を減らすのが一番効果が高そうだと考えたから。結果的にWordpressに起因する503エラーも減るんじゃないかと。さくらのレンタルサーバーの場合特に。
つまり、今悩みの種になっているこれらの魔改造コンテンツでこそキャッシュの出番だろうにそれで使えないとは・・・とガッカリしたところ。

素人ながらWordpress本体の起動前に割り込んで表示のための処理をする、という理屈でいくと、標準以外の処理を行った表示物についてはしょうがないのかな、と思うんですけどね。

1ヶ月程度アクセスログや動作を観察してよさそうなら、無改造のコンテンツでのみ使おうかと思います。

WP Super Casheについてもそのうちまとめます。