トップ 差分 一覧 Farm ソース 検索 ヘルプ RSS ログイン

雑談掲示板

ページの作成や編集にはユーザ登録が必要です。

FSWiki雑談掲示板

サポート掲示板は質問などの書き込みが主になっているようなので、FSWikiを使っての感想など、些細なおしゃべり・雑談の場合はこちらをお使いください。話が盛り上がってきたら適宜、サポート掲示板などに話題を移行させるような感じでの使い方もできるかもしれません。

  • 過去ログはページ下部の選択肢から参照できます。
  • 件数が増えてきたら古いものから順に過去ログに移動します。
  • 雑談掲示板一覧もどうぞ。
  • 設置に関するトラブルや要望などはサポート掲示板のほうにお願いします。
  • バグ報告に関してはバグトラックのほうにお願いします。
  • FSWikiとは無関係と思われる投稿、コメントに関しては削除させていただきますのでご了承ください。
お名前
件名
本文

ページの編集権限を3段階に - kumaneko (2006年01月05日 18時31分21秒)

複数の人間でサイトを作っています。現状では、参照権限についてはゲスト、ユーザ、管理者の3段階で管理していますが、編集権限は管理者と管理者以外の2段階(凍結か非凍結)の2段階しかありません。こちらも3段階にならないものでしょうか?

  • 安定版でもある3.5系では未実装です。どこかのログで(あるいはMLアーカイブだったかも知れません)見た限りでは「4.0系では更新の権限も3段階に…」と議論されていました。私もkumaneko氏と同様な意見を持っておりますが、3.5系にフィードバックされ、取り込まれる事を期待している一人です。 - A_M (2006年01月05日 19時23分37秒)
  • 本来であればユーザ管理も含めて、BugTrack-plugin/106+編集権限というか、Unixのパーミッション管理のような形がベストだと思うのですが・・・。何分私、MSのVBA程度しか使えず、正規表現にいたってはチンプンカンプン・・・。他力本願で申し訳ないんですが。 - kumaneko (2006年01月05日 21時17分20秒)
  • MLです。4.0系で実装されるのは確定だと思いますが、3.5系でも…っていうのはどうなんでしょう? 元々ページの凍結っていうのはWiki独特の考え方で慣れるまで分かりにくいですし、確かに編集権限も参照権限も3段階で統一するなら、凍結機能そのものが不要になると思います。(何を隠そう、MLでこの話題をふったのは私です) 私も、「対応して頂きたい」という想いはありますが、現存の凍結機能と共存させるのは、ユーザの方々には混乱の種となる気がします。やるなら凍結機能は廃止にすべき(凍結ON=ユーザ権限以上での書き込み、とすれば一応互換は保てます)。ですが、マイナーバージョンアップでそこまでやるのは(従来機能を削除するのは)、やりすぎなんじゃないかって思ったりもします。 - あき (2006年01月05日 22時24分44秒)
  • 4.0のCVSには実装されていました。4.0系が安定し、リリースされるのを待つのが正解でしょうね。確かに、3.5系で期待というのは、あき氏の仰るとおりだと思います。 - A_M (2006年01月06日 03時00分10秒)
  • そうですね。管理方法が2種類になるのは問題ですよね。4.0、期待しています。 - kumaneko (2006年01月13日 07時20分41秒)
お名前: コメント:

「プラグイン投稿」からインストールするときに - ZON (2005年12月26日 15時04分13秒)

ども、場当たり改造ばっかりやってるZONです。

先日気づいて BBS-サポート掲示板/472 の方にも書いた事ですがファイルやディレクトリの属性についてです。

プラグイン投稿のページに投稿されているプラグインはUnix以外の環境で作成されたものも(ものが、かな?)多いので、ファイルを解凍した時に得られるファイル属性がまちまちです。このことは、さして重要と言う程の事ではありませんが、ケースによってはエラーとして表面化します。人間とは不思議なもので、この簡単な問題に気づかずに、ついPerlをコマンドラインで立ち上げてシンタックスエラーを疑ってみたりするかもしれません(←僕の事だ)

そこで、無くて良いトラブルを予防するためにドキュメントページのQ&Aにでも書こうかと思っています。以下のような感じでどうでしょう。

Q.投稿プラグインをアップロードしました。管理画面>プラグイン設定で『プラグイン名は出ますが説明が出ません』、そしてインストールしようとするとエラーが出ます
A.ディレクトリやファイルのパーミッションを確認してみましょう。例えば test という名前の投稿プラグインがあった場合、/plugin/testディレクトリの属性が755(drwxr-xr-x)かそれに準ずるものでなくてはいけません。さらに含まれるファイル、例えば Install.pm や TEST.pm の属性も644(-rw-r--r--)かそれに準ずるものでなければなりません。これは「プログラムがそのディレクトリやファイルを読み取れる」事を意味します
    • ※準ずる→ディレクトリの場合705(drwx---r-x)、ファイルの場合604(-rw----r--)というケースもありえます

