Xoopsの高速化の第一弾として、MacOS X 10.4のウェブサーバをapache1.3から2.2.8へアップしました。あわせてphpもphp4.4.7から4.xの最後のバージョン、php4.4.8へアップしました。
さて、次の作業としてphpの高速化を図ります。
phpを高速化するためのプログラムがいくつかあるようですが、ここは国内のphpソリューションベンダとしては最大のZendが無償提供している"Zend Optimizer"を使ってみることにしました。
　　Zend Optimizer
現在Zend Optimizer3.3.0英語版が最新版で、MacOS Xに関してはユニバーサルバイナリー版が提供されています。嬉しいですね！MyZendにユーザ登録をし（無償）ログインするとダウンロードできます。ちなみに日本語ドキュメントも提供されていますが、こちらはひとつまえの3.2.0のものです。まぁさほど違わないでしょう。
インストールは超簡単。ダウンロードしたパッケージを解凍するとinstall.shというシェルスクリプトがあるので、これをターミナルから実行するだけです。
実行により、Optimizer一式が/usr/local/Zend以下にインストールされます。またphpの初期化ファイル、/etc/php.iniの最後にOptimizerの設定が追加され、/usr/local/Zend/etc/php.iniに移動されます。あわせてphp.iniのシンボリックリンクが/etc以下にできます。
無事インストールが終わったら、インストーラがapacheの再起動をしてくれます。これで完了です。

さて、無事オプティマイザーが組み込まれているかどうか確認します。

phpinfo()をつかってphpの環境変数を表示したときに、下記のようなバナーが表示されるはずですが、そこに"Zend Optimizer v3.3.0″という文字が現れれば、無事組み込まれています。

うちのサーバはPowerMac G4 500MHzという非力なマシンなのですが、Xoopsという便利ではあるけれども非常に重いCMSを使っています。いろいろとモジュールが揃っていたり、インターネットを探せばたくさん情報もあるし本も多く出ているのでなかなか他に移行できないのです。

 

が、いよいよもってこの重さに耐え切れず、また先日Apacheの最新版, apache2.2.8がリリースされた というニュースを見て、ぼちぼち高速化を進めることにしました。

 

まずサーバの構成を確認します。俗に"MAMP"というものですが、Living-e AGが最近配布している超お手軽パッケージではなく、地道に各パッケージごとに手動で入れています。理由としては、MAMPパッケージに含まれるアプリケーション以外のものを入れたいときに、格納場所などが特殊なところになっていたりするとやっかいだからです。

 

• OS : MacOS X 10.4.11 (Tiger)
• Webサーバ : Apache 1.3.3 (Tigerに標準のもの)
• php : php 4.4.7 (Xoops2.0.6jaに合わせて)
• MySQL : mysql-standard-4.0.25-apple-darwin7.9.0-powerpc
• CMS : Xoops 2.0.6ja

phpやMySQLが非常に古いバージョンを使っている唯一の理由はXoops2.0.6を安定して走らせるためです。（ひょっとしたら最近だとphp5にMySQL5で動くのかな）

 

一気に全てをアップグレードするのはリスクが大きすぎるので、まずは最もXoopsから遠く、直接的な関係のないapacheから。

 

現在apacheは1.3系とスレッド処理などで負荷処理が賢くなった2.x系があります。

MacOS Xでは、10.4が1.3系、そして新しい10.5が2.x系（現時点で10.5.2には2.2.6が入っています）となっています。なので、「OSを10.5にすりゃいいじゃん！」という気がするのですが、10.5はG4 800MHz以上（たしか）にしかインストールができず、うちのマシンには10.5を入れることが出来ないのです。なので、OSは10.4のままで、必要なアプリのみ手動でアップデートするしかないというわけです。

 

さて、Linux等と違いMacOSの場合、おいそれと簡単には./configure, make, make installとはいかないという事情があります。apacheの場合はそれ自身がMacOSの重要な機能をつかさどっている一部になっているので、その部分を無視して入れてしまうとMacOS側の機能が使えなくなってしまいます。特に問題なのは「Webファイル共有」関係。詳しいところは分からないのですが、例えばLinux向けのapacheディストリビューションには含まれない"mod_bonjour"というモジュールが組み込まれています。

 

またapacheの起動に関しても、rcなどではなく、/etc/hostconfigにWebサーバの起動・停止フラグを記述し、それを見て/System/Library/StartupItems/Apache以下のスクリプトが走るようになっています。ちなみにこれらのMacOS Xとのからみを完全に無視していれることも可能ですし、ちゃんと動きます。ができるだけMacOS Xの作法に従ってエレガントに入れておいたほうがあとあとややこしくなくていいかと。

 

さて、とりあえず実行モジュールを準備する上で一番の問題は上のmod_bonjourをどうするか？という点。Apacheサイトの説明によると、1.3系から2.x系への移行でモジュールとのAPIが大幅に書き換えられ、1.3系のモジュールをそのまま持ってきても動きません　とのこと。

 

なので、その他の多くのモジュールは2.xに含まれるソースからビルドしても問題ないわけですが、mod_bonjourがない。ところでMacOS Xの最新版である、10.5 (Leopard)に標準でバンドルされるapacheは2.2.6なのです。2.2.6と2.2.8の差異はわずかなので、PPC版のMacでMacOS X 10.5が入ったやつがあれば、これから少なくともmod_bonjourだけひっぱってきてインストールしてやれば動きそうな気配です。

 

幸いにもPowerBook G4 15inch (late2006)に10.5を入れたものがあったので、こいつからひっぱってくることにしました。

