サーバの増強

bs_zuho01h
ブランドの公式サイトを運営するサーバを一つ上のコースに変更した。具体的に言うと、SAKURA VPS の 1G コースから 2G コースへ。1G コースではメモリがまったく足りず、土日は Apache の同時接続数を上回ってしまうという状況になっていた(関連記事:落ちる glace.me)。
関連記事にあるようにこれの原因は WordPress をつかっているからで、WordPress を使わずにすべて静的 HTML に移行すれば解決するのだが、年齢認証の所やメニューの構造などでべったりと WordPress に頼り切ってしまっていて、今更静的 HTML とか無理っす! ってことで、2G コースに移行することに(ぁ
で、石狩のデータセンタだと初期費用無料という言葉に目にくらみ、石狩にしてしまった。けど、ダウンロード・サーバも石狩なのよね(汗)。なので、旧公式サイトをダウンロード・サーバにして(こちらは大阪)、公式サイトを石狩にすることにする。
まぁこれらのサーバは Linux なのでボク自身がやるんじゃないんだけどね(ぁ

というわけでアクセスが少なくなり始めた AM3:00 頃、公式サイトを停止し、作業は 1 時間ほどで終了。2G コースにして、CPU コア(仮想)が 2 から 3 に、そしてメモリは 1GB から 2GB に。問題はメモリだったので、メモリはほぼ倍増したことになる。んで、同時接続数を倍に……とはせずに、30 から 50 にした。それでも重くてガタガタということはなくなったようだ。ちなみに Apache の同時接続数のデフォルト値は 200 なので WordPress をつかっていることにより 1/4 にパフォーマンスが落ちていることになる。うーむ……。VPS で WordPress ってのがやっぱりキツいのかなぁ。

apache_processes-day
グラフで見ると、ちょうど真ん中ら辺の Fri 00:00 アタリがぴったり 30 で頭打ちになっている。この間はめっちゃ重くなってしまっていた。Fri 12:00 で 30 を越えてグラフが伸びているのはもう 2G コースになっているからである。

StatPress Reloaded

WordPress のプラグインで、アクセス解析というのがあったので入れてみた。名前は StatPress Reloaded。ただこれはあくまでも WordPress のアクセス解析なので、WordPress に来た分しか録れないが。まぁでも面白そうなので。ところがけっこう情報が古い。どういう情報かというと、OS やブラウザが 3 年ぐらい前で止まっている。あと日本の検索エンジンにまったく対応していない。
というわけで設定ファイルを書き換えて、Docomo や Sleipnir 、livedoor、Yahoo Japan、Rakuten などに対応させた。これは、seachengines.dat を書き換えればよい。

Yahoo|search.yahoo.|p|
Yahoo|search.yahoo.|submit|
Rakuten|websearch.rakuten.co.jp|qt|
Docomo|search.smt.docomo.ne.jp|MT|
Bing|www.bing.com|q|
Bing|bing.com|q|
Sleipnir|search.fenrir-inc.com|q|
Conduit|search.conduit.com|q|

Windows 7, 8 に対応したい場合はos.dat を

Windows 8|WindowsNT6.2|
Windows 7|WindowsNT6.1|

のようにすれば OK。
ただ、この StatPress、痒いところにはなかなか手が届かないようで、出す情報も少ない。この辺、もっといろいろ表示出来ると良いんだけど。まぁだいたいダイジェストって感じ。ただ、訪問者の追跡(どのページを最初に見て、その後どのページを見ていったかなど)がけっこう楽なのが面白い。ブログだとそういう遷移が解った方がイイのだろう。
stat_view

WordPress あれこれ

某サイトをガリガリと作っていた。そのうち TAMA Networks でも挨拶する予定なんだけど、とりあえずサイトを紹介。

どれも WordPress で構築されている。
これらを組んだおかげで、WordPress で自由奔放にサイトを構築出来るようになった。Galette のサンタフル☆サマーのサイトも WordPress である。でも失敗しているところも実はあったりして、例えば GLacé のメニューはパーマリンクが失敗していて、カテゴリ ID が丸見えだったりとか(汗)。これは Windows Server だと rewrite がうまく動かなくなってしまった部分があって、仕方なくこうなっている(汗)。他にも相対・絶対ディレクトリの指定間違いとかがあったりして、そのたびに「あわわ」と慌てたり……いや、ちゃんとチェックしろよ(汗)。

スタッフ・ブログはいわゆる投稿ページで構成されているんだけど、サンタフル☆サマーはすべて固定ページで構成されている。スキンの方に PHP でページ名を判別して、レイアウトを変更している(現在の所、年齢認証、トップページ、その他の三つ)。GLacé 本体のサイトはトップページが固定ページで残りのページは投稿ページを使ってお知らせやダウンロードなんかを構築している。
スタッフ・ブログが一番 WordPress らしい使い方である。

なんでベタの HTML で組まなかったかというと、前の日記にも書いたような気はするけど、WordPress で構築しておけば、HTML が書けない人でもあとから更新出来るからってのが大きなメリットだったんだけど、実際に作ってみるとけっこう HTML の知識が必要だということが解った(爆)。特にサンタフル☆サマーのサイトはほとんど HTML ベタうちでつくってある(汗)。ただ、一応ボクが組んだヤツをコピペすればいいようにはしたんだけど……うーん、難しいなぁ。というのも、実は WordPress のエディタだけで作れないこともないんだけど、エディタ上で組むと、<div> や <span> を無視して改行されてしまったり、画像を挿入されてしまったりしてなかなか使いづらい。せめて <div> とか各段落ごとにうまく区分けして編集出来るようになってれば、WordPress のエディタでもいけそうなんだけどなぁ……。

ところで今回苦労したのが IE9 。とにかく IE9 だと、位置がずれるずれる。
基本 IE10 で作って、Google Chrome で確認してるんだけど、この二つはほとんど差はなく作れたんだけど、IE9 だと凄いずれる。主な原因は、Absolute。特にサンタフル☆サマーのトップページは重ねが多いため Absolute の嵐なのだが、right や left を設定してないと、親の ID(もしくはクラス)の text-align に左右されてしまうのね。本来座標を設定してないと、親の左上が起点になるはずなのだが、IE9 だと text-align で center とか設定されていると、親の真ん中の座標を起点に配置されてしまうのね……。もー。
あと CSS の座標指定を間違えて、 px じゃなくて x って書いてしまったところがあったんだけど、IE10 や Google Chrome ではそれを px として解釈して意図した位置に表示されたんだけど、IE9 では解釈してくれなかった。ところが HTML 側の表示順序を変えたら、意図した座標に表示されたりして、なんだこれw。
ただ IE9 は Windows 7 にデフォルトでついてくるブラウザなので、あんまり無視出来ないのよね。ちなみに IE8 や IE7 では確認してない(ぁ たぶん正しく表示されないような気がする。

まー、そんなこんなで、まだまだ WordPress、というか CMS を使ってサイトを簡単に構築する方法の模索は続きそうだ。
wp

WordPress とスタッドレス・タイヤ(何

相変わらず WordPress をいじっている。
テーマ(デザイン)さえ作っておけば、あとは HTML が解らなくても更新出来るのはよい。しかも WordPress には様々な関数が用意されているので、テーマの中にそれを仕込んでおけば色んなことが出来る。
とまぁ、ほとんど WordPress については理解したんだが、rewrite で変な現象が起きてしまった。それは、URI に必ず index.php というのが入ってしまうことだ。WordPress は rewrite と言う機能を使って、アドレスを自由に設定出来る。
本来、ブログのシステムというのはシステムに引数を渡して動く。例えば、2013 年 2 月 4 日の記事を見たかったら、amatsukami.jp/index.php?20130204 なんてアドレスになる。でもそれだとウェブページっぽくないので、amatsukami.jp/2013/02/04/ なんていう風に設定出来るのだ。amatsukami.jp/2013/02/04/ ってアクセスが来たら、サーバの方でこっそり amatsukami.jp/index.php?20130204 に書き換えているのだ。それが rewrite の機能である(ちなみに TAMA Networks では rewrite を動かしていない)。

事の発端は IIS で日本語の URI が通らないことだった。これが実は後に IIS のバグというのが判明するのだが、それと解らず、WordPress の方の rewrite の設定を変えてしまったのだ。ところがそれ以降、元の設定に戻しても index.php が必ずつくようになってしまった……orz。amatsukami.jp/2013/02/04/ ですむところが、amatsukami.jp/index.php/2013/02/04/ となってしまうのだ。
ネットで検索すると原因はいろいろあるようで、いろいろ試してみたんだけど今のところ解決出来ず。うーん、なんだこれ? ただ IIS はテスト用のサーバで、本番サーバは Linux の apache で動いているから特に問題はないのだが、テスト・サーバと本番サーバでURI が異なるという状態になってしまった。うーん、これは困った。これでは、テストで作ったコンテンツをそのまま本番にコピーすれば動くという環境じゃ無くなってしまうではないか。
まぁ IIS の方は合間合間に調べるしかないかなー。

BCQX6jQCYAACMUY
会社に着いたらスタッドレス・タイヤが届いていた。苦節一ヶ月。ようやくである。
スタッドレス・タイヤを買うことになったのは去年の 12 月、親父の PC の調子が悪いと言うことで呼ばれていたのだが、草津はすでに雪であり、スタッドレス・タイヤが必要だったからだ。そこで買いに行ったのだが、どこも売り切れだった。で、通販で買うことにし、12 月の終わりに注文したのだが、年明けになって「そのタイヤ、エスティマじゃ合わないかも」って連絡があり、選び直しになってしまい、さらにボクが自分が担当するブランドのウェブサイトとかで忙しくなってしまい、1 月の下旬に注文し直し、ようやく届いたと言うわけである。

今冬はこれで勝る!!!

ところでなんで前の車の時はスタッドレス・タイヤを持っていなかったかというと、走り屋仕様のスタッドレス・タイヤはすっげーたかくて、そのうち買おうなんて思っていたら車そのものを乗り換えてしまったでござる。いやー、エスティマのいい所ってとにかく大衆車ってことだよね。色んなパーツが安い。前の車なんて、車検でも毎回すごい金額だったので、エスティマになってからは(燃費以外)財布に優しい車だなーと思っている。

WordPress のテーマとか

カリカリと WordPress のテーマ用の PHP 書いたりしてた。
ボクが担当しているブランドのウェブサイト公開が近づいている。今までは HTML を書いていたんだけど、今回のブランドでは各プロジェクト・リーダーに更新させようと思っている。プロジェクト・リーダーは HTML や CSS に明るいわけではないので、更新のシステムに CMS を導入することにしたのだ。それが WordPress だ。 で、WordPress でブランド用のサイトのデザインを作っておき、ディレクタは WordPress を更新するだけでよいという方法を試すつもりだ。

ただ、うまく行くかどうかは解らない。と言うのも、エロゲ・ブランドのサイトを WordPress だけで作れるかどうか疑問な点がけっこうあるからだ。バナーだけのページとか作れるのかなぁ……?? 実はよく解っていない。

もう一つの懸念点はまったく違うテーマ(デザイン)をページごとに適用したい場合だ。WordPress では特定の記事のテーマを切り変えることが出来るがしかし、これは単純に今あるテーマにそのページ用のデザインを作るという方法をとっていて、まるごとテーマそのものを切り替えることができない。
エロゲではプロジェクトごとにオリジナル・サイトを用意することが多く、プロジェクトごとにデザインも何もかもが異なる。で、色々調べていると、どうやら WordPress はマルチサイト機能というのがあって、そもそも複数のサイトを一つの WordPress で構築出来るらしい。
モードは二つで、サブディレクトリ・モードとサブドメイン・モードだ。
サブディレクトリ・モードというのは、例えば、 amatsukami.jp が親だとしたら、amatsukami.jp/products/ とか amatsukami.jp/developments/ とかサブディレクトリで別のサイトを構築するモード。
サブドメイン・モードは、blog.amatsukami.jp とか tamaki.amatsukami.jp とかサブドメインで別のサイトを構築するモード。
このマルチサイト機能を使うと、各サイトごとにテーマが 0 から設定出来る。なので、まったく違うページも、一つの WordPress で出来てしまうのだ。これは便利!!
というわけで、本ちゃんのサーバはすぐに設定が完了した。それは本ちゃんのサーバが Apache だからだ。WordPress でマルチサイト機能を ON にすると Apache の設定ファイルも生成してくれる。だから、それをそのままサーバに設定すればよい。
ところが更新前のテストに使っているサーバは Windows Server で、そこに WordPress を入れている。マルチサイト機能を使うには rewrite という機能が必要だ。これはどういう機能かというと、URI を色々と内部で書き換えてくれる機能なのだ。例えばサイトを引っ越ししたときに、旧サイトから新サイトへアドレスをサーバ側で書き換えたり、CGI の引数をあたかも HTML の静的ページに見せたりとかそういうときに使う。
IIS には rewrite 機能があるものの、設定の方法が Apache と違う。で、結論から言ってしまうと、Apache の設定をそのまま IIS に設定する方法があるのだが、ボクはそれを知らずに一生懸命 WordPress の rewite の仕様を探してしまった……orz
rewite の仕様を読み、それから WordPress の書き換え後の URI を調べようとしたのだが、とにかくこの WordPress の書き換え後の URI について解説しているページが見つからなくて、あーでもないこーでもないと色々試行錯誤しつつ、だめだー 404 エラーになるーって途方に暮れていたのだ。
で、ふと IIS の rewrite の設定を見てたら、インポートって言うのがあった。よく見ると、.htaccess に書く Apache の設定をそのまま書けばそれがそのまま IIS の設定になるらしい。イヤン、もっと早く言ってよ!!!<お前の目が節穴なだけだ

ということで、無事、テスト・サーバでもマルチサイト機能が動くようになった。
で、まぁ色々とスキンもとりあえずトップページ用は完成したので、更新準備完了。
これから WordPress とは長いつきあいになりそうである。
紹介する曲は、アランフェス協奏曲。ギター協奏曲というクラシックではけっこう珍しい協奏曲。もっともこれをクラシックを認めない人も多いけど(笑)。その昔 Falcom の Brandish っていう RPG のオープニングはこれのパクリオマージュである(ぁ

WordPress の spam 状況

相変わらず、WordPress への spam 書き込みがひどい。まぁ、すでに TAMA Networks が  spammer に周知されてしまったので、もうどうしようもないのだけれど。更新 ping は海外のブログ・サービスには送らないようにした。その辺の話題は、12/12 の日記に詳しい。まぁとはいえ、spam を書き込まれたからと言って、ボクが認証するまでは表には出ないので、このページを見にきてくれた人たちには何の影響もないと思う。

それにしても一日に何通も来るので(WordPress に書き込みをすると、ボクにメールが送られてくる)、ついでに数を調べて見たのだが、実に 75.7% が spam であった。残りの 24.3% がボクが承認した書き込み。いやはや、spam 率が高いですな。

でね、12/12 の日記で更新 ping を海外のものから、日本のものに送るようにしたと書いたんだけど、そしたら日本語での spam が多くなった(爆)。うひー、わたしが浅はかでした! まったくもー!! とりあえずメール通知やめちゃおうかなぁ……。

WordPress 3.5 アレコレ

bs_ruri01f
TAMA Networks で使っている CMSWordPress)がバージョン・アップして、3.5 になった。特に何の気もなく、バージョンアップしてしまった(マテ)。そしたら予想以上にいろいろ変わっていたので、ちょっとびっくり。今度からはちゃんとリリース・ノート読もう!<サーバ管理者としてあるまじき行為
なんと言っても一番変わったのは画像などを貼り付ける画面。今までと全然違う。今まではアップロードが前提となっていて、画像を貼り付けるたびにアップロード画面になって面倒だった。何故面倒かというと、日記で毎日使われているキャラクタの顔は、既にアップロードされているデータであるため、既にあるデータを選ぶ画面(ライブラリ)に切り替えてなくちゃいけなかった。っていうのと、アップロードされたファイルは新しい順に表示されるので、古い方に切り替えなくちゃいけなかったし。それに、写真などをアップロードしたときも、まとめてアップロードしたあとはアップロード画面ではなく、ライブラリ画面から選ぶわけで、アップロード画面なんていうのは、最初だけしか使わないのである。
3.5 になってから、ライブラリ画面がデフォルトとなった。さらに複数の画像が一度に貼り付けられるようになった。今までは一枚貼ってはメディア画面を開き、ライブラリ画面に遷移し、画像を選んでいたのだが、3.5 からは貼り付けたい画面を CTRL や Shift キーで選べば OK。あとはどばーっと並べて貼っ付けてくれる。

トラブルと言えば、アップデート機能が動かなくなったこと。エラー・メッセージを見てみると、C:\Windows\Temp にアーカイブ・ファイルがねーよと出ていた。そこで原因はすぐに分かった。そのフォルダはそもそも PHP などで書き込みできるようにはしていない。CGI でアクセス出来る場所は別に用意してある。今までのバージョンでは php.ini に書かれているテンポラリ・フォルダを見に行っていたようだが、3.5 では Windows の環境変数を見に行ってしまうようだ。
そこであれこれ色々調べて見ると、どうやら WordPress には WP_TEMP_DIR という定数があるっぽい。ここに、CGI 用のパスを設定すればよいのだろうと勝手に推測<ソースを見んかい! wp-config.php に勝手に以下の一行を追加。

> define(‘WP_TEMP_DIR’, ‘テンポラリ・フォルダへのパス’);

無事に更新機能が動くようになった。めでたし、めでたし。