予防目的なので、こういう文章も考えてみました。

◆プラグイン投稿されたプラグインのインストールを確認する
もし「インストールの方法」があれば、最初にそれにしたがって下さい。次に /plugin ディレクトリ以下の、プラグインが含まれている各ディレクトリが755(drwxr-xr-x)かそれに準ずるパーミッションであることを確認します。特にことわりが無ければ含まれる *.pm ファイルのパーミッションは644(-rw-r--r--)か、それに準ずるパーミッションである事を確認しましょう。余裕があれば最後に Install.pm ファイル内に書かれているプラグイン-ファイル名と実際のファイル名が一致しているかどうかも確認しましょう(多くのサーバーでは大文字小文字が区別されます)
◆改造タイプの投稿プラグインについて捕捉
改造前のファイルのバックアップをとっておくことは基本ですが、ここでもファイルやディレクトリの属性(パーミッション)は事前に確認しておきましょう。場所は /lib 以下です。ファイル内部に手を入れますから、見えない文字、特にtabと空白と改行には留意しましょう。(なかでも『空白』は要注意です。日本語入力で全角空白を使っていませんか?) tab はたいてい無害ですが、改行は大方のサーバーでは LF です(FTPソフトの改行変換に任せる事も可能ではありますが)

あるいはもっと簡単に……

/plugin ディレクトリと /libディレクトリ
投稿プラグインのアップロードや改造の後、各ディレクトリは755(drwxr-xr-x)、含まれる *.pmファイルは644(-rw-r--r--)になっていることを確認する

どうでしょうか。小さい問題ではありますが、人的ミスを防ぐという目的でドキュメントに書き足してよいでしょうか?

  • 万人に有益な情報でしたら、断りもなく載せて頂いて良いと思います。ここに投稿するのと同じような感覚で記載してやって下さい。ここよりも、ドキュメント側の方がインデックスが付いて見やすいですし…。 - あき (2005年12月27日 08時09分07秒)
  • 是非お願いします。 - たけぞう (2005年12月27日 22時21分14秒)
  • どうもです。少し長くなりましたが「Q.投稿プラグインをインストールしようとするとエラーが出る」というタイトルでドキュメントの方に書き込みました。ミス等ありましたら指摘してください。 - ZON (2005年12月28日 10時12分26秒)
お名前: コメント:

ダウンロードのぺーじ更新して - びくとりー (2005年12月17日 17時47分02秒)

ダウンロードのぺーじ 安定版のダウンロードはSourceForgeからどうぞ。現在の最新バージョンは3.5.9です。

  • ご指摘ありがとうございます。更新しておきました。 - あき (2005年12月17日 18時56分08秒)
お名前: コメント:

将来的な希望として - H.Holon (2005年12月01日 07時14分10秒)

現在、URLが wiki.cgi?page=ページ名 のような形式になっていますが、wiki.cgi/page/ページ名 といったスラッシュをセパレータとした形式への対応を希望です。自分で修正しようとしたのですが結構埋め込みな query設定などがあって、設定で switchするような作りにするには大事そうでしたので、できれば将来的な実装希望として、お願いしておきます。

