なぜ、十分なサイズの画像がダウンロードされているにもかかわらず、API はしばしばサムネイルの作成に失敗するのでしょうか?
例えば、投稿の冒頭に以下を貼り付けると…
この onebox は 690 x 465 の十分なサイズの画像をダウンロードします:
それでも、トピック用のサムネイルは作成されません。
なぜ、十分なサイズの画像がダウンロードされているにもかかわらず、API はしばしばサムネイルの作成に失敗するのでしょうか?
例えば、投稿の冒頭に以下を貼り付けると…
この onebox は 690 x 465 の十分なサイズの画像をダウンロードします:
それでも、トピック用のサムネイルは作成されません。
画像のサイズに基づくものではありません。一般的に、ワンボックスから画像を取得することはありません。多くの場合、それらはサムネイルとして役に立たないからです。例えば、Meta でよく見られるのは、GitHub のリポジトリリンクです。
誰も私の顔が拡大されてトピックのサムネイルになることを望んでいません ![]()
それはメタに特有の制限ですね。当コミュニティにはGitHubのリンクはありません。すべてがニュース中心であり、onebox画像を使用すべきです。この「顔」の問題により、サムネイルの表示が非常に制限されています。この「顔」の問題に起因するメタの制限を回避し、oneboxから画像を追加する潜在的な方法はありますか?多くのコミュニティはGitHubの「顔」には関心がないと思います。
ここでの改善には大歓迎です。@merefield もこのロジックに関心があることは知っています。この変更はプラグインではなく、コア側で行う必要があるため、これを独立したトピックとして分けます。
既存のロジックは以下の通りです:
特定の種類のワンボックス(例:GitHub)に .no-thumbnail クラスを追加し、Discourse がそれらのみを無視するように設定し、他のワンボックス画像はそのまま表示させることも可能かもしれません。
この件に pr-welcome ラベルを付けますが、本格的な作業を行う前に、このトピックで計画を明確にしてください。
それは素晴らしいですね。現在、当社のトピックの90%はサムネイルが表示されていませんが、表示できる可能性があります。前述の通り、このGitHubの課題は開発者コミュニティに特有の非常に特殊なケースであり、それ以外の大部分のユーザーは、この問題により、明らかにサムネイルを表示できるトピックについてもサムネイルが表示されない状態になっています。
これに賛成です!!!ニュースアグリゲーターやリポスト中心のページなどの用途では、関連するサムネイルがないのは致命的です。
もし皆さんが近々これを統合しない場合、自分でホストしているディストリビューションでこれをどう実現するかアイデアはありますか?
はい、現在は「GitHub のアバター」を Meta などの開発者コミュニティで表示するオプションは検討されていません。しかし、コミュニティの大多数はアバターに関心を持たず、可能な限り多くのサムネイルを表示したいと考えています。特に、投稿者(OP)に対して十分なサイズのワンボックス画像が利用可能な場合、その傾向は顕著です。
あの OP の例は、トピック一覧のプレビューでは正しく表示されます。なぜなら、このプラグインではより広範な基準を使用しているからです。
def extract_images_for_post
# src 属性を持つすべての画像
@doc.css("img[src]") -
# イモジを除外
@doc.css("img.emoji") -
# 引用内の画像を除外
@doc.css(".quote img") -
# ワンボックスのサイトアイコンを除外
@doc.css("img.site-icon") -
# ワンボックスのアバターを除外 #Discourse コアよりも広範な基準
@doc.css("img.onebox-avatar")
end
はい、merefield さん、ありがとうございます。私たちは TLP TC ではなく、david さんのテーマコンポーネントを使用しています。ただし、この件についてチームから進展やオプションが提供されない場合、あなたの評価を使ってコアをパッチする可能性があります。
上記のレンダリングは TLP TC のものですが、はい、私はバックエンドプラグイン(テーマ「サイドカー」)を使用して Ruby を変更しています :)。https://github.com/merefield/discourse-topic-previews/tree/theme_sidecar ホストされている場合、それが選択肢にならない可能性もあることは理解しています。
これは完全に議題に上がっています。そのため、pr-welcome というタグが付いています ![]()
実装のきっかけとなる情報は、こちらの投稿をご覧ください。
@merefield PRを作成していただけますか?残念ながら、私はRubyが全くの初心者です。あるいは、PRのプロセスはどのように進めますか?
@david 確かに、このオーバーライドをプラグインから削除し、コア側の解決策を合意することが最善だと考えます。
@Terrapop 以下は Contributing to Discourse development です。
これについてより直接的なサポートをしたいのですが、現在クライアントワークで手一杯です。
承知いたしました。現時点では、シンプルなプラグインやコアパッチの開発のための簡易な Docker 開発環境を用意しています。その間、この件を確認していただける方が現れるのを待ち、おそらく評価版を通じてパッチを適用することになるでしょう。
ここでの適切な対応は、単なる抽象的な作業ではありません。テストケースの変更が必要であり、2 つのコンポーネント(Discourse と Discourse Onebox)の両方に関わる作業だからです。ただし、行う価値は十分にあります!
ちなみに、Ember に慣れた後なら Ruby は恐れる必要はありませんよ ![]()
はい、残念ながらこれは現在の私の範囲や能力を超えています。
回避策として、私はよく画像を手動でコピーしてウィスパーに貼り付け、そこからサムネイルを選択しています。
自動だとより良いですね。例えば、GitHub のケースをカバーするために、特定のドメインからサムネイルを取得しないようにする設定項目があるとよいかもしれません。
同意します。私たちは @merefield のスニペットを使用して、コアをミニプラグインで上書きしました。しかし、コアチームが最初から何かを提供するのは簡単であるはずです。一部の人が自分の GitHub のプロフィールが表示されることを恐れているという理由だけでこれを欠かすのは、単なる怠慢です。
FEATURE: Allow onebox images to be used as topic thumbnails (#12050) · discourse/discourse@b770c30 · GitHub をマージしました。これにより、Onebox の画像をトピックのサムネイルとして選択できるようになりました。GitHub の Onebox については特別な例外を設けており、必要に応じてさらに例外を追加することも可能です。
(cc @Terrapop @merefield)