Как запустить Discourse в подкаталоге внешнего домена?

Мы переходим с нашего сайта на WordPress на облачную платформу электронной коммерции, которая будет использовать наш основной домен благодаря высокому рейтингу SEO.

Я хочу перенести наши публикации на Discourse и запустить их под тем же доменом. Это возможно?

Для ясности: http://ultraluz.com.br/ будет работать на внешнем сервере, которым я не могу управлять или к которому не имею доступа, поэтому, полагаю, я не смогу использовать хитрости с nginx или что-то подобное. У меня есть доступ только к серверу, на котором будет работать Discourse.

Моя цель — перенести публикации, например, такую: http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/, на Discourse, сохранив тот же путь или, в идеале, domain/blog/same-url, при этом мой основной домен будет указывать на платформу, похожую на Wix, и размещён там.

Возможно, настроить Cloudflare перед обоими сайтами с правилом для маршрутизации трафика на Discourse для подпапки. Мне неизвестно ни об одном таком случае. Вам, скорее всего, придётся нанять специалиста или разобраться самостоятельно. Просто следуйте теме здесь о установке в подпапке и любым материалам Cloudflare на эту же тему.

Мне казалось, что мнение о том, что подпапка лучше для SEO, уже устарело. Я бы рекомендовал использовать поддомен, но если у вас есть бюджет, свяжитесь со мной или напишите в Marketplace.

Технически* вы могли бы реализовать подпапку в Cloudflare с помощью правила страницы уровня Enterprise или, возможно, через Workers, но я крайне скептически настроен насчет того, что мы сможем оказать какую-либо помощь в любом из этих случаев.

Поддержка Cloudflare в любой форме, кроме DNS, крайне затруднительна.

И да, сама компания Google опровергла все мифы о SEO-«чудо-средствах», связанных с размещением всего под одним доменом.

В SEO лучше перестраховаться. Я не вижу, как поддомен blog.domain может улучшить SEO моего домена, поэтому нет смысла использовать поддомен для блога.

