Скорее всего, это можно сделать с помощью CSS.
Перед последним сообщением я попробовал следующее. Это исправило проблему с размером шрифта в заголовке, но сделало размер шрифта остального списка тем на главной странице очень маленьким.
.featured-topic {
font-size: 9px;
}
Вы имеете в виду эти ссылки?
Если я изменю это, я не вижу никаких изменений на остальной части страницы.
После применения вышеуказанного CSS-кода вы можете увидеть список тем ниже. Шрифт стал довольно мелким.
Я удалил CSS-код, и размер шрифта в списке тем снова стал нормальным.
Понятно. Попробуйте это:
.featured-topic h3 a {
font-size: 9px;
}
Спасибо! Всё работает!
Запрос функции: пожалуйста, добавьте возможность отображать краткое содержание темы
Возможно, функция тегов работает с ошибкой или ведёт себя непредсказуемо при работе с ограниченной группой тегов?
Я создал группу тегов со следующим ограничением:
Теги видны всем, но использовать их могут только следующие группы
→ Администраторы, Модераторы

Я добавил тег ‘featured’ из этого компонента в эту группу.
Вот мои настройки компонента:
Когда я создаю тему как Администратор с тегом featured, этот тег виден мне и модераторам, но не другим группам пользователей. Для других зарегистрированных пользователей он отображается именно так:
Tag1, Tag2,
Для администраторов и модераторов тег featured отображается корректно:
Tag1, Tag2, featured
Ещё один момент: если тег скрыт, я считаю, что запятая не должна отображаться. Это сбивает пользователей с толку.
Также я не уверен, что это имеет значение, но темы находятся в категориях, которые видны только зарегистрированным пользователям, а не гостям.
Кстати, спасибо за компонент, отличная работа! Помимо этой небольшой особенности, он работает у меня идеально!
Ха-ха, я наткнулся на свою старую тему, когда искал информацию по одной небольшой неприятности ![]()
И я снова осознал, что фактические загружаемые изображения огромны по сравнению с их реальным отображаемым размером. В моём случае загружается изображение 1000x1000 пикселей, а отображается оно размером менее 200 пикселей.
Я проверил некоторые данные, и если бы я мог заменить их на версию 400x400 пикселей, это сэкономило бы около 83% трафика (для строки с рекомендуемыми постами), или 1,6 МБ в сумме. Я знаю, что эти изображения кэшируются, но это определённо повлияет на начальную загрузку страницы, и, полагаю, это также не способствует ускорению отрисовки страницы, верно? Я использую эти рекомендуемые изображения на каждой странице моего форума, поэтому, думаю, влияние действительно ощутимо.
Было бы возможно добавить опцию в конфигурацию TC, чтобы мы могли выбирать размер изображения, и тогда каждый мог бы настроить это под свою тему?
Отличное замечание! Я давно не смотрел на этот компонент, так что смог провести общее улучшение:
https://github.com/discourse/discourse-homepage-feature-component/pull/96
Теперь изображения используют srcset, поэтому для контейнера автоматически выбирается подходящий размер. Доступные размеры можно задать с помощью новой настройки featured_image_sizes.
Также я исправил настройку «скрыть метку featured» (она не работала, поэтому метки всегда были скрыты) и заменил текстовое поле на настройку типа «теги». Теперь при желании можно использовать несколько тегов.
Отлично, спасибо! Думаю, это также решает проблему с отсутствующим тегом «featured», которая меня очень смущала.
Одна вещь: после обновления это запустило ОЧЕНЬ много задач по обработке изображений — у меня сейчас в очереди более 20 тысяч. Это нормально? Кажется, это довольно расточительно, ведь мне нужны только последние 5…
Хм, да, справедливое замечание, к сожалению, избежать этого невозможно. Думаю, вероятно, стоит отменить эту часть из-за этого. Я делаю это здесь:
Дело в том, что я не могу создать целевое подмножество оптимизированных миниатюрных изображений из темы таким образом, это должно быть всё или ничего. Поэтому нам понадобится какой-то другой метод оптимизации для более ограниченных случаев, подобных этому.
Понял. Будут ли ненужные миниатюры автоматически удалены позже?
И похоже, что в моей теме уже есть несколько разных форматов изображений, которые могут работать нормально — например, 400x400 или 500x500. Как насчёт того, чтобы сделать их настраиваемыми? По сравнению с текущим 1024x1024 это уже даст хорошую экономию пропускной способности, и без дополнительных затрат на обработку/хранение.
(игнорируйте 300x300, 600x600 и 900x900, которые были добавлены обновлением TC):
-rw-r--r-- 1 1000 www-data 723K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1000x1000.jpeg
-rw-r--r-- 1 1000 www-data 757K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1024x1024.jpeg
-rw-r--r-- 1 1000 www-data 30K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_200x200.jpeg
-rw-r--r-- 1 1000 www-data 68K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_300x300.jpeg
-rw-r--r-- 1 1000 www-data 118K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_400x400.jpeg
-rw-r--r-- 1 1000 www-data 185K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_500x500.jpeg
-rw-r--r-- 1 1000 www-data 263K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_600x600.jpeg
-rw-r--r-- 1 1000 www-data 417K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_750x750.jpeg
-rw-r--r-- 1 1000 www-data 470K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_800x800.jpeg
-rw-r--r-- 1 1000 www-data 595K Jun 30 22:18 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_900x900.jpeg
Думаю, нет, потому что исходные изображения всё ещё используются, а это их оптимизированные версии. Никакого реального вреда, кроме как занимать место на диске.
Вы можете очистить их через консоль Rails. Этот код охватывает размеры, которые были включены по умолчанию для этой настройки, и не удалит изображения, созданные другим модификатором.
# 1. Посмотрим, что реально существует, а что всё ещё легитимно зарегистрировано
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. Удаляем ненужные размеры (файлы + записи)
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # не трогаем размеры, которые всё ещё используются чем-то другим
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# записи-попытки без оптимизированного изображения не удаляются каскадно
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
О, да, отличная идея — я могу проверить, какие миниатюры уже существуют, и если они есть, использовать наиболее подходящий размер. Если доступны только оригиналы, они всегда будут работать как запасной вариант.
Реализую это здесь:
Отлично, я проверю это сегодня вечером!
И я только собирался вернуться сюда, чтобы повторить свой старый запрос: возможно ли добавить опцию сортировки строки избранных по дате добавления тега? Наш порядок избранных не определяется датой создания темы ИЛИ последней активностью — для нас порядок должен определяться моментом, когда мы применяем тег. Я не осознавал этого раньше, но сейчас наша строка избранных выглядит немного хаотично ![]()
К сожалению, я не думаю, что это возможно… у нас нет способа сортировать список тем по дате добавления тега. Одним из возможных решений было бы изменить временную метку темы?
Ничего страшного. Пока я обхожу эту проблему с помощью «скотча»: я сделал форк вашего TC и создал запрос в Data Explorer, чтобы получать избранные темы, отсортированные по дате тега и включая URL изображений. Небольшой внешний веб-скрипт загружает и кэширует эти данные, а затем возвращает JSON в TC. Работает как часы, хоть и выглядит немного криво ![]()
С радостью поделюсь своим кодом и запросом, если кому-то понадобится.



