モンスターカレンダー

« 2010年6月
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

PHP全般の最近のブログ記事

xoopsのブックマークモジュール「Shiori」を入れたが動かない。
管理メニュー動かすと画面が真っ白。
PHP Fatal error:  Call to undefined function spl_autoload_register()...
この関数はphp5で使えるということで、4からバージョンアップしてみた。しかしやはり動かない。
このモジュールで同様な事例を探すが、特にない。phpinfoでsplも入っているし。

マニュアルでは
「すべての登録済み __autoload 関数を配列で返します。 autoload スタックが有効になっていない場合は、FALSE. が返されます。 関数が何も登録されていない場合は、空の配列が返されます。」
FALSEが返ってきているから、スタックが有効になっていないらしい。有効にするには?と調べるが、なかなかヒットせず...

そんなこんなでトライ&エラーで、ようやく動きました。

        spl_autoload_register('spl_autoload');
        spl_autoload_register(array(__CLASS__, 'autoload'));

1行目を追加することで、スタックが有効になったのか?
システムによってはこれが自動で実行されるようになっているから問題ないのか?
よく分からないが、便利なモジュールなんで動いてよかった。。

(例2)ログインできない

AUのある機種で、ログインできない、という。
他のキャリアや、AUのほかの機種では問題なくログインできる。

これも試行、試行で....
わかったことといえば

・POSTでhttps://〜 へ遷移 → NG
・<a href="https://〜">XXX で遷移 → NG

結局、遷移先に到達した時に session_id が変わってしまっていたことが原因だった。セッションIDをhiddenで渡したり、パラメタに明示しても、なので、まさか遷移先でそれが受け取られていないというのには、ほんっとうにこれにはやられた。
AUのサーバを経由する時になにがしかの処理が入ってるのか、どうか....

PG内で header("location:https://〜"); とし、セッションIDをパラメタ(クエリ)に含めてやることで、やっとセッションIDが引き継がれた。

※他の<a href="https://〜"> は特に問題ないし、
例によって原因は分からないのだが、追求はできませんのでここまで。

※あと、user agent でブラウザが
UP.Browser/6.2.0.9.2 未満の場合はNGで、それ以上はOKだった。

また、この不具合が出る前、別のコーディングの時は UP.Browser/6.2.0.9.2以上の時はNGで 未満がOKというときもあった。...どういうコーディングだったかは、もはや覚えていないのであるが。

ある程度はPCだけでもテストできます。ケータイ(モバイル)サイト。
しかし、実機だと予想もつかないところでエラーが発生する。
「同じキャリアでもこの機種だと大丈夫なのにあれはダメ」ということが普通に起こる...

(例1)おちる

メールに記載した、とあるURLにアクセスすると端末がおちる。ここでいう「おちる」は、勝手に電源が切れて立ち上がる、再起動。何回やっても、100%再起動。機種はVodafone V703SH。同じ3GでもV902Tは無問題。

https://〜 だったのが問題か? いや、別のhttps://〜のURLは普通にアクセスできている。
あれやこれやと試してみた。

・メール記載のURLをコピペしてブラウザから直接アクセス→NG。再起動
・URLをhttpsでなくhttpに変更してブラウザからアクセス→OK。(httpsが悪いのか?)
・注文キャンセルURL→OK。(→httpsが悪いわけではない)
・テストページにURLへのリンクをはり、そこからアクセス→OK。(????リファラとかチェックしてるのか?)
・メアドを変えたり、URLに他のパラメタをつけてみた→NG。再起動

謎です。
とりあえず4番目の方式だとOKだったので、一枚画面をかませて処理することで決着。理由が分からないからすごーく気持ち悪いけど、機種固有のことなんでこれ以上は一般市民には追求不可能です。

#Voda再起動時に画面に「How Are You?」と出るんですが...
#最悪に決まっとるだろうが、と10回以上心の中でつぶやきました。

SSL電子証明書を、ベリサインで発行していたのです、当初サーバでは。そこではケータイからのアクセスにはなんら問題はなかった。https://〜でも。
しかし、サーバ移転に伴い、ジオトラスト社のものに変更したら、、、https://〜はアクセス不可になってしまった。
正確にはDocomoはアクセスできるが、「このサイトの安全性が確認できません。接続しますか」と必ず聞かれる。毎回必ず。
Vodafoneは、「エラーが発生しました」となりNG! AUもアクセスできず。

スタッフ間でいろいろと調べた結果、以下のような情報が。。

----------
https://q.hatena.ne.jp/1124450440
Geotrustは128bit鍵しか提供していませんので、鍵長128bitに対応していない携帯端末ではエラーになってしまいます。

ベリサインの証明書が堅実だといわれる理由は、他社が提供していない56bit(または40bit)鍵にも確実に対応している為だと思います。

PCサイトの場合はジオトラスト社などの証明書でも十分ですが、携帯サイトとなると56bit(または40bit)鍵を提供するベリサイン社を選択するのが堅実だと思います。
----------

ということで、ベリサインを再度申し込み。で、無事に、どのキャリアからもアクセスできるようになりました。

ケータイ(モバイル)サイトを本格的に開発し始めた。実機でテストするにつれ、いろいろとつまづきが...
まず王道、文字化け。

PC向けのサイトを、PHPスクリプト・Smartyファイル・outputのencoding 全て
EUC-JPで作成していて、これはこれで何も問題はなかった。

<php.ini>
mbstring.encoding = EUC-JP
mbstring.http_input = auto
mbstring.http_output = EUC-JP
mbstring.internal_encoding = auto

ケータイサイトは同じサーバで、同じく内部エンコーディングはEUCで、入出力のみShift_JISとして開発。
スクリプトの初期に

mb_http_output("SJIS");
ob_start("mb_output_handler");

を指定し、ごく普通の表示ページは問題なし。
しかし、inputなど、formの入力要素が出てきた時に文字化け。
Smarty、HTML_QuickFormを使用していたため、この辺りに問題あるのか?とソースを追ってみたり。
Smartyのoutput_filterで出力コンテンツをSJISにしてみたり、
$_POSTをEUCやらSJISやら、いろいろと変換したり。
しかし、NG。何をどうしても一度Submitした後のエラー表示でQuickFormがセットする inputのvalue値がEUCのまま...(他の表示部はSJIS)

最後の手段、PHPのMLに投げようとメールを書きかけ、phpinfo()をもう一度見てみると

「mbstring.encoding_translation None」

今まで気にしていなかった設定項目が。
「入力される HTTP クエリに関して、 文字エンコーディング検出および内部文字エンコーディングへの変換を行う 透過的な文字エンコーディングフィルタを有効にします。 」

Onにして、Apache 再起動。すると、あっさりと文字化けは解決したのだった。脱力...

これは「他人に客観的に説明しているうちに解決」ということにしておく。

現在のコンパイルオプション:

Configure Command './configure' '--with-pgsql' '--without-mysql' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-mbstring' '--enable-mbregex'