リクエスト広場

views
10 フォロー
1,275 件中 1,121 から 1,160 までを表示しています。
8
koishiba 2022/01/31 (月) 11:50:58 0b3fb@8a961

普通にページの改ざん・削除なら、
wikiのバックアップから「誰でも」元に戻せます。

しかし、ページの改ざん後に(例えば「あ」という1文字にしてから)ページ名の変更が行われると、
これが不可能になるのではないでしょうか。
(ページがリネームされた瞬間に、旧ページ名時のバックアップが消滅)

ページ名の変更は、確か副管理者(サブパスワード所持者)でもできなかった筈です。
上記は自分の推測で、実際に試したことはないので間違っているかもしれませんが、
理由もなしに規制されているとは考え難いので、
運営に正確な理由を問い合わせてみると良いと思います。

(ページ名を変更するために)ページを作り直すと言っても、
それ自体はコピペ&Deleteなので1分と掛かりませんし、
ページ名を変更してもリンクなどを修正する手間が残るのは、
ページを作り直す場合と何も変わりません。
つまり、「面倒」であることに関して差はないのですよ。

7
01v 2022/01/31 (月) 01:28:55

ページ名の変更(renameコマンド)は管理者権限ではなく、一般開放して良いと思います。
例えば新規作成、削除、編集は誰でもできます。ページ名の編集権限がこれらと区別される理由が見当たりません。
システム的にはバックアップや添付ファイルなどページ名に紐づいたものが内部に存在しますが、renameコマンドで変更すればこれらの整合性は取れます。
逆に名前を変えたいページを削除してから、別名で新ページを作成してソース文だけ移しても上記のものは引き継げません。ユーザが自分のできる範囲でなんとか解決しようとするとバックアップを失ったり、添付ファイルが迷子になったり、システム側にゴミが残ったりと良いことがありません。
ページ名の変更履歴(RenameLog)はだれでも見れるので仮に荒らされても戻せます。ページ編集の対応と同じことです。

問題が出るとすれば既存ページ名で作られてるリンクやページ参照式のプラグインの整合性です。ページ名をちょっと修正したつもりが気が付かないところに影響が出たみたいなケースでしょうか。しかしそれはシステム側で気にすることではなく運用で解決する問題だと思います。
最終的には管理者の負担に影響がでそうなので、管理者側でOff/Onできるようにしてもいいかもしれません。しかし私の意見としては最初に述べたように誰でもページが作れたり消せたりできる前提のシステムなら名前の変更操作もその中に含まれると思います。なので、設定としてはデフォルトが開放で、管理者の判断で禁止も選択できるのがよいと思います。

ページ名の変更場面はいくつかあります。
誤記などはわかりやすいですがそれ以外で。階層構造をやめたり、逆にページを分類して階層構造に変更したり。
参加者が勝手気ままに付けたページ名を整えたり。カタカナ、全角半角、英語表記を統一したり、スペース替わりに使ってるアンダースコアを直したりなど。
気付いたときにすぐ直したいケースや、計画的にまとめて直すケースなど考えられますが、いずれにしろ全部管理者にお願いする(される)のも大変です。
個人ページや任せてるページなら勝手にやればいいし、自分で話をまとめられるなら自分でやればいいと思います。

4
koishiba 2022/01/30 (日) 23:21:53 0b3fb@021ad >> 3

利用者というのは閲覧者のことですか? それとも編集者のことでしょうか。
1ブロック単位での検索ツールにどのような意味・利便性があるのか、
ちょっと自分には想像できません。(特に閲覧者にとって)

ヒント」「以下の留意点~」に書かれているように、
(他のwikiでも需要がありそうか、なぜそれが必要か理由を書く)
どのような場合に、どんなふうに便利なのか、
簡単でいいので具体的な説明をお願いします。

3
SWEET 2022/01/30 (日) 15:06:33 970b4@7c7f8

あ、僕が欲しいのはページ内じゃなくて、特定の部分でした。(1ブロックとか)
既存のwikiwikiのサイト内検索だと、他のページでヒットしたものまで出てきてしまうので困ります。できれば、特定の部分だけ検索してほしいのですが、ブラウザ側の検索機能だと、関係ないところまで対象になったり、あるいは非表示になっているところを検索できなかったりと不便なところがあります。
それに、検索をかけるのは、僕ではなく、利用者なので、難しい操作はなしにしてほしいです。

