CSSで修正できるかもしれません。表示されないのか、スクロールして確認できるのか教えていただけますか？使用しているブラウザとOSは何ですか？トップに固定表示させることも可能かもしれませんが、問題は、最近一部のブラウザが「工夫」してブラウザバーを下部に移動させていることです。
ブラウザは、モトローラ製スマホの Android 上の Firefox と Chrome です。Discourse アプリでも同じ現象が発生します。
ボタンバーは常に表示されていますが、テキストボックス内で選択範囲が最初の 3 行に含まれている場合、ポップアップメニューの下に隠れてしまいます。
回避策として、最初のテキストの前に 3 回の改行（CR/LF）を挿入し、投稿する前にそれらの余分な改行を削除する方法があります。
「いいね！」 1
はい、ちょうどテストしてみました。おっしゃる意味がわかります。すごくイライラしますよね。でも、私は下部のバーの方がさらにひどいと思います。それに、これをどう実装するか調べる必要があり、その作業には報酬がもらえません。でも、もっときれいな方法があるはずです。他のプロジェクトでも同じ問題に直面しているはずで、標準化された解決策があるでしょう。でも、前述の通り、今は他の優先事項があります。率直に言ってごめんなさい 
編集：追記。右クリック（モバイルではダブルクリック）を無効にする方法はあります。https://stackoverflow.com/questions/381795/how-to-disable-right-click-context-menu-in-javascript しかし、そうするとユーザーはコピーできなくなります。本当に厄介です…
「いいね！」 3
回避策は実用可能ですが、少し不便です。
おそらく、この煩わしさを解決するためのモバイル向け CSS のアプローチがあるはずです。それを探し出す必要があります。
この特殊なケースのために大量のコードを追加するのは、あなたの時間と注意力を無駄にするでしょう（それにオーバーヘッドも増えます）。コミュニティにあなたのプロジェクトを共有してくださり、ありがとうございます。とても親切なことでした。
「いいね！」 3
はい、ご報告ありがとうございます。直しました。
「いいね！」 6
ヒントですが、Rails はいくつかの Ruby クラスに .present? メソッドを追加しており、空文字列との比較よりも優れています。これは主に配列と文字列で機能します。
また、.present? の反対となる .empty? もあります。
「いいね！」 5
このボタンは意図的に削除しました。画像はエディタ経由でアップロードする必要があるためです。しかし、Android の Firefox では何らかの理由でファイル選択メニューがポップアップしないことを発見しました。調査するにはリモートデバッグのインストールが必要となるため、修正には少し時間がかかります。それまでは、画像のアップロードには高度なエディタをご利用ください。
追記：実際には問題なく動作しています。以前にアプリのカメラアクセスを拒否していたため、単に開いていなかったのです。そのため、デスクトップ版と同じ画像アップロードボタンを使用できます。もしご不明な点がございましたら、テスト用にアップロードしたスクリーンショットをご覧ください：
https://cidian.social/t/file-upload-from-mobile/292
「いいね！」 1
ツールバー内で太字、イタリック、リンク、画像アップロードオプションのみを有効にしたいのですが、どうすればよいでしょうか？
「いいね！」 1
完了次第、設定オプションを追加します。
「いいね！」 4
つまり、これに対する回避策はないということでしょうか？プラグイン内で使用されている CKEditor の設定ファイルを編集することはできないのでしょうか？
Image Annotation や BB マークアップなどの他のプラグインとも連携するようにする予定ですか？
「いいね！」 3
わかりました、一点を明確にさせてください。「機能が動作しない」という表現は、WYSIWYG 入力ウィンドウでレンダリングされないことを意味するだけです。最終的な投稿ではすべて正常に動作します。現在のところ、このエディタは Markdown を作成する別の方法に過ぎません。最終的に出力されるのは依然として Markdown です。私の見解では、将来的には「HTML のみ」が正解です。Markdown や BBCode などは、ユーザー体験を過度に複雑にする過去のものです。しかし、すべての BBCode 機能やカスタムプラグインを実装するつもりはありません。それによるメリットがないからです。何よりもまず、自分のユースケースを重視しています。同時に、Discourse の UX を他の人々にとってよりシンプルにすることにも関心があります。エディタ内で Markdown、BBCode、そしてこれらの「タグ」を好む方にとっては、これは適した選択肢ではないかもしれません。
また、この議論をより建設的なものにしていただければと思います。なぜ人々が現在のエディタに代わって WYSIWYG エディタを望むのか、そのユースケースや理由についてお聞かせいただければ幸いです。また、これによってどのようなメリットが得られると期待しているのか、達成したい目標は何なのかにも興味があります。
それが何らかの進展につながるかもしれません。「これらのランダムな機能をすべて無料で実現できるか？」といった問いは、あまり役に立ちません。
よろしくお願いいたします、
Spirobel
「いいね！」 6
HTML へ切り替え、Markdown のサポートを停止すると、プラグインを無効化した後に HTML で作成されたすべての投稿が編集不可能になります。この認識で正しいでしょうか？
「いいね！」 1
@spirobel 個人としてはあなたのプラグインを使っていませんが、その機能には感心しており、素晴らしい努力に敬意を表します！
BBCode がレガシーな構文であることには同意できますが、Markdown が過去のものとみなす考えは私の視点では誤りです。むしろその逆で、基本的な機能セットは長期間存続するでしょう。
主な理由は以下の 2 点です。
- タイプによるフォーマット：タイピングするだけでテキストを正しくフォーマットできるため、集中して効率的にタイピングできます。
- レンダリングされていなくても読みやすい：基本的な Markdown 構文は、生テキストとしても直感的に読み取れるため、多くの理由で非常に便利です。
Markdown の機能を拡張しようとするとき（画像やテーブルなど）、構文が読みづらくなり、入力も面倒なため、機能不全に陥ったり、場合によっては破綻したりすることが多いと思います。
私の見解では、最も優れたエディタはハイブリッドなソリューションを提供すべきです。
- 基本的な構文フォーマットは、編集モードでも構文文字をそのまま表示しながらインラインでレンダリングされます。
- 拡張機能（画像、テーブルなど）は、編集モードでも当然レンダリングされるべきであり、画面上では実際の構文文字で表現されないかもしれません。あえて言えば、これらはプラグインとして扱われ、データタイプに最も適した形式で保存されるべきです。
「いいね！」 6
コメントをいただき、誠にありがとうございます！
おっしゃることはよくわかります。しかし、私はまだ反対の立場です。
長期的に見れば、パワーユーザーにはショートカットの方が有利です。例えば、イタリック体にするショートカットを設けることも可能です。そうすれば、入力しながらショートカットを押すだけで済みます。ショートカットは CTRL+* のようなものでもあり、まるで Markdown を使っているかのようです。
2 点目についてですが、HTML もまた読みやすいと言えます。なぜなら、HTML は常にブラウザでレンダリングされるからです。また、テキストエディタで HTML のコードを見ても、読むことができます。確かに、Markdown の方が少し見栄えが良いかもしれませんが、それはごく基本的な機能に限った話であり、結局のところ大差はありません。
残念ですが、ハイブリッドな解決策は現実的ではありません。私が「HTML のみ」という考え方に傾いた理由の一つは、ユーザーインターフェースの構築に集中でき、言語パーサーのバグをデバッグしながらコンピューター言語学で博士号を取る必要がないからです。私の考えは、技術的負債を増やすのではなく、それを減らすことです。
最終的には、あなたの立場もよく理解できます。私も Markdown に関する文献を読みました。しかし、私にとって、HTML のみのパラダイムの方が、私が目指すものには合っています。また、Markdown が好きな人を変えようとしても無駄だと理解しています。彼らは現在のエディタを使い続けるべきでしょう。しかし、異なるアプローチに興味を持つ層もいるはずです。
このプラグインは、単なる WYSIWYG エディタ以上のものです。私のビジョンは、マークアップ言語を学ぶ必要なく、構造化データを共同で編集できるソフトウェアを Discourse を活用して構築することです。Wikipedia やウィクショナリーのような大規模プロジェクトを見ると、貢献するために必要な形式や手続きが多く、潜在的な可能性があまりにも無駄にされていると感じます。私はその状況を変えたいと考えています。そのためには、Discourse の共同編集機能を活かしつつ、データをシステムに入力するためにマークアップ言語が必要だという概念を捨て去る必要があります。
Discourse で当初 Markdown が採用された理由も理解できますし、その理由も非常に正当なものです。しかし、私の目標は異なるため、私も異なるパラダイムに従っています。
「いいね！」 5
素晴らしいプラグインですね、@spirobel！これは私たちの技術に詳しくないユーザーがまさに必要としているもので、サイトの運営を格段にスムーズにしてくれると思います。お時間を割いてご尽力いただき、ありがとうございます。また、いくつかの気になる点も見つけたので共有させてください。
Shared Edits との競合
このプラグインと Discourse Shared Edits の両方をインストールしたところ、予想通り少し競合していました。ただし、修正可能な問題のようです。互換性を持たせる検討をしてくださるでしょうか？私個人としては、どちらも将来的に不可欠な機能だと考えています。
具体的には、Basic Editor を使って投稿を共有編集すると、既存の投稿テキストが消去されてしまい、編集をロールバックする以外に復元できません。
@メンションで候補が表示されない
Discourse Basic Editor を使うと、@メンションの機能が部分的に壊れてしまうようです。ここであなたをメンションしようとすると、以下のような表示になります：
Basic Editor を有効にすると、候補が表示されなくなります。これは「詳細編集」をクリックした場合も同様です。
「いいね！」 6
はい、これはまだ開発中の段階です。メンション機能については私のリストに記載されています。共有編集についてはまだ確認していませんが、実装は十分に可能です。ただし、共有編集プラグインとの互換性を確保する形で実現する可能性は低いでしょう。基本エディタが導入する変更は非常に大きいため、おそらく基本エディタ内部での解決策が必要になるでしょう。
「いいね！」 4
@sam と話しましたか？彼はその可能性に興味を持っている可能性が高く、確実な助言をくれるはずです。
「いいね！」 1