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

雑談掲示板

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

FSWiki雑談掲示板

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

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

リファラー対応キーワードハイライト - Kinsan (2006年02月24日 20時59分27秒)

ちょっと勘違いから思いついたのですが、大手検索サイトで検索してたずねてきた場合にだけ、検索キーワードと同じ語句だけをハイライト表示してあげるってことは、やろうと思えば出来ますよね。

そこまで親切にしてあげて、見返りがあるかは別ですが(笑)。多分、その分表示も遅くなりますしね。

  • 話し全然違いますけど、ページを更新した時に更新部分をハイライト表示するってのも出来ないですかね - 名無しさん (2006年02月25日 01時37分47秒)
  • ページの途中を更新されるとどこが更新されたか分からないので、いつも差分を見てるんですよね。なんかボタンを押すと差分だけハイライトされるとか、更新された部分を一番上にも表示するとかあったら便利そう。 - 名無しさん (2006年02月28日 01時11分42秒)
  • これも話違うかもですがsearchでの検索結果もハイライト表示されるといいかもですね。ついでに先頭候補に移動するとか。 - 名無しさん (2006年03月24日 15時48分20秒)
  • BugTrack-plugin/235を使うと検索結果がハイライトされますがいかかでしょうか? - 名無しさん (2006年03月24日 16時11分12秒)
  • 単語単位ですが、私のサイトの方で、javascriptだけで対応して見ました。まだ、ベータ版のLayoutテンプレートですが、一応・・・自サイトのSEARCHプラグインと、Google,Yahoo の検索結果に対応できているかもしれません(笑)。切り出し等が雑なコードですので思わぬバグが潜んでいるかも・・・です。あと、入力エリアに任意の単語を指定してハイライトすることもできますです。まだまだ、テスト中・・・ - KG (2006年03月24日 21時57分11秒)
  • こちらでβ版として公開しました。現在機能追加予定ですので全ての機能の組込みが終わりましたら、当サイトにて公開します。 - KG (2006年03月27日 13時26分03秒)
お名前: コメント:

land.to の子wikiでrss - kitta (2006年02月12日 09時25分46秒)

land.toに設置して使っていこうかと思ってるんですが子wikiでrssに広告が挿入されて困ってます。以下二つをすると

「.htaccess」ファイルを設置し、これ以下のフォルダに広告を表示させないファイル形式を設定する。

LayoutIgnoreURI *.cgi

自動挿入を停止したいファイルの任意の箇所に「<!--nobanner-->」タグを挿入する。

を.htaccess テンプレートに行ったんですが親wikiだとrss正常なんですが 子wikiだとrssに広告が入っちゃうんです。

"広告について"を見ると

perl用

require "/ad/bn.cgi";

こんな方法もあるみたいなんですが Perlがよく分からないんでこれは試せていません。どなたか教えていただけないでしょうか?

  • LayoutIgnoreURI *.cgi を *.* にしておけばいいですよ。 - KG (2006年02月12日 09時49分27秒)
  • おぉ なるほどぉ 試してみます。 - kitta (2006年02月12日 09時50分27秒)
  • それって、やっていいのかな?規約上、禁止なんじゃ...。 - 名無し (2006年02月12日 09時54分23秒)
  • 完璧です。*.*とは思いつきませんでした。ありがとうございました。 - kitta (2006年02月12日 09時54分43秒)
  • 全頁で広告が入ればいいんでしょ?問題ないんじゃないでしょうか? - KG (2006年02月12日 09時58分17秒)
  • 自動で入れる広告を 読み込まない様にする事を 禁止してないので、.htaccessを*.*とし任意の位置へ広告入れば良いはずです。 - kitta (2006年02月12日 10時17分01秒)
お名前: コメント:

ドキュメントのフロントページが書き換えられているようです - ZON (2006年02月09日 11時00分23秒)

TipsからたどってFSWikiドキュメントを見に行ったら、フロントページとキーワードが書き換えられているようです。

docs:FrontPage

docs:Keyword

こんな感じの内容

