銀杏の木

インターネットオプションで、「前回のセッションのタブから開始する」にしているのに、全く無視され、ホームページを開いてしまうことがある。

せっかくいろんなページを開いている情報を全部消されてしまい、最悪である。

試しに、再起動をもう一度してみたら、今度は前回開いていたページが復元された。

要するに、いつ発生するか不明で１００％再現しないバグである。

IEのウインドウを複数開いていて、最後に閉じたのがホームページだけ開いていたIEだった・・・なんていうことはない。IEのインスタンスは１つだけだったし、ホームページなぞ開いていなかった。

このバグを起こしたのIEは、IE５とかではない。最新の Windows10 付属のIE11である。

ちなみに、このときのIEは、開いているだけでCPU使用率が１００％になるような状態だった。IEを完全に閉じても４，５分間その状態だ続いた。これもIEの激しくうっとうしいバグである。

しばらく開きっぱなしにしていると、画面が真っ黒になるなどし、スクロールに合わせてチカチカするというバグも抱えている。

こんなうっとうしいバグを複数いまだに抱えているようなブラウザは、いい加減ブラウザのラインアップから引退してほしいものだ。他のブラウザでこんな困ったバグを複数抱えているようなものは見当たらない。IE開発チームのやる気のなさがうかがえる。

さくらのレンタルサーバには pear がインストールされているのだが、権限がないのでパッケージを追加するなど操作することが一切できない。

それでは全く使いものにならないので、自分で pear をインストールする方法をネットで手順を検索してみたのだが、「 pear の公式サイトの go-pear はうまく動作しなくなっていてエラーが出るので（そのサイトに独自に）保存してあるアーカイブをダウンロードしてインストールする」とか、「 go-pear.php をダウンロードして実行する」とか、なんだか変なことばかり書いてあるので、参考にするのはやめて、 pear の公式サイトをたどってみた。

pear の公式サイトの url を開き、「installing PEAR on your system」のリンク先を開き、「Getting and installing the PEAR package manager」のリンク先を開く。

すると、「Unix/Linux/BSD」のセクションに、

とするように書いてある。特に問題もなく go-pear.phar がダウンロードされ、実行する。

