¿Cómo ejecutar Discourse en un subdirectorio de un dominio externo?

Soporte Instalación
1

Estamos migrando nuestro sitio web de WordPress a una plataforma de comercio electrónico alojada en la nube, la cual utilizará nuestro dominio principal debido a nuestro alto posicionamiento SEO.

Quiero migrar nuestras publicaciones a Discourse, pero ejecutarlo bajo el mismo dominio. ¿Es eso posible?

Para aclarar: http://ultraluz.com.br/ se ejecutará en un servidor externo sobre el cual no tengo control ni acceso, por lo que creo que no puedo utilizar trucos de nginx ni algo similar. Solo tengo acceso al servidor donde se ejecutará Discourse.

Mi objetivo es migrar publicaciones como esta: http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/ a Discourse, manteniendo la misma ruta o, en el mejor de los casos, dominio/blog/misma-url, mientras que mi dominio principal está apuntado y alojado en una plataforma similar a Wix.

2

Podría ser posible tener Cloudflare frente a ambos sitios con una regla para enrutar el tráfico a Discourse para la subcarpeta. No conozco a nadie que esté haciendo eso. Probablemente tendrás que contratar a alguien o resolverlo por tu cuenta. Solo sigue el tema aquí sobre instalaciones en subcarpeta y lo que Cloudflare tenga al respecto.

Pensé que la creencia de que una subcarpeta era mejor para el SEO había desaparecido. Mi recomendación sería usar simplemente un subdominio, pero si tienes presupuesto, contáctame o publica en Marketplace.

3

Técnicamente, podrías lograr la parte de la subcarpeta en Cloudflare mediante una regla de página de Enterprise o quizás a través de workers, pero tengo muchas dudas de que podamos ofrecer asistencia con cualquiera de las dos opciones.

Cloudflare es difícil de soportar en cualquier forma más allá del DNS.

Y sí, Google mismo ha desmentido todo el engaño del SEO que consiste en meter todo bajo un solo dominio.

4

Más vale prevenir que lamentar en SEO. No veo cómo un blog.domain podría mejorar el SEO de mi dominio, así que no tiene sentido tener un dominio de blog en absoluto.

He estado pensando en seguir esta guía. ¿Cuál de estos assetsPathnames: ["/public/", "/assets/"] debería usar?

5

Las instalaciones en subcarpetas son mucho más complicadas y muy frágiles.

El punto es que no hay ningún beneficio al ejecutarse bajo el mismo FQDN y hay significativamente más riesgo y costo.

6

Eso es lo que crees. Pero no hay evidencia de que un subdominio ayude a impulsar el dominio principal en absoluto.

Y hasta Cloudflare recomienda ejecutar todo en el mismo dominio.

7

Entonces, ¿por qué, si me lo permites, su comunidad de discurso está en un subdominio?

8

Porque cualquier cosa con cloudflare en el dominio se posicionará bien. Y su foro es enorme

9

Si eso es lo que crees, sigue tu camino. No hay nada para ti aquí. Ve a otro lugar, ve a un sitio donde la gente crea lo mismo que tú.

10

Podría enlazar muchos más enlaces, respaldados por datos, si no estuviera limitado a 2. Y excepto por Cloudflare, que es enorme y no necesita enfocarse en SEO, todos los sitios web en la primera página de esta búsqueda utilizan subdirectorios.

No será difícil encontrar otros lugares donde la gente crea lo mismo, ya que esto parece ser el consenso en la comunidad de SEO.

Pero seguro, si tienes CUALQUIERA evidencia de que un subdominio ayuda a posicionar el dominio raíz, por favor ilumina a internet :slight_smile:

11

Directo de Matt Cutts. Tus “expertos” en SEO te están vendiendo humo.

A lo largo de los años, algunas de las personas más incompetentes que he visto nunca en un equipo han sido los “expertos en SEO”. Son uniformemente una vergüenza y un deshonra para la industria.

12

¡Cierto! Es mucho mejor hacer algo que casi todos coinciden en que no ayudará al posicionamiento web, pero que probablemente provocará que tu sitio se caiga de forma inesperada sin un medio claro para solucionarlo.

13

¿Alguien ha intentado hacer esto con Cloudflare?

14

Como ya explicamos en tu otro tema, lo que estás pidiendo hacer no puede ser compatible aquí.

Necesitarás un plan Enterprise con Cloudflare o crear workers personalizados. En cualquier caso, deberías hablar con Cloudflare.

15

Como se indicó, la respuesta que di anteriormente es todo lo que obtendrás aquí.

Lo que no dejé lo suficientemente claro es que es una tarea inútil.

Como referencia, te cobraría del orden de 1000 USD y no ofrecería ninguna garantía de que funcione por más de una semana después de configurarlo. (O quizás te cobraría 500 USD sin prometer que podría resolverlo en absoluto).

Además, necesitarías el plan Enterprise de Cloudflare.

Si estás interesado, publica en Marketplace, incluye tu presupuesto, menciona que estás dispuesto a pagar por Cloudflare Enterprise y entiende que es probable que sea imposible.

16

Creo que tengo un 80% de la implementación lista. Instalé Discourse en un subdominio como una instalación “normal”.

Luego, creé un worker de Cloudflare que hace proxy de /blog a mi subdominio. Funciona, pero Chrome se niega a cargar ciertos elementos debido a la política de CSP.

¿Alguien tiene alguna idea para solucionar esto? Compartiré el código de mi worker cuando esté al 100%.

Puedes visitar https://ultraluz.com.br/blog para ver qué está ocurriendo.

image
image895×727 61.7 KB

Mi idea es que, una vez solucionado esto, usaré robots.txt para bloquear a Google de indexar mi subdominio, de modo que solo vea e indexe /blog, mientras que yo seguiré pudiendo acceder al subdominio sin problemas si es necesario.

17

Esto nunca funcionará realmente bien con una instalación “normal”; deberías seguir el procedimiento de instalación en subcarpeta. Esto solucionará tus problemas de CSP y muchos más. Aparte de eso, creo que ya estás casi listo.

18

¿Qué debo establecer en DISCOURSE_HOSTNAME al usar DISCOURSE_RELATIVE_URL_ROOT? ¿La raíz relativa será ‘blog’ para mí, correcto?

¿Cómo afecta esto a lo relacionado con SSL? Esta es mi sección de entorno del archivo 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

Las configuraciones de letsencrypt y virtual host son para mi nginx docker (jwilder/nginx-proxy) que se encarga del proxying y la creación de SSL basándose en esas variables…

También tenía esto, pero creo que será reemplazado completamente por el código de allí:

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 {
19

Sí, /blog incluyendo la barra.

No, solo ultraluz.com.br.

Supongo que deberías dejar la parte de LetsEncrypt tal como está.

20

No funcionó de esa manera. Supongo que es porque el worker necesita un dominio para obtener los recursos, y dado que el dominio raíz está en una IP diferente.

Básicamente le estoy diciendo al worker: “cuando alguien vaya a /blog, obtén esto de rootdomain/blog”; esto, por supuesto, solo muestra mi página de error 404 actual de WordPress.

Creo que, debido a todo lo de mismo dominio, múltiples IPs/servidores, se necesita un subdominio para cargar los activos de Discourse. Pero ya es tarde y necesito dormir.

Sin embargo, creo que la forma más sencilla de lograr esto será simplemente corregir los errores de CSP con la instalación habitual en un subdominio.