弊順宣脂利
-喇嶄忽遍社 宣脂
巷望?貧今略秤斌暦徂儂嗤?巷望幹一?巷望奥覚^
廨匍略秤?廨冩宣脂?廨匯捲暦 ̄議娼舞蝕婢?購宣脂捲暦
?宣脂亅咏?宣脂徂儂?宣脂夏恢蛍護?鞭欺阻芙氏才箪悶
議挫得。埋隼ゞ脂咆隈〃及膨噴鎗訳号協阻斤噐
宣脂 鱒墾唐灰議癖喘訳周?徽糞樹嶄?喇噐宣脂鱒墾唐灰叙
冢鯉癖喘噐揖肖、嶷脂、社優羽薦
……以下省略、URLは省きました。

書き込まれているリンクは触っていませんが、フロントページなので元に戻すオリジナルが分からなかったので、こちらに報告します。

お名前: コメント:

FSWiki_liteについて - 名無しさん (2006年02月07日 15時25分30秒)

FSWiki_liteはもう更新されないんですかね・・・Shift_JISでの出力は期待しているところなんですが・・・

  • 私はFSWiki_Liteにパートエディットプラグインが出来れば嬉しいなと思っています。 - 名無し (2006年02月08日 10時57分11秒)
お名前: コメント:

Wikiのメニューとページのメニュー - ゑ (2006年02月05日 01時12分32秒)

Wikiに対するメニューと、Wikiのページに対するメニューが混ざっているのが納得できない。別々にして欲しい。

wiki{トップ 新規 一覧 Farm 検索 ヘルプ RSS ログイン}

page{編集 差分 ソース PDF}

  • トップ 新規 一覧 Farm 検索 ヘルプ RSS ログイン 編集 差分 ソース PDF という順が理想でしょうか? 「新規」はこの位置で宜しいですか? 「ログイン」は一番最後が収まりが良い気がしていたのですが、このように分けた場合、中の方に入ってしまいまが、特に違和感はありませんか? - あき (2006年02月23日 08時15分54秒)
  • この話題に関連するようなことをたまたま昨日・今日と考えていたのですが、Wikiらしい作りを推し進めるならば、ページレイアウトもInterWikiのようにあるページに記述するだけで変更できていいと思う。FreeStyleWikiでは現在、Menu, Header, Footerなどがデフォルトで配置されているが、そこらを簡単に自由にしても良いと思う。この質問を今日見るまでは右上のメニューのことまでは考えていなかったのですが、InterWiki的なやり方でその配置と表示される文字列も自由に変えれるようにしてはどうでしょう。 - Kinsan (2006年02月23日 23時17分47秒)
  • とても興味深い提案ですね。このスレッドの本題からは脱線してしまいますが…。実はA_M殿がこれに近いことにチャレンジしてくれています。サイドバーを左右どちらか一方、というのだけには飽きたらず、両方に配置。さらに、それらをテンプレートで切り替え可にしてしまおうというものです。(BugTrack-sitetemplate/4か又は、この辺りかな?)私はそれを見て以来、xoopsのレイアウトが自由に変えられる仕組みをFSWikiに転用できないか、ずっと考えていました。「InterWikiのように…」というのは管理者以外もレイアウトを変更できてしまうわけでちょっと問題かと思いますが、管理画面で変更できる仕組みにすることは十分実用的で需要も大きいと思います。同じ管理者なら、テンプレートファイルも弄れるというものですが、やはりファイルを直接編集するのと、ブラウザ上から変更できるようにするのとでは随分と使い勝手が異なります。実装する価値は十分にあると思います。ですが、新たな実装手段を考えるまでしなくても、レイアウトの配置される場所毎に固定のページ名を決めておいて、その名前のページを作成したりリネームしたりすることで様々なページレイアウトを楽しめるようなのにするくらいなら、専用のテンプレート(とテーマ)を作成するだけでも実現できてしまいそうです。

