Попробуйте воспроизвести проблему, используя мобильную версию Google Chrome или мобильную версию Firefox (или любой другой мобильный браузер).
2 лайка
Очистка кэша помогла! Спасибо! РЕДАКТИРОВАНИЕ: Или нет. 
1 лайк
Извините за то, что здесь долго не отвечал — был занят другими делами. Скоро снова займусь этим плагином.
@DaleKramer @Hifihedgehog Если у вас есть срочная проблема, дайте знать, и я разберусь с ней на этой неделе.
4 лайка
На самом деле, после обновления сервера проблема вернулась. Она также возникает во всех моих мобильных браузерах:
Я снова добавил быстрые сообщения на thepavilion.io. Можешь воспроизвести проблему там?
1 лайк
Возможно, вы могли бы разобраться с этой проблемой, которую я столкнулся и которая, казалось, указывала на этот плагин как на виновника…
В последней версии быстрые сообщения не работают: при каждом сообщении появляется следующее сообщение:
Извините, вы не можете создать личное сообщение в существующей теме.
Да, я получаю ту же ошибку: Извините, вы не можете создать личное сообщение в существующей теме.
1 лайк
Появляется та же ошибка «невозможно создать ЛС». Не связано ли это с этим коммитом?
Спасибо за отчёты. Я изучу это как можно скорее.
1 лайк
В этом и была проблема. Исправление заключается в том, чтобы переопределить функцию valid? без изменений из этого коммита. Поэтому в файле plugin.rb или подобном сделайте следующее:
require_dependency ‘post_creator’
class ::PostCreator
def valid?
// перепишите здесь, исключив 4 строки
end
Если никто не сделает это завтра, я могу создать PR, так как я занимался этим всё утро.
4 лайка
Это было бы очень кстати. В последнее время очень много дел 
. Спасибо!
1 лайк
1 лайк
Хотя я бы очень хотел получить исправление как можно скорее, меня также беспокоит долгосрочная применимость этого решения. А что, если логика внутри основного метода этой функции изменится?
1 лайк
Да, я согласен, так делать не стоит… особенно с методом valid?, это просто ждёт уязвимости безопасности… и мы не хотим, чтобы Discourse в этом плане стал следующим WordPress… но какой тогда будет хороший альтернативный вариант?
В последнее время я тоже сталкиваюсь с подобными ситуациями, когда есть длинный метод, полный проверок, и мне нужно обойти только одну проверку, прямо посередине этого метода.
Нельзя просто проверить, была ли ошибка :create_pm_on_existing_topic единственной, потому что код завершается сразу, как только она установлена, и после этого мог произойти сбой и другой проверки.
Я бы, по крайней мере, добавил этот модуль в начало, а затем в новом методе valid? проверил бы, является ли это сценарием быстрого сообщения. Если да — выполни модифицированный код валидации, а если нет — просто return super, вызвав основной код. Когда основная функция изменится, сломается только функциональность плагина, а не остальное программное обеспечение форума.
Мне пришлось сравнивать две функции построчно, чтобы понять, что удалённая проверка выглядела так:
if new_topic?
...
else
if @topic.present? && @opts[:archetype] == Archetype.private_message
errors.add(:base, I18n.t(:create_pm_on_existing_topic))
return false
end
...
Комментарий бы не помешал 
Знает ли кто-нибудь лучший способ убедиться, что такие монопатчи остаются поддерживаемыми?
(Я действительно использовал термины «монопатч» и «поддерживаемый» в одном предложении? 
)
На самом деле я до сих пор не понимаю, почему быстрые сообщения сломаны исправлением [FIX: гарантирует, что мы не попытаемся создать новое ЛС в существующей теме #9029]. Исправление 9029 работает для ЛС и тем — тогда почему быстрые сообщения не работают? Это связано с каким-то специфическим способом отправки нового ЛС через быстрые сообщения, который конфликтует с исправлением 9029?
Да, я думаю, что именно так. И #9029 добавил эту конкретную проверку.
Я только что отправил исправление для этого плагина. Дайте знать, как всё получится.
@Oliver_Walker спасибо за PR. Как уже отмечали другие, лучше не переопределять большие методы, но спасибо за попытку 
На свой страх и риск, звучу как заевшая записка из печенья с предсказанием: в 95% случаев, когда вы задумываетесь о переопределении части большого серверного метода, вы идёте против логики фреймворка (хотя есть несколько исключений).
В данном случае первый вопрос: как обычные личные сообщения добавляются в существующие обычные темы ЛС? Оказывается, проблема в том, что плагин пытался назначать архетип private_message каждому сообщению, а не только первому, которое создаёт тему.
5 лайков
Спасибо, @angus. Я предполагаю, что вы смогли это протестировать? Также — могу ли я просто попросить нашего хостинг-партнёра (Communiteq (ранее DiscourseHosting)) перезагрузить плагин за нас?