5
名前なし 2022/01/29 (土) 18:40:00 a3b27@c2ee0

管理人が機能の制限/開放を設定できるようにすればよいのではないでしょうか。
荒らしが発生したら機能を制限し、管理権限を持たない一般編集者では編集できなくする。
また一般編集者による名前変更には1時間とか1日とか1週間とか、クールタイムを設けるなども有効な荒らし対策になるかと思います。

3

逆に考えてみて下さい。
もしも簡単な操作でページ名を変更できたら荒らし放題ですよ。

それに加えてページ名自体、つまりURLを変えるとなれば恐らく内部の書き換えで相当な手間が掛かるはずです。

素人の例えですけども、サイトのサーバー移転をする際に何時間もかかるような感じですね。

ここで見ず知らずの貴方に説教をするつもりはさらさら有りませんが、面倒だからこそいいこともあるのではないのでしょうか?

2

それがめんどくさいし、それが出来るなら解放してほしい。

2
koishiba 2022/01/25 (火) 18:09:18 修正 0b3fb@021ad

別に反対はしませんが、
黒バックの場合、普通の青では余計に視認性が悪化するので、
それだけはやめてください。

追記:

文字色はデザイン テンプレートにより様々です。
(リンクが青文字になるテンプレートもあります)
黒文字とか、特定の環境だけでなく、全体のことも考えてください。

とりあえず↑の方法で折り畳みボタンを好みの色に変更できますが、
それではダメなのでしょうか。
(個人的には、多用しない限り面倒という程ではないように思えます)

【例】
 #color(DodgerBlue){{{{
 #fold(&color(Black){開く};){{{
 #color(Black){{
 折り畳み記事の色は黒、
 折り畳みボタンの色を&color(DodgerBlue){明るめの青};にしたい場合です。
 一寸面倒かもですが、好きな色を指定できますよ。
 }}
 }}}
 }}}}

1
あさかはじゅん 2022/01/25 (火) 11:55:16

 #color(Blue){{
 #fold(あいうえお){{
 かきくけこ
 さしすせそ
 }}
 
 
 #accordion(&color(Blue){たちつてと};,*,close){{
 なにぬねの
 はひふへほ
 }}
 
 
これでできたと思います

9
あさかはじゅん 2022/01/25 (火) 11:52:24

運営の方は見てらっしゃいますか?
どうでしょうか。

1
あさかはじゅん 2022/01/25 (火) 11:51:08

ページの内容を切り取って、消して、新しいページ名でページ作って、貼り付けて更新する。

1
あさかはじゅん 2022/01/25 (火) 11:50:31

設定をWikiごとに変えたい場合困りませんか?

2
名前なし 2022/01/24 (月) 22:30:39 a3b27@c2ee0 >> 1

横からですが、ブラウザの検索機能だと折畳みされている内容が検索から漏れるため、その点は不便ですね。
そういう時、自分は差分表示にしてソース文を検索していますが、見づらいですし一般の利用者に勧められるやり方とは言い難いかと思います。
まぁトピ主さんの目的からするとおそらく不足はないと思います。

1
01v 2022/01/24 (月) 01:54:16

ブラウザ側の機能の検索では不足でしょうか。PCだとCtrl+Fとかで検索できると思います。
また例えばwiki側にページ内検索機能があったとして、どのような検索結果をイメージしてるのでしょうか。サイト全体検索だとヒットするページが列記されるわけですが、ページ内だと該当行に飛んだり色が付いたり程度で、ブラウザの検索機能とたいして変わり映えがしないように思います。

3
名無しの権兵衛 2022/01/23 (日) 13:36:13 f4788@7c7f8

私も同じような現象がおきています。
編集ミスしたとき、この機能を使っても、元通りにはならず、結局やり直しです。

8
821系神 2022/01/22 (土) 10:59:48

自分は早急に実現して欲しいと思っています。

7
とある名無し 2022/01/21 (金) 11:28:27 1f9a7@97205 >> 6

サンプルwikiを見る限りそういう仕様にしてある?
だとすれば正常に表示されるプラグインを追加してほしい

6
とある名無し 2022/01/21 (金) 00:31:23 1d563@22015

文字化けじゃなくてコード化でした。
この現象数年前からあるみたいですね

1
名前なし 2022/01/11 (火) 15:28:49 1cae8@f97ad

