PHPのテクメモ

IEのむかつくバグに関するメモ。
SEOを考えたHTMLコーディングをすると必然的にリストを使うことが増える。リストは当然ながら<li>だし、メニューにも<li>を使う。しかしIEにはCSSの解釈にバグがある。
<li>タグを指定して、スタイルシートで以下のように指定した場合、

float:left;
list-style-image:url(‘hoge.gif’);

表示してほしいはずのhoge.gifが表示されないことがある（表示されたりされなかったりするのがうざい）。これはfloat属性を指定すると、IEが自動的に「display:block;」も含めて解釈してしまうためらしく、当然この属性が指定されると「絵が出ない」となってしまうわけだ。

これはバグなので基本的にこの使い方ではバグを回避できない。回避する方法として次のように指定する。

background:url(‘hoge.gif’) no-repeat;
padding-left:20px;

余白の指定は適宜調整。

久々のcakePHPで、バージョンが前回と違うので少し戸惑っている。記述方法とかぜんぜん思い出せないし。

そこはcakePHP、Railsの流れを汲むのだからスクリプトを自動生成！、と思ってbake.phpを探して以前と同じように

/usr/local/bin/php bake.php

とやってみたがエラーが出て動いてくれない。bakeがなくなるわけはないだろうし・・・動かし方が変わったのだろうか。
しばしの検索の結果、動かし方が変更になったことがわかった。

/usr/local/bin/php ./cake/console/cake.php bake

これでとりあえずモデル、コントローラ、ビューの自動生成ができた。bake.phpも進化しているようで、以前はモデル、コントローラ、ビューの３つだけを自動生成できていたけれど、1.2ではさらに2つメニューが増えているようだ。メニューの一覧はこんな感じ。

[D]atabase Configuration
[M]odel
[V]iew
[C]ontroller
[P]roject
[Q]uit

「Database Configuration」はなんとなく想像もつきそうだが、Projectってなんだろう。まぁ、おいおい試してみよう。

新しいサイトを作ることにした。
毎度考えるのが、WordPressを使うか、その他のCMSを使うか、フレームワークを使うか、フレームワークなら何を使うか・・・。悩みはつきない。
WordPressは速度の問題で悩んでいるところなのでパス。その他のCMSだととりあえずメジャーどころのXoopsだが、結局使いにくい。今回は特に単機能に特化したサービスを立ち上げる予定なので、Xoopsなんかは不向き。で、どのフレームワークを選ぶか、というところで悩む。

Zend FrameWorkを使ってみようか悩むところだが、今回はcakePHPを使うことにした。どうもZend FrameWorkを使うような場面に遭遇しない。もっとライトウェイトなフレームワークがほしいところだ。今回はバージョン1.2がベータ段階になっているのでこちらを採用。そしてインストール（といってもFTPするだけ）。

ファイルをダウンロードして解凍後、FTPにてサーバにアップ。最低限の設置はこれにて完了。ファイルはドメインのドキュメントルートに丸ごとアップロードした。で、早速ブラウザでアクセスした。
cakePHPが親切だと思うのは、この何もしていない状態でアクセスすると、やるべきことをメッセージで教えてくれるところだ。言ってみれば手動のインストーラでもあるわけだが・・・。まずやることが書いてある（エラーは黄色で書かれている）。

Please change the value of ‘Security.salt’ in app/config/core.php to a salt value specific to your application

とのことだ。これは何か適当に文字列を入れておけばよさそうだ。
そして次のメッセージ。

Your database configuration file is NOT present.
Rename config/database.php.default to config/database.php

データベースの設定をしてくれとのこと。用意しておいたデータベースの設定を書き込んだ。修正したファイルをアップロードしてサイドアクセスすると、エラーの黄色がなくなった。つまりこれでインストール完了だ。

さて基本構造はおそらく全バージョンと同じだと思うので、違いを見つけてこのブログにメモしていくことにする。

ネットで調べてみると「PHP5になって遅くなった」という意見がちらほら見受けられる。本来ならバージョンが上がったのだから高速化が図られてほしいのだが真相はどうなんだろう。
バージョンが違うだけとはいえ、PHP4とPHP5はもはや別物に近いといっても過言ではない（らしい）。実際いろいろ試して、その結果としてPHP5のほうが遅いと言われている人もいるようだ。もちろん元のPHPのソースが違うのだから、それぞれ得手不得手なところがあって、あるところではPHP4のほうが早い、なんてこともありうるだろう。そういう場合はよりPHP5に向いた記述をするよう心がけていくべきなんだろう。

と悠長なことをいってられない問題。最近よく利用しているWordPress。これは明らかにPHP4よりもPHP5のほうが遅い（ような気がする）。現在XREAやロリポップを含めて5種類くらいのサーバを試しているが・・・。明らかにPHP5のサーバは遅い（ような気がする・・・といささか弱気な意見ではあるが）。

XREAではPHP4サーバとPHP5サーバを2つ借りている。PHP4はずいぶん前につくったウェブをまだしばらく運営するために借りたつもりだった。だからPHP5サーバにWordPressをインストールし、すでに複数のウェブを運用していたのだが、これがどうにもこうにも遅い。なんでトップページの表示に30秒と科かかってしまうのか。

キャッシュを入れたり、なんだかんだ試してみたけれど、やっぱり一発目のアクセスになると数十秒かかってしまうのだ。最初は「クソ」なサーバ借りちゃったんだ・・・と思っていたけど、ふと以前のクライアントさんに納品したときにことを思い出した。確かそのときもPHP5のサーバにWordPressで納品して遅かったのだ。

もしや。

と思ってPHP4なサーバにサイトを一つ移転させてみた。面倒な作業ではあるが、表示に30秒とか1分もかかるんじゃ使い物にならないから。
するとあら不思議。普通に速い！。あれだけ悩んでいたのに・・・キャッシュをいれても少ししか速くならなかったのに・・・。これは絶対WordPress内のコードに問題がある（んだと思う）。とてもWordPressの問題を追ってる時間はないので、どなたか偉い人が早く改善してくれるのを待つ。それまでは・・・お客さん納品用にWordPressは使えないな。

SQLiteはPHP5から標準で使えるようになった機能だ。しかしPHP4でも使える場合がある。

どんな具合になっているのか。

SQLite関連はPECLライブラリで開発されていたので、モジュール拡張されていれば使用できるということになる。つまりモジュール「sqlite.so」が組み込まれていればいい。これを確認するにはphpinfo()関数を実行するのが手っ取り早い。

表示された中でsqliteがあればOK。

たいていの共用レンタルサーバではMySQLが使用可能だけど、作成できる個数が限定されていることが多い。つまりデータベースが無制限に作成できるわけではないから、自ずとひとつのデータベースの中でプレフィックス文字列を変更するなどして使うことになるのだが、必然的にテーブル数が増えて視認性・操作性が悪くなる。SQLiteの場合は単にファイルを生成するだけだから、容量さえ契約の上限を守っていればいくつでも作成可能なわけだ。つまり作りたいだけ作ることができる。これは魅力的だ。

自分にとってはファイルひとつコピーするだけでバックアップできるところが一番の魅力でもある。

そんなお手軽なSQLite。PHP5が一般的になって、対応アプリが増えれば絶対に流行るとは思うのだが・・・。