Come eseguire Discourse in una sottodirectory di un dominio esterno?

Supporto Installazione
1

Stiamo passando dal nostro sito WordPress a una piattaforma di e-commerce ospitata nel cloud, che utilizzerà il nostro dominio principale grazie al nostro elevato posizionamento SEO.

Vorrei spostare i nostri post su Discourse, ma eseguirli sotto lo stesso dominio: è possibile?

Per chiarire, http://ultraluz.com.br/ sarà ospitato su un server esterno su cui non ho controllo o accesso, quindi credo di non poter utilizzare trucchi nginx o simili. Ho accesso solo al server su cui verrà eseguito Discourse.

Il mio obiettivo è spostare post come questo: http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/ su Discourse, mantenendo lo stesso percorso o, al massimo, domain/blog/stesso-url, mentre il mio dominio principale è puntato e ospitato su una piattaforma simile a Wix.

2

Potrebbe essere possibile utilizzare Cloudflare davanti a entrambi i siti con una regola per instradare il traffico verso Discourse per la sottocartella. Non sono a conoscenza di qualcuno che lo stia facendo. Dovrai probabilmente assumere qualcuno o risolvere la questione da solo. Segui semplicemente l’argomento qui sulle installazioni in sottocartella e tutto ciò che Cloudflare ha a riguardo.

Pensavo che l’idea che una sottocartella fosse migliore per la SEO fosse ormai superata. Il mio consiglio sarebbe di utilizzare semplicemente un sottodominio, ma se hai un budget, contattami o pubblica nel canale Marketplace.

3

Potresti tecnicamente gestire la parte delle sottocartelle su Cloudflare utilizzando una regola pagina Enterprise o forse tramite Workers, ma sono piuttosto scettico sul fatto che possiamo offrire assistenza per l’uno o l’altro.

Cloudflare è difficile da supportare in qualsiasi forma oltre al DNS.

E sì, lo stesso Google ha smentito tutto il fumo SEO che circonda l’idea di accorpare tutto sotto un singolo dominio.

4

Meglio prevenire che curare con la SEO. Non capisco come un blog.domain possa migliorare la SEO del mio dominio, quindi non ha senso avere un dominio blog a sé stante.

Sto pensando di seguire questa guida. Quale assetsPathnames: ["/public/", "/assets/"] dovrei usare?

5

Le installazioni in sottocartelle sono molto più complesse e estremamente fragili.

Il punto è che non vi è alcun vantaggio nell’eseguire sotto lo stesso FQDN, ma solo rischi e costi significativamente maggiori.

6

È quello che credi. Ma non ci sono prove che un sottodominio aiuti a migliorare il dominio principale in alcun modo.

E anche Cloudflare consiglia di gestire tutto nello stesso dominio.

7

Allora perché, per favore, la loro comunità di discussione si trova su un sottodominio?

8

Perché tutto ciò che contiene cloudflare nel dominio si posiziona bene. E il loro forum è enorme

9

Se è quello che credi, vai pure. Non c’è nulla per te qui. Vai altrove, vai dove le persone credono nelle stesse cose che credi tu.

10

Potrei collegare molti altri link, supportati da dati, se non fossi limitato a due. E tranne Cloudflare, che è enorme e non ha bisogno di concentrarsi sulla SEO, tutti i siti web nella prima pagina per questa ricerca utilizzano sottodirectory.

Non sarà difficile trovare altri luoghi in cui le persone credono la stessa cosa, dato che questo sembra essere il consenso nella comunità SEO.

Ma certo, se hai QUALSIASI prova che un sottodominio aiuti a classificare il dominio principale, illuminare pure internet :slight_smile:

11

Diretto da Matt Cutts. I vostri “esperti” SEO vi stanno vendendo olio di serpente.

Nel corso degli anni, alcune delle persone peggiori e meno competenti che abbia mai visto in un team sono state gli “esperti SEO”. Sono uniformemente una vergogna e un’onta per il settore.

12

Vero! È molto meglio fare qualcosa che quasi tutti concordano non aiuterà il posizionamento web, ma che probabilmente porterà il tuo sito a fermarsi inaspettatamente senza un modo chiaro per risolvere il problema.

13

Qualcuno ha provato a farlo con Cloudflare?

14

Come già spiegato nel tuo altro argomento, ciò che chiedi di fare non può essere supportato qui.

Dovrai o pianificare un piano Enterprise con Cloudflare, o creare worker personalizzati. In ogni caso, dovresti parlare con Cloudflare.

15

Come già dichiarato, la risposta che ho fornito in precedenza è tutto ciò che otterrete qui.

Ciò che non ho reso abbastanza chiaro è che si tratta di un’impresa impossibile.

A titolo di riferimento, vi chiederei circa 1000 dollari e non garantirei che funzionasse per più di una settimana dopo averlo configurato. (Oppure potrei chiedere 500 dollari senza garantire di riuscire a risolvere il problema in assoluto.

Inoltre, avreste bisogno del piano Enterprise di Cloudflare.

Se siete interessati, pubblicate una richiesta nella sezione Marketplace, specificando il budget a vostra disposizione, la disponibilità a pagare per il piano Enterprise di Cloudflare e la consapevolezza che è probabile che sia impossibile.

16

Penso di aver completato l’80% dell’implementazione. Ho installato Discourse su un sottodominio come installazione “normale”.

Poi ho creato un worker di Cloudflare che fa il proxy di /blog al mio sottodominio. Funziona, ma Chrome rifiuta di caricare alcuni elementi a causa della policy CSP.

Qualcuno ha idee su come aggirare questo problema? Condividerò il codice del mio worker quando sarà al 100%.

Puoi visitare https://ultraluz.com.br/blog per vedere cosa sta succedendo.

image
image895×727 61.7 KB

La mia idea è che, una volta risolto questo problema, userò solo robots.txt per impedire a Google di indicizzare il mio sottodominio, così vedrà e indicizzerà solo /blog, mentre potrò comunque accedere al sottodominio senza problemi se necessario.

17

In realtà, con un’installazione “normale” non funzionerà mai bene. Dovresti davvero seguire la procedura di installazione in sottocartella. Questo risolverà i tuoi problemi CSP e molti altri. A parte questo, credo che tu sia quasi arrivato alla soluzione.

18

Cosa dovrei impostare per DISCOURSE_HOSTNAME quando uso DISCOURSE_RELATIVE_URL_ROOT? La radice relativa sarà /blog per me, giusto?

Come influisce questo sulle configurazioni relative a SSL? Questa è la mia sezione env del file 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

Le configurazioni per letsencrypt e virtual host sono per il mio nginx docker (jwilder/nginx-proxy) che gestisce il proxying e la creazione dei certificati SSL per me basandosi su quelle variabili…

Avevo anche questo, ma penso che verrà completamente sostituito dal codice qui sopra?

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 con la barra.

No, solo ultraluz.com.br.

Immagino tu debba lasciare la parte di LetsEncrypt così com’è.

20

Non ha funzionato in questo modo. Immagino sia perché il worker ha bisogno di un dominio per recuperare i contenuti, e dato che il dominio principale si trova su un IP diverso.

Sto essenzialmente dicendo al worker: “quando qualcuno va su /blog, recupera questo da rootdomain/blog”. Questo, naturalmente, mostra semplicemente la mia attuale pagina di errore 404 di WordPress.

Penso che, a causa di tutta la questione del dominio unico con più IP/server, sia necessario un sottodominio per caricare le risorse di Discourse. Ma è tardi e devo andare a dormire.

Tuttavia, credo che il modo più semplice per risolvere il problema sia correggere gli errori CSP con una normale installazione su sottodominio.