賛成です。
あまり詳しくないですけども、pukiwiki系で採用している所も多いですし導入自体はそれほど難しくないんじゃないですかね?
既存のwikiへの対応が大変そうではありますが…

2
名前なし 2022/01/09 (日) 12:43:53 9d145@46052

誤字で申し訳ないですが「revert」でも反映されないです。

5
とある名無し 2022/01/07 (金) 23:20:27 bcea2@22015 >> 4

ミスった。

4
とある名無し 2022/01/07 (金) 23:18:40 bcea2@22015 >> 3

#aaプラグイン抜きだと普通に表示される模様。(++

++
3
とある名無し 2022/01/07 (金) 23:15:38 bcea2@22015


#aaプラグイン内に「‒」を入れる

「‒」←こうなる

1
弥七 2022/01/07 (金) 13:33:43

私の環境 Chrome 97.0.4692.71(Official Build)(x86_64)で問題なく動作しています。

ページ差分欄に直接「revent」を記入しても「reventは実装されていません(日本語訳)」のように出てしまいます。

revent ではなく revert ですよ。

2
とある名無し 2022/01/06 (木) 20:46:02 eb0b8@22015 >> 1

ちなみに絵文字でも同じ事が起こります。

1
とある名無し 2022/01/06 (木) 15:38:03 4ad8c@22015

特に空白のUnicodeを使いたいので

9
るー 2021/12/31 (金) 17:59:33 31711@405c5

今月の27日に対応されていました。
https://twitter.com/WIKIWIKI_Japan/status/1475403578961719306

編集範囲が、末尾の連続した空行を含まない、「見出しの内容のみ」になったみたいです。

例えば、このコードで見出し1を編集しようとしたとき、

