さてさて今回は久しぶりのcodingネタですよ。
最近何やっているかというと、なんか再びPHPに戻ってます。
というのも壁のページ作成を例によって某氏と一緒にやっていたから。
いや正確にはやっているから。でも一通り完成といったところですね。見た目は。
今回主に私が書いたのは、WordPressのインストールディレクトリ配下にない場所に置いたPHPファイルから、WordPressの情報を取り出す、という作業。
最初はworpressの関数群を呼び出す必要があるかと思ってたんだけど、よく考えたら(いや考えるまでもなく)自分でQuery発行する気があるなら、データベースに直接クエリ発行してしまった方がいろんな意味で早いんでね？と気づいた訳です。
どの道、書き込みをする気はなかったのでWordPressのデータベースの情報を整合性を破壊する心配はないし。
DBへの負荷はむしろ減るかも知れないし(笑)。
さて私がやったこと、そして躓いたことを。
まず第一に、自分の使っているサーバのDBへアクセスするために必要な以下の情報を確認。
ホスト名、ユーザ名、パスワード
次に、WordPressが利用しているデータベースのDB名。
最後に、WordPress(MU)が利用しているテーブルに着く、データベース接頭辞。
WordPressの関数群を利用するなら、WPDBオブジェクトのインスタンスglobal $wpdbのメンバbase_prefixを参照すれば分かります。
そうでなくとも、phpMyadminするなり、MySQLに接続するなりすれば、分かると思いますが…。
あとはそもそもconfig.phpをみれば丸わかりですな。上記全て。
とりあえず、単純にDBに接続するテスト。mysql_connectを呼んで、適当なテーブルから情報を読み出してみる。
成功。次に、後々使うに決まってるからmysql_な関数たちのごく一部、使いそうなやつだけラッパーを書いた。
ここで、クエリを発行するためにmysql_real_escape_stringをしようとしてハマった。
ただの勘違いでしかないんだけど、echo mysql_real_escape_string($string);すると、文字化けするんだよね。
ちなみに$stringはUTF-8で書いてる。そもそも文字化けして当然だということをよく理解せずに、｢何で文字化けしてるんだー！｣とあっちゃこっちゃのQ&AやらTipsやらリファレンスやらを読み漁るも、解決できず(出来る訳がない)。
ようやっとescapeしているのがシングルクォートや\r\nだということを理解し、なんか徒労感に襲われる(実際徒労なんだが)。
んでクエリにreal_escapeした文字列をぶち込んで成功。
そしてクエリ丸ごとescapeして失敗(そりゃそうだわな)。
やっぱり駄目か…と思いつつ、クエリを渡すとシングルクォートでexplodeして、シングルクォートに挟まれた文字列だけをescapeして再結合するルーチンを追加。シングルクォートがいくつでも今のところ動いているようだ。
やったことは単純で、explodeした後の配列を$stringsとすると、for($i=1;$i
ここまでできれば後は簡単で(といいつつエラーを出しまくったが)、WordPress CODEXのデータベース概要を見ながら、欲しい情報を取り出すクエリを書き、ラッパー関数からクエリの結果をもらい、整形するのみ。
こっから後で出したエラーは行末の;忘れたとか文字列結合演算子.を飛ばしてたとかそんなんばっか。
SQLのWHERE句の中でのNOTを使おうとして詰まったが、!=に書き直したらあっさり動いたので満足している。
もうひとつ微妙なエラーがあったのを思い出した。
if($array[x]=query($query_strings)){}の形式でif文を構成した時、queryの結果がNULLだと、
if文の中は実行されないが、変数にFALSEが入るなんでorz
結局elseの中でunset($array[x]);しましたよ。妙な仕様だなぁ。
たしか$array[]だとちゃんと代入されないんですよねー。
添え字を指定するとミョーなことが起きるorz
ご注意ください(誰が?)。
さて次に私が請け負った作業がCSSの調整。ページの大枠と素材は某氏が既に完成させていて、私は調整だけ。
とはいえクロスブラウザにまつわる問題…と言うよりIE7とIE6で表示が崩れるのを何とかする、つー話だったので、辛かった。
何しろCSSの何がどう影響を与えているのか見当もつかなんだ。
真IE6の挙動は奇怪です…。(と言いつつ我が家のデスクトップのIEはver6ですが)
今回初めてIE8を見直しましたよ。ええ。標準準拠は素晴らしい。
結局どんなところで躓いていたかと言うと、
- XHTMLのxml宣言がひっかっかっていた。
- CSSでfloat指定したセレクタに、widthとpaddingを同時指定するとバグ、に引っかかっていた。
これを修正するまでIE6では絶望的にレイアウトが崩壊していた。いわゆる互換モードだったわけ。
互換モードだとそれこそCSS Hackでもしない限り、まともな表示は望めない。
後者は、IE6 float CSS 上下 崩れるとかで検索して出てきたページで見つけたもの。
ほかのサイトでも見てた内容のような気はするけど(IE6はバグのワンダーランドなので解説サイトは山ほどある)、 この時点まで作ってるサイトのCSSが引っかかってるとは気づいてなかった訳です。
どういうことかといえば、aタグにIDを割振ってあって、CSSの中でaタグすべてについてpaddingを設定しており、 あるIDの要素についてwidthを設定してあった為に、ぱっと見分からないけれども特定の要素に対してどちらも設定されていた、と言う話。
widthがないといかんともし難いので、paddingを削除。
書いてしまえばこれだけなんだけど、なにしろどこで何が起きてるのかさっぱり予想がつかないので、先が見えない。
先の見えないデバッグは心に傷を残します(笑)。
自分で書いたコードならどこでエラーが起きてるか見当が付くし、テストコード挟めばハッキリ分かるので良いんですが…。
JavaScriptもそうですが、ブラウザの非互換性は本当にもうどうしようか、と途方にくれてしまいますね。
もうブラウザなんて一種類で良いよ！！！とか思いましたとも(危険発言)。
そういう私がメインで使っているブラウザはOpera(シェア2%以下)だったりするんですが。
IE6のシェアも今年夏時点でまだ24%あると言うことですから、決して疎かには出来ない…。
クロスブラウザ問題は、永遠に、不滅です。
Tags: CODING, cross_browser, mysql, php, webbrowser, wpmu, 壁, 見聞伝技術部, 覚書