2012年6月29日金曜日

編集時 カテゴリーを変更するとcategory_id.ini.phpがおかしくなる対処

ppBlog 1.8.8


色々とテストなどを行ってinclude_onceが問題なのかもとおもいつつ直接の原因は
utils_admin.phpの292行目あたりの
$CATEGORY_ID[$i] = "$cat|".implode(',', array_filter(explode(',', $ids)));
この赤字の$cat部分。
ここでカテゴリ名だけで書き換えて保存しちゃっているのでアウトでした。
$CATEGORY_ID[$i] = "$_cat|".implode(',', array_filter(explode(',', $ids)));
正しくは$_catで引っ張ってきている元の形で書き込めばいいのです。(直後のロジックでもそうなってる)
やってることはわかるのですが変数名をアンダースコアを多用して混乱を招きやすい変数名で子チョコちょやってるとよくある罠ですね(笑)

しかしinclude_onceの弊害がはっきり出ていないのでコードを修正したままにするかどうか悩みどころですが今回書き換えた部分は
utils_admin.php 277行目あたりのところと
 if($mode=='update' || is_numeric($ontime)){  # 編集後
  //////
  //include_once ($cat_id); // get::$CATEGORY_ID
  include($cat_id); // get::$CATEGORY_ID
  //////
  $index = get_article_index($id, $orgLINES);
  list(,$cat,) = explode('|', $orgLINES[$index], 3);
  if($cat != $category){ // カテゴリーの変更あり
   foreach ($CATEGORY_ID as $i => $catid){
    list($_cat, $ids) = explode('|', $catid);
    list($__cat,) = explode("\t", $_cat);
    if(strpos($catid, $org_id)){
     $ids = str_replace($org_id, '', $ids);
     //////
     //$CATEGORY_ID[$i] = "$cat|".implode(',', array_filter(explode(',', $ids)));
     $CATEGORY_ID[$i] = "$_cat|".implode(',', array_filter(explode(',', $ids)));
     //////
    }
    if($__cat == $category){
     $_ids = array_filter(explode(',', $ids)); array_push($_ids, $_id);
     $CATEGORY_ID[$i] = "$_cat|".implode(',', $_ids);
     }
同じくutils_admin.php最後のファンクション定義の949行あたり
 function make_category_id(){
 global $CATEGORY_LIST;
 $ini = OD.'category_id.ini.php';
 rewrite_ini($ini, '', '$CATEGORY_ID');
 $CATEGORY_ID = array();
 //////
 //include_once (OD.'category.ini.php');
 include(OD.'category.ini.php');
 //////
 foreach ($CATEGORY_LIST as $i => $line){
  list($_cat,) = explode('|', $line, 2);
  list($__cat, $catlink) = explode("\t", $_cat);
  $_articles = get_articles_by_category($__cat);
  $CATEGORY_ID[$i] = array();
  foreach ($_articles as $a){
   list($id,) = explode('|', $a, 2);
   $CATEGORY_ID[$i][] = $id;
  }
  $CATEGORY_ID[$i] = "$__cat\t$catlink".'|'.implode(",", $CATEGORY_ID[$i]);
 } #foreach
 rewrite_ini($ini, $CATEGORY_ID);
}
これでとりあえず記事更新時にカテゴリを変更しても対応できるようになりました。

残る部分としてはカテゴリ名を変更したときにcategory_id.ini.phpが更新されていないので内部的な不一致が起きているところでしょうか。ま、これも一旦category_id.ini.phpを削除して記事更新を行えば正しくなるので気になるまで放置しておきます。

カテゴリー(だらだらその2)

いろいろと試しているとどうもカテゴリーなどをいじった後は
  1. category_id.ini.phpの削除
  2. 記事更新
で、category_id.ini.phpの再作成を強制的に行えばなんとなく綺麗な状態になりそう。

ただし、サブカテゴリーがある状態でカテゴリーをクリックしたときのURLのパラメータの aim= が空っぽになっているので見てみると、category_id.ini.phpのカテゴリーにカテゴリーIDが空っぽのものができているようです。
この辺の動作がとてつもなく不安定に陥ってそうです。
これが仕様なのかどうなのかは若干不明。なのでちょっと確認をして見ました。

ppBlogの本家では静的リンクになっているので試しに静的リンクを有効にしてみると…webサーバーがだめなのか記事更新をしてもまったく動作がダメに(笑)
本家の状態を見る限り、カテゴリーにサブカテゴリーが含まれていてもカテゴリーをクリックすれば該当するカテゴリーの記事を表示するようになっているのでそのように動作するのが妥当かと思われます。

実際の仕様としては親カテゴリをクリックして表示される一覧はサブカテゴリーのものも含まれているのが仕様としては正しいような気がしますが。

さて、ではどうするべきか?

問題があるのはサブカテゴリーがあるカテゴリーがあった場合の挙動。

含まれているカテゴリーは
┬カテゴリー
│└サブカテゴリー
└その他
その他はあったほうがいいのかなと思って全部削除しましたが追加しておきました。
ゼロ件になるとアンカーが無効になってしまうので記事を追加し、サブカテゴリーにも含めておいて
テストを行ってみました。

category_id.ini.phpを削除し、記事を更新すると、カテゴリー、サブカテゴリーともにaimが指定された状態。
カテゴリー、サブカテゴリーの記事のどちらも更新するだけであればaimは変化なし。
(カテゴリー15件、サブカテゴリー1件、その他1件の状態で)カテゴリーの記事をサブカテゴリーに変更して更新するとカテゴリーのaimだけが消失。カウンタは正しい。
(カテゴリー14件、サブカテゴリー2件、その他1件の状態で)サブカテゴリーの記事をカテゴリーに変更して更新すると、カテゴリーとサブカテゴリーのaimが消失。カウンタは正しい。

ここでサブカテゴリーを0件にしないために再度category_id.ini.phpを削除し、記事を更新すると、カテゴリー、サブカテゴリーともにaimが指定された状態。

(カテゴリー15件、サブカテゴリー1件、その他1件の状態で)カテゴリーの記事をサブカテゴリーに変更して更新するとカテゴリーのaimだけが消失。カウンタは正しい。

再度category_id.ini.phpを削除し、記事を更新すると、カテゴリー、サブカテゴリーともにaimが指定された状態。

(カテゴリー14件、サブカテゴリー2件、その他1件の状態で)サブカテゴリーの記事をカテゴリーに変更して更新すると、サブカテゴリーのaimがカテゴリーのaimになっている。
(category_id.ini.phpはサブカテゴリー側のIDが消えている)

サブカテゴリー→カテゴリーへの変更の更新は見かけ上aimが上書きされているように見えるがあきらかに移動もとのカテゴリーIDが消失しているということなのでしょう。

明らかに記事更新時のカテゴリー移動がダメみたいですね。

カテゴリーの不具合(だらだら)

カテゴリーの表示がずっと変わらないので気になっていたのでちょっと様子を見てみました。
いままでカテゴリー操作で行ったことは、初期のカテゴリーを全削除。新規に一つカテゴリーを追加(この状態でエラーが出ていたかどうかは気にしていなかった)
そのまま使っていたのですけどね。
早速問題となるファイル名でgrepしてソースを眺める作業。
root@mzkw04nu:/home/htdocs/blog# grep "category_id.ini.php" *.php
cache.php:  include(OD.'category_id.ini.php');
utils_admin.php: $cat_id = OD.'category_id.ini.php';
utils_admin.php: if(!is_file($cat_id)) make_category_id(); // make category_id.ini.php
utils_admin.php: $ini = OD.'category_id.ini.php';
色々見ていくうちに「サブカテゴリー」の設定が無いからかも…という気がしたので試しに追加してみると…
Warning: include(owner/category_id.ini.php) [function.include]: failed to open stream: No such file or directory in /home/htdocs/blog/cache.php on line 139

Warning: include() [function.include]: Failed opening 'owner/category_id.ini.php' for inclusion (include_path='.:') in /home/htdocs/blog/cache.php on line 139

Warning: Invalid argument supplied for foreach() in /home/htdocs/blog/cache.php on line 141
設定画面でエラーが出るようになった(笑)

サブカテゴリーを削除するとエラーの表示はなくなったが、トップページの表示からカテゴリーが表示されなくなる状態に。

とても気になるのが utils_admin.php の function make_category_id() 中の include_one() のところ。
include_once 
実行中の環境に依存すると思うがinclure_oneは一度メモリーに取り込まれると2回目からは読み込まれないということなので、おそらくここが問題になっているのかな?という気がしたので試しに includeに変更。

サブカテゴリーを追加したり削除してもエラーは出なくなった。
トップページは依然としてカテゴリー表示が行われないので、記事を一つ編集画面を表示させて何も変更せずに更新してみると…
表示がまともになりました。

ここでinclude_oneに戻してから操作してみると問題はなさそうな挙動になるのはカテゴリーがまともになったからだと信じたい…
サブカテゴリーの表示がトップページのカテゴリーの枠に表示されないのが気になったので色々と更新したりサブカテゴリーを削除してみたり「その他」を追加してみたりしたところ、途中からカテゴリー名の右側の"[" "]"の中の数字が16から15に減っていることに気づいた。

category_id.ini.php の内容と記事一覧のURLのIDを見比べてみると一番上(最新のもの?)がcategory_id.ini.phpに含まれていないようだった。

思い切って category_id.ini.php を削除
カテゴリー名の変更が面で 更新ボタンを押すと…
Warning: include(owner/category_id.ini.php) [function.include]: failed to open stream: No such file or directory in /home/htdocs/blog/cache.php on line 139

Warning: include() [function.include]: Failed opening 'owner/category_id.ini.php' for inclusion (include_path='.:') in /home/htdocs/blog/cache.php on line 139

Warning: Invalid argument supplied for foreach() in /home/htdocs/blog/cache.php on line 141
エラー表示が(笑)

更新しても新たに category_id.ini.php は再作成されないようなので記事を一つ編集画面を表示して公開ボタンをおして更新してみると…

トップページのカテゴリーがまともになった雰囲気。

ここでちょっとテスト。

サブカテゴリーを一つ追加して記事のカテゴリーを移動したりしていると…
サブカテゴリーの表示が行われないので見かけ上記事の表示が減ったようにみえる。
記事のカテゴリをメインに戻すと元の数に戻る。
(サブカテゴリーが表示されていない状態がだめっぽい)

サブカテゴリーにしたまま、サブカテゴリーを削除すると、数字がおかしくなったまま。

先ほどの状態に戻りました。

挙動があやしいということはおそらくcategory_id.ini.phpを読み込んでいるところで作成後の再読み込みが行われていないのが問題なのだと思う。

動作としては再作成した直後に再読み込みする処理を入れるのが妥当なのかもしれない。が、、マルチタスクだとPHPのメモリ共有の状態にもよると思うが毎回読み込む必要がありそう。

おそらく作者が処理速度改善のためにinclude_oneを使用していると思うのでこの辺の処理を入れ替えるのは難しいところ。実際問題としては読み込んだファイルのタイムスタンプを保持して更新されていたら読み込む形が一番スマートだとは思う。

2012年6月22日金曜日

幾分まともに

ソースを書き換えて入れ替え終わっていたと思って写真をアップロード。
3分以上かかってようやく完了。

…おかしい…

ソースが変わってなかったですorz

寝ながら複数の環境をみつつやってるとこんなものですね。

気を取り直し書き換えて別の写真をアップしたところ25秒ほどで戻ってきました。
リサンプリングではないのでジャギーが目立ちますけどこれで十分かな?

サクッと戻ってくれば快適なんでしょうけど非力なルーターですしね(笑)

せっかくなのでどこかにオプション設定できればいいのでしょうけどアドイン形式で埋め込めればいいのかなぁ。

ソースをパラパラと見ているのですがうまい切り口が見えないのでとりあえずはここ(直接ソースを変更)まで。

2012年6月21日木曜日

ようやく発見

どうにもgrepで入力ミスしているのかうまく検索できないときがとても多いですが、ようやくたどり着きました。
root@mzkw04nu:/home/htdocs/blog# grep "create_thumbnail" *.php
mob.php:       create_thumbnail(IMG_DIR.$img_name, IMG_DIR.$img_name, $w, $h, $ratio0);
mob.php:       create_thumbnail(IMG_DIR.$img_name, $thumb2img=IMG_DIR.THUMB2.$img_name, $w, $h, $ratio);
upload.php:    create_thumbnail($attached_file, $_attached, $w, $h, $ratio, $quality);
upload.php:       create_thumbnail($_attached, $thumb2img=str_replace(IMG_DIR,IMG_DIR.THUMB2,$_attached), $real_w, $real_h, $ratio2, $quality);
upload.php:     if(!is_file($thumb)) create_thumbnail($_attached, $thumb, $real_w, $real_h, $ratio_s1, $quality);
utils_admin.php:function create_thumbnail($input, $output, $w='', $h='', $ratio='', $quality=75){ // Revised in v.1.8.6
utils_admin.php:    if(!is_file($thumb = IMG_DIR.THUMB1.$_img)) create_thumbnail($img, $thumb, $size[0], $size[1], $ratio1);
utils_admin.php:     create_thumbnail($img, $thumb, $size[0], $size[1], $ratio2);
utils_admin.php:     if(!is_file($thumb)) create_thumbnail($imgfile, $thumb, $size[0], $size[1], $ratio);
utils_admin.php内でImageCopyResampledを行っているのを。(とてもいまさら(笑))
 //@ImageCopyResampled($img_out, $img_in, 0, 0, 0, 0, $_w, $_h, $w, $h) or ImageCopyResized($img_out, $img_in, 0, 0, 0, 0, $_w, $_h, $w, $h);
  ImageCopyResized($img_out, $img_in, 0, 0, 0, 0, $_w, $_h, $w, $h);
コードを直接変更してResampleはコメントアウトさせて見ました。
時間があればもうちょっと何かやってあげようかとは思います。

2012年6月19日火曜日

Motion用のビュワーを作成中

Motionで監視カメラを動作させ続けていますが今のところ全く問題はありません。
ただ、OpenWrtの配布形態のバイナリではMPEG変換がどうも行われないようなので再構築する必要がありそうです。

ですがどうもよく動作を理解していないので今のところWEB/PHPでとりあえず対応しています。

2つの環境で動作させているのですが、ルータではやはり処理能力が不足気味で画像も320×240で動作させて2FPS程度が限界のようです。(保存先をメモリーにすれば幾分早くなるのかもしれませんが必要以上のコマが必要とも思わないのでこれでいいのかなと。)

またファイル数が千単位に膨れ上がるとターミナルやSAMBA接続で厳しくなっているので今のところ月別のディレクトリの中にさらに日ごとに分けて保存するようにしています。
部屋で監視させているとだいたいこれで毎日2000~4000枚のJpeg画像が生成されています。

保存形態は当初から大体このような形で大丈夫かな?と言った程度です。(MPEG運用になればまた違った形になるかもしれませんが。

ざっとした雛形は1日で出来上がったのですが細かいところでいろいろと欲が出てきていていまのところサムネイル用の画像を作成させるかどうかで仕様を悩んでいるところです。

ppBlogで実感していたのですが、どうもルータに画像処理を行わせるとどうしても処理が重すぎてどうにもならない様でどうしたものかと。
PHPで画像ファイルを扱うのは非常に簡素化されているので工夫するにしても差ほど変わらないだろうというのが今のところの感触です。
たった320×240の画像から160×120のサムネイル画像(原画自体がサムネイルじゃないかと思いますけど(笑))を生成するのに処理してるのがわかるぐらい待たされました。
画像のリサイズを行う方法は2つあり、一つは全ピクセル情報をつかってのリサンプリングしリサイズを行う方法。もう一つは単純にピクセルを間引いてリサイズを行う方法。
WindowsXPのころからこの様な処理はどちらにしてもほとんどがハードウェアなどで処理されたりCPU自体の処理能力の向上によって体感速度はあまりかわらないものなのですが、ルータでは明らかに前者よりも単純に間引いてリサイズするほうが処理時間が短く済みます。
出来上がった画像は当然不自然にはなりますが処理時間とのトレードオフと考えれば十分考える余地があります。(このへんの処理もppBlogで手を加えると処理時間が短くサクサク動くようになるのかも?とかちょっと目論んでいますがどうなることやら(笑))

2012年6月14日木曜日

ようやくマウスパッドのドライバを更新

先日のcal_days_in_montの対処として適当なコードで対処しました。(本来はきちんと対処する必要があるのですが目の前の対処だけで済ませました。

その後ふとしたきっかけでノートのマウスパッドのドライバがあるのではないかと感じたのでまた少し検索してみました。

ALPS DRIVERで検索してみるといくつか気になるページがありましたがそれらしいページがAcerのページにありました。

Acer TREIBER

Acer Aspire 5320 Notebook (TouchPad ALPS) Treiber
Version: 7.0.1101.14
Typ: Notebooktreiber
Datum: 2009-06-11 14:40:01
Hersteller Home/Support: Acer
http://www.treiberupdate.de/treiber-download/download-176893-treiber-Acer-Aspire5320Notebook(TouchPadALPS).html

ALPSのデバイスは基本的に実際に販売している側で公開されているのみでALPS側からはリリースされていないので面倒なデバイスですね。

現状一番困っているのはFirefoxが旧バージョンでのいい加減なドライバのサポートを行わない方針になってマウスパッド側でのスクロールが不自由になったのでずいぶん前から探していました。

以前に探したときは旧バージョンの表記ミスや広告表示のためのダミーページばかりでしたがようやくまともそうなページを開くことができました。

WindowsXP 32bit用のドライバもあったのでウィルスチェックを行ったあと入れてみました。

PCの再起動を行うとマウスパットが色々なマウスメッセージをハンドリングするためのダミーウィンドウ用のアプリやベースとなる設定プログラムが起動された。
zip圧縮形式のなかに未圧縮の実行ファイルが格納されていたためか再起動時に何度か起動確認のためのメッセージが表示された.

早速試してみるとようやくまともにFirefoxが動作するようになった。

2012年6月2日土曜日

cal_days_in_month はどこで定義されているのだろう?

<?php
$num 
cal_days_in_month(CAL_GREGORIAN82003); // 31echo "2003 年 8 月の日数は $num 日です";?>
 
Fatal error: Call to undefined function cal_days_in_month() in /home/htdocs/test_cal.php on line 2
 ちょっと使いたかったんですが、見当たらないようです。
どこで定義されているんでしょうかねぇ?