理由としては、CMS的な使い方をしたときに search engineがひっかけてくれないことが一番だったりします。

  • Yahooの場合は、descriptionを埋め込めるならインデックスされるみたいです。またLite版を使ってた時期には、p=(ページ名)がGoogleでもインデックスされたように思います。ちなみに、Googleの場合、ページ名が日本語(URLエンコード)より半角英数字の方がインデックスされやすいかもしれないという経験則を感じます。CGI.pmモジュールを使っているので、変数=値の式は変えられそうにないかも。mod_rewriteで対応しようとした時期もありましたが断念しました。 - A_M (2005年12月01日 15時27分38秒)
  • 思いつきで検証してませんし、変則的ですが、farm処理の前に$path_infoを元に$path_info自身と$cgi->param("page",$hoge)としてパラメータ値も書き換えてだませばmod_rewrite風の書き換えはできると思います。 - typer (2005年12月01日 22時28分45秒)
  • しかし、H.Holonさんが言っておられるのは、ページ生成時のURL生成コードが各所にあって大変そうだと言う事だと思います - typer (2005年12月01日 22時33分59秒)
  • search engineがひっかけてくれませんか?うちは、Yahooやgoogleから来る人が多いですけど。 - Kinsan (2005年12月17日 22時45分05秒)
  • クロールされますが、静的ページに比べてポイントは低くカウントされます。さらに、パラメータ部分が長いほど低くカウントされるようです。この辺はサーチエンジンによって違いますし、日進月歩変化してますので、ハッキリとしたことは言えません。 - あき (2005年12月18日 01時18分20秒)
  • 最近では、RSSフィードが、表示のための条件みたいな話も聞きますね。 - A_M (2005年12月18日 08時06分04秒)
  • BBS-サポート掲示板/470でも軽く触れたURL生成関数を必ず利用するように修正すれば、以降のURL生成コードは簡単に修正できそうですね。現在、標準で同梱されるプラグインについて修正を試みていますが、typer氏の仰るように膨大です。まだまだ時間がかかりそう。 - A_M (2006年01月04日 18時39分39秒)
  • URL生成もですがBugTrack-plugin/223への対応を考えるとリンク生成についても何かメソッドを作った方が良いかも知れませんね。ちなみに竹添さんは何か案をお持ちでしょうか? - typer (2006年01月04日 23時18分14秒)
  • wiki.cgi/page/ページ名のような形式はFarmと被ってしまうのでNGだと思います。もちろん/pageを予約にするなどすればOKなのですが、そもそもPATH_INFOを使った場合と、パラメータを使った場合とでは相対パスでのリンク先が変わってしまうので単純に切り替えできるようにするだけではダメかなと思ってます。せめて標準プラグインではURL生成関数を使用するようにしてmod_rewriteを使う場合など対応しやすいようにしておきたいところです。将来的にURLのカスタマイズを考える際の布石にもなりますし。 - たけぞう (2006年01月05日 00時58分27秒)
  • あと、BugTrack-plugin/223についてはあまり大袈裟な実装はせず、add_menuのオプションで指定するような方法を考えてます。今はメニュー項目などアクションの呼び出しは外部リンクと同じ扱いで、フォームなどから呼び出す際はPOSTメソッドで呼び出してますし、リンク生成関数を作っても使えないケースが多いんじゃないかなと思います。 - たけぞう (2006年01月05日 01時08分19秒)
  • 3.5.10においてURL生成関数を使えそうな場所を挙げてみました。確認が十分とは言えませんが、参考程度にアップロードいたします。 thinkingURL_euc.txt(1273) - A_M (2006年01月06日 07時32分53秒)
お名前: コメント:

3.5.10・・・ - kumaneko (2005年11月30日 22時36分34秒)

BugTrack-plugin/146のパッチあてでつまづいていて、いっそのことなら3.5.10のリリースを待つことにしていました。11月中にリリースとのことだったのですが、いつごろになりそうなのでしょうか?

首を長くして待っています。

  • BugTrack-plugin/146は3.1.10(まだ開発版との位置づけかもしれませんが)でコミットされているみたいですよ。SourceForgeでソースコードリポジトリのところからDL出来ました。ちなみに、ラジオボタンで変更できるようにしてくださっています。 - A_M (2005年12月01日 15時23分13秒)
  • ありがとうございます。先ほどダウンロードして来ました。早速使ってみたいと思います。 - kumaneko (2005年12月04日 11時34分41秒)
お名前: コメント:

FSWiki のテーブルで colspan と rowspan は使用できませんか - 名無しさん (2005年11月11日 14時20分54秒)

FSWiki のテーブルで colspan と rowspan は使用できませんか?
実装されていないようなら次回アップデートで実装して欲しいなと。
需要はないのでしょうか。
  • BugTrack-plugin/162を導入すれば使用できますよ。オプション一覧のところにある「COLS」と「ROWS」です。 - 名無しさん (2005年11月11日 14時33分27秒)
    • どうもありがとうございます。解決しました。既にプラグインがあったのですね。検索しても出てこなかったので。これは標準同梱して欲しいです。 - 名無しさん (2005年11月14日 14時37分46秒)
お名前: コメント:

管理画面を統一したデザインに… - A_M (2005年11月09日 06時26分06秒)

CMS向け拡張パックなどの動きもあるFSWikiですが、ログイン後の画面において、見出しのデザインやカラーリングなどが、選択したテーマに合わせて変化するため、大きくデザインが変わってしまいます。

このため、設置者ほどの知識はなくても、管理を担当するようなユーザを考えたとき、管理画面のデザインが統一されていれば、操作方法などの伝達も単純化され、多くの方に利用していただけるものに発展しそうな気がします。

