該当Wikiを閲覧しましたが、私の環境では何も起きていません。 環境はAQUOS R9、Android 14、Google Chrome v132.0.6834.79、ATOK for Android（※サポート終了の単品版）です。 その場でGboard v14.9.07.696880419に切り替えても、MenuBarで確認しても同じです。
起きた・起きてないの各種環境が出揃わないと何も解決しない気がします。 多数の情報が必要かと思います。
起きてますねw 少なくともAndroidでは、MenuBarに設置したsearch、lookupどちらも指摘通りの問題が起きてます。
太鼓の達人 譜面とかwiki*にて起きています。（他のサイトでも同様起きているらしいです。）
少なくとも、私のサイトでは問題ありません。某サイトを明らかにされないと運営側は何が原因で不具合が発生しているか把握できないので改善できないかもしれません。
こちら白色のアイコンになっていることを確認しました、かなり見やすい…！ 対応ありがとうございます。
改善されたことを確認しました。
当方のwikiでは改善されてないなーと思って調べてみたところ、 ヘッダー行を2行で使う場合、両方に|hを付けないとダメみたいですね。 （連結するのであれば本来は1つでいいはずなんですけど） 回避策がないと思って諦めていましたが、一先ずほっとしました。
可処分時間がそれほど作れずに手直しするページが多くて頭を抱えていました。規制内容が緩和されたことで大幅に手直しするページが減り、助かりました。
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 こちらへの対応を検討お願いします。
該当Wikiを閲覧しましたが、私の環境では何も起きていません。
環境はAQUOS R9、Android 14、Google Chrome v132.0.6834.79、ATOK for Android（※サポート終了の単品版）です。
その場でGboard v14.9.07.696880419に切り替えても、MenuBarで確認しても同じです。
起きた・起きてないの各種環境が出揃わないと何も解決しない気がします。
多数の情報が必要かと思います。
起きてますねw
少なくともAndroidでは、MenuBarに設置したsearch、lookupどちらも指摘通りの問題が起きてます。
太鼓の達人 譜面とかwiki*にて起きています。（他のサイトでも同様起きているらしいです。）
少なくとも、私のサイトでは問題ありません。某サイトを明らかにされないと運営側は何が原因で不具合が発生しているか把握できないので改善できないかもしれません。
こちら白色のアイコンになっていることを確認しました、かなり見やすい…！
対応ありがとうございます。
改善されたことを確認しました。
当方のwikiでは改善されてないなーと思って調べてみたところ、
ヘッダー行を2行で使う場合、両方に|hを付けないとダメみたいですね。
（連結するのであれば本来は1つでいいはずなんですけど）
回避策がないと思って諦めていましたが、一先ずほっとしました。
可処分時間がそれほど作れずに手直しするページが多くて頭を抱えていました。規制内容が緩和されたことで大幅に手直しするページが減り、助かりました。
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
こちらへの対応を検討お願いします。