Я выполнил восстановление, и все внутренние ссылки содержат домен тестового URL, что нарушает работу всех ссылок. Не совсем понятно, почему не подтянулся правильный URL сайта. Есть ли какие-либо решения, как исправить это другим способом, не обращаясь к коду или базе данных для массового поиска и замены?
Я подумал: может, сделать повторное восстановление?
Вам нужно зайти в базу данных и выполнить массовый поиск и замену.
Для этого есть инструмент:
RAILS_ENV=production discourse remap //old.domain //new.domain
Вы можете исправить это, как описано, но такого происходить не должно.
Вы создавали и восстанавливали резервную копию через /admin/backups?
У обеих систем правильно настроено имя хоста?
Спасибо. Это выглядело достаточно просто. Я зашел в приложение, выполнил команду, но, похоже, это не изменило вхождения URL в постах.
Вот что я использовал для переотображения:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Команда выполнилась на базе данных “default” за несколько минут и завершилась сообщением «done» без ошибок.
Я проверил несколько выбранных постов, но ничего не изменилось в ссылках URL ни в одном из них.
Я пересобрал некоторые посты для проверки, где видел dev.domain.com вместо активного domain.com в ссылках, но они остались без изменений.
Затем я выполнил ту же команду, но без https://, и получил следующую ошибку:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
Думаю, в базе данных есть сообщение чата, которое вызывает остановку, но не уверен, почему. Мне, вероятно, нужно как-то увидеть это в БД, как вы можете заметить, мой обычный опыт работы с Discourse не связан с управлением базой данных.
Наконец, я снова выполнил исходную команду переотображения; она заняла несколько минут и завершилась сообщением «done» без ошибок:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Может быть, мне нужно пересобрать посты, чтобы увидеть результат?
Я думал, что пересборка поста — это то же самое действие, но выполняемое для каждого поста отдельно.
Или нужно пересобрать само приложение?
Это должно быть
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Причина использования // заключается в том, что это позволяет сопоставлять http://, https:// и URL без указания протокола, при этом не затрагивая доменные имена в адресах электронной почты.
Что происходит, когда вы это делаете?
Да, хорошо, тогда та же ошибка снова:
Переназначение таблиц по умолчанию...
Ошибка: ERROR: значение дублирующегося ключа нарушает уникальное ограничение "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Ключ (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) уже существует.
Переназначение было применено лишь частично из-за ошибки выше. Пожалуйста, запустите скрипт снова.
Так что хотя бы я использую правильную команду записи, дела идут в гору! 
Больше идей нет?
Помимо этой тупиковой ситуации с переопределением маршрутов в Rails, я подумал: может быть, если я сделаю резервную копию базы данных и выполню восстановление, ссылки-URL будут корректно переопределены в процессе восстановления?
Ошибка, с которой я всё ещё сталкиваюсь, похоже, повторяет или очень похожа на ошибку остановки здесь, для которой потребовалось исправление:
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=...
При попытке выполнить переназначение:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Возможно, @david сможет дать здесь какие-то пояснения?
Это больше похоже на ошибку?
В этой таблице есть ссылки на оба домена, поэтому при попытке их переадресации возникает дубликат ключа. Это не ошибка. Вы пытаетесь создать дубликат ключа.
Вы можете удалить из этой таблицы элементы, относящиеся к корневому домену. Лучшее решение — использовать www вместо корневого домена.
Спасибо. Моя единственная тревога в том, что это развертывание Discourse также страдает от проблемы с non-www / SSL, например, How to add ssl to non-www domain?, но я попробую предложенный вами ремейк, и если он сработает, это заставит меня решить и проблему с non-www!
Переосмысление переназначения сработало, как предложил @pfaffman, но на самом деле оно стало лишь катализатором решения, а не самим решением. Оно помогло мне понять, где я ошибался, буквально «переключило» моё восприятие!
Если бы я правильно прочитал сообщение об ошибке, то есть обратил внимание, я бы решил эту проблему уже давно, так как увидел бы, что ключевая информация содержится именно в сообщении об ошибке.
Мне нужно было просто включить номер поста, отмеченный в ошибке остановки …/p/123456789, в URL, чтобы перейти напрямую и исправить каждый пост вручную.
Это происходило в большинстве случаев во время второго прогона переназначения, когда нужно было преобразовать ссылки с www (из первого прогона) в корневые без www, что и было первоначальной целью.
Теперь внутренние URL должны содержать только корневые ссылки.
Это решает часть проблем с перенаправлением SSL для www, где было много устаревших внутренних ссылок с www. Это не решает проблему, если пользователь вручную вводит www в адресную строку или переходит по внешней ссылке на WWW, но должно устранить все автоматически генерируемые внутренние ссылки. Жду результатов влияния на индексацию в Google, прежде чем предпринимать какие-либо дальнейшие действия по этому вопросу.
Возможно, это будет интересно разработчикам.
Я столкнулся с множеством ошибок вида `duplicate key value violates unique constraint