*1 [#1]
内容1


*2 [#2]
内容2

従来は、1~4行目までの「連続空行を含む」範囲を編集していたのを、
1~2行目までの「見出しの内容のみ」の範囲を編集するように。

ちなみに、編集範囲が変わっただけなので、新たに付け加えた空行は従来通り削除されるようです。

従来の挙動の良いところをとりつつ、要望を吸収したとても良い変更だと思います。
対応ありがとうございました。

2

レスありがとうございます。
なるほど、Tabキーに関しては全く知りませんでした。
それなら誤送信を減らした上でスムーズに送信できますね。
ありがとうございました。

1
01v 2021/12/30 (木) 21:37:41

PCなら内容を入力後Tabキーを押して挿入ボタンへ移動、Enterで送信ではどうですか。

入力途中でEnter誤送信はたまに見る光景です。誤送信しても直接ページ編集して消したり修正したりすればいいのですが、大抵の人はやり方がわからないのか新たなコメントで続きを投稿します。入力欄でのEnter無効は無難な対応だと思います。またwikiのコメント欄に限らず大抵の入力フォームは上記のようにTabで移動しながらの操作が楽です。

5
アカサカ 2021/12/20 (月) 23:30:02 15d8c@2e9f6 >> 3

念の為、二回目も行いましたが改善されませんでした。
画像1
画像2

4
アカサカ 2021/12/20 (月) 23:19:03 15d8c@9ce85 >> 3

01vさん、ありがとうございます。
chrome ・・・>設定>プライバシー>閲覧履歴データの削除
を行いました。

しかし、削除後も不定期に3~5回に一回の割合で発生します。
不具合が発生するのはタイトル項目名のみなので、
タイトル項目に画像を貼り付けるのは非推奨であると
考えるべきでしょうか?
画像1
画像2

3
01v 2021/12/20 (月) 22:52:45 >> 2

設定 プライバシーとセキュリティ 閲覧履歴データの削除で消せませんか。

2
アカサカ 2021/12/20 (月) 10:21:40 修正 9243d@ff838

wikiwiki公式のツイートで
スーパーリロードやキャッシュのクリア
https://twitter.com/wikiwiki_japan/status/1471822144296620032?s=21
をアナウンスされていました。
不具合一つ目と三つ目は、主にスマホ閲覧時に起きます。
スマホのchromeアプリはスーパーリロードやキャッシュのクリアがないので、スマホのアプリを削除→再ダウンロードしていますが、本日12/20も起きました。改善する方法はありませんか?
画像1

4
adherent45cal 2021/12/20 (月) 00:34:19 >> 1

提案ありがとうございます。
ヘッダーとincludeで注意書きを追加し、様子を見てみます。

3
adherent45cal 2021/12/19 (日) 23:42:13 修正 >> 2

荒らしかと思って一応は確認していますがブラウザ・ネットワークID、IPやcookieはバラバラです。

大型アプデ&セールで新規参入者が多く、その上wikiに慣れていない初心者もいるのかと思います。
規制追加しても以降のHITが0のため事前策が欲しいところでした。

今日の分(ヘッダーに注意書き追加)
https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112192109163ea24&page=*Lab. Violet keycard

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219124504b784d&page=*ポーチ

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219124312498ea&page=*SHORELINE

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219123825be894&page=*Hunter matches

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121912322925f4f&page=*用語集

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219101411238d5&page=*ポーチ

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211219042308b71ac&page=*スキル

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112190406523f8e5&page=*RESERVE

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218211458d3bd6&page=*LIGHTHOUSE

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=202112182043420e996&page=*LIGHTHOUSE

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218163916aea3b&page=*Dorm room 206 Key

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121814294779d31&page=*MP-133

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218140348ffd7c&page=*操作の説明

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=20211218032101650fd&page=質問掲示板ログ

https://wikiwiki.jp/eft/?cmd=diff_log&action=detail&did=2021121723443183406&page=*Factory exit key

2
koishiba 2021/12/19 (日) 19:32:41 0b3fb@d5bf5

誤入力の可能性は低いように思えます。
検索フォームの入力欄は「サイト内検索」、ボタンは「検索」になってますが、
コメントフォームは「コメント」「挿入」になっていますし、
皆無とまでは言い切れませんが、さすがに多発はないでしょう。

入力途中に誤ってEnterキー押してしまったり、
イタズラの可能性の方がはるかに高いと思います。
(「毎日10~数10個」もあるなら、イタズラでほぼ間違いないかと)

01vさんも述べているように、
毎回メッセージボックスが表示されたら、個人的には鬱陶しいですね。

1
01v 2021/12/19 (日) 16:59:02

たまにコメントに単語がポツンとあるのを見かけますが検索の誤入力とは気が付きませんでした。ただ確認表示が毎回でるのは普通にわかってる多くの人には鬱陶しい気がします。コメント欄の下に注意書きを書くとか、ページフッターに検索ボックスを配置するとかして誘導してみたらどうでしょうか。注書きはincludeで別ページ参照にすると管理が楽だと思います。コメント欄の注意書きは誤入力以外にも色々必要なことがあります。

8
01v 2021/12/19 (日) 16:36:47 >> 7

キャンセル時の強制保存は修整されたようです。

見出し編集の文末の改行自動削除は私もやめてもらいたいとは思います。見ため以外の問題というか違和感として、例えばページ全体を編集するときは見出し間の改行は取られないわけで、これは改行が禁則やエラーを出すというわけでもなく、まあ当たり前に余計なことはされないわけです。一方で部分編集のときは勝手に取ってしまうちぐはぐさが気持ち悪い感じがします。エディタ的には読み込みの最後の部分に掛ける処理として判断してるのだと思いますが、ページの実体はファイル全体であり部分編集でファイルの終端処理みたいのを掛けるのは余計なことのように思います。

2
アルミナ 2021/12/17 (金) 17:16:17 2f023@f4da4

確かに横幅を圧縮できるのも良いですね
例えばですが、
 #nobr{{
 |~国名|~正式名称|~面積|~人口|
 |イギリス|&fold{United Kingdom of Great Britain and Northern Ireland};|24.5万㎢|6645万人|
 |スリランカ|&fold{Democratic Socialist Republic of Sri Lanka};|6.6万㎢|2103万人|
 }}
といった形で正式名称をfoldで括ってしまえば、最初については画面幅が広くなくとも国名、面積、人口については折り返しなく見れる上に、正式名称のせいであまりにも横幅が長い、ということも回避できそうです。

7
るー 2021/12/16 (木) 22:49:00 修正 31711@a1226 >> 6

文末に//コメントアウトを入れれば可読性は確保できます。

こういうことですよね。

*1 [#1]
内容1

//
*2 [#2]
内容2

しかし、少し不格好かなーと思ってしまいます。
その場しのぎで使うにしても、要望が吸収された後にこれを外す手間も考えると、あまり使いたくはないです。

本題の要望が通るのが一番良いと思うのですが……。

またこの整形動作は保存だけではなく、キャンセルボタンを押したときも強制的発動します。

少し試してみましたが、再現はできませんでした。修正されたのでしょうか。