この提案の発端は、ノリで作ってしまった「ブログライクテンプレート」によって、管理画面のデザイン上のばらつきが懸念される事にあります。

デザイン面においても自由度の高いシステムですので、このような問題も考えるべきなのかなと思い、投稿させていただきました。

  • とても重要な指摘をされているような気がするのですが、上手く伝わっていないかもしれません。具体的に「どういったことをした方がいい」と仰っているのでしょうか? 私は以前にtDiaryのテーマを取っ替え引っ替え試していて、フォームを見失いそうになったことがあります。あれ、かなりデザインが変わって、色や配置がとんでもないことになることがあるんですよね。例えば文字が全く見えなくなったり、ボタンが押せなくなったり…。単にこれを解決するだけでしたら、「管理画面に限ってはテーマを特定のもので固定する」という解決策があると思われますがいかがでしょう? 或いは、「そうしませんか?」といった提案でしょうか? - あき (2005年11月10日 02時15分52秒)
  • コメント有難うございます。「2通りの方法があるのかな」と思いました。1つは、あき氏の仰るとおりで「管理画面に限ってはテーマを固定」という方法。もう一つは、「Form部分に限っては、スタイルについてルールを設ける」という方法です。色々と思案中なのですが、編集画面で「プレビュー機能」がある点において、編集画面用の見栄えと、生成される確認用の見栄えとが混同してしまうように思うのです。こうした点についても、皆さんと一緒に打開策を模索したいというのものです。 - A_M (2005年11月10日 06時16分43秒)
  • 前後しますが、問題提起としましては、「統一しませんか?」ということです。雑談コーナーということで、脈絡の無さをお許しください。 - A_M (2005年11月10日 06時31分37秒)
  • 個々に作成されるテーマに「Form部分に限っては…」という条件を設けるのは多くの方への負担になるでしょうから、「管理画面に限ってはテーマを固定」とかの方が良いと思います。変更したスタイルを確認するには、「プレビューボタン」を設けてクリックすると別ウィンドウで事前確認とかできると良い気がします。事前確認できる機能っていうのは是非欲しいです。管理者がテーマを取っ替え引っ替え品定めしてる最中にユーザが訪れてきたら、ビックリでしょうから…。 - あき (2005年11月10日 21時38分28秒)
  • 別ウィンドウが、最も労力がかからなくて良いかもしれないですね。余談ですが、システム用の画面で言うと、大手のインターネットサイトが提供するブログなどは、管理画面が統一デザインとの事です。ヘルプドキュメントを作成しやすいからなのかもしれませんね。 - A_M (2005年11月10日 21時52分21秒)
  • とりあえず、思いついたのが次の2箇所を修正するパッチです。 - A_M (2005年11月24日 16時51分04秒)

管理画面では、admin というテンプレートとテーマがあれば、パラメータを修正して表示を変えてしまうというもの。

plugin/admin/Login.pm (62):

my $site_tmpl = $wiki->config('tmpl_dir')."/site/admin/admin.tmpl";
my $css = $wiki->config('theme_uri')."/admin/admin.css";
my $css_file = $wiki->config('theme_dir')."/admin/admin.css";
$wiki->config('css', $css) if ( -f $css_file );
$wiki->config('site_tmpl', $site_tmpl) if ( -f $site_tmpl );
my $buf = "<div class=\"admin\">\n<h2>ログイン中</h2>\n";

lib/Wiki.pm (537):

my $site_tmpl = $self->config('tmpl_dir')."/site/admin/admin.tmpl";
my $css = $self->config('theme_uri')."/admin/admin.css";
my $css_file = $self->config('theme_dir')."/admin/admin.css";
$self->config('css', $css) if ( -f $css_file );
$self->config('site_tmpl', $site_tmpl) if ( -f $site_tmpl );
	return "<div class=\"admin\">".$obj->do_action($self).
	       "<div class=\"comment\"><a href=\"".$self->config('script_name')."?action=LOGIN\">メニューに戻る</a></div></div>";
  • kitta氏の投稿したテーマ(051124_W_Lock.zip)をadminに改名して試用しましたが、横幅のブレもなく初心者でも混乱のない管理画面になりそうです。 - A_M (2005年11月24日 17時01分34秒)
  • ログイン公式Webサイト WebLOGiN 新刊案内 - xingyun (2005年12月03日 16時47分00秒)
お名前: コメント:

attachプラグインで大きなサイズのファイルが添付できない - 名無しさん (2005年10月24日 19時16分54秒)

バグとは言えないと思いますので、ここへ投稿します。サーバーのメモリ搭載容量が十分でない場合などに、attachプラグインで大きなサイズのファイルが添付できない場合があります。その場合、AttachHander.pmの50行目あたりを、

