О, это точно баг. Нам нужно будет это проверить, хорошая находка!
4 лайка
Отлично, спасибо за PR, объединено!:
4 лайка
Три проблемы:
- Я довольно уверен, что миниатюры здесь не сериализуются. Проверьте, пожалуйста. Это можно решить, доработав плагин-спутник.
- В последний раз, когда я изучал это, структура страницы не позволяла применять безопасные переопределения только для шаблона листа. Обычно мы не хотим переопределять всю страницу, так как это может привести к нарушению работы или скрыть обновления функций из ядра. Возможно, поможет pull request в ядро…
- Место?
Не стесняйтесь отправлять необходимые pull request.
1 лайк
Справедливые замечания. Возможно, я выберу другой вариант отображения для страниц категорий, например, в виде плиток или что-то подобное.
У меня ещё один вопрос.
Возможно ли настроить отображение страниц категорий (содержащих списки тем) в виде плиток на мобильных устройствах, но с миниатюрами на компьютере? Я пробовал различные настройки, но не смог этого добиться.
edit: Мне удалось это сделать. Позже я подробно опишу, как именно, на случай, если это кому-то пригодится. Я добавил эту правку, чтобы никто не тратил время на объяснение того, как это сделать 
Итак, если я не ошибаюсь, вот настройки…
Сначала нам нужно, чтобы плитки отображались только на мобильной версии (по крайней мере?) списка тем:
Затем миниатюры для компьютера И мобильного устройства:
Сначала я ошибся, так как думал, что «плитки» и «миниатюры» — это два разных способа отображения списка тем, и оба содержат изображения. Но это не так. Миниатюры необходимы, если вы хотите, чтобы изображения отображались в списке тем, независимо от того, используется ли плитка или нет.
Здесь нет необходимости вручную добавлять свои категории:
Поскольку мы переопределим эту настройку, включив следующую:
Теперь у вас должны быть небольшие миниатюры на компьютере в любом списке тем (последние, конкретная категория и т. д.), а на мобильном устройстве — представление в виде плиток с крупными миниатюрами:
2 лайка
У меня небольшая проблема с профилем пользователя, думаю, это мелкий баг:
Поскольку упоминается миниатюра, предполагаю, что это связано с этим компонентом темы.
Кстати, я всё ещё экспериментирую с этим компонентом темы… И он великолепен. 
У меня вопрос. Можно ли запретить теме иметь миниатюру, даже если в теме есть изображения?
Вот мой случай:
У меня есть категория документация, где миниатюры приветствуются.
Но также у меня есть тема, которая содержит общие советы по созданию новой темы:
В ней нет осмысленного изображения, но миниатюра добавляется автоматически:
Единственный способ обойти эту проблему, который я вижу, — добавить случайное изображение в какой-то момент темы и установить его как миниатюру.
Пример:
(хотя признаю, выглядит это неплохо…)
1 лайк
Да, локализация не работает, и её нужно исправить. 
Нет, если есть изображение, система попытается его использовать. Добавление ещё одного хорошего изображения — идеальное решение
Это также улучшит согласованность макета вашей страницы.
В любом случае я часто использую компонент «Избранные темы» (встроенный TLP или другой), чтобы подытоживать такие посты вверху, поэтому наличие изображения очень кстати.
1 лайк
Я пытаюсь ограничить миниатюры и плитки определённым тегом в дополнение к определённым категориям, но это не работает для тегов. Вот моя страница настроек: я хочу видеть плитки и миниатюры только для тега «featured». Подскажите, пожалуйста, делаю ли я что-то не так.
Также в настройках плагина отсутствует строка:
Ещё одна ошибка связана с опцией «Удалять ссылки из краткого содержания темы».
Как уже сообщалось, если её отключить, ссылки полностью исчезают — вместе с их текстом, а также кнопкой «Читать далее»:
Если же опцию включить, ссылки в кратких содержаниях появляются, как и ссылка «Читать далее», но по какой-то причине:
-
Ссылка «Читать далее» не оформлена как ссылка (об этом тоже уже сообщалось, но так как все эти проблемы связаны с одной и той же опцией, я предпочитаю объединить их в одном сообщении):
-
Некоторые краткие содержания обернуты неправильно. Вот несколько примеров:
Здесь обернута только первая часть предложения из краткого содержания:
Пустая строка обернута как краткое содержание:
Я с радостью помогу ещё, но, к сожалению, ничего не знаю о плагинах и большей части кода 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: ИСПРАВЛЕНИЕ: отсутствует локализация в настройках пользователя и обновлены пути локализации
1 лайк
Спасибо!
Касательно опции плагина topic list excerpt remove links, могу ли я предложить изменить используемый вами регулярный выражение?
URI::regexp удаляет любую строку, содержащую шаблон ссылки, что, на мой взгляд, не всегда желательно.
Иногда текст ссылки совпадает со значением её атрибута href. Это даже очень распространённый случай на любом форуме, и удаление текстового содержимого может привести к странным отрывкам с предложениями, лишенными смысла.
Это регулярное выражение также иногда удаляет слова, находящиеся как внутри, так и вне ссылок. Примеры приведены ниже.
Вот сравнение с другим регулярным выражением: <a .+?\>(.+)?<\/a>
Это лишь пример регулярного выражения; я понимаю, что URI::regexp обрабатывает ссылки более сложным (и предположительно более надежным) способом.
Вот пример поста:
А вот получившиеся отрывки в списке тем:
URI::regexp
↓
(текстовое содержимое ссылки Facebook удалено, а также по неизвестной причине было удалено слово “Day” в фразе “Astronomy Picture of the Day”
)
<a .+?\>(.+)?<\/a>
↓
Ещё один пример, касающийся удаления текстового содержимого ссылки, из-за чего отрывок становится странным для чтения:
URI::regexp
↓
(«ссылка была This may be my favorite halo»…?)
<a .+?\>(.+)?<\/a>
↓
(теперь это имеет смысл)
Итак, я не утверждаю, что <a .+?\>(.+)?<\/a> лучше, это был лишь быстрый тест, но я не уверен, что использование URI::regexp является лучшим выбором с учётом результатов. Это касается обеих причин, которые я упомянул: исчезновение текстового содержимого ссылок, что иногда делает отрывки странными, а также удаление слов внутри или вне ссылок по неясным причинам. Последняя проблема, кажется, встречается достаточно часто, чтобы не игнорировать её.
3 лайка
Я осознаю недостатки текущего метода (включая удивительно чрезмерный энтузиазм текущего алгоритма, который удаляет слишком много), но мы пришли к этому через опыт.
Основная причина, по которой существует этот вариант, на самом деле заключается в следующем:
- сохранить форматирование превью, когда ссылки очень длинные (то есть удалять все ссылки, чтобы длинная ссылка никогда не просачивалась в отрывок и не вызывала проблем). Попробуйте сценарий, когда ссылка очень-очень длинная. В старой теме поддержки полно проблем с постами в темах, содержащими длинные ссылки.
- сохранить отрывок как предсказуемую область для клика, где он всегда будет вести к теме. Текст слишком мал, чтобы это было на усмотрение.
Также должно быть:
- просто в поддержке и не должно создавать шума в поддержке. Поскольку текущий метод является поддерживаемым утилитарным классом, мне не нужно беспокоиться о его поддержке.
Я пока не убежден, что нам нужно менять это для широкой публики?
Я мог бы быть открыт к тому, чтобы сделать это выбором из трех вариантов: ВЫКЛ, без ссылок (то есть текущий метод) и экспериментальный? PR приветствуется. Сначала я перенесу текущий код sidecar в ветку master плагина. Я постараюсь сделать это на этой неделе.
3 лайка
Спасибо за ваш ответ 
Я исправил последнее предложение в своём предыдущем сообщении — забыл одно слово…
Я написал:
и также иногда удаляет слова внутри или вне ссылок по непонятной причине. Последняя проблема, кажется, встречается достаточно часто, чтобы её нельзя было игнорировать."
Я забыл слово «не», поэтому…
и также иногда удаляет слова внутри или вне ссылок по непонятной причине. Последняя проблема, кажется, встречается достаточно часто, чтобы её нельзя было игнорировать.
Возможно, я плохо разбираюсь в коде, но попробую разобраться и исправить проблему №2, о которой я упоминал здесь: Topic List Previews (TLP) - #110 by Canapin сегодня.
(выдержки неправильно обернуты в .topic-excerpt: обёртка, похоже, закрывается прямо перед первой ссылкой в выдержке, а не в конце выдержки)
Честно говоря, лучший подход, возможно, — поднять вопрос с разработчиком этой утилиты, чтобы они исправили это? Она определённо ведёт себя не так, как вы ожидаете?
Да, я ещё не смотрел это. Если хочешь, можешь создать PR с исправлением в это время.
1 лайк
Спасибо, я об этом не думал. Я даже не знал, откуда взялась эта утилита.
После небольшого поиска выяснилось, что регулярное выражение распознаёт практически любое слово или строку как часть схемы URI, если они сразу же (без пробела между ними) сопровождаются двоеточием. Это понятно, но всё же слишком строго, поскольку в английском языке (в отличие, например, от французского) пробел перед двоеточием не ставится. Поэтому «легитимные» слова «поглощаются» регулярным выражением просто потому, что за ними, к сожалению, следует двоеточие.
Исправление могло бы заключаться в добавлении поля (не заполненного по умолчанию, чтобы избежать проблем в существующих установках) в настройках плагина, где можно было бы указать схему (или схемы), которые нужно исключить.
Например, настройка могла бы выглядеть так:
Схемы URI для исключения: http|https|ftp|mailto
Это привело бы к следующему результату:
#{URI::regexp(['http', 'https', 'ftp', 'mailto'])}
(к сожалению, это чувствительно к регистру, но, безусловно, это можно как-то исправить)
Если поле настройки пустое, то будет использоваться:
#{URI::regexp}
что соответствует текущему поведению.
Было бы принято предложение с таким изменением в виде pull request?