Привет, у меня проблема: при клике на страницы «Условия использования», «Часто задаваемые вопросы» или «Конфиденциальность» открывается пустая страница с постоянно вращающимся курсором «занято».
Как это исправить?
Как сделать эту информацию доступной и довести её до сведения потенциальных пользователей, которые заходят на сайт, но ещё не зарегистрировались для получения доступа по паролю?
Сейчас посетитель видит только базовое окно входа на главной странице, и до регистрации у него нет никакого представления о том, релевантен ли ему этот форум или какие условия применяются.
Теперь, когда сайт и почта полностью настроены и работают на домене форума, я не хочу рисковать и портить всё, перенаправляя домен на отдельную веб-страницу, размещённую на другом хостинге, как это было предложено, а также переносить форум на поддомен или аналогичное решение. Кроме того, я не хочу тратить 47 долларов в год на платный плагин, чтобы добавить немного больше информации на главную страницу домена.
В качестве неприятного и неэстетичного обходного решения я добавил руководство, предназначенное для тех, кто рассматривает возможность регистрации, путем кастомизации текста самого диалогового окна входа.
Если я решу перенести форум на поддомен, каких сложностей мне следует ожидать как новичку:
Настройка целевой страницы на основном домене, которая также будет размещена на моём сервере DigitalOcean Droplet (чтобы не платить за дополнительный сервис)?
Обеспечение бесперебойной работы входящей и исходящей почты через Mailgun и сохранение всей функциональности?
Фоновая проблема заключается в том, что я бы предпочел управлять контентом целевой страницы и обновлять его прямо из административной панели, а также включать её в автоматические резервные копии. Это звучит довольно сложно, если не использовать один и тот же домен, не говоря уже об одном и том же программном обеспечении.
Мне бы очень хотелось увидеть хотя бы базовый функционал целевой страницы, встроенный в ядро Discourse, для тех, кто не хочет или не нуждается в управлении отдельным сайтом.
Это касается как авторизованных пользователей, так и анонимных (неавторизованных)? Если да, то это указывает на довольно фундаментальную проблему, которая не должна зависеть от манипуляций с доменом или поддоменом.
В нашем случае мы определённо хотим разместить Discourse на корневом домене, так как это абсолютный центр нашей деятельности. Поэтому я тоже искал, как лучше всего оптимизировать /admin/customize/site_texts/login_required.welcome_message и другие элементы этой страницы.
Хорошая новость в том, что в этом тексте можно использовать обычный Markdown и другие стандартные элементы; это обеспечивает гораздо большую гибкость. Я делаю это, создавая тему в Staff, а затем копируя её в раздел настройки. @codinghorror — было бы крайне полезно, если бы для людей в нашей ситуации это работало так же, как страницы «Часто задаваемые вопросы» и другие.
Кроме того, вы можете добавить ссылки на страницы «Конфиденциальность» и «Условия использования» (которые должны быть видны анонимным пользователям), используя компонент темы Custom Header Links (с дополнительными стилями CSS). Конечно, меня это не устраивает, и я хочу, чтобы анонимные пользователи также видели страницы «Часто задаваемые вопросы» и «О нас» (при этом сохраняя форум закрытым), поэтому я попросил помощи:
Это верно для авторизованных пользователей. У пользователей, не выполнивших вход, нет возможности увидеть что-либо, кроме окна входа (если я что-то не упускаю?)
Очень странно, что для авторизованных пользователей недоступны ни одна из этих страниц. Сохранены ли у вас темы, в которых они находятся, в категории #admin?
Ах, возможно, это и есть ключ. У меня нет категории «Admin». Я почистил категории, которые казались пустыми и в остальном не были достаточно отличимыми от других категорий. Очевидно, они не были пустыми. Предположим, я могу скопировать содержимое этих тем с этого сайта и воссоздать их в одной из оставшихся категорий на моём сайте. Как мне затем связать их с соответствующими пунктами меню? Или мне просто воссоздать категорию «Admin»?
Извините, я, кажется, имел в виду Staff. Я тоже возился с этим в нашем экземпляре, но сохранил темы. Эти темы называются «FAQ/Руководство» (ID темы 5), «Условия использования» (ID темы 4) и «название вашего форума Политика конфиденциальности» (ID темы 6).
Подозреваю, что с ними что-то особенное — только администраторы могут редактировать первый пост в каждой из них, независимо от настроек категории. Их воссоздание может оказаться непростой задачей. Удачи!
Категория #Staff никогда не удалялась, но похоже, что темы каким-то образом были удалены.
Что касается содержания этих тем, особенно тем «Условия использования» и «Политика конфиденциальности», то простое копирование того, что я нашел на этом сайте Discourse Meta, не работает, так как оба документа сильно ориентированы на конкретную юрисдикцию и контекст, которые не применимы к моему форуму. Есть ли какие-то более общие (возможно, даже релевантные для Новой Зеландии?) источники, из которых можно почерпнуть информацию?
Также подтверждаю, что простое добавление категории ‘Admin’ и создание в ней темы ‘FAQ’ не помогло — ссылка FAQ по-прежнему открывает пустой экран с вращающимся курсором мыши.
Хорошо, продолжая эту тему: просмотр URL-адресов, использованных в исходном FAQ, показывает, что тема FAQ находится непосредственно в подпапке с названием «faq», например:
https://meta.discourse.org/faq#civilized
В то время как если я создам новую тему FAQ и вставлю туда содержимое, она перейдет по адресу вроде этого:
https://nzarchitecture.net.nz/t/faq/15074
Как создать правильную подпапку или разместить темы в ней? При подключении к моему Droplet на Digital Ocean через FileZilla я не вижу ничего, что можно было бы распознать как прямую стандартную структуру папок для содержимого сайта Discourse, поэтому предполагаю, что здесь используется какая-то изощренная магия Ruby on Rails для генерации этих URL-адресов/путей.
Пока что я нашел обходной путь: использовать любой URL, который генерируется при воссоздании этих отсутствующих тем, и вставлять их в соответствующие поля «альтернативный внешний источник» в разделе Настройки/Правовые вопросы панели управления.
Тем не менее, было бы неплохо привести всё в порядок надлежащим образом, если есть такая возможность — не знаю, какие ещё последствия могут возникнуть из-за повреждённой или отсутствующей первоначальной настройки.
Они являются встроенными (определёнными системой) для встроенных тем. Восстановление их в исходном состоянии до удаления, вероятно, потребует вмешательства в PostgreSQL.
Спасибо, Стивен. К сожалению, я не знаю, с чего начать работу с PostgreSQL.
Возможно ли вообще было удалить их, если они были встроены и не входили ни в одну категорию, которую пользователь может напрямую редактировать или к которой имеет доступ?
Также я заметил, что даже когда эти темы существовали у меня, они игнорировали информацию из раздела «Настройки/Обязательные поля», предоставленную при настройке: название компании, применимое право и город для разрешения споров — то есть что-то уже было сломано.
Кроме того, всё это, по сути, не имеет юридической силы, если у пользователя нет возможности ознакомиться с условиями обслуживания до регистрации. Это может быть довольно фундаментальной проблемой для всех форумов на Discourse, защищённых паролем?
Спасибо, Натан.
Интересно и обнадеживающе, что я могу ссылаться на это, даже не авторизовавшись.
Мне очень хотелось бы видеть рабочие ссылки на FAQ, Условия использования и т. д. в диалоговом окне регистрации/входа, но пока что все ссылки для меня возвращают ответ «У вас нет прав» для пользователей, которые еще не зарегистрировались.
Это можно сделать с помощью другого обходного пути:
Сделайте все категории видимыми только для уровня доверия 0 (или более строгого), за исключением той, которая содержит ваши информационные посты (сделайте её видимой для всех). А затем сделайте форум публичным. Конечно, они больше не будут попадать на страницу входа, и это довольно радикальный способ достижения этой цели.
Может ли кто-нибудь подсказать, как восстановить встроенные юридические темы и их ID (или хотя бы создать пустые редактируемые сообщения по правильным/оригинальным URL-адресам для каждой встроенной юридической темы) через PostgreSQL или иным способом?
Просто создание новых версий с теми же названиями в категории «Персонал» не работает — получившиеся URL-адреса отличаются, и новый пользователь не может получить к ним доступ при регистрации (клик по ссылке в диалоге регистрации просто возвращает его к диалогу входа).
Хорошо, похоже, никто не может помочь с этим. Поможет ли создание форума с нуля, а затем восстановление сохранённой резервной копии базы данных? Или восстановление резервной копии просто снова применит удаления?
Где-то в этой базе данных есть небольшой фрагмент данных, который нужно изменить, чтобы эти сообщения снова появились. Вот он на самом деле:
В таблице ‘topics’ для ID 4, 5 и 6 поле deleted_at будет содержать временную метку. Если вы сможете удалить эти записи (заменить их на пустое значение), то всё снова заработает.
Я знаю, что это можно сделать через Ruby/Rails, но это пока за пределами моих навыков — однако для специалиста с соответствующими знаниями это займёт всего 5 минут. Возможно, тот, кто настраивал для вас этот экземпляр, сможет помочь.
Спасибо, Натан.
К сожалению, я следовал официальному руководству, но без глубокого понимания процесса.
Ранее разработчик помог мне перенести некоторые данные, и я связался с ним неделю назад по этому вопросу, но пока ответа так и не получил.
Тем не менее, меня интересует: существует ли приложение с открытым исходным кодом для настольных компьютеров, которое подключается к базе данных PostgreSQL на Digital Ocean и позволяет просматривать и редактировать таблицы? Или хотя бы такое, которое может прочитать и отредактировать скачанную резервную копию, которую затем можно восстановить?
** Редакция — перечитав ответы на похожий вопрос, я понял, что консенсус сводится к использованию Ruby для любых операций, а не к применению дружелюбных графических интерфейсов для работы с базами данных.
Тем не менее, какие команды нужно ввести в PuTTY, чтобы получить доступ к базе данных и удалить временные метки в поле deleted_at таблицы topics для записей с ID 4, 5 и 6 (после создания резервной копии)?