The Blue and Violet Storys

　先日、拙作「表示モード別分岐モジュール」に悪戦苦闘していたために、これが何なのかは知っていました。

うぁ、さては「分岐モジュール」でまたドジったか？？？！！！
と思い、慌てて分岐モジュールの記事に「不都合発生」のアナウンスを入れて原因解明に臨みました。

　どうやら、記事投稿時に「改行を＜br /＞に変換して投稿」オプションで、「変換しない」にしていた場合に生じるようです。

　もちろん、Blognの方で上の「変換しない場合」に改行コードの代わりに「｛:rn:｝」をログに挿入してあったわけですが、どうも原因は「分岐モジュール」ではなくて、「タグ拡張モジュール」の方だったようです。

　「｛:rn:｝」をBlognで使うようになったのがいつからなのか定かではない（ver2.4.xをスルーしてしまいましたから／汗）ですが、タグ拡張モジュールは「続き」の文章をindex.phpで整形済のものではなくて生ログ（$val["more"]）を引っ張ってきて処理してあり、その中でindex.phpで行っているのと同様（必要なもののみ）の処理を行っているのですが、この「｛:rn:｝」の部分には対応してありませんでした。

　最新版（ver1.15）の公開時期から見ると、それも当たり前の現象です。

　対応は簡単で、不足している処理を付け加えてあげればいいだけです。

　以下に追加コードを紹介しますね。

[モジュールフォルダ内、xtratagsフォルダの中のfunction.php 25行目付近]

下の赤い文字の部分を追加してください。




≪ 続きを隠す

　結論をいうと、コメント投稿画面であまり大きな認証画像が表示されるのも何なので、今回は公式の「コメント投稿用画像認証モジュール」を採用しました。実装方法も簡単でしたしね。

　で、これを使うにあたって唯一の不都合は、「アルファベットの見間違い」による認証エラーが多発したことです。

　特に「Q」と「Ｏ」それもちっこい字のとき……（笑）

　いやはや、この間、コメントアイコンがらみのテストで、何度もテスト投稿したわけですが、我ながら何度も認証エラーしてしまい、これはなんとかしないといけない、と思ったわけです。手がけていたコメントアイコンも後回しにして、こちらを先にいじりました。

　その結果、認証画像は「０～９」の数字のみの４桁。表示される文字の大きさもこれまで各文字「１～５」の５段階ランダムだったのを「３～５」で大きめの文字が表示されるようにしました。

　実際の話、数字４桁でもスパム対策の効果としては十分であろうと考えています。
　BlognPlusをターゲットにして、専用にOCRエンジンを組み込んだスパムを走らせる輩がいるとはそうそう考えられませんからね。

　また、手打ちで入力されるとしたら、それこそ画像認証は意味を為しませんし。


≪ 続きを隠す

　コメントアイコンモジュールでの苦労話は既出として、表示モード別の方は、以前から実現したかった記事内でのコード表示。

　ブログンの記事ログを見比べながら手がけたのはいいのですが、どうも「記事」や「続き」の表示段階で、初期設定で許可されたタグ（a,b,などなど）との関係なのか、一度"＜"を"＆ｌｔ"に変換したものをまた戻したり、とややこしいことをやっているようです。

　さらに改行の取扱いが記事投稿時のオプション「改行を自動的に＜br /＞に変換して投稿する」などとの関係でしょうか、オプションによって処理後のバッファの内容がかなり異なります。
　なにより、コード表示というからには、記事投稿時の状態がそのまま表示して欲しいわけだし。

　いっそ、「＜br /＞に変換」で投稿されたものについては、比較的対応しやすかったのですが、「＜br /＞に変換しない」場合、取得したバッファの中身に改行コードが見当たらないということになってしまいました。明示的に書き込んである＜br /＞はそのままコード表示されるべき代物ですから手をつけるわけにはいかない。

　もうひとつ困ったのが、初期設定で許可を出している「form」や「div」タグで、開始はいいのですが、終了時の「/form」「/div」が他のタグと同じような処理がなされていない。（漏れなのか仕様なのか）
　ifviewで返還したはずがまた舞い戻っているという変な現象が発生してしましました。（謎です）

　というわけで、Blognがいろいろ手を出す前の記事ログを取得して、先にこちらの意図どおりの返還をしてしまえ、ということになりました。

　それが、index.phpへの記述が２か所に増えた理由です。変換したコード部分のタグを「すべて」Blognが感知しない独自のタグに書き換え、その後通常処理させた後、再びifviewを呼び出して表示用に置き換えてやったわけです。

　ここまで苦労しながら、実際には記事じゃなくてHPの方でコードの紹介、参照をするつもりで整理しているというのが矛盾してますけどね。