• /etc/apache2 （設定関係の入っているフォルダ。1.3では/etc/httpdでした）
• /usr/libexec/apache2 (mod_*の入っているフォルダ。1.3では/usr/libexec/httpdでした）
• /usr/include/apache2 (ヘッダファイル関係。実行時には直接は必要ありませんが）
• /usr/sbin/apachectl, httpd （apache2.2.6の制御アプリと本体）

ためしに、そのままごっそりコピーしてきて、ただし/usr/sbin以下の2つのファイルだけは現行の1.3と重なっていますので、上書きしてしまっては大変ですから、オリジナルをapachectl1.3, httpd1.3にリネームして、2.2.6のものをapacheclt2.2.6, httpd2.2.6として同様にコピーし、MacOS Xが起動時に期待する名前となるようシンボリックリンクを張ってから起動してみます。

 

% ln -s ./apachectl2.2.6 ./apachectl

% ln -s ./httpd2.2.6 ./httpd

 

これで、だめもとでapachectl startをかけてみます。

が、見事撃沈。予想はしていましたが、ダイナミックリンクライブラリ関係も大幅に新しくなっているようで、エラーが出るライブラリをひとつひとつ10.5からコピーしてきましたがきりがありません。早々にLeopardの2.2.6を動かすという甘い考えは捨てて、apache本家のソースアーカイブからビルドすることにしました。（これにより必要なダイナミックライブラリも作られます）幸いにも本家ソースはそのままMacOS Xでビルドできるようになっているので、./configure, makeでおしまいです。

さて、ここで普通ならばmake installとやりたいところですが、標準のapacheがインストールされる場所とMacOS Xでは場所が違います。さて困った、どうするか。

しかし幸いにもapache2のインストール先は、ダイナミックライブラリを除き、/usr/local/apache2以下に設定ファイルなども含め全て集約されるので、とりあえずmake installでインストールしておき、あらためて必要なファイルをコピーして移動するか、シンボリックリンクを張ることで対応することを考えます。ちなみに対応関係は以下のとおりです。

	MacOS X	apacheオリジナル
実行イメージ	/usr/sbin	/usr/local/apache2/bin
設定ファイル	/etc/apache2	/usr/local/apache2/conf
モジュール	/usr/libexec/apache2	/usr/local/apache2/
コンテンツ	/Library/WebServer/Documents	/usr/local/apache2/htdocs

MacOSが期待する場所へあとでシンボリックリンクを張っておけば大丈夫でしょう。またいっぽうで上記でビルドしたapachectl, httpdはapacheデフォルトのパスにhttpd.confなどがあることを期待するので、そちらにリンクを張ります。モジュール関係、ログファイル、コンテンツファイルの場所に関しては、httpd.confと、あと2.xから増えた./conf/extra, ./conf/otherディレクトリ以下にある追加設定ファイルに記述されているのでこれらを書き直せば問題ありません。

 

こういう付け焼刃的なやり方をせず、きちんと見るべき場所、インストールされるべき場所を指定してビルドするときは、apacheのconfigureのマニュアルをご覧下さい。

 

1.3のhttpd.confと、MacOS X 10.5に標準で入っていた2.2.6のhttpd.confの中身を良く見比べて、1.3の方で手動で設定している部分を転記します。

 

終わったらapache -vとか、httpd -vとかやってちゃんと2.2.8の実行イメージが見えているかを確認したうえで、apachectl startをします。

 

これで無事入れ替え完了！

 

となればよかったのですが、xoopsが使っている肝心のphp4.4.7のモジュール、php4_mod.soが動きません。php4のサイトを見ると、どうやら2.x系向けに作り直してやらねばならない様子。しょうがないのでphpのサイトから、4.4.7、ではなく、つい最近リリースされた最新版の4.4.8を持ってきて、

 

./configure –with-apxs2=/usr/local/apache2/bin/apxs –with-mysql=/usr

 

とかやったように思います（汗）

追記：

その後いじってると、mb-string関係の機能がごっそり落ちていたので、ブログで記事がアップされない、などの不具合が出ました。以下のスクリプトをconfigure.shという名前で保存し、chmod 555 configure.shとしてビルドしたらうまく動くようになりました。手抜きはいけません、手抜きは（汗）

#!/bin/sh
./configure \
  –with-apxs2=/usr/local/apache2/bin/apxs \
  –enable-mbstring \
  –enable-mbregex \
  –enable-zend-multibyte \
  –with-xml \
  –with-mysql

これで/usr/local/apache2/modules/libphp4.soが出来るので、これを/etc/apache2/httpd.confのモジュールがロードしてあるところの下のほうに下記を追記し、

#LoadModule fastcgi_module     libexec/apache2/mod_fastcgi.so
LoadModule php4_module        /usr/local/apache2/modules/libphp4.so　←これを追加

<IfModule !mpm_netware_module>

さらに、/etc/apache2/other/php4.confというファイルを以下の内容で作り（同じ場所にあるphp5_mod.confからコピーして作ります）

<IfModule php4_module>
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php-source .phps

        <IfModule dir_module>
                DirectoryIndex index.html index.php
        </IfModule>
</IfModule>

あらためて、apachectl startを実行すると。。。お！無事動いています。

とりあえずいくつかあるバーチャルホストでxoops、Drupalなどの動きを確認してますが、いまのところ問題なく動いているようです。

次はｐｈｐの高速化か、MySQLだなぁ。。。

追伸：

新しいApache2.2.8の本体をMacOS Xが期待する場所に直接おかず、シンボリックリンクにしたのにはわけがあります。apacheはMacOS Xの機能の一部になっているので、ソフトウェアアップデートで上書きされてしまう可能性があるからです。ソフトウェアアップデートを実行したがために上書きされてしまっては元も子もないので、シンボリックリンクにしておき、ソフトウェアアップデートが上書きするのはリンクのみにしようとしたわけです。これならアップデート後、おかしくなったらリンクを確認し、実態に置き換わっていたらあらたえてリンクを張りなおせばオッケーです。

追伸２：

apache1.3をapache2.2.8に入れ替えた結果ですが、残念ながら劇的に応答が速くなった感じはありません。ただまぁ、アクセスが集中することがあれば、威力をきっと発揮してくれることでしょう（汗）

　　「人生は毎日が勉強」

といいますが、xoopsサイト運営に付いても同じ事が言えるようです。

　　「Webサイトは毎日機能強化」

　一通りサイトの形ができたので、当面コンテンツ作りに専念しようと思ってたんですが、やりはじめると、「あ、これはここにメニューを追加したいなぁ」とか「ここにリンク追加のボタンを追加したいなぁ」と、とめどもなくやりたいことがでてきて、結局コンテンツを作りながらサイトそのものの機能強化も併せて実施しているような状況です。

　さて、先日トップページに「このサイトについて」のカスタムブロックを作成して設置したんですが、いつも表示しておくのもスペースがもったいないので、左側のメニューに追加する事にしました。

　必要なときに読めればいいですからねー。

　こういった任意のブロックはXoopsのカスタムブロックで作っちゃうのが早いんですが、このカスタムブロックを表示するには、いずれかのモジュールに割当をしないとだめですよね。とりあえず「トップページ」に割り付けをしてたんですが、メニューに表示をするには、カスタムブロック単独では無理。さてどうしたものか。。。

　いろいろと調べてると、noneモジュールってのを見つけました。

　noneモジュールってのは、何の機能も持たないモジュールとしてXoopsに追加できる必要最低限のコードのみを持ったモジュールです。このnoneモジュールはモジュールなので、Xoopsにモジュールを追加した後、「none→このサイトについて」てな感じで名前を変更してやれば、メニューに「このサイトについて」が追加され、これをクリックすると、白紙のページが表示されます。このモジュールに先ほどのカスタムブロックをアサインしてやればいいわけです。

　さて、とりあえずこのnoneモジュールをXoopsのmodulesディレクトリにコピーします。あとあとメニューに追加されたときに、noneモジュールへのURLが

http://www.sailweb.net/modules/none/

になってしまうので、これはかっこよくない！なので、ついでにディレクトリ名も変更する事にしました。
単純に

modules/none/

を

modules/about/

にしてやればいいんですが、これだけだと管理画面でアイコンが出てきません。それでnoneモジュールを構成する以下のファイルのxoops_version.phpファイルを編集します。

// change
$modversion[’name’] = ‘NONE モジュール’;
$modversion[’dirname’] = “none”;

このnoneをaboutに変更してやります。

　これでXoopsの管理画面からモジュールの追加をしてやると、無事noneモジュールの追加が完了です。管理画面のモジュール管理画面にて、noneモジュールの名前をnoneから「このサイトについて」に変更し、メニューでの表示順序を1にしておきます。（これで「ホーム」の下に表示されます）

　さてモジュールを追加したら、忘れずにゲストへのアクセス権減を追加しましょう。

　最後に「このサイトについて」を記述したカスタムブロックを、このnoneモジュールの中央真ん中へ表示するよう割り付けします。これでおしまいです。

　うむ、なかなかいい感じ。

　Xoopsの管理画面で何か設定を変更したりした際に、それを実行する際のボタンが画面の下に表示されます。たとえば下記のような感じ。

 

 

　だいたいが「キャンセル」「送信」という場合が多いですが、いったいこの「送信」ってどういう意味なんでしょうね。元々の英語版での文字列は"GO"です。GOならば意味がピンと来ます。こういう場合の意味は「実行」です。ところがなぜか、日本語版では、何かを決定する場合のボタンの文字列が全て「送信」になってます。なぜこのような文字に訳してしまったのか、不思議で仕方ありませんが、僕としては非常に気に入りません。ここは「実行」あるいは「決定」であるべきです。

 

　そこで、これを変更する事にしました。Xoopsの日本語モードであちこちに表示される「送信」文字列は、

{xoops_dir}/language/japanese/global.php

で定義されています。

define('_GO','送信');
define('_NESTED','ネスト表示');
define('_NOCOMMENTS','コメント非表示');

上から１７行目に肝心の「送信」文字が設定されている所がありますので，これをテキストエディタ等で変更してやればOKです。

define('_GO','実行');

　終わったら忘れずに、システム管理画面の「モジュール設定」で「システム管理」モジュールの更新を忘れずに実行しましょう。（そうしないと、変更が反映されません）

 

　「送信」という意味合いは、このXoopsという管理システムを作ったか、あるいは中身とその動作を良く理解している人間からすれば、このボタンを押す事で，内部でどのような処理が実行されるのか，が想起される表現なのかも知れません。

 

　しかし、多くの利用者は中身の動きについてよく理解している人はまれで、殆どの人の理解はもっと直感的です。

「送信」ボタンを押す　→　ただちに変更される。

間でどのような処理がなされ、何がおきているかなど、まぁどうでもいいことです。例えば車を運転しているときに、ブレーキを踏む行為を考えます。普通は

「ブレーキを踏む」　→　「車が減速する（とまる）」

という具合に、行為と結果が単純に結びついています。もしブレーキペダルにラベルをつけるとすれば、「減速する」とか「停止する」といったところが妥当でしょうか。ところが車の設計者は、ブレーキペダルを踏む事によって中で何が起きているか知っているので，つい「油圧を高める」といったラベルをつけてしまうかもしれません。「送信」という訳にはそういった意味あいがあるように感じます。

 

　ユーザからすれば、極端な話中身の動作はどうでも良く、自信が実行した行為によって、結局何が起こるのか？が直感的に分かれば良いし、むしろ複雑なシステムでは極力中身の動きを意識せずに操作できるように、外側からそのシステムを操作するための手足、インタフェースをデザインする必要性があります。これをユーザサイドから見たときに「インタフェースの透明化」、システムサイドから見たときには「機能の隠蔽（あるいはカプセリング）」と言います。「透明化」の意味する所は、いまこのボタンを押したら、結果として何が起こるか瞬間的に分かるようにまるで向こう側がガラス張りのように見通し良くなっている、ということであり、「隠蔽」とは、ユーザが中を見なくても良いよう、外側のインタフェーを分かりやすくして、中の動きや機能を見えなくする、（そして混乱を少なくする）ということを意味します。

 

　このような意識が少しでも頭の中にあれば、ちょっと工夫でシステムの誤操作や操作上の混乱を少なくする事ができます。今後ますます、世の中にある道具や機械、システムが複雑化していくのに伴って、これまで以上に設計者／管理者はこのようなインタフェースの透明化を明示的に意識する必要があるでしょう。Xoopsの「送信」の問題は些細なことではありますが、まだまだそんな些細な事にさえ注意が払われない道具が氾濫しており、とても気になります。■

 

↓↓↓　「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

このサイトも、ブログの部分はとりあえず枠組みができあがったので、ぼちぼち日記も（なるべく）毎日書くようにしています。

 

そこそこコンテンツも増えてきたら気になるのが、自分のサイトがGoogleとかの検索サイトでちゃんと検索できるようになっているか？ということです。 一応、最初の頃にGoogleとYahoo!に関しては検索登録をしていたのですが、ここんところいくつか書き加えた記事が検索にひっかかるようになっているか調べてみました。

 

一般的に検索サイトのbotが探しにくるにはしばらく時間がかかるのですが、Xoops Analyzerでログを見ていると、定期的にGoogleやYahoo!などのbotがちゃんと見にきてくれているようです。 ところが、Googleで検索をかけてみると、トップページしか出てこない！肝心の日記記事はまったくひっかかりません。 Webをぐぐってみると、どうやら検索エンジンは、URL表記が動的表記よりも静的表記をより好んでクロールしてくれるようです。

 

インストールしたままのwordpressの各日記記事へのURLは以下のようなフォーマットになっています。

    http://www.sailweb.net/modules/wordpress/index.php?p=96 　※1

つまり、index.phpというphpのスクリプトに、記事番号96を与えると、ID=96の記事が表示されるという寸法です。このようにphpやperlなどのスクリプトにパラメータを与えて、表示される内容を動的に生成しているページをbotはどうも苦手としているようです。

 

またこのような動的生成ページのURL表記を俗に「動的表記」と言います。

 

いっぽう、Googleなどの検索サイトのbotが好む静的表記は、以下のような表記です。

    http://www.sailweb.net/modules/wordpress/2007/04/23/96/   ※2

つまり、URLを見た限り、一見/2007/04/23/96/index.htmlといったようなプレーンなhtmlファイルへのリンクです。

したがってせっかく見に来てくれたbotにきちんと情報を持っていってもらうには、※1のような表記を※2にしてやる必要があります。

 

さてそのやり方ですが、単純な方法は、動的に生成されたページをあらためて静的なhtmlファイルとして別に保存してやる、という方法ですが（たとえプログラムなどで自動処理をしたとしても）手間がかかる上、同じ情報がひとつのwebサーバに２重に存在するという点であまりよろしくありません。ディスクスペースを２倍消費するし、管理も２度手間になります。

通常はこのような人海戦術的単純戦略はとらずに、webサーバのURL書き換え機能を利用するのが常套手段です。例えば多く使われているwebサーバであるApache（アパッチ）には、mod_rewriteというモジュールが組み込まれていることが多く、これを使ってURLの書き換えを比較的簡単に行うことができます。mod_rewriteモジュールは大手のフリーのブログサイトであればだいたい組み込まれていることが多いようです。

またApacheのmod_rewriteモジュールの使い方については、例えば下記のようなサイトを参照されると良いでしょう。

  mod_rewriteリファレンス

mod_rewriteの基本ですが、

Apacheのsystem configurationファイル: /etc/httpd/httpd.confなど、もしくは

ユーザディレクトリの設定ファイル: <任意のユーザwebドキュメントディレクトリ>/.htaccess

のいずれかに、mod_rewrite機能をonにするコマンドと、書き換えのルールを記述してやれば使えるようになります。

 

httpd.confはApache全体のシステム設定用のファイルで、こちらにmod_rewriteの記述をしてやる方が.htaccessへ記述するよりも処理の負荷が低いらしいです。しかしながら、当然自分が管理しているサーバでなければhttd.confはいじれません。フリーや商用のブログサイトに間借りしている場合は.htaccessを使うことになります。

今回、僕はhttpd.confへの記述追加を試みたのですが、後述しますがwordpressが自動生成してくれるmod_rewrite用のコードが、.htaccess用に記述されているようで、単純にこれをhttpd.confへ追記しただけではうまくいきませんでした。なので、以後は.htaccessへ追記するやり方を書きます。

 

１．httpd.confの確認

この項目は、ご自身がサーバを管理していてhttpd.confをいじれる人のみが必要な作業です。外部サーバを借りている場合は、殆どのケースすでに設定がなされているケースが多いようなので、次に進んでください。

まず、httpd.confで、ユーザディレクトリで.htaccessが使えるようになっているかどうかを確認しましょう。今回はwordpressのモジュールにアクセスがあった場合にmod_rewriteが動けばよいので、Xoopsのwordpressモジュールのインストールディレクトリを<wp_home>だとして、以後説明をします。<wp_home>はご自身の環境にあわせて読み替えてください。

まず<wp_home>にあとで設置する、.htaccessファイルをapacheがきちんと読んで処理してくれるよう、<wp_home>での.htaccess利用を許可する必要があります。これは、httpd.confの中に以下の行を追記することで使えるようになります。

<Directory <wp_home>>

    AllodwOverride all

</Directory>

なお、これを指定することで、ユーザ側が.htaccessに必要な処理を記述することで、全ての処理をオーバーライドできるようになるので注意が必要です。なので、<Directory *>などとせず、ほんとに使いたいディレクトリ（今回はWordpressのインストールディレクトリ）のみを明示的に指定するようにしたほうが良いでしょう。バーチャルホストを使っている場合は、

<VirtualHost <バーチャルホスト名>>

<Directory <wp_home>>

    AllodwOverride all

</Directory>

</Virtual>

という感じで、バーチャルホストの記述の中に追記します。

httpd.confでこの記述を追記したら、apacheを再起動する必要があります。

% apachectl restart

これで無事新しいhttpd.confが読み込まれて、該当のwordpressのディレクトリで.htaccessを使えるようになります。

もしうまくいかなかったら、apacheのエラーログを見て、記述に間違いがないか、きちんと起動しているかを確認すると良いでしょう。

(/var/log/httpd/error_logとか）

 

２．.htaccessの作成

.htaccessは普通のテキストファイルなので、ご自身でサーバがいじれる場合は、サーバの<wp_home>に直接viなどで作成しても良いですし、外部のサーバを使っている場合はPCでテキストファイルを作成しておいて、ftpでアップロードしても良いでしょう。

さて、基本的なやり方は下記のとおりです。（実際のwordpress用の設定方法は後述します）

例えば、

http://www.sailweb.net/modules/wordpress/index.php?p=97　(1)

を

http://www.sailweb.net/modules/wordpress/articles-97.html　(2)

という静的リンクに書き換えたいとします。その場合は下記のようなルールを.htaccessに記述します。

RewriteEngine on　(3)
RewriteCond %{REQUEST_FILENAME} !-f  (4)
RewriteRule ^articles-([0-9]+).html+ index.php?p=$1  (5)

(3)は、このディレクトリへのアクセスの際にmod_rewriteエンジンを使う、という宣言です。(4)は、外部のウェブブラウザからこのディレクトリにアクセスしてきた場合に、該当ファイルがなければ、(5)のルールを適用する、という条件文です。そして(5)が肝心のルールです。

(5)のルールの意味は"^"が行頭を示し、行頭からすぐに"articles-"という文字列が続くことを意味します。そのあと([0-9]+)は"0〜9までの数字が一つ以上続く文字列"を意味しますので、(2)の"97″がこれにマッチします。そしてその後ろに”.html"が続くというパターンを示しています。なお([0-9]+)の両サイドの"(,)"（カッコ）がグループを意味し、マッチした文字列を$1という変数で参照することができます。

つまりここでは"$1=97″ということになります。さて、スペースをはんさんで"index.php?p=$1″という記述がありますが、$1はここでは97に置換されるので、結果として、(2)の"articles-97.html"は(1)の"index.php?p=97″に置換されて、無事アクセスできる、という仕組みです。

なお、.htaccessへ記述するルールのなかで、(5)の検索パターン"^articles-([0-9]+).html+"の中には、サブディレクトリの記述ができないようなので、注意しましょう。たとえば、archiveというサブディレクトリが<wp_home>以下にあったとして（wp_home>/archive）このarchiveというサブディレクトリを検索パターンに含めたいことがあるかもしれません。

つまり"^archive/articles-([0-9]+).html+"という感じです。しかしこれはちゃんと動きません。もしそのようなサブディレクトリを使いたい場合は、まさにそのサブディレクトリの中に.htaccessを作るようにします。（ちなみに、httpd.confではそういった記述は可能です。ただし、<Directory <dir>>の<dir>との兼ね合いになります）

.htaccessは、その場所にアクセスがあった場合に毎回webサーバが読み込むので、.htaccessを置いた瞬間から有効になります。もし一時的にこの設定を無効にしたいとか、編集中は使って欲しくない、というときは、.htaccess.workとか適当な名前に変更しておくと良いでしょう。

さて、これで無事(2)のURLで(1)へアクセスがリダイレクトされるようmod_rewriteの設定が終わりました。

が、これで終わりではありません。mod_rewriteとしての設定はこれで十分なのですが、本来の目的はSEO対策、つまり検索サイトのbotが当該ホームページをクロールしにきたときに、そのページのどこかにこの静的URL(2)で書かれたリンクがあって、当該ホームページにそのページが存在することを知ってもらわねばなりません。

 

３．wordpressでの静的リンク設定

予め当方環境では、xoops用のwordpressモジュールである、WordPress Me 0.6.0aを使っていることを記しておきます。

当該サイトに、肝心の静的URLで示される日記ページがあることをbotはどのようにして知るでしょうか？人間のユーザであれば、wordpress Meの「最近の投稿」ブロックのリンクから辿るでしょう。つまり、この「最近の投稿」ブロック（を含め、そのほかの関連ブロック）からのリンク表記も静的URLになっていなければなりません。デフォルトでは、このへんのリンクは、マウスカーソルをリンクにあわせてもらえばわかりますが、依然として動的表記のままです。つまりこれではSEO対策になりません。

サイトのページ上で現れるそのほかのリンクも全て静的URL表記になっていなければ結果としてBotは肝心の各日記ページを登録できないのです。幸いにもwordpressでは、$Permalinkという変数で、各モジュール内部でのリンク表記が記述されており、この$Permalinkを適切に設定してやることで、複数あるブロックのphpのファイルや、htmlテンプレートを書き換える、ということをしなくて良いようになっています。

xoopsの管理者メニューの中で、「wordpress」モジュールを選んで、

wordpressオプション

ブロック管理

一般設定

のうち、「wordpressオプション」を選びます。画面が切り替わると、複数あるオプションカテゴリのうち、一番最後に「Permalinks」という項目があります。これを選択します。このPermalinksの設定画面で、$permalinkという変数に置換文字列の指定をします。この文字列中で使える変数に関しては、詳細説明がこの画面にありますので、詳しくはそれを参照していただくとして、当方は下記の文字列を指定しました。

/%year%/%monthnum%/%day%/%post_id%/

その下にある「Permalinks構造の更新」というボタンを押すと、その下のテキストエリアに、ReWriteEngine onという文字列から始まる、複雑な文字列が生成されますので、これを全て選択してクリップボードにコピーし、（つまりWindowsであれば、ctrl+a, ctrl+c、MacならCommand+a, Command+c）、これを先ほどの２．の.htaccessに全てコピーします。

これで、2007/04/22のid=97の日記記事の場合は、/2007/04/22/97/という文字列に変換され、

http://www.sailweb.net/modules/wordpress/2007/04/22/97/

という静的URLでアクセスできるようになります。またwordpressの各ブロックのリンクもこの$permalinkの設定によって、すべてこれを使ったリンクを生成するようになるので、検索エンジンのbotがクローリング時にちゃんと情報を取り込んでくれるようになります。

これで、大元のSEO対策は終了です。

 

２．に記した一般的なmod_rewriteのやりかたは、wordpressモジュールに限らず使えますので、そのほかのモジュールなどで静的リンク書き換えをしたい場合は利用すると良いでしょう。mod_rewriteにはそのほかにも、エラーページのカスタマイズや、直リンク禁止の処理など、多様な処理が可能なので、さらに一歩進んで勉強したい場合は下記あたりを参照すると良いでしょう。

　　Apacheチュートリアル：：.htaccess

　　Apache Module mod_rewrite

 

↓↓↓「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

昨日に引き続き、Wordpressのスタイルの調整を行いました。

昨日は、xoopsのブロック管理で表示位置を指定できる投稿ブロックのスタイル調整のみでしたが、Wordpressのページに移ったときの投稿記事のスタイル調整の場所がわかりましたので、記しておきます。

「新規投稿」リストから記事をクリックしたり、「カテゴリ一覧」でカテゴリをクリックしたときには、昨日調整した部分とはどうも無関係で別のcssなりが使われているようでしたので、同じthemes/defauｌｔ以下のディレクトリのファイルを一つ一つ覗いてみました。なお以下では、Wordpressのモジュールインストールディレクトリのパスを<wp_home>と書くことにします。

昨日調整をしたのは、

<wp_home>/themes/default/wp-blocks.css.php

でした。そこで同じディレクトリの中のほかのファイルを探していると、内容がよく似た

<wp_home>/themes/default/wp-layout.css

というcssファイルを見つけました。まぁこの辺はWordpressの解説本あたりを見ればきちんと説明がなされているのでしょうが、まだ買ってないので手探りで進めています。
さて、果たしてこのcssが懸案のそのほかの記事表示に使われているcssなのかどうか調べるために、試しにファイル名を“-wp-layout.css“に変更してから、サイトの記事を再描画してみました。すると、cssの指定が全くなされていない素のHTMLの表示になったので、

　　　「ビンゴっ！」

です。
中身を眺めてみると、先に編集したwp-blocks.css.phpとはcssのクラス名やIDは同じように指定されているものの、微妙に違うところがあります。最初はwp-blocks.css.phpで上書きしてやろうとたくらんでいたので、危ないところでした。したがって昨日の修正分をこちらへ一気に反映する方法はないので、wp-layout.cssを開いて、ひとつひとつ手作業でコピーしていきます。

話が前後しますが、予めオリジナルのthemeをバックアップしておくのが安全です。

<wp_home>/themes/default

を

<wp_home>/themes/default.org

としてコピーしておいてから編集を始めましょう。

編集すべき場所は、wp-blocks.css.phpで修正をしたクラス、IDと同じクラス、IDの部分です。wp-layout.cssの中身を見ればすぐに分かりますが、例えば、wp-blocks.css.phpの

#wpBlockContent$wp_num h2 {
 　　font-size : 18px;
 　　font-family: “ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;;
 　　border-bottom: 1px solid #dcdcdc;　←ブログ記事日付の下の線
 　　padding-bottom: 2px;　←日付文字列と線の間の間隔
 　　margin-bottom: 10px;　←下の線と、その下に表示される行との間隔（正確には違いますが）
}

は

#wpMainContent h2 {
 　　font-size : 12px;
 　　font-family: “ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;;
}

が該当します。

上記の例では"h2″というのが同じところを見つけ、オレンジの3行をwp-layout.cssの同じh2のところにコピーします。

同様にwp-blocks.css.phpで修正をしたクラス、IDと同じクラス、IDの部分をwp-layout.cssの中に見つけ、追記、修正します。具体的には、僕の場合は以下の部分を修正しました。

ブログタイトル文字列：
　#wpBlockContent$wp_num h3　→　#wpMainContent h3
URLリンク（グローバル定義）：
　#wpBlockContent$wp_num a　→　#wpMainContent a
URLリンクでイメージのもの（グローバル定義）
　#wpBlockContent$wp_num a img　→　#wpMainContent a img
URLリンクで訪問済みのもの（グローバル定義）
　#wpBlockContent$wp_num a:visited　→　#wpMainContent a:visited
URLリンクでマウスカーソルを重ねたとき（グローバル定義）
　#wpBlockContent$wp_num a:hover　→　#wpMainContent a:hover
ブログタイトルのURL
　#wpBlockContent$wp_num .storytitle a　→　#wpMainContent .storytitle a
ブログタイトルのURLで訪問済み
　#wpBlockContent$wp_num .storytitle a:visited　→　#wpMainContent .storytitle a:visited
ブログタイトルでマウスカーソルを重ねたとき
　#wpBlockContent$wp_num .storytitle a:hovor　→　#wpMainContent .storytitle  a:hovor
カテゴリ・投稿者・投稿日文字列
　#wpBlockContent$wp_num .meta →　#wpMainContent .meta
カテゴリ・投稿者・投稿日文字列でURLの部分
　#wpBlockContent$wp_num .meta a →　#wpMainContent .meta a
カテゴリ・投稿者・投稿日文字列のURL部分で訪問済み
　#wpBlockContent$wp_num .meta a:visited →　#wpMainContent .meta a:visited
カテゴリ・投稿者・投稿日文字列のURL部分でマウスカーソルを重ねたとき
　#wpBlockContent$wp_num .meta a:hover →　#wpMainContent .meta a:hovor
ブログ本文の文字列
　#wpBlockContent$wp_num .storycontent →　#wpMainContent .storycontent
引用部分
　#wpBlockContent$wp_num blockquote →　#wpMainContent blockquote

今回、この作業にあわせて、引用文章の装飾もオリジナルから変更しました。オリジナルでは、引用部分はインデントされ、引用部分の左端に縦にグレーの太い線が表示されていましたが、これを、グレーの線を消し、変わりに引用部分全体の背景を薄いオレンジ色に変更しました。変更の内容は下記のような感じです。（wp-blocks.css.phpのファイルの修正の内容です）

変更前：
#wpBlockContent$wp_num blockquote {
　　border-left: 5px solid #ccc;
　　margin-left: 1.5em;
　　padding-left: 5px;
}

