暗中模索の右往左往 – マルチサイト化したWordPressのドメインを変更したい

http://blog.ham-labo.com/memo/php/25.html

したんだけど、いくつか疑問

prefix_option テーブルのoption_value（旧ドメインを新ドメインにreplace）

って説明されていた部分と、既存のコンテンツ部分のURL修正とかが面倒だったので、wp-config.phpを修正とDBをフルダンプして、エディタで該当ドメインを一気に置換してみた。
一応注意点としては、メールアドレスまで修正しないように注意しましょうと。
忘れていて、慌てて@www.domeinで検索して、修正しましたけどね・・・。

とりあえず上手くいったみたいなので、ちょっと様子を見てみます。
ついでに

RewriteCond %{HTTP_HOST} ^example\.com
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

とか書いておくと、より良いかも。

で、ちょっと調べると、国内の記事だと、query_postsを使って～と、それじゃ駄目でしょ的な感じだったので、使い方をちょっと書いておいてみる。

	$args = array(
		'post_type' => 'post',
		'paged' => $paged
	);

	$my_query = new WP_Query($args);
	if ($my_query->have_posts()) :
		while ($my_query->have_posts()) : $my_query->the_post();
			・・・略・・・
		endwhile;
	endif;
	if(function_exists('wp_pagenavi')) wp_pagenavi(array('query' => $my_query));

とりあえず、こんな感じで。

単純に抽出条件を、引数で渡してあげれば良いんだけど、って思っていたら、実体そのものを渡していたのねと。
ということで、情報源はこちら。

pagination – wp_pagenavi() with custom wp_query()? – WordPress – Stack Exchange
http://wordpress.stackexchange.com/questions/9576/wp-pagenavi-with-custom-wp-query

AuthType Basic
 AuthUserFile パスワードファイルへのパス
 AuthName "Please input your Account & Password"
 Require valid-user
Satisfy Any
Order Allow,Deny
 Allow from 許可するIPアドレス

Satisfy AnyのAnyをAllにすると、IPで縛った上でのパスワード認証が必要になりますよっと。

1. Retinaディスプレイ
   予想通り、4倍の解像度になりました。1024×768から2048×1534。辺を2倍すれば良いので、わかりやすい計算で助かりますｗ
   実際問題として、元画像の辺をそのまま2倍にすればいいので、開発的には楽ですけど、ぶっちゃけアラが目立つはずなので、画像作るのが大変そうだなあと。
   ハイパーキュービックでストレッチしても、さすがに目立とうだろうからなあ～的な。
2. A5Xプロセッサ
   4コアのA6プロセッサの噂も出ましたが、GPU部分が4コアのA5Xプロセッサで落ち着きましたね。CPU部分はA5と同じデュアルコアなのでしょう。
   Retinaディスプレイの、高解像度をコントロールするには、さすがにA5じゃ無理だったと言うことですね。
   あと、メモリーは多分1GBですね。512MBじゃ解像度に対しても足りないでしょうし。
3. LTE
   予想通りで、AT&T、Verizon2タイプでの提供が確定していますね。Softbankが使用するTD-LTE方式については言及されなかったので、どうなんでしょう？現時点で言及無いので、駄目なのかな？
4. カメラ
   個人的には正直どうでも良いですｗ
   iPhone4Sと同じカメラ乗せました。的な感じですね。
5. テザリング
   実はこれが一番びっくりしました。
   iPhoneでのテザリングはバッテリー容量などを考えると、一番良い方法だと思ってたのに、残念ながら非対応でした。
   でも、日本の事業者だと現時点でSoftbankだけで、Softbankはテザリング開放しないから、SIMフリー版の、AT&T方式の3G/LTEモデルを、docomo系MVNOの格安SIMで使うのがベストバイだと思います。
   まあ、香港あたりから輸入しなければなりませんが。

とりあえず他にもいろいろあるけど、こんな感じでｗ