Header,Footer,Menuを全ページ共通で配置させているのは、テンプレートでそのように定義しているからです。HeaderというページをFooterという名前にリネームすれば配置が上部から下部に移動します。これの延長で、Left1(左サイドバー1段目)、Left2(左サイドバー2段目)...、Right1(右サイドバー1段目)、Right2(右サイドバー2段目)...、CenterLeftTop(中央左上段)、CenterRightTop(中央右上段)、CenterLeftBottom(中央左下段)、CenterRightBottom(中央右下段)のように配置されるテンプレートを作成しておけば、似たようなことはできるのかな、と…。

  • このテンプレートにベストマッチするテーマを作成しようと凝り始めると本当に時間がいくらあっても足りなくなってしましそうですが、こういった仕組みを考えること自体は意外と楽しいものかもしれません。 - あき (2006年02月24日 00時45分44秒)
  • 別スレッドにした方がいいかな? - あき (2006年02月24日 01時45分06秒)
  • メニュー部分は、実装の仕様があるにも関わらず微調整できるメニューアイコン・プラグインを活用すると幸せになれたように思います。ところで、他のCMSの殆どがTABLEでレイアウトしていますよね。個人的に「スタイルシートを使わないときに、どういう流れの文章になるか」というのもWikiらしい視点だと考えています。 - A_M (2006年02月24日 06時28分37秒)
  • FSWikiの隠し機能として、登録済みのページをテンプレートとして、新規ページを作ることが出来ます。この機能などを利用するためにも、メニューセットを複数使い分けれると良いと思います。また、サイドメニューを表示しないモードってのは、印刷のために前からある需要ですよね。 - Kinsan (2006年02月24日 08時01分57秒)
  • cssファイルを簡単に作成し、使い分けれる仕組みも欲しいですね。 - Kinsan (2006年02月24日 08時07分37秒)
  • ここで指摘されているメニューに関しては、メニュー項目の属性(Wiki or Page)か何かの情報を付加しないと解決は出来ないでしょうね。その情報さえあれば、混在させたり分割させたりすることも可能になると思います。属性の追加だけであれば、iconmenu で設定できるようにすることも可能ですね。あとは、プラグイン形式で wikimenuプラグインは存在しません。 とか pagemenuプラグインは存在しません。 とか指定して表示できるようにするなどの方法が考えられます。 - KG (2006年02月24日 10時24分35秒)
  • 自動で振り分けようとすると属性情報が必要でしょうけども、ユーザーが自由に簡単にメニューを変更できるならば、自動振り分けは不要だと思います。 - Kinsan (2006年02月24日 17時54分17秒)
  • メニューを自由に変更できるというと、例えば {{menu メニュー項目[,メニュー項目][,....][,v]}}というような指定で、指定されたメニュー項目が表示可能であれば表示する。さらに、vオプションが指定されたら縦に表示する・・・などのような機能? - KG (2006年02月24日 19時15分02秒)
  • 上で書いたように、InterWikiのようにある特定の書式で、ある特定の名前のページを作ると、それがトップメニューにあるという仕組みが良さそうに思います。そのページに、表示される文字列とそのリンク先となるACTIONまたはURLを組にして記述するってことでどうでしょう。

例えば、下記のような感じでTopMenuというページに書き込むことにしてはどうですか。

:トップ:page=FrontPage
:新規:NEW
:一覧:LIST
:検索:SEARCH
:ヘルプ:page=Help
:RSS:RSS
:ログイン:LOGIN

- Kinsan (2006年02月24日 20時33分00秒)

  • Kinsanさんの仰るような方法(メニューも別ページ)は前から考えていたんですけど、プラグインを新しくインストールしたときに自動でメニューが出てきたほうがいいかなぁ、ということでそのままにしてます。実は作りかけ(放置中)のJava版では別ページでメニューの内容を定義できるようになっています。 - たけぞう (2006年02月25日 09時24分19秒)
  • メニューに関しては、私は新たな仕様は不要だと思います。A_M殿もコメントされてますように、Wikiメニューにアイコン画像を表示するプラグインがありますので…。冒頭で私が最初に質問したのはCMSパックでこの辺りの順番をちょっと弄ってみたいな、と思ったためです。 - あき (2006年02月27日 13時18分03秒)
お名前: コメント:

ダウンロード・カウンターは定期的にクリアしている? - KG (2006年01月23日 19時59分38秒)

当サイト(本家fswikiサイト)において、ダウンロードカウンターが定期的にクリアされているようですが・・・これは意図した動作なのでしょうか?というか、手作業でカウンターをクリア(上書き?)されているのでしょうか?

