После использования функции «Восстановить HTML» на некоторых постах и того, что она сработала на моём продакшн-форуме, я перекомпилировал все свои посты с помощью задачи rake.
Меня удивило, что посты с битыми изображениями НЕ были исправлены.
Поэтому я провёл эксперимент: перекомпилировал конкретный пост на моём тестовом форуме (та же резервная копия; те же данные) как через команду rails, так и через задачу rake, и вот что получилось:
Изображения появляются на секунду, но пост быстро возвращается в исходное состояние с битыми изображениями.
Однако, если я использую функцию «Восстановить HTML», всё работает идеально, и изображения не становятся битыми. Более того, через несколько минут они корректно загружаются на сервер.
Так что, не мог бы кто-нибудь объяснить этот феномен? Почему перекомпиляция через rails или задачу rake ведёт себя именно так, и в чём разница между восстановлением HTML и перекомпиляцией из командной строки?
Записи экрана:
из консоли rails:
из задачи rake:
Меня это очень интригует (и я всё ещё пытаюсь исправить изображения во всех своих постах пакетно).
Пример, где я использовал Восстановление HTML, показывает, что встроенные изображения этого поста корректно отображались и автоматически загружались на сервер (очевидно, их оригинальная ссылка, ведущая на casimages, всё ещё здесь, но это ожидаемое поведение), несколько дней назад: Frensh Vw Bus CHERIZET 2019 SK - #13 par buggyderby - Vos sorties - VW Camper
Я думаю, что эта задача rake помечает их на пересборку и также запускает пересоздание миниатюр. Вы проверяли Sidekiq, чтобы убедиться, что задачи стоят в очереди?
Задача rake rebake для поста запускает PullHotLinkedImages через 4 минуты и мгновенно увеличивает количество обработанных задач на единицу, но я не вижу ничего добавленного во вкладку очереди.
Несколько постов, для которых я выполнил ручную пересборку HTML, уже несколько дней корректно отображают изображения (они также загружены на мой сервер).
Боюсь, я не знаю, почему это работает иначе, чем администраторский гаечный ключ по сравнению с консолью, но я нашел эту тему с похожей проблемой, и им удалось решить её, выполнив повторную выпечку через API:
Кроме Джей, который заметил возможную разницу между rake/rails rebake и rebuild HTML, у кого-то есть ещё идеи?
Будем рады официальному ответу о различиях между этими задачами
Если мы не сможем разобраться, я начну использовать API для «пересборки HTML» моих 40 000 постов, содержащих потенциальные проблемы с изображениями… И надеюсь, что это сработает для меня
Или, может быть, есть какой-то другой способ «пересобрать HTML» с помощью rails?
Rake posts:rebake: post.rebake!(**opts), где opts обычно пуст.
Для Oneboxes можно попробовать задачу posts:refresh_oneboxes, а для битых изображений — задачу posts:invalidate_broken_images. Последняя, возможно, решит вашу проблему.
После попытки выполнить post.rebake!(invalidate_broken_images: true) для всех моих 40 000 постов, содержащих строку [img], это сработало для многих изображений… Но далеко не для всех, несмотря на то, что они размещены на одном и том же внешнем хостинге изображений.
Например, у меня есть тысячи «рабочих» ссылок casimages (ведущих на валидные изображения и отображающих их в предпросмотре редактора при редактировании), которые в обработанной версии постов оказались битыми. Они были корректно отображены и загружены на сервер благодаря моему скрипту, но при этом есть много других случаев, когда этого не произошло, и я не понимаю почему.
Post.where('raw LIKE ?', '%[img]%').find_each do |p|
p.rebake!(invalidate_broken_images: true)
end
У меня также есть ссылки на изображения с других хостингов, которые были загружены, и некоторые из них тоже не сработали.
Я не смог найти никаких различий между этими постами и ссылками на изображения. У всех были рабочие изображения, и тот факт, что они использовали один и тот же хостинг изображений, меня сбивал с толку.
Я пробовал выполнять эту операцию несколько раз, и результаты были непоследовательными, независимо от внешних хостингов изображений… Некоторые изображения загружались, некоторые — нет. Это выглядело как случайность.
Здесь я буду говорить только о casimages, хотя на импортированном мной форуме использовались и другие хостинги изображений.
Так что я подумал, что возможно casimages временно заблокировал мой IP-адрес, если я попытался получить слишком много изображений с их серверов. Это могло бы объяснить как тот факт, что это не сработало для всех изображений, так и случайность успешной загрузки изображений с моего сервера.
Бывали даже случаи, когда опция «Rebuild HTML» работала — только сначала — изображения затем отображались вместо значка битого изображения, хотя они всё ещё хранились на их внешнем хостинге, но когда запускалась задача Sidekiq по подтягиванию внешних изображений, изображения ломались.
То же самое при использовании rail-скриптов с rebake!(invalidate_broken_images: true).
Поэтому я сейчас пробую более медленный подход, ожидая 5 секунд между каждой командой rail rebake!:
total = Post.where('lower(raw) LIKE ?', '%[img]https:%').count
i = 0
Post.where('raw LIKE ?', '%[img]https:%').find_each do |p|
p.rebake!(invalidate_broken_images: true)
print "#{i}/#{total}"
print "\r"
i +=1
sleep(5)
end
Я посмотрю примерно через 60 часов, стало ли лучше…
Мне хотелось бы понять основы моей проблемы здесь и почему «обычный» rebake не может загрузить изображение на сервер (если я не был временно заблокирован casimages).
Обратите внимание, что на этот раз сертификат сервера casimages выглядит в порядке
Также я не понимаю, что именно делает invalidate_broken_images. Я не очень хорошо знаком с кодом Discourse.
Я посмотрел в коде упоминания invalidate_broken_images и нашел эти файлы:
Почему он ищет конкретно строку <img? Мои посты импортированы из phpBB, и в исходной версии содержатся только теги bbCode [img], а не теги <img>; так как же это могло повлиять на мои посты (и повлияло, см. мое предыдущее сообщение)?
Также я не совсем понимаю разницу между этими двумя методами (?):
Кажется, что rebake устанавливает аргументы по умолчанию в false, а rebake! — в true.
Как они связаны между собой (я, кстати, знаю о назначении символа ! в Ruby), и почему они находятся в разных файлах?
Моя цель — только понять, почему мои внешние изображения иногда загружаются, а иногда нет, и можно ли найти надежный способ загружать их правильно и автоматически, даже если это означает загрузку одного изображения в час.
Я занимаюсь этим почти две недели, и это сводит меня (и людей, для которых я мигрировал их сервер) с ума.
Кроме того, в логах Discourse нет ничего, кроме множества сообщений Sidekiq is consuming too much memory (using: 592.25M). Обратите внимание, что я работаю на Ubuntu через WSL в Windows 10, но намерен использовать рабочее решение (если найду его…) на нашем VPS.
Это находится ниже, где вы видите, что оно делает в строке 716. Оно удаляет эти изображения, чтобы попытаться загрузить их снова. (по крайней мере, на первый взгляд)
Итак, я почти завершил 55 часов повторной обработки моих постов, содержащих [img], с задержкой в 5 секунд между каждой итерацией из моих 40 000 постов, выполненной через rails-скрипт.
По моим наблюдениям, это работает намного лучше, чем раньше. Большинство валидных изображений (я исключаю Imageshack и его непредсказуемое поведение) на первый взгляд, по крайней мере, безупречно загружаются на мой форум, но я проведу более тщательную проверку, чтобы быть уверенным на 100%. То, в чем я уверен на 100%, так это в том, что результаты гораздо, гораздо лучше и стабильнее.
Поэтому я подозреваю, что проблема, с которой я столкнулся (и, возможно, проблема от @Amethi), заключавшаяся в случайных сбоях при загрузке удаленных изображений с помощью invalidate_broken_images, была связана с某种 формой ограничения скорости со стороны различных хостинг-провайдеров изображений…? Странно то, что я не заметил никаких проблем с другими импортированными форумами…
Тем не менее, если результаты будут достаточно удовлетворительными, а задержка действительно улучшит загрузку удаленных изображений, я применю тот же метод на своем продакшн-форуме, но увеличу время между каждой повторной обработкой поста с 5 секунд до 10 или 15 секунд (или, возможно, даже больше, мы не спешим, это все довольно старые посты, а VPS имеет значительно более низкие характеристики, чем мой собственный компьютер).
Я не хочу делать преждевременных выводов, но решение моей первоначальной проблемы может заключаться в применении как решения, предложенного Ричардом, так и добавлении задержки между каждой повторной обработкой поста.