リクエスト広場

例に挙げられたページを見ましたが、その使い方なら見出し内編集で同じことができます。

見出し内編集は見出しの横の鉛筆マークから行います。
見出し毎編集機能

includeで呼び出したページで対象の見出し内を編集のリンクを作るなら以下のように書きます。

[[見出し編集>https://wikiwiki.jp/splatoon3mix/?cmd=edit&page=サーモンラン%2F特殊な状況%2Fラッシュ&id=v5d06fff]]

これも鉛筆のリンクからわかります。id=文字列はソースの見出しの各アンカーを任意に書き換えられます。
またInterwikiを使えばもう少し簡略に記述できます。

includexで抽出してaeraeditの数が減った場合、編集対象がずれるのは仕方がないと思います。
ページ内順位2番のエリアがincludexにより抽出され1番目に位置するようになればリンクは1番として生成されて、実体のある元ページの2番にはたどり着かないような状況でしょう。aeraeditはソースに固有idみたいな記述をしないので順番でしか見分けができないでしょう。

なんとしてもareaeditでやるなら、includexで呼び出したページに以下のようにリンクを作れば対象エリアを編集できます。

[[エリア編集>https://wikiwiki.jp/splatoon3mix/?cmd=areaedit&areaedit_no=2&inline_plugin=0&page=サーモンラン%2F特殊な状況%2Fラッシュ]]

areaedit_no=番号に対象のareaを指定します。対象のaeaeditの編集リンクのURLを確認すれば上記と同様のものがわかります。
/は%2Fに置き換えます。
エンコードされた読めない文字列を気にしないのであれば単純にリンクのURLをコピペでもよいです。

includexで呼び出したとき間違ったareaeditのリンクを消すには以下のようにします。

#includex(サーモンラン/特殊な状況/ラッシュ,titlestr=off,section=(filter=ムニ・エール海洋発電所),firsthead=off,except=#areaedit)

解決しました。
書式指定を使ってもできないと思ったんですが、列の数が相違してただけでした。

該当のWikiのページをみてみたいです。

返信ありがとうございます。
1番目の「ユニーク文字列とカッコ数を制御してexceptする方法」で試してみます。

現状のwikiwikiで使えない「行末コメント」のマルチラインは自分も試したんですが、最初にも書いてある通り書いても消されちゃうんですよね…残念です
表もそうですね、&null埋め込んで制御しようとこともありましたが、仰る通りごちゃごちゃし過ぎて…
ベースになってるpukiwikiがそういうのを許してないのかな

行末コメントを可能にする(今はできない)
上記の方法は色々面倒だったり、カッコの数で制御するのは分かりにくいのと書いた当人以外には何を意図してるのか理解できないでしょう。誰かがマルチライン記述を増減させてカッコの数が自動で変わったら破綻します。
新しい機能として行末に非表示コメントを入れられるようになれば、もっと直接特定の行を指定できるのでよいです。過去に何回か要望してますが。

• マルチライン

  #マルチライン{{//コメント
  文章
  }}//コメント
  

  特定のマルチラインプラグインをincludexで外したいケースに使える。(今回のケース)
  また1ページに閉じカッコが沢山あるとどの開きカッコに対応してるかわかりにくいので、開きカッコと閉じカッコにペアでコメントをつけられると良いです。

• 表

  |1|2|
  |3|4|//コメント
  |5|6|
  

  表の外側にコメントを入れられると行を分類したり検索したりincludexするのが楽です。表の中に不可視のプラグインでコメントを埋め込むこともできますが、スプレッドシートでの管理の観点からデータ列に余計な情報をいれてゴチャゴチャさせたくないです。

• ブロック型

  #プラグイン()//コメント
  

  includeで特定の行を指定したときはこの書き方ができると良いです。(オプションに落書きできないこともあるので)
  通常のコメントであれば次の行に説明書きでもいいのですが。

• 文章

  表示しない//コメント
  

  これをやると既存記述で//が入ってる文章に影響がありそうなので上手くないかもしれません。URLとか。
  &null(コメント);で運用するのがいいかも。

別ページで見出しで制御する方法
ページ1

*A
表示しない
*B
表示する

ページ2

#flex_container(flex-start){{{
#flex_box{{
#includex(ページ1,section=(filter=A))
}}
#flex_box{{
#includex(ページ1,section=(filter=B))
}}
}}}

