可処分時間がそれほど作れずに手直しするページが多くて頭を抱えていました。規制内容が緩和されたことで大幅に手直しするページが減り、助かりました。
22日午前1時現在、一時動作不具合となっていたタイトル行セル連結を含むtablesortが正常動作していることを確認できました。 ご対応ありがとうございました。
正常に動作しているのに勝手に使用不可とか、ホントいい迷惑ですよね。
おそらくこの17日の変更が原因だと思うのですが、これまで動作していたタイトル行（|hや|f）のみにセル連結を含む数多くの既存テーブルが、「tablesort の使用方法に誤りがあります」となって動作不具合となっているようです。 全てを再編集するのは非現実的と思われ、タイトル行についてはセル連結を可能とする従来仕様に速やかに戻していただきたいです。
https://zawazawa.jp/wikiwiki-request/topic/214
メッセージを出力するようにしました。 また、一部の環境で動作してしまう問題があったため、 全ての環境で一貫して動作しないように調整しました。
ご連絡ありがとうございます。 上記の不具合、対応しました。
こちら賛同します。部分的なテンプレートなど、全範囲選択+コピーができないような内容において手間やミスの削減に繋がると思います。
"[[]]"で囲う
&lastmod("[[ページ名]]");
構文解析
""で囲う
&new("ページ名");
SMS認証済みだったのに「認証のない書き込みは制限されています」ってメッセージまた出て書けないけど、バグ？
誰も著作権のことなど話していません。
以前のスレで著作権物の話が出て議論する必要もないことを、レスしている方がおられましたので、一応 注意喚起のつもりでした。不快な思いをさせてしまい大変失礼いたしました。
他人が立てたトピックに乗っかって何度も話をすり替えないでください。
大変失礼しました。どうやらこちらの思っていたこととはだいぶん違うみたいですね。 仰る通り、木主の要求（提案）は、先に添付ファイルを削除→その後にページの削除という手順が要求される現状を変えて欲しいという事みたいでバックアップまでは触れられてないみたいです。 すり替えたつもりではありませんが管理上の事、そして添付ファイルのことなどかと思い 代替案として提案させていただいた次第です。
自動バックアップ自体必要ない
こちらも間違っていました。 自動バックアップではなくて、画像のサイズ間違え、画質の不具合等などのバックアップ自体必要ないですよね。と言うことでした。
いずれにせよ、このあたりでこの件は終わりにさせて頂きます。 何か本題をすり替えた様に思われているみたいですが、すり替えたつもりはありませんのであしからず。
誰も著作権のことなど話していません。 他人が立てたトピックに乗っかって何度も話をすり替えないでください。
管理者はいかなる理由があろうとも情報を提供して頂いているだけ 自動バックアップ自体必要ない 判断を管理者がするのは違うのではないかと 手動で定期的なローカルバックアップを取れば良い
……呆れてモノが言えません。 なのであなたに対するこれ以上の議論はやめにします。
あらかじめ申し上げておきますが著作権物の話は論外です。 運営・管理者・情報提供者３者 権利はありませんので。
木主はバックアップのことなど話していません。
確かに話していませんが、それだったらと思ったので こちらで以前提案させて頂いた案を、代替案として提案させていただいただけです。
理由があって添付ファイルのバックアップを削除したい場合は、 その理由を管理者に告げ、後は管理者の判断になります。
何故管理者の判断になるのでしょうか？ 管理者はいかなる理由があろうとも情報を提供して頂いているだけなので 情報提供者の判断でバックアップも含めて削除出来ても問題ないかと思います。
削除に要する時間は1分程度ですし、それが管理者の役割（の一つ）ですので、 あなたが責任だの負担だのと気にする必要はないです。
管理者の方の役割と言ってもすぐの事にはなりませんし連絡がつかない場合は論外です。 責任・負担と言うのはついでの物事でその様なこともあるのではないかと言う事です。
「何度も失敗する」「恥ずかしい」というのはあなた個人の事情なので、 第三者にはどうでもよい理由です。
それは第三者の方・管理者の方にとってはどうでも良い事かと思いますが 添付ファイルをアップする側としてはそうではないですよね。 その人の立場によって、考え方に違いがあるとは思いますが 気軽にアップする為にもそのようにして頂けたらと思います。
そのような理由で自動バックアップに事実上の穴を開けさせ、 運営には大規模改修を、管理者には手動で定期的なローカルバックアップを要求するのは身勝手なエゴでしかありません。
そもそも画像のサイズ間違え画質の不具合等で、自動バックアップ自体必要ないですよね。 その判断を管理者がするのは違うのではないかと思いますが如何でしょうか？
運営に大規模改修が、必要かどうかは分かりませんが、前述の通り 管理者はいかなる理由があろうとも情報を提供して頂いているだけなので 本当に必要であれば、手動で定期的なローカルバックアップを取れば良いことなので 更に最悪の場合は、運営側でもバックアップを取られているかと思いますので 管理者が運営側に、問い合わせれば問題なないかと思います。 ですが、画像のサイズ間違え画質の不具合等などのバックアップは 自動であっても手動であっても必要ないかと思いますが。
エゴを言っているわけではなく、もっと自由性を高めるために提案をさせて頂いただけです。 ただ、大規模改修が必要であるのであれば確かにエゴになるかも知れませんが。
木主はバックアップのことなど話していません。 木主の要求（提案）は、先に添付ファイルを削除→その後にページの削除という手順が要求される現状を変えて欲しいという事でしょう。 ページを削除した後からでも添付ファイルが削除できるようにするか、 ページを削除すると添付ファイルも同時に削除されるようにして欲しいという要望です。 （バックアップは別です）
尤も手順を守って削除すればいいだけの話ですし、 うっかり添付ファイルのことを失念して先にページを削除しても、 もう一度同名ページを作成すればいいだけの話なので、重要度は低いと思いますが。 添付ファイルは他ページが参照している可能性もあるので削除は慎重であるべきで、 荒らしによるページ削除からの復旧の手間を考えても、 「ページ削除→同時に自動で添付ファイルも削除」はやめた方が良いと思います。
ページ（記事）にせよ添付ファイルにせよ、 （管理者以外による）バックアップの削除など論外です。 理由があって添付ファイルのバックアップを削除したい場合は、 その理由を管理者に告げ、後は管理者の判断になります。 削除に要する時間は1分程度ですし、それが管理者の役割（の一つ）ですので、 あなたが責任だの負担だのと気にする必要はないです。
「何度も失敗する」「恥ずかしい」というのはあなた個人の事情なので、 第三者にはどうでもよい理由です。 そのような理由で自動バックアップに事実上の穴を開けさせ、 運営には大規模改修を、管理者には手動で定期的なローカルバックアップを要求するのは身勝手なエゴでしかありません。
こちらも通報画面に使われている文字色の変更によって、視認性が良くなったことを確認いたしました。ご対応ありがとうございます。
https://nulljapan.jp/presen-black-back/ 例えば、黒背景に濃い青色は見にくいですし、白背景に黄色は見にくいです。逆に黒背景に黄色は見やすいですし、白背景に濃い青色は見やすいです。
引き続き、視認性改善に向けた対策をお待ちしております。
対策が取られ、コントラストの暗いwikiwikiでも常時、閉じるボタンの認識が出来るようになりました。ご対応ありがとうございます。
ご対応いただき、どうもありがとうございます。画面下部に常時表示される広告の右上に閉じるボタンが追加され、改善されているのを確認いたしました。
ご返信ありがとうございます。
削除済みページに残った添付ファイルのバックアップデータを管理者でも直接削除できなくなる
あまり詳しくはないのですが ページ自体が削除されても、管理者なら確か削除出来たのではないかと思いますが 「添付ファイルの一覧」「バックアップを含む添付ファイルの一覧」
基本的に、ページと添付ファイルは、紐づけられていますが 管理の方は恐らく別々になっていますので。
ただ、その削除したい添付ファイルを、添付数が増えると探すのが大変かと思います。 なので、こちらのスレの提案とは少し違いますが （それ以前の問題となりますが、添付した時点での話なので） 以前こちらの方で提案させていただいた、スレを代替案として提案させていただきました。
個人的な意見になりますが、基本的に荒らしが云々の前に、添付した本人がサイズや画質などを 間違って添付した場合は、バックアップ自体必要ありませんよね。
皆様と自由にページを、構成していく仕組みである以上 そこまで、管理者や運営などが責任を背負う必要はありませんよね。 添付した本人の自己責任であると考えますが如何でしょうか？ そうすることにより、管理者も管理しやすくなり、編集する人も さらに利便性を向上できるかと思います。
削除済みページに残った添付ファイルのバックアップデータを管理者でも直接削除できなくなる(ダミーページを一度作らないといけない)のはちょっと不便かも…とは思いました。
ひとまず最初に要望しておりましたサービスについてご検討よろしくお願いします
大変遅くなりましたが確認いたしました。この度はご対応いただき感謝申し上げます。
あと追加で、暴走して勝手にアップした本人が バックアップごと削除されてしまうと言うご意見もありますが 管理者側ですべてのページのバックアップを取ることも可能かと思いますので 定期的に管理者側がすべてのページ（添付ファイル）のバックアップとることも 出来るのではないでしょうか？ そもそも、きれいな画像で分かりやすく情報を提供しようと考えている人が 一般論として成功した画像のバックアップを故意的に消そうとは思いませんよね？
更に恐らく運営側でもバックアップは取られていると思いますので 最悪の場合は管理者が運営側に問い合わせればこの問題は解消できるかと思いますが いかがでしょうか？
荒らし行為による削除があった場合でも、有志の方による復旧が可能な仕様となっています。
荒し行為が云々ではなくて画像を添付した本人が サイズ間違え、更に画質の不具合で添付した場合は バックアップなどから差し戻す必要はありませんよね？ バックアップから差し戻す場合は、荒らしなどが悪意を持って いたずらに削除したりした際に、差し戻す必要があるだけなので しかもそのようなものを他の人に見られてしまうと 何か恥ずかしい気持ちにもなりますし、添付するのも躊躇してしまいますよね。
その都度、管理人さんに「間違えて添付したので削除して欲しい」と 言わなければならないのも少し面倒かとも思いますし その都度対応して頂くのも大変かとも思います。
画像添付の際にサイズ間違え、更に画質の不具合などは 添付した後でないと分からないこともありますので バックアップその物の意味がありません。 その為、個々の画像添付者の判断でもバックアップも含めて 削除できるようにして頂きたいです。
具体的な案としては 1段階目で従来通り、誰でも削除でき（バックアップは残ります） 2段階目でバックアップの削除のみ管理者に加えて パスワードの設定等でアップロード者も行えるようにする。
2案目は ドロップダウン方式にして 一般（ここは誰でもOK）、アップロード者、管理者と分けて パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
こんな感じでいかがでしょうか？
>> 1 https://zawazawa.jp/wikiwiki-request/topic/212
是非 参考になさって下さい。
https://zawazawa.jp/wikiwiki-request/topic/212
返信有り難うございます。 tablesortの説明ページを読み飛ばしていました。申し訳ありません。
iOSではメモリ不足時にバックグラウンドのアプリやブラウザタブが再読み込みされることがあるようです。 この動作により、アンカー位置に戻されている可能性があります。
荒らし行為による削除があった場合でも、有志の方による復旧が可能な仕様となっています。 完全な削除には管理権限が必要です。
利便性をさらに向上させるための代替案について、 引き続き他の方と議論を進めていただけますと幸いです。
いただいたご意見は、今後の開発の参考とさせていただきます。
embedプラグインですが、公式が提供していない方法で情報を取得することには、 以下のリスクが伴うため慎重に検討させていただきます。
ご理解のほどお願いいたします。🙇♂️
このBandcampの埋め込みプラグインには、ニコニコ動画のビデオをYouTubeの用に埋め込み出来る機能もあるみたいです。 他にも非常に多くのサービスを埋め込めるプラグインがバンドルされた非常に便利なものですので、導入の検討をお願いします。
BandcampはoEmbedに非対応のため、個別で埋め込みプラグインを用意する必要がありそうです。 https://stackoverflow.com/questions/71066372/wordpress-acf-oembed-field-embedding-bandcamp-content/71066511#71066511
pukiwikiで使用可能なBandcampの埋め込みサービスを発見しました。 https://github.com/ikamonster/pukiwiki-embed-plugins こちらへの対応を検討お願いします。
追加の要望ですが、Bandcampの埋め込みにも対応してほしいです。 音源がBandcampにのみ投稿されていることがあり、埋め込め無いと不便になることがあるからです。
あと、ニコニコ動画を埋め込む際、YouTubeと同様の形でビデオを直接埋め込めるようにしてほしいです。
善処・ご検討された上で断念された旨、承知いたしました。基本的に結合しない形にして運用してまいります。ご報告ありがとうございます。
結合された先頭列についても、保守性や互換性の観点から非対応とさせていただきます。 （エラー表示になる予定です）
かしこまりました。今後もアナウンスがあると今後の方針も決めやすいです。よろしくお願いいたします。
ご確認ありがとうございます。 oEmbed にはセキュリティリスクがあるため、慎重に検討いたします。
具体的には、oEmbed が返す HTML に悪意のスクリプトが含まれる場合、 WIKIWIKI全体が攻撃対象になる可能性があります。
このリスクを軽減するため、安全性を確認し、対策を講じた上で導入を判断します。
結合された場合でも正しく動作するよう対応を進めて参りましたが、 保守性や互換性の観点から、結合は非対応とさせていただくことになりました。 (結合が発生した場合はエラー表示となる予定です)
iPhoneやiPadなどのiOS上のブラウザは、一般的なブラウザとは異なる独自の仕組みで動作しており、 この影響で互換性の問題が生じる場合があります。
結合対応を行うと保守性が悪化するため、現状では対応を見送らせていただきますが、 今後iOSが対応する際には再度対応を検討いたします。
何卒ご理解のほどお願い申し上げます。
互換性や保守性の観点から、tablescroll はテーブル書式にのみ動作する仕様といたしました。
テーブル書式以外の文字列やプラグインが挿入されると、正しく動作しない、 あるいは不安定になる現象が確認されたため、このような対応を取らせていただきました。
仕様をご理解いただき、慎重にご利用いただけますと幸いです。
可処分時間がそれほど作れずに手直しするページが多くて頭を抱えていました。規制内容が緩和されたことで大幅に手直しするページが減り、助かりました。
22日午前1時現在、一時動作不具合となっていたタイトル行セル連結を含むtablesortが正常動作していることを確認できました。
ご対応ありがとうございました。
正常に動作しているのに勝手に使用不可とか、ホントいい迷惑ですよね。
おそらくこの17日の変更が原因だと思うのですが、これまで動作していたタイトル行（|hや|f）のみにセル連結を含む数多くの既存テーブルが、「tablesort の使用方法に誤りがあります」となって動作不具合となっているようです。
全てを再編集するのは非現実的と思われ、タイトル行についてはセル連結を可能とする従来仕様に速やかに戻していただきたいです。
https://zawazawa.jp/wikiwiki-request/topic/214
メッセージを出力するようにしました。
また、一部の環境で動作してしまう問題があったため、
全ての環境で一貫して動作しないように調整しました。
ご連絡ありがとうございます。
上記の不具合、対応しました。
こちら賛同します。部分的なテンプレートなど、全範囲選択+コピーができないような内容において手間やミスの削減に繋がると思います。
"[[]]"で囲う
構文解析
""で囲う
構文解析
SMS認証済みだったのに「認証のない書き込みは制限されています」ってメッセージまた出て書けないけど、バグ？
以前のスレで著作権物の話が出て議論する必要もないことを、レスしている方がおられましたので、一応 注意喚起のつもりでした。不快な思いをさせてしまい大変失礼いたしました。
大変失礼しました。どうやらこちらの思っていたこととはだいぶん違うみたいですね。
仰る通り、木主の要求（提案）は、先に添付ファイルを削除→その後にページの削除という手順が要求される現状を変えて欲しいという事みたいでバックアップまでは触れられてないみたいです。
すり替えたつもりではありませんが管理上の事、そして添付ファイルのことなどかと思い
代替案として提案させていただいた次第です。
こちらも間違っていました。
自動バックアップではなくて、画像のサイズ間違え、画質の不具合等などのバックアップ自体必要ないですよね。と言うことでした。
いずれにせよ、このあたりでこの件は終わりにさせて頂きます。
何か本題をすり替えた様に思われているみたいですが、すり替えたつもりはありませんのであしからず。
誰も著作権のことなど話していません。
他人が立てたトピックに乗っかって何度も話をすり替えないでください。
……呆れてモノが言えません。
なのであなたに対するこれ以上の議論はやめにします。
あらかじめ申し上げておきますが著作権物の話は論外です。
運営・管理者・情報提供者３者 権利はありませんので。
確かに話していませんが、それだったらと思ったので
こちらで以前提案させて頂いた案を、代替案として提案させていただいただけです。
何故管理者の判断になるのでしょうか？
管理者はいかなる理由があろうとも情報を提供して頂いているだけなので
情報提供者の判断でバックアップも含めて削除出来ても問題ないかと思います。
管理者の方の役割と言ってもすぐの事にはなりませんし連絡がつかない場合は論外です。
責任・負担と言うのはついでの物事でその様なこともあるのではないかと言う事です。
それは第三者の方・管理者の方にとってはどうでも良い事かと思いますが
添付ファイルをアップする側としてはそうではないですよね。
その人の立場によって、考え方に違いがあるとは思いますが
気軽にアップする為にもそのようにして頂けたらと思います。
そもそも画像のサイズ間違え画質の不具合等で、自動バックアップ自体必要ないですよね。
その判断を管理者がするのは違うのではないかと思いますが如何でしょうか？
運営に大規模改修が、必要かどうかは分かりませんが、前述の通り
管理者はいかなる理由があろうとも情報を提供して頂いているだけなので
本当に必要であれば、手動で定期的なローカルバックアップを取れば良いことなので
更に最悪の場合は、運営側でもバックアップを取られているかと思いますので
管理者が運営側に、問い合わせれば問題なないかと思います。
ですが、画像のサイズ間違え画質の不具合等などのバックアップは
自動であっても手動であっても必要ないかと思いますが。
エゴを言っているわけではなく、もっと自由性を高めるために提案をさせて頂いただけです。
ただ、大規模改修が必要であるのであれば確かにエゴになるかも知れませんが。
木主はバックアップのことなど話していません。
木主の要求（提案）は、先に添付ファイルを削除→その後にページの削除という手順が要求される現状を変えて欲しいという事でしょう。
ページを削除した後からでも添付ファイルが削除できるようにするか、
ページを削除すると添付ファイルも同時に削除されるようにして欲しいという要望です。
（バックアップは別です）
尤も手順を守って削除すればいいだけの話ですし、
うっかり添付ファイルのことを失念して先にページを削除しても、
もう一度同名ページを作成すればいいだけの話なので、重要度は低いと思いますが。
添付ファイルは他ページが参照している可能性もあるので削除は慎重であるべきで、
荒らしによるページ削除からの復旧の手間を考えても、
「ページ削除→同時に自動で添付ファイルも削除」はやめた方が良いと思います。
ページ（記事）にせよ添付ファイルにせよ、
（管理者以外による）バックアップの削除など論外です。
理由があって添付ファイルのバックアップを削除したい場合は、
その理由を管理者に告げ、後は管理者の判断になります。
削除に要する時間は1分程度ですし、それが管理者の役割（の一つ）ですので、
あなたが責任だの負担だのと気にする必要はないです。
「何度も失敗する」「恥ずかしい」というのはあなた個人の事情なので、
第三者にはどうでもよい理由です。
そのような理由で自動バックアップに事実上の穴を開けさせ、
運営には大規模改修を、管理者には手動で定期的なローカルバックアップを要求するのは身勝手なエゴでしかありません。
こちらも通報画面に使われている文字色の変更によって、視認性が良くなったことを確認いたしました。ご対応ありがとうございます。
https://nulljapan.jp/presen-black-back/
例えば、黒背景に濃い青色は見にくいですし、白背景に黄色は見にくいです。逆に黒背景に黄色は見やすいですし、白背景に濃い青色は見やすいです。
引き続き、視認性改善に向けた対策をお待ちしております。
対策が取られ、コントラストの暗いwikiwikiでも常時、閉じるボタンの認識が出来るようになりました。ご対応ありがとうございます。
ご対応いただき、どうもありがとうございます。画面下部に常時表示される広告の右上に閉じるボタンが追加され、改善されているのを確認いたしました。
ご返信ありがとうございます。
あまり詳しくはないのですが
ページ自体が削除されても、管理者なら確か削除出来たのではないかと思いますが
「添付ファイルの一覧」「バックアップを含む添付ファイルの一覧」
基本的に、ページと添付ファイルは、紐づけられていますが
管理の方は恐らく別々になっていますので。
ただ、その削除したい添付ファイルを、添付数が増えると探すのが大変かと思います。
なので、こちらのスレの提案とは少し違いますが
（それ以前の問題となりますが、添付した時点での話なので）
以前こちらの方で提案させていただいた、スレを代替案として提案させていただきました。
個人的な意見になりますが、基本的に荒らしが云々の前に、添付した本人がサイズや画質などを
間違って添付した場合は、バックアップ自体必要ありませんよね。
皆様と自由にページを、構成していく仕組みである以上
そこまで、管理者や運営などが責任を背負う必要はありませんよね。
添付した本人の自己責任であると考えますが如何でしょうか？
そうすることにより、管理者も管理しやすくなり、編集する人も
さらに利便性を向上できるかと思います。
削除済みページに残った添付ファイルのバックアップデータを管理者でも直接削除できなくなる(ダミーページを一度作らないといけない)のはちょっと不便かも…とは思いました。
ひとまず最初に要望しておりましたサービスについてご検討よろしくお願いします
大変遅くなりましたが確認いたしました。この度はご対応いただき感謝申し上げます。
あと追加で、暴走して勝手にアップした本人が
バックアップごと削除されてしまうと言うご意見もありますが
管理者側ですべてのページのバックアップを取ることも可能かと思いますので
定期的に管理者側がすべてのページ（添付ファイル）のバックアップとることも
出来るのではないでしょうか？
そもそも、きれいな画像で分かりやすく情報を提供しようと考えている人が
一般論として成功した画像のバックアップを故意的に消そうとは思いませんよね？
更に恐らく運営側でもバックアップは取られていると思いますので
最悪の場合は管理者が運営側に問い合わせればこの問題は解消できるかと思いますが
いかがでしょうか？
荒し行為が云々ではなくて画像を添付した本人が
サイズ間違え、更に画質の不具合で添付した場合は
バックアップなどから差し戻す必要はありませんよね？
バックアップから差し戻す場合は、荒らしなどが悪意を持って
いたずらに削除したりした際に、差し戻す必要があるだけなので
しかもそのようなものを他の人に見られてしまうと
何か恥ずかしい気持ちにもなりますし、添付するのも躊躇してしまいますよね。
その都度、管理人さんに「間違えて添付したので削除して欲しい」と
言わなければならないのも少し面倒かとも思いますし
その都度対応して頂くのも大変かとも思います。
画像添付の際にサイズ間違え、更に画質の不具合などは
添付した後でないと分からないこともありますので
バックアップその物の意味がありません。
その為、個々の画像添付者の判断でもバックアップも含めて
削除できるようにして頂きたいです。
具体的な案としては
1段階目で従来通り、誰でも削除でき（バックアップは残ります）
2段階目でバックアップの削除のみ管理者に加えて
パスワードの設定等でアップロード者も行えるようにする。
2案目は
ドロップダウン方式にして
一般（ここは誰でもOK）、アップロード者、管理者と分けて
パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
こんな感じでいかがでしょうか？
>> 1
https://zawazawa.jp/wikiwiki-request/topic/212
是非 参考になさって下さい。
https://zawazawa.jp/wikiwiki-request/topic/212
返信有り難うございます。
tablesortの説明ページを読み飛ばしていました。申し訳ありません。
iOSではメモリ不足時にバックグラウンドのアプリやブラウザタブが再読み込みされることがあるようです。
この動作により、アンカー位置に戻されている可能性があります。
荒らし行為による削除があった場合でも、有志の方による復旧が可能な仕様となっています。
完全な削除には管理権限が必要です。
利便性をさらに向上させるための代替案について、
引き続き他の方と議論を進めていただけますと幸いです。
いただいたご意見は、今後の開発の参考とさせていただきます。
embedプラグインですが、公式が提供していない方法で情報を取得することには、
以下のリスクが伴うため慎重に検討させていただきます。
ご理解のほどお願いいたします。🙇♂️
このBandcampの埋め込みプラグインには、ニコニコ動画のビデオをYouTubeの用に埋め込み出来る機能もあるみたいです。
他にも非常に多くのサービスを埋め込めるプラグインがバンドルされた非常に便利なものですので、導入の検討をお願いします。
BandcampはoEmbedに非対応のため、個別で埋め込みプラグインを用意する必要がありそうです。
https://stackoverflow.com/questions/71066372/wordpress-acf-oembed-field-embedding-bandcamp-content/71066511#71066511
pukiwikiで使用可能なBandcampの埋め込みサービスを発見しました。
https://github.com/ikamonster/pukiwiki-embed-plugins
こちらへの対応を検討お願いします。
追加の要望ですが、Bandcampの埋め込みにも対応してほしいです。
音源がBandcampにのみ投稿されていることがあり、埋め込め無いと不便になることがあるからです。
あと、ニコニコ動画を埋め込む際、YouTubeと同様の形でビデオを直接埋め込めるようにしてほしいです。
善処・ご検討された上で断念された旨、承知いたしました。基本的に結合しない形にして運用してまいります。ご報告ありがとうございます。
かしこまりました。今後もアナウンスがあると今後の方針も決めやすいです。よろしくお願いいたします。
ご確認ありがとうございます。
oEmbed にはセキュリティリスクがあるため、慎重に検討いたします。
具体的には、oEmbed が返す HTML に悪意のスクリプトが含まれる場合、
WIKIWIKI全体が攻撃対象になる可能性があります。
このリスクを軽減するため、安全性を確認し、対策を講じた上で導入を判断します。
結合された場合でも正しく動作するよう対応を進めて参りましたが、
保守性や互換性の観点から、結合は非対応とさせていただくことになりました。
(結合が発生した場合はエラー表示となる予定です)
iPhoneやiPadなどのiOS上のブラウザは、一般的なブラウザとは異なる独自の仕組みで動作しており、
この影響で互換性の問題が生じる場合があります。
結合対応を行うと保守性が悪化するため、現状では対応を見送らせていただきますが、
今後iOSが対応する際には再度対応を検討いたします。
何卒ご理解のほどお願い申し上げます。
互換性や保守性の観点から、tablescroll はテーブル書式にのみ動作する仕様といたしました。
iPhoneやiPadなどのiOS上のブラウザは、一般的なブラウザとは異なる独自の仕組みで動作しており、
この影響で互換性の問題が生じる場合があります。
テーブル書式以外の文字列やプラグインが挿入されると、正しく動作しない、
あるいは不安定になる現象が確認されたため、このような対応を取らせていただきました。
結合された先頭列についても、保守性や互換性の観点から非対応とさせていただきます。
（エラー表示になる予定です）
仕様をご理解いただき、慎重にご利用いただけますと幸いです。
互換性や保守性の観点から、tablescroll はテーブル書式にのみ動作する仕様といたしました。
iPhoneやiPadなどのiOS上のブラウザは、一般的なブラウザとは異なる独自の仕組みで動作しており、
この影響で互換性の問題が生じる場合があります。
テーブル書式以外の文字列やプラグインが挿入されると、正しく動作しない、
あるいは不安定になる現象が確認されたため、このような対応を取らせていただきました。
仕様をご理解いただき、慎重にご利用いただけますと幸いです。