変更後：
#wpBlockContent$wp_num blockquote {
　　font: 95%;
　　margin-top: 1em;
　　margin-bottom: 1em;
　　margin-left: 1.5em;
　　background-color: #fffacd;
　　border: 2px solid #ffffff;
　　padding: 5px 10px;
}

もともとは、border-leftで行の左端に、5px(ピクセル）のグレーの幅の縦線を入れるようになってますが、これをやめて、フォントを現状より少し小さめの95%に設定、引用部分の囲みの上下のスペースを1emに設定、引用文字列背景を#fffacdに設定、背景のエリア上下の端と上下の文字の間の間隔を5px、左右を10pcに設定、そして囲みの周囲の線を白(#ffffff)で、2pxの実線に設定しています。囲みの線は引用が一つだけならいいのですが、引用の中に更に引用をする場合は、インデントで判断はつきますが、せっかくですから引用全体を白の線で囲むことでさらに明示的にわかるようにしています。

ま、こんな感じで、あとはIDなりを眺めればだいたいどこの定義なのかがわかります。

もしブログの表記と、表記中の修正したい部分がcssのどこかわからないときは、例えば

content_block-template.php

の中でタグやクラス、IDがどのように使われているかを眺めればだいたい分かります。

いろいろと少しずつ調整しながら試してみてください。

↓↓↓「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

 

 

本サイトのブログモジュールは、XoopsのモジュールではメジャーなWordpress Meの0.6aを使っています。機能的には満足なんですが、標準のスタイルでいくつか気に入らないところが合ったので、昨晩スタイルシート辞典とか見ながらちょっといじってみました。

 

なお、この設定を真似ようとする方へ予め次の確認をしてください。Wordpressの一般設定でthemeをxoopsのものでなく、wordpress添付のthemeを使うように設定してください。また僕自身も試行錯誤でやっていて、今回は記事ブロックの部分にだけ有効ですので、そのほかのwordpressブロックのカスタマイズは、おそらく別のファイルをいじる必要があります。

 

さてthemeをwordpress標準のものを使う場合、記事ブロックのスタイルに関するファイルは、

　　　<xoops_home>/modules/wordpress/themes/defualt/wp-blocks.css.php　…　※1

です。これを修正します。

（注意：思い出しながら書いているので、ひょっとすると違っているところもあるかもしれません。）

 

（１）ブログタイトル下に表示されるカテゴリや日時のフォントが小さすぎる

ブログのタイトル下に、カテゴリ、投稿者、そして投稿日時が薄いグレーの文字で表示されます。MacのSafariではそれでもなんとか文字としての品格を保っているのですが、WindowsのSleipnir（おそらくIE7も同じ。同じレンダラーですからね）で表示すると、文字のドットが間引きされすぎて、ブログ上のごみのように表示されます。まずはこの文字を少し大きくしたい。

これは※１のファイルの.metaと.meta aのIDにて定義されています。

#wpBlockContent$wp_num .meta {
 　　font-size: .75em;
}