ページ3

#flex_container(flex-start){{{
#flex_box{{
#includex(ページ1,section=(filter=B))
}}
}}}

ユニーク文字列とカッコ数を制御してexceptする方法

• 消したいマルチラインプラグイン開きカッコ行の(オプション)に適当な文字列を入れる
  無意味なオプションを解釈されないことを利用する
• 消したい文章行は不可視なインラインプラグインを同様に差し込む
  &null(適当な文字列);など
• 消したいマルチラインプラグインの閉じカッコ}の数を制御する
  意味のない#null{{}}を入れ子に組み込む
• includexのexceptで適当な文字列と消したい閉じカッコ数を指定する
  あるいは逆に表示したいところだけ上記のように制御してfilterで抽出する

今回の例であれば以下のようにする
ページ1

#flex_container(flex-start){{{{
#flex_box(,非表示){{{
表示しない&null(非表示);
#null{{
}}
}}} //入れ子を増やすためにダミーの#nullを入れて}}}にする
#flex_box{{
表示する
}}
}}}}

ページ2

#includex(ページ1,except=非表示|^}}}$)

ID変わったの謎すぎる

ちなみにまだ続いています。
1週間毎の模様

返信ありがとうございます。運営からの説明によって、疑問が晴れてバックアップの仕組みについて理解いたしました。
「タイムスタンプを更新せずに「ページの更新」をする」を利用すると差分が発生しているため、実際の日時ではなく以前と同じ日時でバックアップされますと注意書きがあると助かります。

「タイムスタンプを更新しない（管理者のみ）」にチェックを入れてページを更新すると上記のようになります。