これが厄介だったのは、特権管理者（admin）だと発生せず、管理者や編集者だと発生したと言うことです。

最初はWYSIWYGプラグインかと思って、いくつか試したけれど変わらず、とりあえず他にもということで、自動整形を停止するプラグインを使ってみたり、いろいろ試したけどうまくいかなかったので、わらにもすがる勢いで2chで聞いてみたら、まんまな回答をもらえたので、その原因と回避策をまとめて書いてみる。

WordPress › フォーラム » マルチサイトの管理者で投稿するとHTML属性が削除される
http://ja.forums.wordpress.org/topic/4351

muは元々ksesフィルターがあるので、解除する場合にはunfilteredmuというプラグインが一般的に使われます。バグではなくマルチサイト（wpmu）の仕様です。

なるほど。バグでは無く使用ですか・・・。しかもMU時代からの名残なのね。というか、これってはまったことある人多いんじゃ無いのかなあ？と思いつつ、回避策で書かれていたunfilteredmuというプラグインを探したけれど、管理画面のプラグイン検索からはヒットしませんでした。
仕方が無いのでGoogle先生に聞いてみると、 ”Unfiltered MU”って名前でヒット。同じ名前をプラグイン検索で行うと、ちゃんとヒット。
って事でインストール・有効化で、無事に管理者・編集者でも<div>や<p>タグにidを設定することが出来るようになりましたというお話。

地下鉄は使い物にならない

正直なところ、地下鉄を利用している限り、現状ホームは入るけど、ホーム外は入らないのは当然として、一度切れてから再度エリアに入った際の、再接続に偉い時間がかかるのが難点。
この再接続を待っている間に、ひどいときには電車が発車してしまい、当然何も通信できずに次の駅まで待つことがありました。
もしスマートフォンを利用して、高速通信用にWiFiを使用しているのであれば、WiFiをOFFにして、3G通信のままにしていた方が、実はストレスが少ない状態でした。

WiMAXはホームでも現状ダメダメです。

気がついたらサスペンドモード

電池の消費を抑えるために、一定時間通信が発生しないと、ルーター側でサスペンドモードに切り替わるのですが、ちょっとアクセスできない間に切り替わってしまい、さあ使うぞ！と思ったらサスペンドモードです。1分お待ちください。という事がちょくちょくあります。
まあ、これは現状電池の持ちを考えると、厳しいところがあるのですが、すぐ使えないっていうストレスがたまります。

現在起動が徐々に高速化してきたので、だいぶましかなという感じです。

使う人が多すぎると、チャンネルが確保できない

これはIT系の大規模な展示会などでしか起こりませんが、有る特定のエリアで大量の人が使用しているため、WiFiの空きチャンネルが無くなって、まともに繋がらなくなることがありました。
このような場合には、正直主催者側が、無料で専用のWiFiのアクセスポイントを用意して、アクセスコントロールするしか無いとは思うのですが、現状だめだめな状態だと思います。

ビックサイトと幕張メッセ限定かなと思いますが、電車内でのアクセスポイントの増加数を見る限り、近いうちに身近な場所でも問題化すると思います。

本気で使うと電池が全然持たない

だいぶ改善しましたが、本気でヘビーに使ってしまうと、まだまだ電池の持ちが厳しいかもしれません。
朝から帰りまで普通に使うとなると、 フル充電+外部電源が必要な状態です。もっともこれは、スマートフォンにも言える状態ですが。

社内で遠慮無く充電できる環境は、かなり恵まれているんですけどね。

結論

正直高速通信は魅力だけど、邪魔ってのが、自分自身の結論です。
電池や帯域の問題がある程度めどがつけば、スマートフォンのテザリングに、ほとんどが吸収されると思っています。
そして、スマートフォンが無いけど、屋外でデータ通信が必要な人向けの商品になっていくと思います。

