自分も同意見です。 ついでに言えば、リクエストした時点で「やや改善」されているのも意味不明です。
文面などから察すると、過去に無意味な提案を繰り返してきた人物と同一人物のように思われます。
https://z.wikiwiki.jp/wikiwiki-request/topic/482 https://z.wikiwiki.jp/wikiwiki-request/topic/483 https://z.wikiwiki.jp/wikiwiki-request/topic/484 https://z.wikiwiki.jp/wikiwiki-request/topic/485 https://z.wikiwiki.jp/wikiwiki-request/topic/476
追記：
指摘を受けて一部修正したようですが、 「やや改善」タグを外したのはともかく、 文章の方は「最近では管理者権限やご意見などでサポート履歴に重複が起きています」 と、ますます意味不明なものになっています。
>> 1さんが指摘しているように、
を具体的に説明しないと何も伝わらず、誰にも賛同されないと思います。 勿論、運営も動かないでしょう。 （意味不明なのですから、困惑しかないでしょう）
まず「サポート履歴」が何を指すのか分かりませんので、重複がどのような状況なのかも分かりません。 何が問題でどう改善してほしいかも全く分かりません。
もう少し具体的に説明されてはいかがでしょうか。
画像の添付自体は>> 1の方の方法でできます。 ただしwikiwikiでは512KBまでのファイルしか添付できず、それを超えるものは自動で圧縮されてしまいます。 GIFの場合はこの自動圧縮がかかると静止画になってしまうため、添付時点で512KB以下にしておく必要があります。 「GIF 圧縮」などで検索をかければ圧縮用のサイトがいくつか出てくると思うので、そちらを利用してみてください。
こちら私からも対応をお願いしたいです。 こうしたNGワード機能はコメントが完全ブロックされるのが一般的かと思うので、それをSMS認証によって回避出来るという現象は直感に反するように思えます。 （不具合としてリクエスト広場に起票する前に試しに検索してみたら、このトピックを見つけました）
zawazawaのNGワード機能は無条件でブロックされるかと思いますので、それに統一して頂きたいです。 何卒よろしくお願いします。
ありがとうございます。不具合修正確認しました。
ご連絡ありがとうございます。
上記の不具合、修正いたしました。
ご確認のほどよろしくお願い申し上げます。
https://wikiwiki.jp/sample/ファイルを添付する https://wikiwiki.jp/sample/ファイル(画像)を貼り付ける https://wikiwiki.jp/sample/他のページの添付画像を貼り付ける
特にlazy_foldを多用しているページの使用感が著しく損なわれますね。 公式のアナウンスが無いので何とも言えないですが、lazy_accordionで発生しないなら置き換えたほうがいいですかね。
賛成します。
できれば管理側でパレットの色、数は変更できると助かります。 色の検討をせず、「テンプレにあるから」で使用され、大変読みにくいwikiが散見されます。
管理人様、先ほど書き込みが制限されている件でご連絡差し上げた者です。
改めてお詫びさせてください。先ほどは操作の不手際から、大変ご迷惑をおかけして申し訳ありませんでした。決して荒らす意図はなく、記事を編集したいという気持ちが先走ってしまい、配慮に欠ける行動をしてしまいました。
今後は同じようなことは二度としません。もし制限を解除していただけるのなら、今度こそルールを守り、しっかりとした記事作成に貢献したいと考えています。
身勝手なお願いで大変恐縮ですが、ご検討いただけますと幸いです。どうぞよろしくお願いいたします。
#responsive_layout_item の引数で0（width: 0 or display: none）を許可してほしいです。 複合的な切り替わりポイントを利用して、PCとモバイルとで表示内容を変更したいためです。
#cssboxを利用してデザインを調整する場合、 標準の_layout.cssで@media(max-width)等で見た目を制御されているため、環境によっては想定した表示とずれる場合があります。 #responsive_layout_item(12,12,0) のように指定することで、表示させないこともできるようにしてほしいです。
すみません。勘違いだったかもしれません。
https://c.wikiwiki.jp/wiki/poke-unite/blocking-log/view?id=016dd3a5-c69e-4246-a0cc-13a8f3dc0ae3 こちらがSMS認証済みなのに編集規制されているように見えたのですが、
https://c.wikiwiki.jp/wiki/poke-unite/diff-log/view?did=20260211205339f9547 https://c.wikiwiki.jp/wiki/poke-unite/diff-log/view?did=2026043020320918f3f SMS認証することで規制されずに編集できている履歴もありました。
現状の機能では、毎日監視する運用でないと検索が厳しいです。 せめて、詳細検索時は7日分をまとめて表示できないでしょうか。
本当に欲しい機能としては、以下の内容を確認するため、クッキー・IP・ホスト名・SMSトークン、いずれかの完全一致での編集差分（またはページ名と編集日時だけ、あるいは編集したことがあるページ名一覧だけでも）表示してほしいです。
https://z.wikiwiki.jp/wikiwiki-request/topic/481 こちらの改修が関係している可能性を考えています。
WCAGのコントラスト比の基準を満たさない組み合わせは読みにくいので（例：白地に黄文字）そこは考慮してほしいですね。
https://webaim.org/resources/contrastchecker/
追記
AVIFの現状の最大の弱点は圧縮に時間・計算量がかかる（特に最大圧縮率を追求した場合）ことですが、ユーザが勝手に自分の端末で圧縮する場合はWikiWikiのシステム側の懸念事項はありません。
リミッターの画像を仮にAVIFにする場合は圧縮率を必要に応じて下げるなどが必要になるかも知れません。
圧縮の時に使うAV1エンジンでSVT-AV1というものを選べば時短になりますが、YUV420固定なため非可逆WebPの弱点を引き継いでしまいます。とはいえ非可逆WebPからの切り替えであれば改悪ではありません。
パレットを追加するメリットはあまり無いように思えます。
細かく色を設定したいのならカラーコード(#xxxxxx)で事足りますし、選択肢が多すぎることで逆に編集の妨げになるケースも考えられます。 （似たような別の色を使ってバラバラに設定されてしまうと、後から変更したい時に一括置換ができなくなるなど）
特定の色だけに限定するとしても、パレットの〇〇番目を使ってくださいと説明するよりもカラーコードを直接指定した方がより確実です。
追記です。 結果的に早計な変更になってしまい申し訳ありませんでした。 私の環境でも動作することを確認できました。 対応いただき、ありがとうございました。
おそらく運営側にて対処されたかと思いますが、本日Edge、Chromeにて動作することを確認しました。 ただし設定文字数によってスクロール速度が変わったり、リピートまでに少し長い間が空いてしまうなど以前とは使い勝手が異なる点にご注意ください。 こちらの事象は解消されたようです。
トピ主です。 皆さん、情報ありがとうございました。 wikiwiki側の不具合ではなさそうとのことなので、タグを変更しました。
私のwikiではさほど多用しているわけではないので、代わりのプラグインを私から要望を出すことはいたしません。 もし他に希望する方がいれば、お任せします。
ありがとうございました。
marquee自体の廃止に1票です。 Webブラウザが拒否しているのですからどうしようもありません。 廃止といっても互換性維持のため現在のまま放置されるのかと思います。
代用品を求める場合は再提案をお願いします。
wikiwikiの不具合ではなく、 単に各ブラウザがmarqueeのサポートを終了しつつあるというだけの話かと。 私のスマホ（Android 16 / Firefox 148.0.2）では動作していますが、 今後もサポートが続く保証はありませんし（Windows版Firefoxでは、かなり前のVer.から動作していません） 環境ごとに動作がバラバラでは困るので、廃止に一票です。
個人的には全く不要でどうでも良い機能ですが、どうしても必要なら、 代替プラグインの実装を要望されたらよろしいのではないでしょうか。 要望者が多いようなら、ひょっとしたら実装してくれるかも知れません。
本日、スマートフォン(android)でも機能しなくなっているのを確認しました。
元になったと思われるHTMLのmarquee要素は大昔に非推奨機能となり、今後サポートの保証はありません。 参考
これを機に廃止してしまって良いのではないでしょうか。
脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、 モバイルだけでなくPCでもソースコードが表示され、 あらためてよく見ると、ページのソースコードではなく、 こちらの内容が表示されているようです。 これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、 右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨ 理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。 トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？ 右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。 ■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1) ■ 今後の対策 どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、 現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
ってGemini(代筆)がいってた 【補足】 ・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね) ・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ ・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね 【脚注】 (※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。 ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。 しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。 やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。 ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！ 添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます 私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？ 軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。 添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。 現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、 今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな 6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、 「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@ |￣￣￣￣￣|゜人 |2026年| Ｙ |¨¨¨¨¨| ゜＋ ＋| 実 |人 | 家 | Ｙ 。 | 安 の | ＋ 。| 心 様 |∩ /フ | 感 な |||㎜ | ！ |=¨=
迅速なご対応ありがとうございました！ タグを「解決済」に変更しました。
自分も同意見です。
ついでに言えば、リクエストした時点で「やや改善」されているのも意味不明です。
文面などから察すると、過去に無意味な提案を繰り返してきた人物と同一人物のように思われます。
https://z.wikiwiki.jp/wikiwiki-request/topic/482
https://z.wikiwiki.jp/wikiwiki-request/topic/483
https://z.wikiwiki.jp/wikiwiki-request/topic/484
https://z.wikiwiki.jp/wikiwiki-request/topic/485
https://z.wikiwiki.jp/wikiwiki-request/topic/476
追記：
指摘を受けて一部修正したようですが、
「やや改善」タグを外したのはともかく、
文章の方は「最近では管理者権限やご意見などでサポート履歴に重複が起きています」
と、ますます意味不明なものになっています。
>> 1さんが指摘しているように、
を具体的に説明しないと何も伝わらず、誰にも賛同されないと思います。
勿論、運営も動かないでしょう。
（意味不明なのですから、困惑しかないでしょう）
まず「サポート履歴」が何を指すのか分かりませんので、重複がどのような状況なのかも分かりません。
何が問題でどう改善してほしいかも全く分かりません。
もう少し具体的に説明されてはいかがでしょうか。
画像の添付自体は>> 1の方の方法でできます。
ただしwikiwikiでは512KBまでのファイルしか添付できず、それを超えるものは自動で圧縮されてしまいます。
GIFの場合はこの自動圧縮がかかると静止画になってしまうため、添付時点で512KB以下にしておく必要があります。
「GIF 圧縮」などで検索をかければ圧縮用のサイトがいくつか出てくると思うので、そちらを利用してみてください。
こちら私からも対応をお願いしたいです。
こうしたNGワード機能はコメントが完全ブロックされるのが一般的かと思うので、それをSMS認証によって回避出来るという現象は直感に反するように思えます。
（不具合としてリクエスト広場に起票する前に試しに検索してみたら、このトピックを見つけました）
zawazawaのNGワード機能は無条件でブロックされるかと思いますので、それに統一して頂きたいです。
何卒よろしくお願いします。
ありがとうございます。不具合修正確認しました。
ご連絡ありがとうございます。
上記の不具合、修正いたしました。
ご確認のほどよろしくお願い申し上げます。
https://wikiwiki.jp/sample/ファイルを添付する
https://wikiwiki.jp/sample/ファイル(画像)を貼り付ける
https://wikiwiki.jp/sample/他のページの添付画像を貼り付ける
特にlazy_foldを多用しているページの使用感が著しく損なわれますね。
公式のアナウンスが無いので何とも言えないですが、lazy_accordionで発生しないなら置き換えたほうがいいですかね。
賛成します。
できれば管理側でパレットの色、数は変更できると助かります。
色の検討をせず、「テンプレにあるから」で使用され、大変読みにくいwikiが散見されます。
管理人様、先ほど書き込みが制限されている件でご連絡差し上げた者です。
改めてお詫びさせてください。先ほどは操作の不手際から、大変ご迷惑をおかけして申し訳ありませんでした。決して荒らす意図はなく、記事を編集したいという気持ちが先走ってしまい、配慮に欠ける行動をしてしまいました。
今後は同じようなことは二度としません。もし制限を解除していただけるのなら、今度こそルールを守り、しっかりとした記事作成に貢献したいと考えています。
身勝手なお願いで大変恐縮ですが、ご検討いただけますと幸いです。どうぞよろしくお願いいたします。
#responsive_layout_item の引数で0（width: 0 or display: none）を許可してほしいです。
複合的な切り替わりポイントを利用して、PCとモバイルとで表示内容を変更したいためです。
#cssboxを利用してデザインを調整する場合、
標準の_layout.cssで@media(max-width)等で見た目を制御されているため、環境によっては想定した表示とずれる場合があります。
#responsive_layout_item(12,12,0) のように指定することで、表示させないこともできるようにしてほしいです。
すみません。勘違いだったかもしれません。
https://c.wikiwiki.jp/wiki/poke-unite/blocking-log/view?id=016dd3a5-c69e-4246-a0cc-13a8f3dc0ae3
こちらがSMS認証済みなのに編集規制されているように見えたのですが、
https://c.wikiwiki.jp/wiki/poke-unite/diff-log/view?did=20260211205339f9547
https://c.wikiwiki.jp/wiki/poke-unite/diff-log/view?did=2026043020320918f3f
SMS認証することで規制されずに編集できている履歴もありました。
現状の機能では、毎日監視する運用でないと検索が厳しいです。
せめて、詳細検索時は7日分をまとめて表示できないでしょうか。
本当に欲しい機能としては、以下の内容を確認するため、クッキー・IP・ホスト名・SMSトークン、いずれかの完全一致での編集差分（またはページ名と編集日時だけ、あるいは編集したことがあるページ名一覧だけでも）表示してほしいです。
-- 初犯かどうか（何らかの操作ミスの可能性があるのかどうか）
https://z.wikiwiki.jp/wikiwiki-request/topic/481
こちらの改修が関係している可能性を考えています。
WCAGのコントラスト比の基準を満たさない組み合わせは読みにくいので（例：白地に黄文字）そこは考慮してほしいですね。
https://webaim.org/resources/contrastchecker/
追記
AVIFの現状の最大の弱点は圧縮に時間・計算量がかかる（特に最大圧縮率を追求した場合）ことですが、ユーザが勝手に自分の端末で圧縮する場合はWikiWikiのシステム側の懸念事項はありません。
リミッターの画像を仮にAVIFにする場合は圧縮率を必要に応じて下げるなどが必要になるかも知れません。
圧縮の時に使うAV1エンジンでSVT-AV1というものを選べば時短になりますが、YUV420固定なため非可逆WebPの弱点を引き継いでしまいます。とはいえ非可逆WebPからの切り替えであれば改悪ではありません。
パレットを追加するメリットはあまり無いように思えます。
細かく色を設定したいのならカラーコード(#xxxxxx)で事足りますし、選択肢が多すぎることで逆に編集の妨げになるケースも考えられます。
（似たような別の色を使ってバラバラに設定されてしまうと、後から変更したい時に一括置換ができなくなるなど）
特定の色だけに限定するとしても、パレットの〇〇番目を使ってくださいと説明するよりもカラーコードを直接指定した方がより確実です。
追記です。
結果的に早計な変更になってしまい申し訳ありませんでした。
私の環境でも動作することを確認できました。
対応いただき、ありがとうございました。
おそらく運営側にて対処されたかと思いますが、本日Edge、Chromeにて動作することを確認しました。
ただし設定文字数によってスクロール速度が変わったり、リピートまでに少し長い間が空いてしまうなど以前とは使い勝手が異なる点にご注意ください。こちらの事象は解消されたようです。トピ主です。
皆さん、情報ありがとうございました。
wikiwiki側の不具合ではなさそうとのことなので、タグを変更しました。
私のwikiではさほど多用しているわけではないので、代わりのプラグインを私から要望を出すことはいたしません。
もし他に希望する方がいれば、お任せします。
ありがとうございました。
marquee自体の廃止に1票です。
Webブラウザが拒否しているのですからどうしようもありません。
廃止といっても互換性維持のため現在のまま放置されるのかと思います。
代用品を求める場合は再提案をお願いします。
wikiwikiの不具合ではなく、
単に各ブラウザがmarqueeのサポートを終了しつつあるというだけの話かと。
私のスマホ（Android 16 / Firefox 148.0.2）では動作していますが、
今後もサポートが続く保証はありませんし（Windows版Firefoxでは、かなり前のVer.から動作していません）
環境ごとに動作がバラバラでは困るので、廃止に一票です。
個人的には全く不要でどうでも良い機能ですが、どうしても必要なら、
代替プラグインの実装を要望されたらよろしいのではないでしょうか。
要望者が多いようなら、ひょっとしたら実装してくれるかも知れません。
本日、スマートフォン(android)でも機能しなくなっているのを確認しました。
元になったと思われるHTMLのmarquee要素は大昔に非推奨機能となり、今後サポートの保証はありません。
参考
これを機に廃止してしまって良いのではないでしょうか。
脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、
モバイルだけでなくPCでもソースコードが表示され、
あらためてよく見ると、ページのソースコードではなく、
こちらの内容が表示されているようです。
これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、
右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨
理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。
トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？
右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
lazy_foldは「ブラウザが画像を表示するタイミング」を遅らせてデータ転送量を減らすためのもので、
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。
■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms
この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1)
■ 今後の対策
どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、
現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
現状維持でOKです！サーバーの負荷軽減に協力しようというそのお気持ちだけで100点満点です！💖
ってGemini(代筆)がいってた
【補足】
・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね)
・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ
・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね
【脚注】
(※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。
ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。
しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。
やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。
ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！
添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます
私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？
軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。
添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。
現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、
今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな
6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、
「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
迅速なご対応ありがとうございました！
タグを「解決済」に変更しました。