Wie man Discourse in einem Unterverzeichnis einer externen Domain ausführt?

Unterstützung Installation
1

Wir wechseln von unserer WordPress-Website zu einer cloudbasierten E-Commerce-Plattform, die aufgrund unseres hohen SEO-Rankings unsere reine Domain verwenden wird.

Ich möchte unsere Beiträge zu Discourse migrieren, aber unter derselben Domain betreiben. Ist das möglich?

Um es klar zu sagen: http://ultraluz.com.br/ wird auf einem externen Server laufen, den ich nicht kontrollieren oder darauf zugreifen kann. Daher glaube ich, dass ich keine Nginx-Tricks oder ähnliches verwenden kann. Ich habe nur Zugriff auf den Server, auf dem Discourse läuft.

Mein Ziel ist es, Beiträge wie diesen http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/ zu Discourse zu migrieren, aber denselben Pfad beizubehalten oder bestenfalls domain/blog/same-url zu verwenden, während meine reine Domain auf eine Wix-ähnliche Plattform gezeigt und gehostet wird.

2

Es könnte möglich sein, Cloudflare vor beiden Seiten zu platzieren und mit einer Regel den Traffic für den Unterordner zu Discourse zu leiten. Mir ist niemand bekannt, der das bereits macht. Du wirst wahrscheinlich jemanden einstellen oder es selbst herausfinden müssen. Folge einfach dem Thema hier zu Installationen in Unterordnern und den entsprechenden Informationen von Cloudflare.

Ich dachte, die Annahme, dass ein Unterordner besser für SEO sei, sei veraltet. Meine Empfehlung wäre, einfach eine Subdomain zu verwenden. Wenn du jedoch ein Budget hast, kontaktiere mich oder poste im Marketplace.

3

Du könntest den Unterordner-Teil bei Cloudflare technisch über eine Enterprise-Seitenregel oder möglicherweise über Worker umsetzen, aber ich bin ziemlich skeptisch, ob wir bei beidem Unterstützung bieten können.

Cloudflare ist über DNS hinaus in jeder Form schwer zu unterstützen.

Und ja, Google selbst hat das ganze SEO-Schlangenöl rund um das Zusammenpferchen alles unter einer einzigen Domain widerlegt.

4

Bei SEO gilt: Lieber auf Nummer sicher gehen. Ich sehe nicht, wie ein blog.domain-Subdomain das SEO meiner Domain verbessern würde, daher macht ein Blog auf einer Subdomain überhaupt keinen Sinn.

Ich überlege, dieser Anleitung zu folgen. Welche ```
assetsPathnames: [“/public/”, “/assets/”]

5

Subordnungs-Installationen sind weitaus komplexer und sehr anfällig.

Der Punkt ist, dass es keinerlei Vorteil bringt, unter derselben FQDN zu laufen, dafür aber deutlich mehr Risiko und Kosten entstehen.

6

Das ist deine Überzeugung. Es gibt jedoch keinerlei Belege dafür, dass eine Subdomain die Hauptdomain in irgendeiner Weise stärkt.

Und selbst Cloudflare empfiehlt, alles unter derselben Domain laufen zu lassen.

7

Warum ist dann, bitte schön, ihre Diskussionsgemeinschaft auf einer Subdomain?

8

Denn alles mit Cloudflare in der Domain rankt gut. Und ihr Forum ist riesig.

9

Wenn das das ist, woran du glaubst, dann zieh weiter. Hier gibt es nichts für dich. Geh woanders hin, geh dorthin, wo die Menschen an das Gleiche glauben wie du.

10

Ich könnte noch viel mehr Links mit entsprechenden Daten hinzufügen, wenn ich nicht auf zwei Links beschränkt wäre. Abgesehen von Cloudflare, das riesig ist und sich nicht auf SEO konzentrieren muss, verwenden alle Websites auf der ersten Seite dieser Suche Unterverzeichnisse.

Es wird nicht schwer sein, weitere Stellen zu finden, an denen Menschen dasselbe glauben, da dies in der SEO-Community anscheinend Konsens ist.

Aber natürlich, wenn du IRGENDEINEN Beweis hast, dass eine Subdomain hilft, die Root-Domain zu ranken, bitte belehre das Internet :slight_smile:

11

Direkt von Matt Cutts. Ihre SEO-„Experten

12

Stimmt! Es ist um ein Vielfaches besser, etwas zu tun, worüber sich die meisten einig sind, dass es die Web-Rankings nicht verbessert, aber wahrscheinlich dazu führt, dass deine Seite unerwartet offline geht, ohne dass es eine klare Möglichkeit gibt, das Problem zu beheben.

13

Hat das schon mal jemand mit Cloudflare ausprobiert?

14

Wie wir in Ihrem anderen Thema bereits erklärt haben, kann das, was Sie tun möchten, hier nicht unterstützt werden.

Sie benötigen entweder einen Enterprise-Plan bei Cloudflare oder müssen benutzerdefinierte Worker erstellen. In beiden Fällen sollten Sie sich an Cloudflare wenden.

15

Wie bereits erwähnt, ist die Antwort, die ich zuvor gegeben habe alles, was Sie hier erhalten werden.

Was ich nicht deutlich genug gemacht habe, ist, dass dies eine aussichtslose Aufgabe ist.

Als grobe Orientierung würde ich Ihnen in der Größenordnung von 1.000 US-Dollar in Rechnung stellen und keinerlei Garantie geben, dass es länger als eine Woche nach der Einrichtung funktioniert. (Oder ich könnte 500 US-Dollar verlangen, ohne zu versprechen, dass ich es überhaupt hinbekomme.

Außerdem bräuchten Sie den Cloudflare Enterprise-Plan.

Wenn Sie interessiert sind, posten Sie im Marketplace, nennen Sie Ihr Budget und geben Sie an, dass Sie bereit sind, für Cloudflare Enterprise zu zahlen und verstehen, dass dies wahrscheinlich unmöglich ist.

16

Ich denke, ich bin zu 80 % mit der Implementierung fertig. Ich habe Discourse auf einer Subdomain als „normale

17

[quote=“UltraLuz, Beitrag: 16, Thema: 134788”]
Ich habe Discourse als „normale

18

Was soll ich für DISCOURSE_HOSTNAME einstellen, wenn ich DISCOURSE_RELATIVE_URL_ROOT verwende? Der relative Pfad wird für mich also blog sein, richtig?

Wie wirkt sich das auf SSL-bezogene Einstellungen aus? Dies ist mein env-Abschnitt in der YAML-Datei:

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

Die Abschnitte zu Letsencrypt und Virtual Host dienen meinem nginx-Docker-Container (jwilder/nginx-proxy), der das Proxying und die SSL-Erstellung basierend auf diesen Variablen übernimmt.

Außerdem hatte ich dies, aber ich denke, es wird vollständig durch den Code dort ersetzt:

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

Ja, /blog inklusive des Schrägstrichs.

Nein, nur ultraluz.com.br.

Ich vermute, du solltest den LetsEncrypt-Teil so belassen, wie er ist.

20

Es hat nicht so funktioniert. Ich vermute, das liegt daran, dass der Worker eine Domain benötigt, um Inhalte abzurufen, und die Root-Domain sich auf einer anderen IP befindet.

Im Grunde sage ich dem Worker: „Wenn jemand zu /blog geht, hole dies von rootdomain/blog