MP3プレイヤーが出るさらに前、携帯電話にWalkmanくっつければ、すごくいいのにと言って、 全く相手にされなかったのを思い出しつつつぶやいてみましたｗ

$ ab -n 100 -c 100 http://www.brolog.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done

Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /
Document Length: 60832 bytes

Concurrency Level: 100
Time taken for tests: 2.725 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 6111000 bytes
HTML transferred: 6083200 bytes
Requests per second: 36.70 [#/sec] (mean)
Time per request: 2724.592 [ms] (mean)
Time per request: 27.246 [ms] (mean, across all concurrent requests)
Transfer rate: 2190.34 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 261 1218 636.6 1552 2308
Processing: 0 696 662.2 619 2289
Waiting: 0 523 544.3 492 2047
Total: 660 1914 612.4 1993 2723

Percentage of the requests served within a certain time (ms)
50% 1993
66% 2350
75% 2450
80% 2472
90% 2510
95% 2555
98% 2693
99% 2723
100% 2723 (longest request)

圧倒的な改善。まあ、予想通りなんだけど、DB Cache Reoadedとか効いているのかなあ？とちょっと思ったり。
というか、ここまで速度差が出ると、標準の機能としてWordPressに出力キャッシュを搭載する必要が来ているんじゃ？と思う。標準で提供できるレベルになれば、いくつかのプラグインとの不整合とかも、何とか調整できそうな気もするしねえ。

とりあえず、ある程度レスポンスよく出来たので、このプラグイン類のセットで、仕事用のサーバーを設定してみようかなと。まあ、どう考えても、あまりにも一般的なセットで落ち着いた気もしないでもない。

$ ab -c 100 -n 100 http://www.brolog.com/
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done
Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /
Document Length: 60346 bytes

Concurrency Level: 100
Time taken for tests: 33.678507 seconds
Complete requests: 100
Failed requests: 91
(Connect: 0, Length: 91, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2
Total transferred: 6276041 bytes
HTML transferred: 6253317 bytes
Requests per second: 2.97 [#/sec] (mean)
Time per request: 33678.509 [ms] (mean)
Time per request: 336.785 [ms] (mean, across all concurrent requests)
Transfer rate: 181.96 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 14 2.7 14 19
Processing: 3126 16295 7988.2 16859 31081
Waiting: 2443 15150 7881.2 15455 30474
Total: 3136 16310 7990.2 16875 31100

Percentage of the requests served within a certain time (ms)
50% 16875
66% 20712
75% 23592
80% 24305
90% 27182
95% 29011
98% 29684
99% 31100
100% 31100 (longest request)

　 　　_, ._
　 （　ﾟ Дﾟ）
　　( つ旦O
　　と＿)_) 

　 　　_, ._
　 （　ﾟ Дﾟ） 　　ｶﾞｼｬ
　　( つ　O. __
　　と＿)_) （__(）､;.o：。
　　　　　　　　　　ﾟ*･:.｡

・・・一応、静的ファイルでも・・・

$ ab -c 100 -n 100 http://www.brolog.com/sitemap.xml
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done

Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /sitemap.xml
Document Length: 55375 bytes

Concurrency Level: 100
Time taken for tests: 0.614033 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 5976628 bytes
HTML transferred: 5948308 bytes
Requests per second: 162.86 [#/sec] (mean)
Time per request: 614.033 [ms] (mean)
Time per request: 6.140 [ms] (mean, across all concurrent requests)
Transfer rate: 9504.38 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 10 1.3 11 15
Processing: 94 335 142.6 346 571
Waiting: 31 247 148.9 242 496
Total: 103 346 143.3 357 583

Percentage of the requests served within a certain time (ms)
50% 357
66% 420
75% 467
80% 481
90% 546
95% 570
98% 580
99% 583
100% 583 (longest request)

とりあえず普通みたいだ・・・。ということは・・・かなりPHPとWordPressへのチューニング必須だなあ・・・。それなりに高速化のプラグインは入れているんだけど、ちょっと泣けてきたって事で。

導入

http://wordpress.org/extend/plugins/db-cache-reloaded-fix/ からファイルをダウンロードし、解凍後 WordPress のプラグインディレクトリにアップ、もしくは管理画面のプラグインの項目から、DB Cache Reloaded Fixで検索してインストールして終わり。
そしてプラグインの設定画面から有効化して終わり。

すごく簡単なはずでした。が、見事にはまりました。今回はまったエラーは次のパターンでした。

Caching can’t be activated. Please chmod 755 wp-content/db-cache-reloaded-fix/cache folder

エラーの内容に wp-content/db-cache-reloaded-fix/cache のパーミッションを755にしてね～ということだったので、ディレクトリを作成、パーミッションも755にしてこれでOKだね！と作業しました。

動かない！じゃあググれ！

状況が変わりませんでした。
よくあるお約束なので、じゃあ777でどうよ？ということでパーミション変更。これなら書けるだろうということで、見ていたのですが、やっぱり駄目。
仕方が無いのでいろいろググってみると

WordPress高速化プラグインDB Cache Reloaded Fix – サツぽろ、ニッキ。 http://1day.sorezore.net/2011/09/20/13190/

キャッシュは動作していません。wp-content フォルダのパーミッションを 755 に変更してください。
とエラー出る場合は、サーバーのコントロールパネルでPHP5.1.6以上のバージョンか確認してみるとよいかも。

PHP自体は5.3系なので、関係ない。

DB Cache Reloaded導入でWordPress3.1を高速化（coreserver,xrea編） | 某氏のたわごと NEXT
http://1day.sorezore.net/2011/09/20/13190/

xreaやcoreserverではPHPがセーフモードで動作するため上記の方法では導入できません。

さくらのVPSで、セーフモードでもないので関係ない。でも、やっぱりここでもキーはパーミッションと実行状態。

他にもいろいろ見てみるけど、ほぼ全て問題なく動作している模様。
でも、そういうサーバーについては普通のレンタルサーバーっぽかったので、よけに悩む事になりました。

じゃあ、動くサーバーでどうさせようか

むだに悩んでもしょうが無かったので、実際に簡単に動作するのか、他のレンタルサーバーで動作しているWordPressにインストールして実験してみることにしました。

・・・なんの問題なく動作しやがった・・・。＠さくらのレンタルサーバー ビジネスプロ

ちょっと頭抱えたくなったのは置いておいて、WordPressもプラグインもPHPもバージョンがそろっているので、環境的にはかなり近い状態になりました。
とりあえず動いているプラグインの状況を確認してみると、

wp-content/db-cache-reloaded-fix/cache

無いんですけど？
はい？って事でもしかしてと思いました。
そしたら、 ありましたよ。

wp-content/plugin/db-cache-reloaded-fix/cache

ってのが・・・。

頭痛い・・・。

と、上記を踏まえ、以下のようにすることで、問題なく動作するようになりました。

chmod 777 wp-content/plugin/db-cache-reloaded-fix

終わり。

以下解説

WordPress上で作成したディレクトリ/ファイルの所有者 apache
FTPでアップロードした際のディレクトリ/ファイルの所有者 ftpuser

よくあるレンタルサーバーのように、上記が同じユーザーの場合には問題なく動作します。
このサーバーのように異なる場合には、WordPress上での自動インストールや、普通にFTPでアップしただけでは、プラグインのディレクトリに対してapacheが書けないからエラーになっていました。なので、apacheが書き込めるように、パーミッションの変更を行いました。
もしくは、 db-cache-reloaded-fixディレクトリの所有者をapacheに書き換えてしまう方法もありますが、これだと管理画面でのプラグインのバージョンアップが面倒になってしまうので、あんまりお勧めできないかなと。
で、今回最大の問題点だったのは・・・

出力するエラーのディレクトリ名間違っているやんけ～～～！！！

ということでした。