このような選択肢が表示されるので、 all を選択すると、１から１２まで順番にディレクトリを設定することになる。基本的に提案されて表示された通りのディレクトリで問題ないが、 Public Web Files directory だけは、提案通りに入力すると $prefix/www となってしまう。提案通りの $prefix を入力していある場合、 /home/（ユーザID）/pear/www となるのでそれではまずい。 /home/(ユーザID）/www と入力しなければいけない。

１から１２までの入力を完了すると、先程の選択肢の表示に戻るので、今度は ENTER だけ入力すると、インストールが始まる。設定内容は /home/（ユーザID）/.pearrc に保存される。

と WARNING が表示されるので、さくらのレンタルサーバのコントロールパネルを開き、「アプリケーションの設定＞PHP設定の編集」を選択し、エディットボックス内に、

と入力し「保存する」ボタンを押し保存しておく。

先程の go-pear.phar の設定の続きに話を戻すと、その後、

と聞かれるが、 Y と返事しても、 /usr/local/php/7.3/etc/php.ini は、レンタルサーバのユーザからは編集できない（だからレンタルサーバのコントロールパネルに編集する場所がある）ので、ここは N と答えておく。

などと、ちょっと文句を言われるが気にしない。

と警告されるが、自分のサーバの場合はどちらの pear を実行して pear list としてみても PEAR のバージョンに変化がないので問題はなさそうだ。気になる場合は /home/（ユーザID）/pear/bin を PATH に追加しておくとよい。その際は、 /usr/local/bin/pear よりも優先して実行されるようにしておくこと。

以上が、さくらのレンタルサーバに pear をインストールする手順だ。なぜか、ネットに上がっているさくらのレンタルサーバへの pear のインストール方法には、このようにしてインストールすると書いてあるサイトが皆無だった。一体どうしてなのだろう？そもそも go-pear.php ってなんだ？そんなファイルなかったぞ？？ go-pear.phar の間違いなのか？それにエラーもなく普通にインストール、実行できるのだが・・・。

rNote の検索プラグイン search.php の動作を修正した。

search.php は、各記事の .xml ファイルを全て読み込み検索処理を行うが、その際、 .xml ファイル内のタグの内容だけでなく、タグ自身も検索対象に含むかどうかを選択するフラグがある。

このフラグがデフォルトで true にセットされていた。なので、検索文字列として rNote と入力した場合、全ての記事がヒットしていた。

これでは意味がないので、 記事の .xml ファイルのタグ自身は検索対象から外すよう、フラグを false にした。

ところが、このときの動作として、

  $entry_buf = _file_get_contents(DIR_DATA . $fname);

  if(!$this->bSearchTags){

    $entry_buf = strip_tags($entry_buf);

というように、 strip_tags() の結果を使用して検索している。これだと、記事内の全てのタグの内容が無条件に検索対象になってしまうので、意図しない結果をもたらす。これではまずい。

そこで、検索対象とするタグを Title, Text, Addition, Keys に限定することにした。それぞれ、記事の題名、本文、追記、キーワードである。

これで、例えば rNote を検索文字列に指定した場合でも、正しく rNote が題名、本文、追記、キーワードに含まれる場合のみヒットするようになった。

もう解決しました（笑）。

管理画面用プラグイン化した rnotepad.php のクラスの冒頭で <script> タグで直書きされていた javascript コードを、丸ごと変数に代入しておき、 disp() メソッドで作られるページの中身に javascript 部分を追加する形にすることで、他のプラグインの実行時に影響しないようにすることができた。

直書きされているとなぜ、動作設定プラグインの実行時にも javascript が出力されてしまうかというと、動作設定プラグインで「この内容で設定する」ボタンを押した場合に、値が post され ranoteadmin.php が読み込み直されるときに、ボタンの表示部分の処理で、全てのプラグインの require_once での読み込み処理が走り、そこで javascript が読まれて出力されてしまっていた。

今回は、これを、 rnotepad クラスの disp() メソッドが呼ばれたときにだけ出力するようにしたので、他のプラグインへの影響をなくすことができたというわけだ。

意外と早く完全な解決方法が見つかってよかった。

同時に、 config.php （動作設定プラグイン）のバグも修正することができた。

こちらは、setcookie() で cookie が設定されたときに、その設定内容がリロードされるまで $_COOKIE に変更内容が反映されないことに気づかず、 filter_input(INPUT_COOKIE,COOKIE_TESTFLAG) を実行して cookie の値を取得してしまっていたため、リロードがかかるまでラジオボタンの位置の変更が反映されなかった。 $_COOKIE[COOKIE_TESTFLAG] で読み取る方法に戻すことで、修正することができた。（ setcookie() 直後に $_COOKIE に変更後の値を直接代入しておく処理はオリジナルの状態から書かれていた。）

rnotepad を管理者画面に組み込んだのは良かったが、問題が起きた。

「動作設定」を実現させているプラグイン config.php 内で cookie を使用しているのだが、 setcookie() 関数が動作しなくなってしまった。

理由を調べて分かったが、「setcookie」によると setcookie() は、

ほかのヘッダ情報と同様に、 クッキーは、スクリプトによる他のあらゆる出力よりも前に 送信される必要があります（これはHTTPプロトコルの制約です）。 や タグはもちろん 空白も含め、あらゆる出力よりも前にこの関数をコールするようにしなければなりません。

ということだが、 rnotepad.php では、 javascript を使用している。

それのどこがいけないかというと、 rnoteadmin.php の動作として、管理画面用のプラグインを順にファイルから require_once() で読み込む。そのとき読み込んだプラグイン内に javascript のコードが含まれていると、その場で

が出力されてしまうのだ。その結果、　setcookie() は失敗する。

動作設定の画面で「この内容で設定する」ボタンを押すと、 config.php が呼ばれ、毎回上のような動作になるので、必ず setcookie() は失敗してしまう。

これを回避するには、先日実装したコールバックプラグインの機能を使い、新たに「 rnoteadmin.php が読み込まれ、管理画面用プラグインが読み込まれる前に実行するコールバック」を追加し実装するしかないが、そうすると、 config.php の処理が２つのファイルに分かれてしまい、見通しが非常に悪くなるのでやりたくない。

いっそ、 config.php の今の実装を見直し、「携帯用ページをテスト」のフラグを他の項目同様 cookie ではなく config.ini を用いるように変更してしまえば　cookie を使わないので、とりあえず問題は回避されるが、 cookie を使わずに特定のブラウザからのみ携帯用ページを表示させてテストするという動作を実現させる方法が分からない。それに、 cookie の使用をやめて回避したのでは、今後 cookie を使用したくなったときに困るので、これは単なる逃げであり解決ではない。

う〜ん、これは困った・・・。どうすべきか。