フィルターモジュールが上手く機能しない・・・。
Posted by amayadori on 2007/05/28(月) 11:40
atom@o--i.net さんの質問:
質問
aom@o--i.net wrote:
唯どーもスマイリーもそうなんですが画面表示関係が不安定なんで試行錯誤しておったところです。
スマイリーの場合 画像表示されずコード文字になってしまいます。
実は、atomさんのサイトでのやりとりなのですが、ちょっとネタに使わせてもらうことにしました(;^_^A アセアセ…
実際のサイトでのやりとりは実のところをご覧ください<(_ _)>
要するに、コンテンツや、コメントなどの投稿をするときに利用できるフィルターモジュールが、思った通りに表示してくれないまたはタグがそのまま表示されてしまう･･･(T.T)
と言うことのようです。
解答
amayadori(atomさんのサイトでのコメント) wrote:
顔マークについては、フィルターでおそらくコントロールしているのだろうと思いますので、フィルターの順序を変更してみると改善するかもしれません。
管理→サイト設定→入力書式→(顔マークを設定しているフィルタ)→設定→再編成
ー10→１０の順番でフィルターが処理されます。コードが表示されると言うことですから、最初に実行した方が良いのかもしれません。
ワタシは顔マークは入れていないし、他のフィルターとの兼ね合いもあるので、断言は出来ませんがBbcodeと他のフィルターで順番を変えたら良くなったりしたことがあるので、改善する可能性もありますのでおためしください。
フィルターモジュールはフィルター管理メニューでの重み付け設定の順で処理されますので、フィルターモジュールによってはこの順番の影響を受けてしまう組み合わせがあるようです。
例えば、似たような構文のタグを使用しているとか、その処理に仕方によっては後に処理されるフィルターに影響を与えてしまうなどなど。
フィルターの重み付けの順番を変えることによって改善されることが多いです。どれが先に処理された方がよいか?というのはなかなか一概に言えるモノではないのですが、どうしても、改善できなければ干渉しあっているフィルターのどれかをあきらめるなど、妥協が必要な場合もあります。
あるいは、干渉しあっているフィルターを同居させないフィルターのセットを複数作成して、コンテンツ内容によって使い分けるなど工夫によって使いこなせる場合もあります。
トラックバック
URLから "-notspam" を削除してトラックバックを送信してください。トラックバックポリシーは こちらに提示しています。
あー、この辺は判ります。技術屋さんじゃありませんけど。
ちょっとずつ内容の違うフィルターセットがいくつかあります(笑)
もういいかっ!って、削除しちゃったときは、きっと大あわてするんですよ･･･いつも(^_^;)
確かに、おっしゃるとおりですね。通常の"編集"という行動を考えたら至極当たり前の様な気がします。
と、言うことは、デフォルトが削除できてしまう方に問題がはらんでいると言うことなのかな?
jboxの方でもありましたよね。uid=1が削除できてしまうのは･･･というお話。
アレと同じ類の問題のような気がしますね。
システムを多少なりとも理解している人ならば、何となく判っているやってはいけないことでも、やはり、ユーザーの裾野が広がってくれば来るほど、想定外の行動を取ることは考えていかなければならなくなりますものね。
とおなじで、
というのは、改めていかないといけない曲がり角に来ているのかもしれませんね。
私の場合、削除しないのは技術屋の性といいますか、常に後戻りできるようにしますので。
デフォルトの入力書式にフィルタを加えるのではなく、デフォルトのはそのまま置いておいて、新規に入力書式を追加するのもそうだったりします。
使用不可で編集できなくなるというのは、まあ判らなくもないです。
例えば、adminだけフルHTMLの入力書式が使用可の状態で、adminがその書式で書いたノードは他のユーザは編集不可となるわけです。これはこれで、ある意味筋が通っていると思います。
ですから、多分、後から入力書式を使用不可にする方がイリーガルなんでしょう。考え方によっては、それがベストではないと思いますが。
しないですね、ワタシは。
入れたら入れっぱなしが実は多い(笑)無効にはしてますが、ディスク上にはそのまま残っていることも少なくないですね。
フィルターはよほど不都合でもない限りはそのままですね。
ただ、それとシステムの挙動というか安全性と言うことは別問題なので、やはり、編集ができなくなると言うのはシステム設計という視点で見たらちょっといただけないですね。
フィルターに依存しない状況というのはプレーンテキストなのですから、その状態が最低ラインと考えて、投稿時に指定されたフィルターが存在しなくなった場合はプレーンテキストとして扱う･･･とした方が、システムの安全性としては高い気がします。
あまりよろしくない状況を想定するのであれば、フィルター変更移行ツールのようなモノがあっても良いかもしれませんね。DBのあるレコードを書き換えるだけなんだとは思うんですけど(^_^;)
削除って...、あまりしないものなんですね。
でも、編集できなくなるというのは微妙なところですね。
考え方によってはありだと思いますが、設定した側にとっては、そういう説明は見たことがないような気がするので、想定外の出来事ということになりそうですよね。
ワタシも削除はやったことがありませんね。
要するに、admin以外は自分の投稿ですら編集できなくなる？
という事なんですかね？
まぁ、想定外と言えば想定外なのでしょうけど、何とも柔なシステムという気がしてしまいますね。
投稿時の書式セットが無くなったら、プレーンテキストという扱いしにしてしまうと言う方がシステムとしては安全な気がしますが･･･
システム設計として、どうなんでしょうね？
「削除」はやったことないですが、違うような気もしますね。想像ですが、
削除→所定の入力書式が無い→デフォルト使用
使用不可→不正アクセス→編集不可
という感じじゃないでしょうか。
adminなら全入力書式にアクセスできますので、adminで一つずつ入力書式の指定を変えていくという対処は可能です。かなり面倒くさいですが。(^^;;
私はDBを直接修正しました。
削除とは違うんですかね？
以前、書式を削除したときは、その書式を適当しているコンテンツはデフォルトの書式になって、レイアウトが少々...ということはありましたが編集はできましたので、「削除」は問題はあるけど、地道に修正作業すればOKかも...です。
えっ！
思いっきりやってます、ワタシ(T.T)
古いコンテンツなんて滅多に編集とかしないですが、そんな副作用があるとは･･･。
そうなると、入力書式セットを増殖させていく以外ないんですね･･･(T.T)
まぁ、編集しないからいいんですけど(開き直りか)
(^^/
私もやりました。直感的には判り辛いですよね、この問題は。
フィルターの動作を理解しないと、トライ＆エラーで確かめなければならないので辛いですね。
あと、入力書式のパーミッションを途中で変えると、古いコンテンツが編集できなくなります。
インストール時の入力書式で暫く運用した後、新しいフィルターを入れるために新たに入力書式を追加して、他の入力書式を使用不可にしたら、以前のコンテンツが編集できなくなってしまいました。(^^;;
もしかして、みんな一度は体験することなのでしょうか?(笑)
かくいうワタシも経験してますね。
最初は確か、Footnoteモジュールの時だったような。もう、ずいぶん前なのでよく憶えてないけれど(^_^;)
次は割と最近。Bbcodeが上手く反映されなくて、ちょうどその頃にReptagのお試しもしていたのもあり、そのせいかな？とか思ったりもしたんですが、Reptagを無効にしても治らなかったので、どうも違うようだ･･･と。
確固たる自信があった訳じゃないけど、もしかしたら･･･でフィルターの設定でBbcodeのウェイトを小さくしたら改善したので、ここだったかーと、思ったモノです。
使い慣れてくると欲が出て、色々なモジュールを入れてみたくなりますからね。その頃が一番、罠に陥り安いのかもしれませんね(^_^;)