Я изучаю возможность создания общего форума для двух отдельных сайтов: моего блога и портфолио. Идея заключается в том, чтобы использовать одну базу данных форума для обоих сайтов, позволяя пользователям и темам быть общими для двух сообществ. Однако я хотел бы, чтобы форум имел разный дизайн в зависимости от того, с какого сайта зашел пользователь, чтобы каждое сообщество ощущалось уникальным, оставаясь при этом частью общего пространства.
У меня есть опыт веб-разработки, хотя я давно не работал над крупными проектами такого масштаба. Я готов погрузиться в изучение необходимых технологий, чтобы реализовать эту задумку, но буду признателен за советы относительно того, осуществимо ли это с помощью Discourse.
В частности, меня интересуют следующие вопросы:
Может ли Discourse поддерживать разные темы или стили в зависимости от домена или URL, с которого пришел пользователь?
Возможно ли настроить Discourse так, чтобы отображался индивидуальный брендинг (логотипы, цвета и т. д.), сохраняя при этом общую базу пользователей и пул тем?
Существуют ли плагины или расширения, которые могли бы упростить реализацию такой задачи?
Есть ли какие-либо советы относительно проблем или ограничений, о которых стоит подумать при реализации подобной конфигурации?
Этот проект пока находится на стадии концепции, и я планирую начать его разработку в конце года. Я хочу убедиться, что Discourse подходит для реализации этой идеи, прежде чем окончательно определиться с выбором платформы.
Заранее спасибо за любые insights, предложения или ресурсы, которые вы сможете предоставить!
Я всё ещё не до конца понимаю.
Итак, домен a указывает на форум, а домен b — на тот же форум или другой форум с той же базой данных? Если так, возможно, это другой форум с той же базой данных? Тогда стиль может отличаться.
Быстрый поиск здесь не показывает, что это можно сделать легко.
Возможно, более простой путь — использовать переключатель, привязанный к основной группе, и создать две группы, где переход из группы A в группу B меняет тему. При этом можно использовать, например, пользовательскую домашнюю страницу для групп через #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). Но как это может произойти, если второй экземпляр не уведомляется об изменении, сделанном первым экземпляром? Да, данные хранятся в базе данных, но уведомления нет.
Так что просто база данных = stateless. Каждый раз, когда вы делаете запрос, он снова обращается к базе данных — нет состояния в памяти. Или всё же есть?
В остальном мне очень нравится идея плагина. Я согласен, что это правильный путь, и я всё ещё считаю, что SEO — это не то, что вы выбираете сделать, а то, что вы должны делать, чтобы привлечь аудиторию. Дублирование могло бы быть способом решить эту проблему. Даже с точки зрения пользователя это может показаться подозрительным: если я вижу текст, который написал на одном сайте, возможно, с ссылкой на другой сайт, о котором я не знал, это меня сильно беспокоит. Дублирование контента обычно используется низкокачественными сайтами. Именно поэтому они получают понижение в рейтинге SEO. Но это уже тема для категории #community.
Я думаю, здесь возникла путаница в определениях. Серверный код 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.