”.75em"はアルファベット"m"の高さを1とするサイズで、現状これの0.75倍になっているので、これを１とか、1.5とか、あるいは２とか好きな倍率に設定しましょう。

 

（２）ブログ本文のフォントサイズが小さい

ちょっとフォントが小さすぎるんですよね。ブログ本文についてはstorycontentというIDのcssにて定義されています。

#wpBlockContent$wp_num .storycontent{
 　　font: 95% “ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;
}

これは現状選択されているフォントサイズの95%で表示する、ということなので、とりあえず100%とか120%とかにすれば大きくなります。ちなみに上記の記述は、その場所の標準サイズに対する相対定義なので、絶対サイズで指定したい場合はfont-sizeを使って、

font-size: 18pt　"ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;

とかで指定してやればよいでしょう。

 

（３）ブログ本文の行間が狭すぎる

これも上記の.storycontentにて定義します。上記のstorycontentというIDの部分を修正すればいいのですが、現状行間調整の指定がなされていないので、とりあえず、文字の高さの1.2倍（つまり文字の高さの0.2倍のスペースを行間にとる）場合は

#wpBlockContent$wp_num .storycontent{
 　　font: 100%/120% “ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;
}

としてやればよいです。(100%/100%とすると行間がなくなってしまいます）

一般的にはline-height;という要素を使って

#wpBlockContent$wp_num .storycontent{
 　　font: 100% “ヒラギノ角ゴ Pro W3″, Osaka, Verdana, “ＭＳ Ｐゴシック”, sans-serif;
　　line-height: 120%;
}

