WIKIWIKIユーザー助け合い掲示板

こちらは主にユーザー同士の情報交換や問題解決に向けた掲示板です。
運営が閲覧・回答している以下の掲示板に再度、書き込みされてみてはいかがでしょうか。
リクエスト広場 https://zawazawa.jp/wikiwiki-request/

もし不具合ならば、運営さんは早急な対処をよろしくお願い致したいです。

特に決まりはありませんが、最初にやった方が良いと思うのは
FrontPageの体裁を整えることですね。

初期状態では、編集者（特に登録ユーザー）向けに幾つか注意事項が並んでいますので、
目を通したら、あなたのwikiに合った内容に書き換えてください。
訪れた人が、FrontPageを一見しただけで、何のwikiか理解しやすいのが好ましいです。

時々初期状態をそのまま放置している人がいますが、
訪れた人が面喰らうだけなので、放置は止めた方が良いです。

FrontPageを編集したら、次はMenuBar（左サイドメニュー）を編集してみましょう。
MenuBarは、しおりを兼ねた、そのwikiの全体目次のようなものです。
作りたいページタイトルをMenuBarに書き出しておき、
後はタイトル末尾の?をクリックして順にページ編集していけば良いと思います。
具体的なやり方はさんぷるwikiに書いてあるので参考にしてください。

…と言いたかったのですが、
よく見ると汎用の解説ページへのリンクが貼ってあるだけなので、
初心者には一部解り難い部分があるかと思われます。
（運営さん、ココの記事は初心者向けに少し書き直した方が良いですよ）

ちなみに上記さんぷるwikiの「MenuBarを編集しよう!」は、
①wikiツールバーにある「サイト内検索」で「MenuBar」ページを探す
②MenuBarページを編集する
という意味です。

次回からはいちいち検索からMenuBarページを呼び出さずに済むように、
MenuBar自体にアクセスリンクを付けておくと良いかもしれません。
（やり方は上記ページの「MenuBar編集画面へのリンク～」に書かれています）

wikiのリンクを書いてほしいです。みんなが協力できるようになります。

訂正。:config/AutoLinkはサイトによっては最初からはないかもしれません。
以下のサンプルページを参照して、同様に作ってみてください。
リンク

特定の単語をAutoLinkから除外できます。各サイトにある以下のページにやり方が書いてあります。

:config/AutoLink

AutoLinkはwikiwikiとして非推奨方針なのは変わってはいないでしょう。
非推奨な主な理由はServerに負担がかかるからです。AutoLinkは編集したページ内容に対して、サイトの全ページ名が列記されたような辞書を参照して、一致する文字列を探し出してリンクを掛けてくれます。編集した文字列の量 ｘ 存在するページ数みたいな関係で負荷が増大するでしょう。そしておそらく新規ページが作られるたびに辞書が更新され、既存の全ページに対してこのやり直しが入ります。
しかし逆を言えば、同様のことを人間がやろうとすればもっと大変なわけです。
ページ数が多いサイトの場合、関連する単語を手動で[[]]で囲うのはとても手間がかかります。またソースも[[]]だらけになって見づらくなります。そもそもどの単語のページが存在するかなんて把握しきれず、どこに[[]]かけるべきなのか判断しきれません。
また新規ページが増えた場合、そのページへのリンクを既存の大量のページに対して見直すことになります。
ページ数が多いサイトほどAutoLinkは活躍します。

除外ページ指定は正規表現で記述します。
"A|B|C"と書けばA,B,Cいずれかの文字列を含むページがヒット(プラグインとしては除外)します。
"コメント"と書けば"コメント/～"みたいなページは表示されなくなります。
半角記号を含ページ名は書き方に注意が必要です。詳しくは正規表現を調べてください。
また表示件数を指定する必要があります。省略はできません。

#popular(20,FrontPage|ページ2|ページ3)

ちなみに高機能なpopularxは導入されていません。
sonotsさんのシリーズは優秀なのでご検討いただきたいです。

これあちこちで起きてるみたいですね。私が利用しているwikiでも同じ報告がありました。

教えていただいた内容で解決できました。ありがとうございます。

serach機能ではできません。正規表現が使えればいいのですが、使えません。
可能性としてはgoogleのサイト内検索を使えばできるかもしれません。
googleで以下のように検索してください。

site:wikiwiki.jp/あなたのサイト名 "あいうえお"

サイト名の後は半角スペースで区切ります。ダブルコーテーションはなくてもいいかもしれません。

通常のgoogle検索はInternet上のあらゆるサイトを対象にしますが、上記のように書くと検索サイトを限定できます。
今回は//コメントをヒットさせたくないわけですが、これはwikiのソース上に書かれておりhtmlに変換されたあとは表に出てきません。
googleはソース文は見れないので結果的に//コメントはgoogleの検索対象になりません。
ただしgoogleはリアルタイムで全文検索してるわけではないでしょうから信頼性に欠けるかもしれません。

またInterwikiを使えばwiki上の入力Boxから同じことができます。
Interwikiについては以前書いた次のページをみてください。
Interwiki

