差分

このページの2つのバージョン間の差分を表示します。

--- dokuwiki_tips [2018/09/11 09:05] – [名前空間の使い方] 管理者
+++ dokuwiki_tips [2018/09/11 10:02] (現在) – [名前空間の使い方] 管理者
@@ 行 1: / 行 1: @@
+[[start]]＞[[dokuwiki_start]]
+====== DokuWiki アドバイス ======
+DokuWikiは色々な使い方ができるので最適なアドバイスとならないかもしれませんが、私が使っていてこうした方が良いと思った事を書き出しておきます。
+----
+===== ファイル名の付け方 =====
+==== 単語の場合 ====
+ウィキは文書に「%%[[ ]]%%」だけで内部リンクができるようになっているのでページ名は<fc #9400d3>単語そのままが良い</fc>です。
+<code>例文：[[日本]]の初代[[内閣総理大臣]]は[[伊藤博文]]である。</code>
+>例文：[[日本]]の初代[[内閣総理大臣]]は[[伊藤博文]]である。
+ただし日本語でのリンクは一部のブラウザやWebサービスでURLエンコード(例：日本→%E6%97%A5%E6%9C%AC)される点は留意しなければなりません。
+外国人向けの内容でURLが英字しか使えないローカルルールがある場合は、サイト設定で「最初の見出しをページ名とする」を「常に使用する」にして__ファイル名は英語__として__日本語の見出しをページ名__とする方法もあります。しかし編集する人は下記のような意味不明な文書を書かなければならないので大変です。
+<code>例文：[[japan]]の初代[[prime_minister]]は[[hirohumi_ito]]である。</code>
+各ページの見出しが、japan=日本、prime_minister=内閣総理大臣、hirohumi_ito=伊藤博文、となっていれば表示は。「[[日本]]の初代[[内閣総理大臣]]は[[伊藤博文]]である。」になります。
+==== 文書の場合 ====
+文書や見出しそのままファイル名にすると文字数が多くURLが長くなったり、リンク時にも長い文書を入力しなければならず使い勝手が悪くなるので、キーとなる単語を2～3個使い<fc #9400d3>省略したファイル名にする</fc>のが良いです。
+例えば「DokuWikiのインストール方法」の場合は「dokuwiki_install」などとします。
+----
+===== 名前空間の使い方 =====
+名前空間(ネームスペース)はWindowsのフォルダのような物で、名前空間が違えば同じファイル名が使えたり編集権限を一元管理できるようになります。
+DokuWikiの使い方にもよりますが、<fc #fa8072>Windowsのフォルダ管理と同じ考え方はNG</fc>です。多くのWindowsユーザーはフォルダ内にファイルが多くなると見やすくするため日付・内容・カテゴリなどでフォルダを細分化していると思いますが、ウィキでは通常使用する<fc #ff00ff>名前空間は<del>1つだけのほうが</del>(※)少ない方が良い</fc>です。（※サーバーの性能にもよりますが1つの名前空間に1万近いページがあるとサイトマップ表示などで速度が低下するので少し分類した方が良いみたいです。2018/08/28追記）
+理由はウィキの内部リンクにあります。名前空間が同じなら ''%%[[ページ名]]%%'' でリンクできますが別の名前空間の場合は ''%%[[名前空間:ページ名]]%%'' となります。
+例えば、単一の名前空間であれば下記のように書き方で内部リンクできます。
+<code>
+例文Good：[[日本]]の初代[[内閣総理大臣]]は[[伊藤博文]]である。
+</code>
+しかし名前空間を多用した場合は下記のように書かなければなりません。
+<code>
+例文Bad：[[国家:日本]]の初代[[役職:内閣総理大臣]]は[[人名:伊藤博文]]である。
+</code>
+一つの名前空間に文書が多くなると目的のファイルを探すのが大変になるのではと思うかもしれませんが、ウィキではファイルが直接見える場面はほとんどありません。「わかりやすいページ名」にし「目次の作成」や「検索用キーワードの登録」など心掛ける事で目的の文書に簡単にたどり着く事ができます。
+世界最大のインターネット百科事典「Wikipedia」を見ても名前空間はヘルプや公式発表ページなどで一部でしか使われおらずメインの用語辞典では名前空間は使っていません。
+では名前空間はどんな場合に作るべきかと言うと
+  * 名前空間単位で閲覧編集権限を与えたい時（会社などの部署単位で権限を分ける時）
+  * 一つの名前空間で完結する内容で、他の名前空間にリンクしない/されない時。
+  * 同名ファイルができやすい状態。
+  * トレース(パンくず)を使いたい時
+  * ウィキとして使わない時(ブログとして使用するなど)
+----
+===== メディアファイルは別の名前空間で管理 =====
+DokuWikiでは文書作成中に画像やファイルなどのメディアファイルをアップロードすると文書と同じ名前空間に保存されますが、<fc #ff00ff>文書とは別の名前空間で管理</fc>した方が良いです。
+つめの理由はメディアマネージャーとアップロード画面のサムネイル(縮小画像)表示です。メディアマネージャーやアップロード画面を表示すると名前空間の全画像が縮小表示されリスト化されますが、<fc #fa8072>画像が多いと縮小画像であってもダウンロードや表示に時間がかかる</fc>ようになります。最適な枚数はサーバーや編集環境によって異なると思いますが私の環境では画像300枚越えたあたりでサムネイル表示の遅さを感じたので<fc #ff00ff>1つの名前空間に画像は200枚以下</fc>になるよう細分化するのが良さそうです。
+つめの理由は<fc #fa8072>アップロードは権限が高い</fc>事です。DokuWikiのアクセスコントロールは「読取→編集→(新規)作成→アップロード→削除」の順なのでユーザーにアップロード権限を与えると文書の新規作成もできるようなります。文書作成を制限したままアップロード権限を与えたい場合は<fc #ff00ff>アップロードはアップロード専用の名前空間だけ</fc>にする事で文書用の名前空間を守る事ができます。この状態でもアップロード用の名前空間には文書の新規作成ができますが他の文書が無いので発見と削除が容易です。
+つめの理由は<fc #fa8072>メディアファイルは文書からリンクが1つでもあると削除できない</fc>仕組みだからです。何らかの理由(部署の統廃合など)で文書を別の名前空間に移動する場合に、自分に編集権限の無い文書からメディアファイルにリンクがあるとファイルを削除できません。こういった事態にならないため<fc #ff00ff>メディアファイルは生涯変更しない名前空間で管理</fc>した方が良いです。
+次のような名前空間で管理するとよいと思います
+  * 1.表示が遅くなったら新しい名前空間を増やす(file001～file999)
+  * 2.アップロード頻度が月100枚程度なら月単位(file2001_01)
+  * 3.旅行などでアップロードが多い場合は個別にする(file_20010101_usa)
+  * 4.アクセス管理するならユーザー名やグループ名など(file_username)
+  * 5.上記の複合パターン
+問題点は、DokuWikiではメディアマネージャーの<fc #ff0000>ファイル名検索でしかファイルを探せない</fc>ので、本稿の管理方法を使っても使わなくても、ファイルが多くなると特定のファイルを見つけ出すのは難しくなります。対策としてはファイル名に検索用のキーワードを入れるか、文書としてファイル名・内容・キーワードなどをリスト化したファイル目録を作成して管理するなど対策が必要です。
+----
+===== 内部リンクを作る =====
+WordPress等のブログには、トップページやカテゴリページの作成やページ送りや戻りなどページ間のリンクを自動で行ってくれますが、ウィキにはそのような機能が無く内部リンクは自分で作成する必要があります。
+文書を作成する場合は
+  * 既存文書から必ずリンクを作る
+  * 新しい文章から目次や前のページに戻れるようリンクを作る
+複数ページにわたる文書を作成する場合は
+  * 見出しや目次ページの作成（１ページ目に統合してもよい）
+  * 個々の記事にページ送りや戻しのリンクを作る(内容に順番が無い場合は不要）
+  * 見出しにはトップページに戻るリンクを作る
+などが必要です。
+はじめは面倒に感じますが慣れてしまえば気にならないと思います。
+----
+===== プラグインは厳選しましょう =====
+足りない機能を補ってくれるプラグインですが、プラグインは開発が止まったりバグで利用できなくなったりDokuWiki本体のバージョンアップの影響で動作しなくなる事がありますので、下記の点の注意してインストールした方が良いです。
+.プラグインをアンインストールしても通常動作に影響が出ない物を選ぶ
+文書に手を加えない入力支援や管理者専用のプラグインであればアンインストールする事態になってもフロント側のWebサイトには影響が出ません。
+.使用範囲が少ない物を選ぶ
+専用タグなどで文書を加工するタイプで使用範囲が広いと、アンインストールする事態になった時にタグを削除するなどの修正が広範囲に及び修正作業に時間がかかります。使用範囲がトップページやサイドバーなど限られた場所だけであれば修正も簡単に終わります。
+.利用者が多く定期的にバグの修正が行われているプラグインを選ぶ
+目安でしかありませんが利用者が多ければバグは不具合の発見が早く、バグ修正が行われてるならDokuWiki本体やPHPのバージョンアップ時でも継続して使える可能性が高いです。
+.上記の3点に関係なくプラグインを多く入れれば、それだけセキュリティリスクやバグなど発生しやすくなりますので
+、本当に必要なプラグインだけ入れるのが良いです。
+----
+[[start]]＞[[dokuwiki_start]]