と多くのマニュアルなどには出てますね。

 

（４）URLリンクの文字が薄すぎる

これはaタグへの指定で定義されているので、下記の行を修正します。"#9B9FAE"のところを"black"とか色の名前で書いても良いです。

#wpBlockContent$wp_num a {
　　color: #000080;　　←Navyにしてみました。カラー名で"Navy"と書いても同じ効果が得られます。
}

ただし、注意が必要なのがここを修正すると、ブログ記事に出ている全てのURLリンクのカラーが修正されます。タイトルだけ修正したいとか、本文中だけ修正したい、という場合は追加で指定が必要です。たとえばこのcssでは、ブログ本文のタイトルもURLとなっており、これは下のほうに別のIDで定義されているので、そこにタイトルの色を別に指定します。

#wpBlockContent$wp_num .storytitle a {
　　text-decoration: none;
　　color: #0000FF;　　←追加。これだと青になります。
}

こうすれば、ブログタイトルの(URL部分の）色と、本文のURLの色を分けることができます。

 

（５）おまけ。URLリンクのアンダーラインを点線にする。

最近CSSをいじり始めたのですが、非常にいろんなことができることがいまさらながらになってわかって面白いです。
URLリンクの下線を点線にするには、まずURLの装飾パラメータであるtext-decorationを無効にします。

#wpBlockContent$wp_num a {
　　color: #9B9FAE;
　　text-decoration: none;　←　まず下線の装飾を無効にする。
　　border-bottom-width: 1px;　←　次に文字周辺を取り囲むboxの下辺のみサイズを指定する。
　　border-bottom-style: dotted;　←　最後に下辺のスタイルを点線に指定する。
}

