Я изучаю возможность создания общего форума для двух отдельных сайтов: моего блога и портфолио. Идея заключается в том, чтобы использовать одну базу данных форума для обоих сайтов, позволяя пользователям и темам быть общими для двух сообществ. Однако я хотел бы, чтобы форум имел разный дизайн в зависимости от того, с какого сайта зашел пользователь, чтобы каждое сообщество ощущалось уникальным, оставаясь при этом частью общего пространства.
У меня есть опыт веб-разработки, хотя я давно не работал над крупными проектами такого масштаба. Я готов погрузиться в изучение необходимых технологий, чтобы реализовать эту задумку, но буду признателен за советы относительно того, осуществимо ли это с помощью Discourse.
В частности, меня интересуют следующие вопросы:
Может ли Discourse поддерживать разные темы или стили в зависимости от домена или URL, с которого пришел пользователь?
Возможно ли настроить Discourse так, чтобы отображался индивидуальный брендинг (логотипы, цвета и т. д.), сохраняя при этом общую базу пользователей и пул тем?
Существуют ли плагины или расширения, которые могли бы упростить реализацию такой задачи?
Есть ли какие-либо советы относительно проблем или ограничений, о которых стоит подумать при реализации подобной конфигурации?
Этот проект пока находится на стадии концепции, и я планирую начать его разработку в конце года. Я хочу убедиться, что Discourse подходит для реализации этой идеи, прежде чем окончательно определиться с выбором платформы.
Заранее спасибо за любые insights, предложения или ресурсы, которые вы сможете предоставить!
Я всё ещё не до конца понимаю.
Итак, домен a указывает на форум, а домен b — на тот же форум или другой форум с той же базой данных? Если так, возможно, это другой форум с той же базой данных? Тогда стиль может отличаться.
Быстрый поиск здесь не показывает, легко ли это реализовать.
Более простой вариант — использовать переключатель, привязанный к основной группе, и иметь две группы: переключение с группы A на группу B будет менять тему, возможно, используя что-то вроде Customization > Theme component (кастомная домашняя страница для групп). Или, может быть, использовать Modern Category+group boxes, установленные дважды (как в теме Air), с настройками, зависящими от темы/основной группы.
Хотя я сам не знаю. Меня беспокоит, не приведет ли наличие двух установок Discourse к повреждению базы данных? Хотя у некоторых есть тестовые сайты, но, думаю, тестовый сайт обычно резервируется с основного?
Итак, если пользователь открывает сайт A, переходит на форум с сайта A, то применяется тема A.
Затем тот же пользователь открывает сайт B, переходит на форум с сайта B и видит тему B?
Что будет, если у пользователя уже применена тема A, он заходит на сайт B и обновляет страницу форума? Будет ли применена тема B или сохранится тема A?
Полагаю, вы можете запускать несколько экземпляров движка (установок Discourse) на одной базе данных (для этого потребуется отдельная база данных). Однако я бы запускал только один Sidekiq, иначе они начнут конкурировать за задачи. В остальном, поскольку Discourse — это stateless-приложение, количество запущенных экземпляров, по-моему, не имеет значения.
Теперь вопрос, касающийся сути всей проблемы: зачем? И не противоречит ли это правилам SEO? Мне кажется, Google не любит, когда обнаруживает одинаковый контент на нескольких сайтах.
На самом деле, возможно, некоторые вещи будут работать не так, как ожидалось — например, обновления интерфейса в реальном времени (если кто-то обновит статью, и она магическим образом перерендерится, пока вы её читаете). Кажется, что два сайта не будут сообщать друг другу об изменениях, поэтому придётся полагаться на то, что пользователь обновит браузер. Возможно, есть и другие проблемы. Например, если вы измените настройки сайта на одном из них, второй, вероятно, тоже не заметит этого, и вам, возможно, придётся перезапустить его.
Судя по Scaling up and sidekiq, это, по-моему, вполне решаемая задача. Sidekiq, похоже, справляется с этим, а остальное — вопрос правильной настройки Redis.
Это немного не по теме, и я не хочу уводить разговор в сторону, но хотел бы выразить свою простую признательность.
Я считаю, что мы живем в эпоху интернета, когда нужно думать либо о SEO, либо о своих пользователях.
И я не сомневаюсь, что самохостинг Discourse будет использоваться теми, кто выбирает своих пользователей.
Я искал эту функцию, потому что у меня есть личные проекты с той же аудиторией и целевой направленностью. Мульти-сайт с SSO был наиболее близким вариантом, но я не добился успеха, так как это медленно и неудобно.
Я поддерживаю идею автора темы и начинаю следить за этим
Discourse не является stateless-приложением, и вся информация хранится в базе данных. Поэтому, если вы запустите несколько экземпляров поверх одной базы данных, они автоматически будут выглядеть одинаково, и изменения в одном сразу отразятся в другом.
Это «просто» вопрос переключения тем. Возможно, стоит использовать существующую логику предварительного просмотра тем и сделать так, чтобы плагин смотрел на имя хоста вместо параметра URL.
Размещение одного и того же форума под двумя URL может оказаться самой сложной частью, особенно с точки зрения SEO. Это приведет к проблемам с дублирующимся контентом и каноническими URL-адресами.
Не могли бы вы прояснить этот момент? Было бы действительно интересно узнать немного больше о том, как это работает. Мне кажется, ваши два утверждения противоречат друг другу? Я думаю, что именно синхронизация всего содержимого и спрашивал автор темы (OP). Но как это может произойти, если другой экземпляр не уведомляется об изменениях, внесённых первым экземпляром? Да, данные сохраняются в базе данных, но уведомления об этом нет.
Так что просто: db = stateless. Каждый раз, когда вы делаете запрос, система снова обращается к базе данных — в памяти нет состояния. Или всё же есть?
В остальном мне очень нравится идея плагина. Я согласен, что это правильный путь, и я по-прежнему считаю, что SEO — это не то, что можно просто выбрать, а то, чем необходимо заниматься, чтобы привлечь аудиторию. Дублирование контента могло бы быть способом решить эту проблему. Даже с точки зрения пользователя это может показаться подозрительным: если я увижу текст, который я написал на одном сайте, но ссылка на него ведёт на другой сайт, о существовании которого я не знал, я буду сильно обеспокоен. Дублирование контента обычно используется низкокачественными сайтами. Именно поэтому поисковые системы снижают их рейтинг в выдаче. Но это уже тема для категории Community Building.
Я думаю, здесь возникла путаница в определениях. Серверный код Discourse (в некотором роде*) не имеет состояния, но весь экземпляр Discourse (веб-клиент, серверный код, Redis, кэшированные файлы, база данных) — не является таковым.
Обратная сторона медали в том, что, поскольку серверный код не имеет состояния, такая конфигурация не может выполнить то, что хочет OP, так как негде хранить информацию о том, какой URL и тему следует обслуживать. Описываемая вами конфигурация на самом деле соответствует настройке с балансировкой нагрузки, где есть несколько веб-контейнеров и один экземпляр базы данных/Redis. Это один сайт.
* Я говорю «в некотором роде», потому что во многих местах есть множество уровней кэширования
Понятно. URL основного сайта тоже хранится в базе данных? Значит, это не вопрос конфигурации локального экземпляра? В таком случае очевидно, что оба экземпляра всё ещё будут пытаться обслуживать один и тот же контент.
Вы правы: настройка с двумя серверами вообще не помогает Discourse выбрать правильную тему.
Теперь я вспомнил, что возникнет проблема и с контентом. Если вы вставите ссылку в Discourse, он опубликует полный URL. Таким образом, кто-то, читающий тему, созданную на другом сайте, при клике на ссылку будет перенаправлен на него. То же самое касается загрузок, см. Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Другой проблемой могут быть электронные письма. С какого домена будут отправляться уведомления? Ещё одна проблема — социальные плагины (Facebook и др.) или вход через Google будут перенаправлять на неправильный сайт (или, возможно, откажут в авторизации).
Внезапно, из левого поля, появляется гораздо более простое решение: использовать один экземпляр с двумя категориями — по одной для каждого родительского сайта. Это позволит обойти все вышеупомянутые проблемы.
Есть множество возможностей стилизовать категории и темы внутри них с помощью простого CSS, используя класс category-category_slug.
Если вы хотите сделать одну из них «домашней» или основной для определённой группы пользователей, то вам понадобится инструмент, описанный здесь: Custom Homepage for Groups.