ないのですか、返事ありがとうございました。
地道に削除＆添付頑張ります...

利用者がwikiwikiにプラグインを実装する方法はありません。
具体的に使いたいプラグインがあればwikiwikiに対して要望なりアピールすれば検討してくれかもしれません。
荒らしについては私も過去に対応したことがあり、今回の件に関連させてあればよい機能を話題に上げました。
直接あなたの件に向けたコメントではないです。

回答ありがとうございます。コメントはpcommnetになります。
zawazawaコメントは埋め込み廃止になったと伺っていましたが、wikiwikiは例外なのは存じませんでした。
とは言え、大したコンテンツではないため、荒らしが頻繁に訪れる訳ではありませんので、
実装するかは検討とします。
編集時刻制限に関しては、ご推察の通り、運営が負担になっているのは事実ですが、
編集して頂いている多くの方々がいる中で、私個人の都合に合わせる訳にはいきません。
心配なのはあくまでも、設定したのに規制されないという点になります。
何かしらの仕様(適用に時間がかかる、複数合致するとバグですり抜けるなど)
が存在するのかなと質問させて頂きました。まぁ無いと思いますが…
ちなみにwikiwikiにプラグインが実装出来るとは存じませんでしたが、
何かしら参考になるサイト等はありますでしょうか。

荒らしの話題に関連して。
管理機能として各Wiki毎の運営時間を指定できるようになると管理の負荷が下がると思います。
ずっとPCの前で構えているわけにはいきませんし、寝るときや不在のとき心配になります。wikiの管理者といっても余暇でやってる人がほとんどでしょう。
管理に時間を取られたり気を揉んだりするとwiki運営が負担になってきます。継続性やwikiとして採用されるためにはwikiの機能が管理者の視点で充実してることが望ましいです。

例えば就寝時間の22:00-8:00は書き込み禁止、毎週何曜日は不在なので書き込み禁止とか。
現在の編集制限は今から何日までは指定できるようですが、これも予め期間で指定できるとよいです。何日から何日まで旅行で不在とか。
編集制限が一般にわかるようにスケジュールの状況を表示するページやプラグインもあるとよいです。

また一般編集者が現在どのような制限が掛かってるわかるように、各ページのどこかに現在の制限状況が表示されると良いです。編集ボタンにバツがつくとか。HTML convert timeの横あたりに表示がでるとか。編集ボタンを押す前に分かったほうが無駄がないです。
ただ荒らしに対しては事前に編集可否がわかってしまうので、編集状況の表示は管理メニューでコントロールできたほうがよいかもしれません。

原因はわかりませんが、コメントはpcommnetですか。
その情報だけだと原因は誰もわからないでしょう。具体的なページや情報が書きにくければwikiwikiに直接問い合わせたほうがいいでしょう。最近あったアップデートに関連があるかもしれませんし。
またこの機にzawazawaのコメントを検討してみるといいかもしれません。あっちはあっちで管理機能が充実してるようです。

複数ファイルを同時に選択してアップロードする方法は、たぶんないです。
添付にしたいページの添付ボタンから一つずつやるのが早いと思います。

回答ありがとうございます。
ご指摘頂いた箇所を修正して機能するようになりました。

%（半角パーセント）を％（全角パーセント）に変えると機能します。
tablesortは対象文字列に%が入っている場合、数字として並べ替えを試みることが原因です。

回答ありがとうございます。理想的な形にまとめることができました。

注釈は相互リンクになっているため、
対称でないとリンク衝突が発生してしまいます。

非対称にしたいなら注釈ではなく、
アンカー（anameプラグイン）を使用すれば良いのではないでしょうか。
（勿論片道リンクになります）

【例】