dottedをdashedにすれば、ドットの点線ではなく、切れ切れの点線となります。なお、ブログタイトル下のカテゴリや日付にも点線がつきますのでこれらからははずしたい場合は、.meta a .meta ulなどのIDの指定のところに、border-bottom-width: none;とかをついかで指定してやればよいです。

ご参考までに僕が使ってる参考図書をのっけておきます。最近物忘れが激しくて、外部記憶に頼りっきりです。以下の本はコンパクトにまとまっているので、手元においておくと便利です。

■追記(2007.4.20)

（５）のアンダーラインの指定ですが、実際には以下のように、線幅、スタイル、カラーを一緒に指定していました。（５）のように分けて指定しても問題はありませんが、こちらのほうが行数が減るので、おすすめです。

#wpBlockContent$wp_num a {
　　color: #483D8B;
　　border-bottom:1px dashed #483D8B;　←３つのパラメータを1行で指定
　　text-decoration: none;
}

見ていただければ一目瞭然ですが、1px(ピクセル)で、dashed(破線)で、色を#483D8Bで、という具合に指定します。線種はsolid(実線)とかdotted(点線)とか、他にもいくつか選べます。

↓↓↓　「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

まだまだ週末の遠い週2日目の火曜日、いかがお過ごしでしょうか？