投稿プラグインの利用頻度などの目安になるので、できればカウンターはクリアしない方がよいのですが・・・。

  • 言われてみれば最近頻繁過ぎるくらいにクリアされますね。3.5.9になった辺りから、頻度が増した気がしますが気のせいでしょうか?最近は更に更に、といった感じがします。 - あき (2006年01月23日 22時20分28秒)
  • ファイルが壊れているのかもしれないですね。次のバージョンでは設定ファイルの読み書き全般にファイルロックを実装しようと思います。 - たけぞう (2006年01月24日 11時58分57秒)
  • 了解しました。意図的ではなかったのですね。てっきりメンテナンス時に上書きしてあるのかと思ってました。対応の方よろしくお願いします。 - KG (2006年01月24日 22時31分57秒)
  • FSWiki - A_M (2006年01月26日 21時02分54秒) あれ、こんなところでSUBMITしていました。特に意味は無いです f(^^;
お名前: コメント:

XML on Wiki - Kinsan (2006年01月11日 15時15分09秒)

構造を持ったデータをWiki上で管理するならば、やはりXMLを使うのが良さそうですが、XMLって人間が書くには不向きです。

Wiki記法の拡張でXMLが扱えたらって思って、ちょっと探してみたのですが、YAMLっていうフォーマットがWiki記法に馴染みやすそうです。

YAMLを扱えるブロック型プラグインを作り、そのプラグインを実行すると、Wikiページの他にXMLデータを別ファイルに保存するようにすると良さそうです。

あとは、XML用のCSSを簡単に作れる仕組みを用意すれば、構造を持ったデータをWiki上で入力・編集及び表示することが出来ますね。

  • YAMLのフォーマットについてナナメ読みしてみました。確かにXMLにも対応しやすい印象を受けています。XMLへのアプローチとして面白そうだとおもいます。 - A_M (2006年01月13日 21時45分47秒)
お名前: コメント:

HereIs構文 - Kinsan (2006年01月06日 00時01分24秒)

FSWikiを含めて一般的なWikiでは、行を単位とし、行頭文字でブロック型の書式を指定する文法を採用し、複数の種類のブロック型の書式を同時に指定することが出来ないことがほとんどです。

このため、例えば表の一つの欄に、複数の段落からなる文章を入れるなんてことが出来ません。

Wikiに装飾的な表現能力を持たせるべきではないと、私も思いますが、論理構造的なものを表すのに必要な表現能力は欲しいと思います。

今月の『Software Design』のWikiつまみぐいに書かれていた増井さんの記事の中でシェルやPerlのHereIs構文と同じ文法を使っている例が出ていて、それを読んで気付いたのですが、HereIs構文を採用すれば、Wikiの標準的な文法からそれほど変更せずに、上記の問題が解決可能です。

つまり、下記の様な入力を処理できるパーサーにするのです。

,列1,列2,列3
,列1の内容,<<EOF1,<<EOF2
これが列2の内容です。
EOF1
これが列3の内容です。

途中で段落を分けても処理できるようにします。
EOF2

この様なHereIs構文による書式のネストを許す場合には、HTMLやXHTMLは元々書式がネストする構造なので、各パーツを処理する部分は変更せずに済みますが、パーサーの全体は大きく修正する必要がありそうです。

これが出来るようになると表現能力が増しますし、整形済テキストにおいて各行の先頭にスペース文字を加えなくても良いことに出来るなどの副次効果もあり、非常に魅力的なのですが、パーサーの改造が大変そうです。

そういう意味で本件は提案ではなく、雑談です。

  • 表内に複数行を記述できる機能とかは是非欲しいですね。includeプラグインをパラグラフではなくインラインで作成すれば、現在の仕様の延長でも一応は実装できそうな気がします。インクルード時にパート指定なんかができると余計なページをいくつも作成する必要がないので比較的スマートな実装になるのではと…。それとも、「他のページから読み込む」という考え方そのものが分かり辛いでしょうか? - あき (2006年01月06日 07時33分36秒)
  • HereIs構文の採用は、Wiki文法に関しては、現在の仕様の延長になります。書式のネストの実現方法として、行単位のプログラミング言語からブロック単位のプログラミング言語への発展をヒントに、括弧などでブロック構造をとる方法も考えついたのですが、標準的なWikiの文法とは相性が悪いです。いずれにしても、パーサーを大きく改造しなてはいけないであろう点が、ネックです。それを考えると、HereIs構文を既に使っているところが、さすが増井さんだなって思います。(現在の携帯電話の漢字変換方式を考案したのが増井さんだったと思います。) - Kinsan (2006年01月06日 20時39分19秒)
  • 上の例を見ての感想ですが、効率的に書けるのは分かるのですが、プログラマー向けの記法である気がします。一般ユーザには、どの行からどの行までがどの列に対応するのか分かりにくいのでは?ということで記法についてはもう少し吟味した方がいいかもです。例えばこんな感じに…。(あくまで例です。もっと良い案があれば是非…) - あき (2006年01月07日 01時50分48秒)
,列1,列2,列3
,列1の内容,{{expand col2}},{{expand col3}}

<col2>
これが列2の内容です。
</col2>
<col3>
これが列3の内容です。

途中で段落を分けても処理できるようにします。
</col3>
  • 上記のあきさんの例を汎用化したようなものを以前にMLで提案したことがあります。そのときの結論は「わかりにくい」であったと思います。標準でサポートされることはないんだと思います。しかし「複数行マークアップ」にはこうした根強い需要があるのは確かでしょうね。3.5系で使える複数行プラグインもありますし。ポイントは誰にとって必要な機能なのか?を考えることにあると思います。今回のTABLEのケースでは、添付のCSV形式ファイルをTABLEに変換するプラグインがあったら代替可能でしょうか? - いしだなおと (2006年01月07日 22時12分57秒)
  • 繰り返しになりますが、執筆者が表現したい論理構造を表現する手法は、Wikiで提供されるべきだと思います。その点において、行を基本としたWikiの標準的な文法により、ブロック型書式をネストして複数指定することが出来ないという制限につながっていることに対して、解決策を求める人がどの程度いるか聞いてみたいと思います。 - Kinsan (2006年01月10日 12時01分37秒)
  • ブロック型プラグインを利用して試しに作ってみました。書式は異なりますが、こういうのでよろしいのでしょうか? - KG (2006年01月11日 02時02分21秒)
  • いいですねぇ。決して解りにくくはないです。同一ページ内で同じkeyが使い回しできるのも、別の用途としても使い道があると思います。inskeyとinsvalっていうプラグイン名も分かりやすくていいですね。ところで、これ、insval内にinskeyを記述したりするとどうなるんでしょう?ネストは無視ですか?それとも一度だけ展開? - あき (2006年01月11日 13時44分35秒)
  • ネストはやってみたんですが、上手く動かないです。でも、きっと対応してみせます(笑)。もちろん insval で指定したキーと同一キーは無視するようにする予定です。 - KG (2006年01月11日 13時59分03秒)
  • 私も見ました。ネストした時(例えば、表の1つのセルに箇条書きを入れ、箇条書きのそれぞれの項目が複数の段落からなる場合)には、ちょっと分かり難く、論理構造に則した表現がし易いというWikiの特徴からは外れる気がしますが、使い易そうですね。(これが出来るってことは、FSWikiのパーサーを修正して、HereIs構文に対応させるのも簡単? いずれにしても、ネストの処理が大変そうですね...) - Kinsan (2006年01月11日 14時35分23秒)
  • ネスト処理の組み込みがほぼ完了しました。近々アップしたいと思いますが・・・複数行対応プラグインも同時にバージョンアップしますのでよろしくお願いします。CacheParser周りの対応部分のコミットがリリース(3.5.11?)されるまでは、該当箇所の修正は複数行対応プラグインで対応します(詳しくはMLを参照してください)。 - KG (2006年01月11日 20時09分19秒)
  • BugTrack-plugin/248 にて insert プラグイン として公開いたしました。 - KG (2006年01月14日 03時05分35秒)
お名前: コメント:

ページの編集権限を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秒)
お名前: コメント:

[ 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 ]

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