Я попытался настроить это здесь, но миниатюры для наших тем, похоже, не создаются.
Связано ли это каким-либо образом с настройкой периода редактирования? Компонент темы «Предварительный просмотр списка тем» также не отображает миниатюры, пока первый пост остаётся редактируемым, но для этой категории такой подход совсем не подходит. Мы предпочли бы, чтобы пользователи могли редактировать свои посты в этой категории неограниченно долго.
Как только модули фронтенда, так и миниатюры списков тем и предпросмотры списков тем используют один и тот же базовый процесс генерации миниатюр, который работает на бэкенде. Эта асинхронная задача выполняется только после истечения периода редактирования ОБНОВЛЕНИЕ: если изображение находится на удалённом сервере. Если изображения загружаются локально, процесс генерации миниатюр запускается немедленно.
Этот процесс нельзя изменить с помощью компонента темы; для этого потребуется плагин или изменение кода бэкенда (не считая того, что для TLP существует дополнительный плагин с некоторыми расширенными функциями).
Стоит отметить, что до того как поддержка миниатюр была добавлена в ядро, предпросмотры списков тем были плагином и работали примерно так же в плане планирования создания миниатюр. Я не могу говорить от имени команды, но логика сохранения такого подхода понятна: вы не хотите генерировать миниатюры, если исходное изображение может быть часто отредактировано или удалено, или что, если изображение будет добавлено в последнюю минуту?
Один из способов смягчить эту проблему — использовать функцию иконки/изображения по умолчанию в каждом компоненте темы. Для вида «кирпичная кладка» или «плитка» это хотя бы уменьшает резкие изменения в макете. Или можно уменьшить период редактирования?
А, да, я понял. Это полностью логично как поведение по умолчанию — мы оказались в непростой ситуации, поскольку в этой категории будут публиковаться в основном моды для Minecraft, поэтому естественно, что первое сообщение в любой теме будет редактироваться редко, а миниатюру, скорее всего, будут менять.
Предполагаю, что вы не знаете никаких плагинов, позволяющих изменить это поведение, если подумать? Я понимаю, почему Core не поддерживает это, но полагаться только на льготный период нам не получится.
Хотя стоит добавить, что значительная часть борьбы на самом деле заключается в точном определении желаемого практического поведения, которое будет работать во всех пограничных случаях. Затем следует выполнить работу, то есть убедиться, что то, что вы хотите, будет работать на практике. Всё это можно изменить. :).
Если пост изменится после дедлайна, я считаю, что система должна запланировать ещё один запрос и обновить миниатюру.
Гарет, приношу извинения за путаницу. Вернувшись к своему рабочему столу, я провёл быстрое тестирование и перепроверил логику.
Мое заявление было неполным:
Если изображение находится где-либо удалённо (включая onebox удалённой ссылки, когда оно хранится в CDN), то эскизы обрабатываются с задержкой через фоновую задачу: Jobs::PullHotlinkedImages, и она действительно планировалась после периода редактирования (эта часть была верной):
НО: оказывается, если вы загружаете изображение напрямую на сайт (например, вставив его), эскизы создаются в асинхронном процессе, который запускается немедленно. Если вы замените изображение на другое локальное, это также отразится практически сразу. Я обновил несколько сообщений выше. Поскольку я делаю это нечасто, я упустил эту часть.