さてこのブログでやっとのこと３件目の日記となります。
根が超めんどくさがりなので、すでに息切れしています（汗）

「釣りは気が短いほうが良く釣れる」

と昔ソクラテスはのたまいました（うそ）

その心は、のんびり糸を垂れて、怠惰な時間をすごすことそのものを
楽しめない輩は、釣果をあげるべくありとあらゆる工夫をする、
ということを言ってる訳で、僕も間違いなくその類です。

さて、すでに3件目で手抜きのことを一生懸命考えています。

「mixiで書いた日記を（必要に応じて）そのまんまブログのほうへ
　コピーできたらなぁ。。。」

などと妄想気味にGoogleっていましたら、その逆を見つけて
コロンブスの卵的衝撃を受けている次第です。

　wp-mixipublisher-1_0_0rc2

これは、Xoopsのwordpress（この日記機能を実現しているモジュール）で
書かれた日記を、そのまんまmixiの方へコピーするというものです。

なるほど、こちらで書いたものを向こうにコピーするという手もあったか。

なんかインストールが一筋縄ではいかないらしいですが、めんどくさがりの
心をくすぐりますねぇ〜

画像とかアフィリエイとのリンクがどうなるのかちょっと不明ですが、
帰ったら早速入れてみるとするか。

めんどくさがりも、結局めんどくさいと思いながらそこから脱出するために
結局めんどくさい作業をまめに行って、ともすれば次から次にやることが
増えてしまうネガティブスパイラルに陥ることもしばしば。

