* メニューバーの中でInvalid XHTML対策済みプラグインを使用するとInvalidになる [#m87a16c2]
- ページ: [[BugTrack2]]
- 投稿者: [[Ilfa]]
- 優先順位: 普通
- 状態: 完了
- カテゴリー: その他
- 投稿日: 2007-07-23 (月) 00:41:25
- バージョン:
#contents
** まとめ・修正 [#ca748a1f]
WikiテキストをXHTMLに変換する処理について:
- PukiWiki本体は何もしない。
- PukiWiki の read プラグインなどは、指定したページ1つに関するconvertを事前に行ってからスキンを呼ぶ。
-- スキンは基本的にデザインのみを担当している。
-- デザイン上の都合で、スキンによってはさらに別のページをconvertしたいことがある。デフォルトのスキンでは、MenuBarというページをconvertする。
-- これらのサブページのconvertは、PHPがデータの出力を開始する前に行うべきである(理想としては、メインページとほぼ同じタイミングでconvertされるのが良い)。そうでないと、動的なプラグインをそれらサブページの中で使用した時に、DTDやmetaヘッダなどに関する不整合が生じる可能性がある。
修正:
- スキン内部において、データの出力を開始する前にサブページのコンバート処理を行う。
-- [[cvs:skin/pukiwiki.skin.php]] (r1.55-1.56)
-- [[tDiaryスキン]] は既に同様の処理手順になっているため、修正の必要なし。
** メッセージ [#n42d85dd]
Invalid XHTML 1.1になるプラグインについては、PukiWikiではプラグイン内で下記のように処理することになっている。
global $pkwk_dtd;
(中略)
if (! isset($pkwk_dtd) || $pkwk_dtd == PKWK_DTD_XHTML_1_1)
$pkwk_dtd = PKWK_DTD_XHTML_1_0_TRANSITIONAL;
ところが、このようなプラグインをメニューバー内で使用した場合、標準のスキンでは、メニューバーが処理される前に$pkwk_dtdの内容を確定してheaderとして出力されてしまっているため、XHTML 1.0 Transitionalにはならず、Invalid XHTML 1.1となってしまう。
対策としては、スキンの中で、
if (isset($pkwk_dtd)) {
$meta_content_type = pkwk_output_dtd($pkwk_dtd);
} else {
$meta_content_type = pkwk_output_dtd();
}
?>
<head>
<?php echo $meta_content_type ?>
このように$pkwk_dtdの内容を出力している部分より前の行で
if (arg_check('read') && exist_plugin_convert('menu')) {
$menuhtml = do_plugin_convert('menu');
}
として、メニューバーの内容をとりあえず実行して変数に取り込んでおいて、メニューバーの実際の出力部分を下記のようにすれば、とりあえずはInvalidにならずに済む。
<?php if (isset($menuhtml)) { ?>
<div id="menubar">
<?php echo $menuhtml ?>
</div>
<?php } ?>
泥縄式ではあるが、とりあえずの対策としては、これがいちばん簡単。
根本的な修正をやろうとすると、かなり大がかりになりそうなので・・・
--------
- 冗長な判定を簡略化しますた -- &new{2007-07-23 (月) 21:02:29};
- $submenutextでなく$submenuhtmlの方がしっくりね。 -- &new{2007-07-23 (月) 21:07:47};
-- もしかしてsubは要らない？ -- &new{2007-07-23 (月) 21:08:24};
- コメントありがとうございます。「menubarを処理してる所が変だ」という話題の一つのようですね。他にも似たような話題が無かったっけな・・・ -- [[henoheno]] &new{2007-07-23 (月) 23:12:39};
-- MenuBarのようなサブページを(いくつ、どんな時に)表示するかどうかはスキン次第ですから、スキンの中で解決しておくのが良いのでしょう。 -- [[henoheno]] &new{2007-07-23 (月) 23:14:29};
-- [[cvs:skin/pukiwiki.skin.php]] (r1.55) こんな感じでいかがでしょうか。
-- [[tDiaryスキン]] はとっくにこのような処理を実施していたので、修正の必要がありませんでした。 -- [[henoheno]] &new{2007-07-23 (月) 23:28:39};
--- r.1.55 スマートですね。OKです。という表現が失礼なくらいOKです。 -- &new{2007-07-24 (火) 06:32:07};
--- ちょっといけてない部分があったので、もう一つコミットしときました -- [[henoheno]] &new{2007-07-26 (木) 11:35:03};
--- [[cvs:skin/pukiwiki.skin.php]] (r1.56)
#comment
----
** コメント: デザイン(1) [#f06c3904]
- これは MenuBar の変換のタイミングと、本文の変換のタイミングが異なるために生じる問題の一種ですよね。変換タイミングが異なるために本文では使用できたのにMenuBarでは使用できなくなるプラグイン（変数、仕組み）が実は多数あると感じています。明らかな代表的な例では、スキンを切り替えるプラグイン、を MenuBar に設置することができません(MenuBar の変換はスキン内で行われる、つまりスキンがすでに実行されているので切り替えられない）。他の例では、最近 Plus! のほうであがった [[plus:BugTrack/146]] - $head_tags が MenuBar, SideBar などでは使えない。があるでしょう。これも実質同じ問題です。他にも数多くの差異が生じることと思います。この同種の問題には、MenuBar の変換を本文が変換されるのと同等のタイミングにすることで対応可能だと思います。スキン内だけで対応したい所ですができないと思います。 -- &new{2007-07-24 (火) 10:02:29};
-- 議論すべき点は MenuBar を使用しないスキンでも MenuBar を前もって変換しておくべきか否かだと思います。現在スキンで MenuBar を変換しているのは、MenuBar を使用するスキンでのみ変換するのが理に叶っているという考え方によるものだと思います。 -- &new{2007-07-24 (火) 10:05:20};
-- しかし、個人的には MenuBar を使用しないスキンでも MenuBar を変換（プラグインを実行）しておいてくれると、たとえばカウンタープラグインなどを MenuBar に設置すれば全ページのカウントをしておけるので便利だと思っています。 -- &new{2007-07-24 (火) 10:07:16};
- どんなサブページをどれだけconvertしたいのか、という部分(Wikiとしてのデザイン)を担当しているのはスキンなので、それを規定する箇所は変わらないでしょう。で、「どんなページをconvertすべきか」という部分を遅延させて、スキンでの追加要求を受けてから、全部まとめて処理する路線にできるのならそれが健全なんじゃないでしょうか。従来型のスキンを救えるかどうかも含めて、仕組みはしっかり考えた方がいいです -- [[henoheno]] &new{2007-07-26 (木) 11:37:32};
-- 「それを規定する箇所は変わらない」というのはMenuBarはあくまでもスキン内で変換、ということでしょうか？そういう考え方とすると、本文もスキンでいつ出力するかを決めているので、本文の変換もスキン内でやるべき、ということになるかもしれません。そういう考え方もいいのですが、そうなるとやはりスキン指定プラグインは設置できなくなるんですよね。うーん。 -- &new{2007-07-27 (金) 04:16:58};
-- ちなみに、そのスキン切り替えプラグインというのはどれですか? -- [[henoheno]] &new{2007-07-30 (月) 00:19:58};
-- [[BugTrack/634]] に載っている[[skin プラグイン>plus:plus:Plugin/skin.inc.php]]のことかも。plus のパッケージに含まれていますし。 -- &new{2008-03-21 (金) 21:22:47};
-- [[BugTrack/634]] に載っている[[skin プラグイン>plus:Plugin/skin.inc.php]]のことかも。plus のパッケージに含まれていますし。 -- &new{2008-03-21 (金) 21:22:47};
- すでに上で挙がっている、$head_tags もそうなんですが、$foot_explain もcatbody 関数内で内容を確定させているので、MenuBar 内で注釈を使えません。
// List of footnotes
ksort($foot_explain, SORT_NUMERIC);
$notes = ! empty($foot_explain) ? $note_hr . join("\n", $foot_explain) : '';
// Tags will be inserted into <head></head>
$head_tag = ! empty($head_tags) ? join("\n", $head_tags) ."\n" : '';
正確には、注釈へのリンクは表示されるのに、リンク先であるその注釈が存在しない状態になります。&br;ついでに$head_tags がMenuBar 内で使えないと不便な例を挙げると、[[BugTrack/721]] に載っている[[keywords.inc.php>official:自作プラグイン/keywords.inc.php]] をMenuBar 内で設定して、全ページに同じキーワードを設定しようとしても、いまはできません。同じことをしようとすると、read の時だけキーワードがでるように、スキンを書き換えするしかないのです。&br;めったにキーワードを変えないのならスキン修正でもいいのでしょうが、頻繁に手直しするのなら、やはりPukiWiki 上で実現できたほうがいいのでは？と思うのです。 -- &new{2008-03-21 (金) 21:22:47};
-- ただ互換性を考えると、今ある場所はそのままにして、$foot_explain や$head_tags を追加する可能性のある処理がすんだ後、Output 前に収得しなおすしかないような気がしてしまう・・・ -- &new{2008-03-21 (金) 21:22:47};
-- skin/pukiwiki.skin.php (1.56) を修正する場合の例
// MenuBar
$menu = arg_check('read') && exist_plugin_convert('menu') ? do_plugin_convert('menu') : FALSE;
+
+// List of footnotes
+ksort($foot_explain, SORT_NUMERIC);
+$notes = ! empty($foot_explain) ? $note_hr . join("\n", $foot_explain) : '';
+
+// Tags will be inserted into <head></head>
+$head_tag = ! empty($head_tags) ? join("\n", $head_tags) ."\n" : '';
// ------------------------------------------------------------
// Output
#comment
----
** コメント: デザイン(2) [#f06c3904]
- 実装をとやかく言う前に仕様を明確にした方が良いかと。まず、自作プラグイン作者向けに本体内部の仕様を明確にすること（ドキュメント化）。今回のようなMenuBarの問題は自作プラグイン作者が本体の内部仕様を知らない/理解しないまま作成したため、発生したものと思います。自作プラグインの作者がそれらを理解していれば、テスト時に気づくはずでしょうし、ドキュメントが整備されていれば、そういったツッコミもあったことでしょう。[[ロードマップ]]にあるとおり、「意識合わせ」として「開発環境周りの資料・整備がいるのかもしれない」なのでしょうね。 -- &new{2007-07-24 (火) 17:53:56};
-- 不明確なのは仕様というより要求、というかユーザーのニーズであるかのように思われます。3rd party向けのドキュメントをこの時点で作るのは大変なので、PukiWikiの事情と、ユーザーの都合を明確にして、他のコメント欄で解決させるのがいいと思います。意識あわせ等は御意の通り。 -- [[henoheno]] &new{2007-07-26 (木) 11:35:44};
#comment
----
** サブページを全て同じタイミングでconvertした方が都合の良いケースに関する話題 [#k65d20be]
-- 仕様云々に言い換えると「プラグインをMenuBar においても本文においても効果が同じ」にしませんか？という提案になりますね。そのほうが理に叶っている、かつわかりやすいと思います。これならばドキュメントももはや必要ないでしょう。 -- &new{2007-07-24 (火) 21:30:51};
-- ＞。今回のようなMenuBarの問題は自作プラグイン作者が本体の内部仕様を知らない/理解しないまま作成したため、発生したものと思います。&br;
むしろ本体devの側で気付いていなかったため、発生したものと思っています。ドキュメントとしてこれに言及したものがないですから。 -- &new{2007-07-24 (火) 21:28:27};
-- 実装は上では一切言っていないので、これから言うと、pukiwiki.php に
+global $menubar;
+$menubar = do_plugin_convert('menu');
の2行を適当な場所におき、スキンでは echo $menubar だけすることになると思います。-- &new{2007-07-24 (火) 21:52:12};
- 上でも議論すべき点として少し述べましたが、実装を考えてみた所、細かい仕様として３つのオプションが考えられそうです。 -- &new{2007-07-24 (火) 22:10:41};
- 下流工程で歯止めをするより、上流工程で歯止めをすることが分からないかなぁ。。。残念。Invalid XHTML1.1もMenuBarもJavaScript((Content-Script-Type))もCSS（を含む他の脆弱性）も自作プラグインの作者が「本体内部の仕様を知らない/理解しないまま作成したため」だと思いますが、、、ドキュメントが必要なんですよ。また、自作プラグイン作者が投稿する際に注意を促すもの、チェックリストのようなものも必要だと思うんですがねぇ。 -- &new{2007-07-25 (水) 06:55:03};
-- そして、現状仕様に不満足な自作プラグイン作者等がdevに提案する。で、良いと思いますが。。。 -- &new{2007-07-25 (水) 06:56:38};
-- 上流工程とか何のことを指しているのかわかりませんが、今回の問題はskinの仕様がまずかった(メニューバーが処理される前に$pkwk_dtdの内容を確定している)わけで、skinの修正をする、という今回の対応で問題ないのでは。修正前のようにOUTPUT部分で動的な出力(今回ではMenuBarを表示するかどうか)等行うと不具合発生の要因になりやすいと思うので、今回の修正のように生成できるものはあらかじめ生成しておくのがよいですね。 -- [[ぃぉぃぉ]] &new{2007-07-25 (水) 12:34:33};
- ちょっと待ってください。まるで現状の MenuBar の変換タイミングが期待通りである（仕様である）ようなことをおっしゃっていますが、果たしてそうなのですか？そうなのであれば、今回のBugTrackもバグではなく、仕様変更であったということなのですか？私はバグ（期待通りでない動作）だと思っていましたが -- &new{2007-07-25 (水) 12:32:35};
-- プラグインを MenuBar においても、本文においても同じ動作になる、ということです。言うまでもなさそうですが・・・汗）この BugTrack もそのために立ち上げられたものですし・・・ -- &new{2007-07-25 (水) 12:50:13};
- 他のコメント欄と話題がかぶっている気がする -- [[henoheno]] &new{2007-07-26 (木) 11:38:40};
#comment
** メタコメント: 他人のコメントを含めた話題の整理 [#f296c739]
- うーん、自分のコメントだけ全部消していくというのは、人間的にどうなんでしょう？文章がつながらなくなってしまっていますが -- &new{2007-07-25 (水) 13:02:28};
-- wikiだから自分で戻したら？これ以上、付き合わないので勝手にどうぞ。
-- 自分のコメントのみならず他人のコメントまで消していくとは、あなたは本当に人間として最低だ -- &new{2007-07-26 (木) 01:44:48};
- ここだけ見ると、まるで消された話題があったかのように見えますが、各種見た範囲では(最終的に)上に再掲されている様ですね。見出しなどによる話題の分割や整頓がスムーズにできておらず、コラボレーションの喜びを知らないBBSユーザー同士の掛け合いがあったかの様に見えるので、どちらもwikiユーザーとしての経験を積んでいただきたいかな・・・。
>
+一回一回の修正(とかコメント)はテーマを絞って、主語述語を明確に保ち、(結果的に)後で整理しやすい様にする。その人にしか言えない観点を常に含めるのが望ましいし、主張については修正者・修正日などが適切に解るようにする
+別の話題が見えてきたら、早めに(第三者に納得されるように気を配りながら)話題を分ける。他のページでも触れた[[構造化プログラミング>Wikipedia:構造化プログラミング]]と同じように、なるべく少ないコストで話題をまとめるようにする
+周りに納得されるような、うまい見出し(話題の要約)を考えて提示する(思いつかないなら「コメント」からでいい)。
<
といった事を、できれば周りと調整しながらうまくやって下さい。構造すら変えられるという事や、だからこそ様々なきっかけをエネルギーに転換できるというwikiの利点を体得して欲しいなぁ -- [[henoheno]] &new{2007-07-26 (木) 11:13:42};
-- これはいわゆるバッドノウハウってやつですよね？ pukiwiki のコメントが使いづらいから人間が気をつけなければならない。バッドノウハウは期待しても実際にやってくれる人は多くないものです。-- &new{2007-07-27 (金) 04:27:45};
- 何らかの味気ない((話題の邪魔をしない、そこそこユニークな、色々考えると半角アルファベットと数字を使った方がいいだろう))ユーザー名を名乗りつつコメントするのをお勧めします。後から付けるのでもいいです。整理し辛いので。 -- [[henoheno]] &new{2007-07-26 (木) 11:23:12};
- (調べてみましたが、「捨て台詞の様なコメントを残しつつ、いくつかのコメントをまとめて削除」という乱暴な修正が一度あった様ですね) -- [[henoheno]] &new{2007-07-29 (日) 23:56:14};
- メイントピックは解決できているため、完了にしておきます。何かあればコメント/整理して下さい。 -- [[henoheno]] &new{2007-08-05 (日) 21:23:53};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