犬も歩けば棒に当たる [[※1>#EDOKEI]]

一寸先は闇 [[※2>#KYOKEI]]

石の上にも三年 [[※2>#KYOKEI]]

井の中の蛙 [[※4>#SONOTA]]

論より証拠 [[※1>#EDOKEI]]

六十の手習い [[※4>#SONOTA]]

花より団子 [[※1>#EDOKEI]] [[※3>#OHSAKA]]

針の穴から天井覘く [[※2>#KYOKEI]]

（以下ページ最下部に）
 #br

&aname(EDOKEI){※1}; 江戸系
&aname(KYOKEI){※2}; 京系
&aname(OHSAKA){※3}; 大阪系
&aname(SONOTA){※4}; その他

ありがとうございますー！

むぅ、そうなるとwikiwikiがどうこうできるような問題でなさそうですね、みなさんありがとうございました

リクエスト広場のほうで同種の話がありましたがステータスが解決済みになってました。
改めて動作を確認してみてください。

現時点ではPCのFirefoxだと.pluginのままダウンロードされました。
スマホのandroidだと.binでダウンロードされました。
サーバー側ではなくブラウザー側が受け取ったときに内容を解釈して変換するのかもしれません。

そうなんですね！環境によって変わるのかなぁ、こちらはさっきためしたのですが「.bin」のままだったので修正ではなさそう。chromeだと「.plugin」になりました。

文章の説明よりもコピペで問題が再現できるように書いてください。
問題がでるのに10行必要ですか。1行だと不具合がでないのですか。
＆attachrefがあると問題がでるのですか。ないときはどうなのですか。
問題がでる最小構成を探してみてください。

>> 2の「post.plugin」と「diagonal.plugin」をクリックしてダウンロードしましたが、トピ文にあるような「.bin」と変換されることなく「.plugin」のままダウンロードできましたよ。
環境はWin10/21H1でChrome ver.100(最新)とAndroid5でChrome ver.95です。(androidの方は環境が古すぎて参考にならないかもですが。)
もしかしたら水曜から金曜の間で運営の方で修正等なされた可能性もありますが、報告まで。

つまり実行できないやつはとりあえず「.bin」にしちゃうってことなんですかね、なんとなく理解できたと思います

詳しくはないですが添付リンクをクリックしたとき、それが自動で実行されない仕組みだとおもいます。変更されないのは.jpgや.txtなど一部の素性がはっきりするものだけでしょう。

とりあえず折り畳みで

これって不治の病なん…？とりあえずwikiwikiのurlはったほうがええんやろか、

ここで扱うトピックとしては不適当と思うので、
一般論としてコメントします。

wikiに定期的に更新しなければならないという決まりはないですし、
追加する情報・記事がないなどの理由で何年も更新されないwikiなど珍しくありません。
ご指摘のwikiの状況は知りませんが、
単にやる気のある編集者が一人も残っていないだけという場合もあるでしょう。

原則としてwikiは誰でも（あなたでも）編集できるものなので、
欠けている情報や追加したい記事などがあるなら、
あなたがやってみても良いのではないでしょうか。

お返事ありがとうございます
確かにこれだと近いものはできますが…
どうしても見にくくなってしまうんですよね、
やはり地道に作っていくしか無さそうです。

強引にできなくもないです。
Responsive_layout

#responsive_layout_container(N){{{{
#responsive_layout_item(150px){{{
#nobr{{
|あああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ|
|いいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいい|
}}
}}}
#responsive_layout_item{{
|う|
|え|
}}
}}}}

この件でなんらかの修正をされるとき影響が出ないように書いておきます。
私は#null{{}}とincludexの組み合わせを活用しており、修正に際して現在の動作に影響が出ると困ります。
具体的には以下のような使いかたをしてます。
なんのことかピンとこないかもしれませんが、要はinclude呼び出しで#null{{}}の中の記述を意図的にgrepしてるのでこれができる仕様は維持してもらいたいです。

元ページ

#null{{
隠しコード
}}
文章や表

加工ページ

#includex(元ページ,filter=隠しコード|元ページの文章や表の抽出)

つまりコメントではなくプラグインや文章の呼び出しみたいな使い方です。
これは現在includexがソース文を単純テキストとして解釈してくれるため、コメントアウト部分を外部から呼び出すための不可視な埋め込み領域として利用してます。
隠しコードとはプラグインでも文章でもなんでもいいのですが、例えば表のヘッダーや書式行を埋め込んだりします。
なんのメリットがあるのかというと、例えば元ページの膨大な表からgrepで必要な行だけ抜き出して、さらにヘッダーや書式行を差し替えて表示させるようなことです。加工ページでヘッダとや書式行を追記してもincludeで呼び出された表とは合体しないのでこの方法が有用です。

本来抽出する部分から#null{{～}}で記述した行数分上にシフトしてます。
前述の例ではソース文基準で3行上にずれます。
#null{{～}}内の行数を増やすとその分さらにずれます。

一方で
//コメントアウトの場合はずれません。たとえば//#null{{～//}}と修正すると期待通りの結果になります。
#nullを#foldに変えた場合もずれません。つまりマルチライン記述が問題というわけでないです。

おそらく
section=(filter=^h04$)の記述にマッチする見出し行が先頭から何行目に位置するかをカウント(A)
さらにその見出内に何行あるか(あるいは次の見出しまで何行あるか)カウント(B)
A～B行を抽出みたいな動作をしてるしてるのではないかと思います。
しかしこのカウントするとき#null{{～}}の行がカウントされてないように見えます。

本来見出しh04の内容のみ以下のように表示されるべきだが

*h04
4

以下のように誤表示されると言ってますね。

2
*h03

ありがとうございます。

対象のページ

* h01
1
#null{{
コメント
}}
* h02
2
* h03
3
* h04
4
* h05
5

includex

#includex(対象のページ,section=(filter=^h04$))

当面の対策として//コメントアウトすれば問題はでないと思います。
簡単なやり方として

• 編集エディターの上にある[構文ハイライト (β版 ver 0.1.8)]にチェックを入れる。
• コメントアウトしたい行を選択する。複数行可能。
• 画面上の[編集]メニューからコメントアウト選択。あるいはショートカット[Ctrl]+[/]。