また(ry

なるほどです。
それぞれの規制ルールをAND演算でグループ化する感じでしょうか。

1. 規制ルールにIDを振る
2. 対象項目[規制ルールID]を新しく作成
3. パターン種別[AND演算]を新しく作成
4. パターンに 01&&02&&03 のように書き、全てがTrueで規制発動
   ただし、AND演算に記載されている規制ルールIDは単体で規制発動されない

こんな感じでしょうか？
ただ、規制を回避するようなシステムに詳しい荒らしなら、簡単にUA偽装したりブラウザ変えたりしそうです。
わざわざ機能を追加する必要があるかどうか…

https://wikiwiki.jp/pp/faq#08

このSMS認証は制限に巻き込まれた場合の救済措置機能です。

こちらに書いてあるとおり、救済措置があるので、しばらくページごとSMS認証かけたらいいのではないかと思いました。

https://www.clvs7.com/blog/2019/09/20/bookmarklet-for-aa/
これ

たとえば、ページ名X、攻撃者が 255-255-255-255-node.example.comから user agent:BrowserAgent(Mozilla-12)で書き込みをしていて、ドメイン制限であれば\d+-\d+-\d+-\d+-node.example.comでマッチはしますが、その場合ページ名Y(平和なページ)への書き込みまで制限されてしまいますし、同じように user-agent: Chrome(Mozilla...)で acessしてくる人も制限されてしまいます。

cookie, ipについては毎回削除＆再接続によって変化させてきますので、それらの論理積を取ったマッチングを取りたいのです。また、対象ページも何ページかに限定されていますので、(X|X1|X2)などでmatchさせたいと考えています。

コメントありがとうございます。REST APIのリストについては見落としておりました。ただ情報的に少なすぎて書き込みに関する user-cookie, user-ip, user-ua等について各個に再度読み込むのもリクエスト過多になるかと思いますので、そういった情報も付与していただける引数がAPIに追加されると管理的には助かります。

２番めについてもアップロードと巻き戻しでは差分(バックアップ)の履歴的に違ってきますので、巻き戻しを APIに追加していただけると助かります。

昨今１時間あたり10を越える通報があることもあり、荒らし行為に難儀しております。このあたりできるだけ省人化を図れないかといろいろ工夫を考えております。攻撃者の側もある程度知識がある人物の場合、現状のフィルタ実装では容易にかいくぐれてしまいますので、人的コストが馬鹿にならず、できるだけ編集時情報をプラスしたかたちで書き込み情報を取得できると助かります。

また求められた
やっぱり週一周期？

助言ありがとうございます。知らなかったです。やってみます。

flexboxを使用すれば普通にできます。

さんぷるwiki

更新リスト取得：単純にページ名と更新時刻のリストを最新n個取得できるかたちでかまいません。もし parameterを取れるのであれば diff flagなどを用意して Trueである場合には変更内容も jsonに含めていただけると最善です

REST APIでページリストが取得できます。

curl "https://api.wikiwiki.jp/<wiki-name>/pages" \
-H "Authorization: Bearer eyJ0eXA..."

ページ名とtimestampが帰ってくるのでそれをソートしたらどうでしょうか？

{
  "pages": [
    {
      "name": ":config",
      "timestamp": "2022-01-01T00:00:00+09:00"
    },
    {
      "name": "FrontPage",
      "timestamp": "2022-01-01T00:00:00+09:00"
    },
    ...
  ]
}

ページ巻き戻し：これは荒らしであると判断できる場合に現在では過去の内容を取得して新しく書くというかたちになるため、巻き戻したのか追記したのかわかりません。これは履歴管理的にも困りますので、現在差分ページにあるような巻き戻しリンクに対応した APIをお願いします。

これはちょっとわかりません。
REST APIで自動化できそうですがどうでしょう？
定期的に監視して更新があったページ内容を取得して保存、荒らしだと判断したら、荒らされる前の内容をアップする。
差分も作っておけば、いろいろできそうです。

具体的にどのような文字列をマッチさせたいのでしょうか？
大抵はワイルドカード * で対応できそうです。
ソースとマッチさせたい箇所を教えていただくことはできますか？

PCのみ表示、スマホのみ表示は個人的には結構欲しいですね

追記。こちらの正規表現ですが \d+などの表現だと抜けてしまうようです。内部で matchingをしているのは ereg系でしょうか、preg系でしょうか。できれば最大限に正規表現のマッチングパターンを拡張していただけますと非常に助かります。

普通に入力箇所がおかしく、自分のミスで検索できていないことに気づきました…申し訳ないです……

確認しました。横並びプレビューで、ブラウザーを横方向に拡大していくと、ある幅を境に表示が13px→12pxにかわりました。他にも画面全体の行の開始位置もかわりました。
また、プレビューではなく通常表示においてブラウザーの横幅を狭めていくと、ある幅を境に12px→13pxにかわりました。
ご指摘の通りこの動作は表示幅が狭いときはデバイス側の表示体が小さいとみなしてフォントを自動で拡大する機能のようです。よって不具合ではなく仕様であると解釈しました。

この前管理人なのにsms認証を求められましたね。その時はコントロールパネルの各種設定にある逆引きできないIPアドレスでもSMS認証要求なしで許可するをONにすることで求められなくなりました。ただこれだと解決にはならないので信頼できる編集者とかは設定できてもいい気がします

またSMS認証求められた。
4Gだと2日に1回くらいSMS認証求められてたけど、Wi-Fiでも週一で求められるように変更されたのかな？

なるほど、その通りかもしれません。スマホで見るとサイズ未指定時は13pxと同じに見えます。後日PCでも幅を変更して確認します。
この現象のせいでプレビューの表の幅の辻褄が合わず、時間をくいました。

これはデバイスに合わせて文字を見やすくするための仕様なのではないでしょうか。
昨年の5月頃にwikiwikiはレスポンシブデザインになりましたが、
それ以前の「PC向け」と「スマホ向け」でデザインが異なっていた頃から、このような仕様でした。
たとえば、wikiの基本文字サイズが12pxに設定されている場合、
「PC向けデザイン」ではそのまま12pxで表示され、「スマホ向けデザイン」では13pxで表示されていました。

「スマホ向けデザイン」が廃止され、レスポンシブデザインになった現在はどうなってるのかというと、
モニタの横幅が一定以下になると、wikiのメニューバーなどの配置が、スマホ・タブレット向けの表示に切り替わり、
wikiの基本文字サイズが12pxに設定されていても、以前の「スマホ向けデザイン」のように13pxで表示されます。

たとえば、FirefoxでもChromeでもどちらでもいいですが、ブラウザのウィンドウの横幅をマウスでドラッグして調整してみてください。
横幅が一定以下になると、左側にあるメニューバーが下側に配置され、スマホ・タブレット向けの表示になるはずです。
この表示に切り替わったとき、フォントの大きさに注目してください。13pxになってるはずです。
※wikiの基本文字サイズとは別に、フォントサイズを指定した場合は、表示が切り替わっても指定したサイズが維持されます。

つまり、質問の「横並びプレビューでは13pxで表示される」のは、
表示領域の横幅が足りないため、スマホ・タブレット向けの表示でプレビューされているということです。
このような仕様になってるようなので、表などを作った場合は「スマホやタブレットのユーザーにはどんな風に見えるのか」なども意識するといいと思います。
フォントが大きくなると意図しない改行などがある場合がありますから。

お二方ともありがとうございます。
紹介していただいたものを試してみようと思います

指定したテキストを、指定した期間だけ自動で繰り返し表示するプラグインならtomorrow_scheduleというのがあります。
wikiwikiでも使用できます。

指定日は「毎週●曜日」「毎月第●週●曜日」「毎月●日」「毎年●月●日」などが指定でき、
指定日の何日前から表示するかも指定できるので、
例えば「只今セール期間中!」というテキストを、毎年8月10日～31日の間だけ自動で表示する
といったことが可能になります。

ただし時刻・時間単位での指定はできませんので、
ご要望に叶うかはわかりません。

決まったテキストのON/OFF表示なら、
コメントアウトを付けたり外したりすれば良いのでは? とも思います。

wikiwikiには時間で表示を制御する機能はほとんどありません。
minicalendar_viewer、calendar_viewerなどはありますが、使い勝手はよくないでしょう。
また&new(nodate){日付};で日付を指定してNew表示を出すことはできます。
おそらく求められているのは以下のような形式のプラグインだと思いますが、そういうものはないはずです。

#view(表示条件){{
表示内容
}}

