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

雑談掲示板

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

FSWiki雑談掲示板

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

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

ダウンロード・カウンターは定期的にクリアしている？ - 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
,列１の内容,<<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
,列１の内容,{{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独特の考え方で慣れるまで分かりにくいですし、確かに編集権限も参照権限も３段階で統一するなら、凍結機能そのものが不要になると思います。（何を隠そう、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をコマンドラインで立ち上げてシンタックスエラーを疑ってみたりするかもしれません(←僕の事だ)

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

Ｑ.投稿プラグインをアップロードしました。管理画面＞プラグイン設定で『プラグイン名は出ますが説明が出ません』、そしてインストールしようとするとエラーが出ます
Ａ.ディレクトリやファイルのパーミッションを確認してみましょう。例えば 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(1340) - 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秒)
  • コメント有難うございます。「２通りの方法があるのかな」と思いました。１つは、あき氏の仰るとおりで「管理画面に限ってはテーマを固定」という方法。もう一つは、「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秒)
  • とりあえず、思いついたのが次の２箇所を修正するパッチです。 - 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秒)
お名前： コメント：

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

メニュー

関連リンク

入門Wiki〜みんなで投稿/編集できるWebの作りかた

検索

キーワード

Google

Google

最新

2023/3/30

2023/3/29

2023/3/22

2023/1/31

2023/1/23

Copyright (C) 2002 Naoki Takezoe
Powered by FreeStyleWiki3.6.5 with Perl5.020002