≪ 続きを隠す

　ところが、開発ページ向けにもう少しは詳しくreadme.txtを用意し、ページも更新できたところで問題が生じた。

　実際にコメントの投稿テストをしてみたら、アイコンが表示されてない。

　あらら？

　あまり、自分の記事に自分でコメントを入れることは想定してなかったので、今まで気付かなかったわけですね。愚かな（うぅ）


　とりあえずベーシックな状態（スパム対策モジュールをコメントアウト）から確認作業をしていったわけですが、

(1)これまでアイコン追加の記述は引数と戻り値に（$_POST["blogn_cmes"] など）を使用している。
(2)Blognの方では引数が変数になってしまっている（$blogn_post_cmes など）。……以前は(1)と同じPOSTでした。

　びっくりですよぉ。

　最初はせっせと(1)でメッセージの先頭にアイコン部分のコードを埋め込んだのに、(2)ではそんなの無視してて、アイコンが反映されてません。それに気づいて(1)の方でも変数による呼び出しにしてやると、ちゃんとアイコンが表示されるようになりました。

　続いて対策モジュールを復活させてやると、

　またアイコンが表示されなくなったぁ……

　これは、対策モジュールの中身を覗くまで謎が解けませんでした。

(3)そしてスパム対策モジュールでは中身で$_POST["blogn_cname"] を使っていた。

　対策モジュールと連動させるために、再び(1)の呼び出しをもとに戻すのは、もし対策モジュールを導入されていない方がいた場合に不都合が生じます。まして他の作者の手によるモジュールを前提にしたモジュール開発というのは変な話になるでしょう。

　基本的にはBlognの仕様に合わせるのが妥当です。

　その上で、もし対策モジュールを使用される場合の記述方法をreadme.txt（or解説ページ）に追加させることにしました。

　そういったわけで、技術的には何ら変更はないのですが、バージョンを1.4に上げて改めて公開することになった次第。

　

≪ 続きを隠す

　前々から作ろうとは思ってはいました。というのは、このサイトの場合、使用するスクリプトにかなり制限がかかるので、一般に出回っているもので、仕様に合わない（あるいは改造が難しい）場合は「自分で作れ」ということになるからです。

　その制限というのは、

　「サイトのphpの中に埋め込み表示ができること」

　今回のサイト改編にあたり、すべてのコンテンツをルートのindex.phpからオプションで選択して表示させるようにしたことで、

「事実上、そのままで使えるスクリプトは存在しない」

　ということになってしまいました。

　以前はフリーのスクリプトをどっかから見つけてきて、その表示にあたって、無理やりサイト側のスキンを使わせるよう改造していましたが、これからは「自分自身ではhtml表示せずに、内容を変数に文字列を格納して返す」ようにしてもらわなければいけなくなりました。

　サイト側では、戻ってきた変数を自分のページのコンテンツエリアに流し込んでやればいいわけです。その方がサイト側もスクリプト側も扱いが簡単で統一性も出てきます。（とは両方自分で作るから言えることなのですが）

　そんな仕様に合わせて、先日のsxEditも、本体をindex.phpから呼び出す形で作ってあったわけですね。
　これから作っていく用語集も、それに準じて作ることになるでしょう。

　んで、そもそもphp版で参考となる用語集スクリプトがあまりに少ない。
　cgi(perl)版ならけっこうよさげなのを見かけるのに…



≪ 続きを隠す

　HPの作成にいそしむ中、ちょっとした改編なら、エディタやFTPソフトを立ち上げなくても、ましてや外出先でも編集できれば便利かな、という姑息な目的で作成しました。おおもとは、その目的および、自分のサイトの構成やスタイルに特化したもので、あまりエレガントとは言い難い代物だったのを、もう少しわかりやすく、一般的な使用に堪え得るものとして構築しなおしました。これなら公開しても構わない（？）

　現在、詳細ページは準備中ですが、これまで（そしてこれから）作ってきたスクリプト等の一覧およびダウンロードできるページ（開発コーナー）が用意できましたので、興味のある方はご覧くださいませ。

sxEdit紹介


　HPへはトップ（スタート）ページを経由しないと入れない仕様ですが、サイト内およびこのブログからのページ移動なら許可するようにしてあります。

　遷移→aタグによるターゲット属性selfによるページ移動

　ターゲット属性blank（新規窓）や、JavaScriptなどによるlocation.hreｆとかでは、直前のＵＲＬがクリアされるので、おそらくダメです。クッキーにＨＰのトップへのアクセス記録が残っていれば別ですが。






≪ 続きを隠す