それはバグですね。調査が必要です。よく見つけました！
「いいね！」 4
素晴らしい、PRありがとうございます、マージしました！
「いいね！」 4
3つの課題：
- サムネイルはここでシリアライズされていないと思います。確認してください。サイドカープラグインを強化することで克服できるかもしれません。
- 前回確認したとき、ページの構造ではリーフテンプレートに限定された低リスクのオーバーライドが許可されていませんでした。一般的に、ページ全体をオーバーライドしたくはありません。これは、破壊的な変更を引き起こしたり、コアからの機能更新をマスクしたりする可能性があるためです。コアへのPRが役立つかもしれません…
- スペース？
必要なPRを自由に提出してください。
「いいね！」 1
もっともな点です。カテゴリページには、ボックス表示などの別の表示方法を選択するかもしれません。
別の質問があります。
トピックリストを含むカテゴリページを、モバイルではタイル表示、デスクトップではサムネイル表示にすることは可能でしょうか？いくつかの設定を調整してみましたが、達成できませんでした。
編集：達成できました。後で、他の誰かの役に立つかもしれないので、どのように達成したかを詳しく説明します。誰も時間をかけて説明してくれる必要がないように、この編集を追加しました。
まず、タイル表示がモバイルビュー（少なくとも）のトピックリストにのみ表示されるようにする必要があります。
次に、デスクトップとモバイルの両方でサムネイルを表示します。
最初に、タイルとサムネイルが、画像を含むトピックリストの2つの異なる表示方法であると考えていましたが、そうではありませんでした。タイル表示であっても、画像を表示するにはサムネイルが必要です。
ここにカテゴリを手動で追加する必要はありません。
以下の設定を有効にすることで、この設定を上書きするためです。
これで、デスクトップでは、任意のトピックリスト（最新、特定のカテゴリなど）に小さなサムネイルが表示され、モバイルでは大きなサムネイルを備えた「タイル」表示になります。
「いいね！」 2
ユーザープロフィールに小さな問題があります。おそらく小さなバグだと思います。
サムネイルについて言及しているので、このテーマコンポーネントに関連していると思われます。
ちなみに、このテーマコンポーネントでまだ遊んでいます…素晴らしいです。
ちなみに、このテーマコンポーネントでまだ遊んでいます…素晴らしいです。
質問があります。トピックに画像が含まれているにもかかわらず、サムネイルが表示されないようにすることは可能でしょうか？
私のケースです。
ドキュメントカテゴリがあり、サムネイルは歓迎されます。
しかし、新しいトピックを作成する際に一般的なアドバイスを提供するトピックもあります。
意味のある画像はありませんが、自動的にサムネイルが追加されます。
この問題を回避する唯一の方法は、トピックのどこかにランダムな画像を追加し、それをサムネイルとして設定することだと思います。
例：
（しかし、見た目は良いと認めます…）
「いいね！」 1
はい、そのローカライゼーションは失敗しており、修正が必要です。
いいえ、画像があればそれを使用しようとします。追加で素敵な画像を追加するのは完璧な回避策です
これにより、ページのレイアウトの一貫性も向上します。
いずれにしても、そのような投稿をトップで要約するために、フィーチャーされたトピックコンポーネント（組み込みのTLPのものか別のもの）をよく使用するため、画像があると非常に便利です。
「いいね！」 1
サムネイルとタイルを特定のタグと一部のカテゴリに制限しようとしていますが、タグでうまくいきません。ここに私の設定ページがあります。フィーチャーされたタグのタイルとサムネイルのみが必要です。何か間違っているか教えていただけますか。
プラグインの設定にも文字列がありません。
また、トピックリストの抜粋からリンクを削除するオプションにもバグがあります。
すでに報告されているように、無効にすると、テキストだけでなく「続きを読む」ボタンもまったくリンクがなくなります。
有効にすると、抜粋にリンクと「続きを読む」リンクが表示されますが、何らかの理由で、
-
「続きを読む」リンクがリンクとしてスタイル設定されていません（これもすでに報告されていますが、すべて同じオプションに関連しているため、すべての問題をまとめて報告することにしました）。
-
一部の抜粋が誤って折り返されています。例：
ここでは、抜粋の文の最初の部分のみが折り返されています。
抜粋として空行が折り返されています。
さらに協力できれば嬉しいのですが、残念ながらプラグインやDiscourseのコードのほとんどについては何も知りません… 
「いいね！」 1
それはバグのように見えます。すぐに確認します。
「いいね！」 3
beta ブランチで修正しました。問題がないか確認していただけますでしょうか。その後、マージします。
これが機能するためには、tag と tag-mobile を削除し、特定のタグをタグリスト設定に追加する必要があります。
（ベータ版を別のコンポーネントとしてインストールし、テストテーマに関連付けます。）
コアでの破壊的変更であることが判明しました。
詳細設定ボタンを使用してブランチを表示し、「beta」と入力してください。
しばらくご連絡がない場合は、そのままマージしますが、テストしてフィードバックをいただくチャンスです。
「いいね！」 1
これは、
を少しずつ行い、途中で知識を拾い集めることでしか得られません 
「いいね！」 3
テーマコンポーネントがインストールされている場合、ウェブサイトをナビゲートするとJSエラーも発生します。
あなたのウェブサイトでも確認できます: https://starzen.space/
任意の投稿をクリックして、JSコンソールを確認してください。
TypeError: Cannot read properties of null (reading 'querySelector')
エラーは、このDiscourseファイルのこの行でトリガーされています:
「いいね！」 1
コアにおける破壊的変更のようです: FIX: Don't listen for focus/blur events if the topic-list opts out of… · discourse/discourse@97e7bb1 · GitHub
主に以下のコミットで修正されました: COMPATIBILITY: add css class to tiles to support focus · merefield/discourse-tc-topic-list-previews@4f0f0f0 · GitHub
私のサイトでデモしたように、beta ブランチで修正しました。
このように修正する利点は、タイルに最後の閲覧インジケーターが表示されるようになったことです
（ほとんどのエラーはモバイルでも消えましたが、このインジケーターは通常モバイルでは表示されないため、これで修正とみなします！）
タイトル要素に関連する、より頻度の低いエラーについては、今後対応する必要があります。
「いいね！」 1
これはbetaで修正されました：FIX: missing localisation on user prefs and update locale paths
「いいね！」 1
ありがとうございます！
プラグインの「トピックリスト抜粋リンク削除」オプションについて、現在使用されている正規表現を変更することを提案してもよろしいでしょうか？
URI::regexp は、リンクパターンを持つあらゆる文字列を削除しますが、これは必ずしも望ましいとは思いません。
リンクのテキストコンテンツが href 値と同じであることが時々あります。これはフォーラムでは非常に一般的なケースであり、テキストコンテンツを削除すると、意味をなさない文章が含まれる奇妙な抜粋につながる可能性があります。
この正規表現は、リンクの内側または外側にある単語も削除することがあります。以下に例を示します。
別の正規表現との比較： \u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
これは単なる例の正規表現です。URI::regexp がリンクをより複雑に（そしておそらくより確実に）処理することは理解しています。
以下は投稿の例です。
そして、トピックリストでの抜粋結果：
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
（Facebookリンクのテキストコンテンツが削除され、「Astronomy Picture of the Day」の「Day」という単語も不明な理由で削除されました
）
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
別の例です。抜粋を読むのを奇妙にするリンクテキストコンテンツの削除についてです。
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
（「リンクは『This may be my favorite halo』でしたか？」）
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
（これで意味が通じます）
したがって、\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e がより優れていると提案しているわけではありません。これは単なる簡単なテストでしたが、URI::regexp を使用することが、私が述べた 2 つの理由（リンクのテキストコンテンツが消え、抜粋が奇妙になることがあること、そして時折不明な理由でリンクの内側または外側の単語を削除すること）に関して最良の選択であるかどうかはわかりません。後者の問題は、軽視できないほど頻繁に発生するように思われます。
「いいね！」 3
現在の方法の欠点（現在のアルゴリズムの驚くほど奇妙な過剰な熱意により、削除しすぎることも含みます）は理解していますが、経験を経てここにたどり着きました。
このオプションが存在する主な理由は次のとおりです。
- リンクが非常に長い場合のプレビューの書式設定を保持する（つまり、すべてのリンクを削除して、長いリンクが決して抜粋に漏れ出して問題を引き起こさないようにする）。非常に非常に長いリンクのシナリオを試してください。古いサポートトピックは、長いリンクを含むトピック投稿に関する問題で散乱しています。
- 抜粋を予測可能なクリックサーフェスとして保持し、常にトピックに移動するようにします。テキストが小さすぎるため、これは任意ではありません。
また、次のようにもなるはずです。
- 保守が容易で、サポートのノイズを引き起こさない。現在の方法はサポートされているユーティリティクラスであるため、保守を心配する必要はありません。
一般公開のためにこれを変更する必要があるとは、まだ確信が持てません。
オフ、リンクなし（現在の方法）、実験的という3つのオプションの選択肢を設けることは検討してもよいかもしれません。PRを歓迎します。まず、現在のサイドカーコードをマスタープラグインブランチに移動します。今週中にそれをやろうとします。
「いいね！」 3
返信ありがとうございます 
前の投稿の最後の文を修正しました。単語を忘れていました…
書いたのは
リンクの内側または外側の単語が、不可解な理由で時々削除されます。後者の問題は、無視できるほど頻繁に発生するようです。」
「not」を忘れていましたので…
リンクの内側または外側の単語が、不可解な理由で時々削除されます。後者の問題は、無視できないほど頻繁に発生するようには見えません。
コードのことはあまり理解できないかもしれませんが、今日、ここで言及した問題2を理解して修正しようと思います: Topic List Previews (TLP) - #110 by Canapin
（抜粋が .topic-excerpt で適切にラップされていません。ラッパーは、抜粋の終わりではなく、抜粋に含まれる最初のリンクの直前で閉じられるようです）
正直なところ、そのユーティリティのメンテナーに問題を提起して修正してもらうのが最善のアプローチかもしれませんね？それは確かに期待どおりに動作していませんよね？
ええ、まだ見ていません。それまでの間、自由にプルリクエストで修正してください。
「いいね！」 1
ありがとうございます。そのことは考えていませんでした。このユーティリティがどこから来たのか全く知りませんでした。
少し調べてみたところ、基本的に正規表現は、コロンの直後に続く限り（つまり、間にスペースがない限り）、単語や文字列をURIスキームの一部として認識します。これは理解できますが、英語（例えばフランス語とは対照的に）では単語とコロンの間にスペースを入れないため、少しやりすぎでもあります。そのため、「正当な」単語が、不幸にもコロンに続いているという理由だけで正規表現に食われてしまいます。
修正としては、プラグイン設定に、削除したいスキームを入力できるフィールド（既存のインストールに害を与えないように、デフォルトは空）を設けることが考えられます。
例えば、設定は以下のようになります。
削除するURIスキーム: http|https|ftp|mailto
これにより、以下のような結果になります。
#{URI::regexp(['http', 'https', 'ftp', 'mailto'])}
（ただし、残念ながら大文字小文字を区別しますが、これは確実に何らかの方法で調整できるはずです）
設定が空の場合、以下が使用されます。
#{URI::regexp}
これは現在の動作です。
このような設定を持つプルリクエストは歓迎されますか？