だからって途中でほったらかしにできないんですよねぇ。。。

実のところ「めんどくさがり」と「まめ」ってのは表裏一体のようです。

先日来、友人から頼まれたお店のホームページの件、 サイト構築関係の懸案事項は先週末から
全然手が付いてない

 

（だって疲れて遅く帰ってきてビール飲んだら眠くて。。。）

 

んですが、なんともやっかいな問題が一つ解決しました。

CMS※にはとりあえずでXoopsを入れてるんですが、 今回新しくバーチャルホストの設定を
Apacheにして、 お店ドメインのページはそちらを見に行くように しました。

このサーバには他にいくつかお遊びでNucleusなどの CMSも動いてて、それらは特に問題なく
使えてます。

それで、まぁXoops自身はこれまでもインストールの実績が あるんで、ちゃちゃっといれて、
あと管理画面でいじれば、 と思ってたら、なんとログインできない！

正確に言うと、ログインはちゃんと受け付けられて、

　　「ようこそ！ｘｘｘさん」

ってのは出るんですが、その次の画面で肝心のログイン後の 画面にならず、再びログイン画面に
舞い戻ってしまいます。

以前にいれてるホームページのほうはまったく問題なし。

　　「おかしい！」

実はXoopsってインストール後にログインできない！って トラブルがとっても多いんですねー。
僕自身も何度かひっかかり ましたが、今回はまた別の原因みたい。

おうちの内部ネットワークからはMacのSafariで問題なく ログインできるんですが、外部から
WindowsのSleipnirで ログインしようとすると、振り出しに戻ってしまいます。
クッキーの件とか、ファイアーウォールのHTTP Refererの 件とか、いろいろと調べましたが、
結局のところ既存システム では何の問題も無くログインできてるわけですよ。

つまりこのサイト固有の問題。インフラがらみではない。

まぁ相当な時間悩んではあきらめ、いっそNucleusにしようか とも思いましたが、気に食わない。
それでちょこちょこと ネットをぐぐってたんですが、ひょんなところで理由が 分かりました。

単純にブラウザ固有の問題。 それもこのサイトにアクセスする際にだけ発生する。

ためしにWindowsの純正ブラウザであるIEだと、おぉ ログインできるじゃん。
ついでに一昨日きたMacBookProの Safariでも、なんだよぉちゃんとログインできるじゃない。

どーもSleipnir自身の問題のようです。 ま、ブラウザ固有の問題なら、後回しにできます。
良かったよかった。

あとはメールのほうのバーチャルドメイン対応だなぁ。 Linuxならなーんの問題も無いのにね、たぶん。
でもなんとか乗り切ります！

※CMS ; Contents Management System ホームページの内容を更新管理するのを楽に
　　　　してくれる仕組み。 BBSやらリンクやらアルバム機能やらがセットに なってるもの。
　　　　代表的なものとして、Xoops（ずーぷす） Movable Type, Nucleusなんかがあり。
　Safari ; Macintoshの標準Webブラウザ
　Sleipnir ; Windowsの高機能（？）ブラウザ
　ヴァーチャルドメイン、ホスト； １台のPCで、複数のドメインのホームページや メールサーバをまかなう方法。

↓↓↓「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/