Я подумываю следовать этому руководству. Какой из параметров ```
assetsPathnames: [“/public/”, “/assets/”]

Установка в подпапку гораздо сложнее и крайне ненадежна.

Суть в том, что при запуске под одним и тем же FQDN нет никакой выгоды, зато риски и затраты значительно возрастают.

Это ваше мнение. Но нет никаких доказательств того, что поддомен каким-либо образом способствует продвижению основного домена.

Более того, даже Cloudflare рекомендует размещать всё в рамках одного домена.

Тогда почему, скажите на милость, их дискурсивное сообщество находится на поддомене?

Потому что любые домены с cloudflare в названии хорошо ранжируются. А их форум огромен.

Если вы так считаете, проходите мимо. Здесь для вас ничего нет. Идите в другое место, туда, где люди верят в то же, что и вы.

Я мог бы привести ещё много ссылок с подтверждающими данными, если бы не был ограничен двумя. И за исключением Cloudflare, который является гигантом и не нуждается в фокусировке на SEO, все сайты на первой странице по этому запросу используют подкаталоги.

Не составит труда найти и другие места, где люди придерживаются того же мнения, поскольку в SEO-сообществе это, кажется, общепринятое мнение.

Но, конечно, если у вас есть ЛЮБЫЕ доказательства того, что поддомен помогает ранжировать корневой домен, просветите интернет :slight_smile:

Напрямую от Мэтта Каттса. Ваши «эксперты» по SEO продают вам змеиное масло.

За эти годы некоторые из самых худших и наименее компетентных людей, которых я когда-либо видел в команде, — это «эксперты» по SEO. Они единодушно позорят и опозорят отрасль.

Верно! Гораздо лучше сделать что-то, с чем большинство согласится, что это не поможет в ранжировании сайтов, но, скорее всего, приведёт к неожиданному сбою вашего сайта без ясного способа его исправить.

Кто-нибудь пробовал сделать это с Cloudflare?

Как мы уже объясняли в вашей другой теме, то, что вы просите сделать, здесь не поддерживается.

Вам понадобится либо корпоративный тариф Cloudflare, либо создание собственных Workers. В любом случае вам следует связаться с Cloudflare.

Как уже говорилось, ответ, который я дал ранее, — это всё, что вы здесь получите.

Я не объяснил достаточно ясно, что это дело для глупцов.

Для ориентира: я бы взял с вас порядка 1000 долларов и не дал бы никаких гарантий, что это будет работать дольше недели после настройки (или, возможно, взял бы 500 долларов без гарантий, что вообще смогу это решить).

Вам также потребуется тарифный план Cloudflare Enterprise.

Если вы заинтересованы, напишите в Marketplace, укажите бюджет, подтвердите готовность оплатить тариф Cloudflare Enterprise и осознайте, что это, скорее всего, невозможно.

Я думаю, что реализация этого завершена на 80%. Я установил Discourse на поддомене как «обычную» установку.

Затем я создал Cloudflare Worker, который проксирует /blog на мой поддомен. Это работает, но Chrome отказывается загружать некоторые элементы из-за политики CSP.

Есть ли у кого-нибудь идеи, как обойти это? Я поделюсь кодом своего Worker, когда всё будет готово на 100%.

Вы можете перейти по адресу https://ultraluz.com.br/blog, чтобы посмотреть, что происходит.

Моя идея заключается в том, что после исправления этой проблемы я просто использую robots.txt, чтобы запретить Google индексировать мой поддомен, так что он будет видеть и индексировать только /blog, в то время как я смогу при необходимости свободно обращаться к поддомену.

На самом деле, это никогда не будет работать особенно хорошо при «обычной» установке. Вам действительно стоит следовать процедуре установки в подпапке. Это решит ваши проблемы с CSP и многие другие. Кроме того, я думаю, что вы почти у цели.

Какое значение следует задать для DISCOURSE_HOSTNAME при использовании DISCOURSE_RELATIVE_URL_ROOT? Для меня корневой относительный путь будет blog, верно?

Как это влияет на настройки, связанные с SSL? Вот мой секция env в файле yml:

env:
  LANG: en_US.UTF-8
  DISCOURSE_RELATIVE_URL_ROOT: /forum

  VIRTUAL_HOST: forum.ultraluz.com.br
  VIRTUAL_PORT: 80
  LETSENCRYPT_HOST: forum.ultraluz.com.br
  LETSENCRYPT_EMAIL: redacted@email.com

  DISCOURSE_HOSTNAME: forum.ultraluz.com.br
  DISCOURSE_DEVELOPER_EMAILS: 'redacted@email.com'

  DISCOURSE_SMTP_ADDRESS: smtp.sendgrid.net
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: apikey
  DISCOURSE_SMTP_PASSWORD: "password"
  DISCOURSE_SMTP_ENABLE_START_TLS: true
  SSL_POLICY: Mozilla-Modern  

Настройки Let’s Encrypt и виртуального хоста предназначены для моего nginx-контейнера (jwilder/nginx-proxy), который обрабатывает проксирование и создание SSL на основе этих переменных…

Также у меня было вот это, но, думаю, оно будет полностью заменено кодом выше:

run:
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 172.18.0.0/24;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        types {

Да, /blog, включая слэш.

Нет, только ultraluz.com.br.

Полагаю, вам следует оставить часть с LetsEncrypt без изменений.

Так не сработало. Думаю, это потому, что воркеру нужен домен для получения данных, а корневой домен находится на другом IP-адресе.

По сути, я говорю воркеру: «когда кто-то заходит на /blog, получай это с rootdomain/blog» — и это, конечно, просто отображает мою текущую страницу ошибки 404 от WordPress.

Думаю, из-за всей этой ситуации с одним доменом, но разными IP-адресами/серверами, для загрузки ресурсов Discourse необходим поддомен. Но уже поздно, и мне нужно спать.

Однако, по-моему, самый простой способ решить эту задачу — просто исправить ошибки CSP с помощью стандартной установки на поддомене.