my $hundle   = $cgi->upload("file");
my $filecont;
while(<$hundle>){ $filecont = $filecont.$_; }

my $uploadfile = $wiki->config('attach_dir')."/".&Util::url_encode($pagename).".".&Util::url_encode($filename);

open(DATA,">$uploadfile") or die $!;
binmode(DATA);
print DATA $filecont;
close(DATA);

以下のように訂正することで、動作させることができます。

my $hundle   = $cgi->upload("file");
#my $filecont;
#while(<$hundle>){ $filecont = $filecont.$_; }

my $uploadfile = $wiki->config('attach_dir')."/".&Util::url_encode($pagename).".".&Util::url_encode($filename);

open(DATA,">$uploadfile") or die $!;
binmode(DATA);
while(<$hundle>){
    print DATA $_;
}
close(DATA);

以上。

  • 容量云々以前に、添付ファイルの内容をすべてメモリに取り込んでしまう従来の実装よりも改善案の方がいいように思えますね。 - gyo (2005年10月25日 10時26分26秒)
  • 上記改造案でも、改行コードが存在しなければ同じ現象が発生しそうです。while()文で1行毎に読み込むのではなく、任意の指定サイズ毎に区切って読み込む必要がありますね。 - あき (2005年10月25日 15時21分41秒)
  • readですね。青ラクダ本から:while(read $hundle,$_,16384){print DATA $_} - typer (2005年10月25日 20時39分38秒)
  • 今時のバッファサイズは幾らくらいが良いのかな? - typer (2005年10月25日 20時46分54秒)
  • 「今時」で言うなら、今回のようなリードをしながらのライトくらいでしたら、先読みやバッファリング出力が有効に働きますので、極端に大きすぎたり小さすぎたりしなければパフォーマンス的には殆ど変わらないはずですよ。上記のサイズであれば問題無いと思います。 - あき (2005年10月25日 21時39分01秒)
  • 修正しておきます。 - たけぞう (2005年10月26日 00時08分00秒)
お名前: コメント:

携帯電話での閲覧時に固定のフッタ - A_M (2005年10月20日 19時43分25秒)

4.0 の企画が上がっているので、雑談程度かと思いますが、tmpl/(template_name)/(template_name)_handyphone.tmpl に次のような1行を加え、

<!--TMPL_VAR NAME="COMMENT"-->

wiki.cgi に、次のリストのように加えると、携帯電話で閲覧時にもHandyFooter という特別ページをフッタとして固定表示できますね。

227. if ($is_handyphone) {
228.   # 携帯電話用処理
229.   my $handy_footer = "HandyFooter";
230.   if($wiki->page_exists($handy_footer)){
231.     if($wiki->can_show($handy_footer)){
232.       $template->param(COMMENT => $wiki->process_wiki($wiki->get_page($handy_footer)));
233.     }
234.   }
235.   $output = $template->output;
236.   &Jcode::convert(\$output,"sjis");

試してみると、編集モードでも表示されるので、詰めが甘いですが…。

4.0まで待ちきれない人向けの小話です。

  • 編集モードの時は「EDIT_MODE」がセットされているので、<!--TMPL_UNLESS NAME="EDIT_MODE"-->で対処出来ると思います。 - typer (2005年10月20日 23時57分26秒)
  • あ、ケイタイ時はセットされてなかった(^^; - typer (2005年10月20日 23時59分27秒)
  • なるほど。 ということは、"EDIT_MODE" をセットしちゃえば、出来そうかも知れませんね。 - A_M (2005年10月21日 03時01分04秒)
  • 上記の232行を if($action eq ""){ } で囲うと、編集時(?)に非表示になりました。 - A_M (2005年10月21日 06時22分23秒)
お名前: コメント:

bugtrackプラグインでBugList.pmで同じ内容の行は必要? - sige (2005年10月17日 20時41分30秒)

初心者なのでどこで問い合わせたらいいのかわかりませんでしたので雑談に書かせてもらいました。bugtrackプラグインでBugList.pmの93行目と94行目が同じ内容ですが、94行目は必要でしょうか?

    • 92行目 # サマリを作成
    • 93行目 my $bug_teian = 0;
    • 94行目 my $bug_teian = 0;
  • 要らないと思います。 - あき (2005年10月17日 22時29分56秒)
  • ご報告ありがとうございます。修正しておきました。 - たけぞう (2005年10月18日 00時45分18秒)
お名前: コメント:

[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 ]

最終更新時間:2014年08月28日 09時33分14秒