googleスプレッドシート上で表示内容を時間制御して、それを#google_spreadsheetを使えば掲示はできるでしょう。
ただページリンクと連動させるなどはできません。
スプレッドシートで表示内容を時間制御する方法は

• 掲載開始、掲載終了、表示フラグ、表示内容の列を作る
• 今日と期間の関係から表示フラグを計算
• Filter関数で表示フラグを条件に表示内容をFilter

SMSが届かなかったの、おやすみモードが原因でした

横解像度 x 縦解像度 = 画素数 です。

画素数の小さい画像を張り付けたければ、
予めペイントなどでサイズ調整した画像を用意してアップロードすれば良いだけです。

またJPEGの場合、圧縮率を大きくすることでもファイル容量を小さくできます。

編集しようとした内容は、個人情報が載っているページの削除をしようとしました。

ちなみに移行先としてはWikiHouseを考えています。

端末によって変わるっぽい

ID変わってるけど本人です(毎日変わるのかそれとも端末によって変わるのか)。
いっそのこと自分のWikiごと他のWikiサービスに移行しようかな…自分のWikiも編集できないようじゃ本末転倒なので…

規約違反のWikiの管理者にアク禁されてて、それで編集しようとすると電話番号認証求められて(入れても「ご入力された電話番号は規制対象となっております。」って言われる)
それで違う番号(捨て電話番号)を入れると自分のWiki等他のWikiでも電話番号認証求められるようになった。