1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

WP 5.1 WP-Mulitsite-Konzept in Verbindung mit WP-Job-Manager

Dieses Thema im Forum "Konfiguration" wurde erstellt von lin, 6. Juli 2019.

  1. lin

    lin Well-Known Member

    Registriert seit:
    1. Dezember 2013
    Beiträge:
    799
    Zustimmungen:
    1
    hallo und guten Morgen Community,

    vorweg: die Frage ist auch die; ist dieser Thread besser im Plugin-Forum untergebracht oder im Konfigurations-Forum.

    ich wlll Wordpress in einem Multisite-Aufbau zum Einsatz bringen. Die Idee (die zugegebenermaßen noch weitere Ausreifung braucht) ist diese.

    ich habe drei Domains die alle sinnvollerweise an eine DATENBANK andocken. Auf dieser DB ist die WP-Job-Manager-Installation.

    Die Architektur koennte dann so aussehen:

    jobs_a.mysite.com
    jobs_b.mysite.com
    jobs_c.mysite.com

    Nun frage ich mich ob man das mit dem WP-Multisite-Konzept auch umsetzen kann? Meint ihr dass das geht.
    Ich werde mal die entsprechenden Dokumente zu dem Multisite-Konzept durcharbeiten.

    Viele Grüße
    lin

    update: habe eine sehr interessante Dokumentation gefunden zum Thema Multisite:
    https://marketpress.de/wordpress-multisite-einrichten/
     
    #1 lin, 6. Juli 2019
    Zuletzt bearbeitet: 6. Juli 2019
  2. lin

    lin Well-Known Member

    Registriert seit:
    1. Dezember 2013
    Beiträge:
    799
    Zustimmungen:
    1
    Hallo und guten Abend,


    ich hab mir nochmals Gedanken zu dem Thema URL-Weiterleitung gemacht: Also im engeren Sinne zu dem Thema
    Manuelles Weiterleiten oder Maskieren der Domain oder der Subdomain.

    Wie oben beschrieben ist die Architektur ja z.B so beschaffen:

    jobs_a.mysite.com
    jobs_b.mysite.com
    jobs_c.mysite.com

    Auf der - Sammelseite.Job.Mysite.com würde dann die ganze DB und die Logik sitzen. Wenn ich hier mit einer Weiterleitung von Domain und Subdomain arbeite, dann kann man - so denke ich - den Seitenbesucher automatisch an eine andere Website weiterleiten. Das ist doch im Grunde eine tolle Sache - oder nicht!? Also ich denke dass durch Maskierung verhindert wird, dass Besucher die Domain- oder Subdomainweiterleitung sehen, indem in der Adressleiste des Webbrowsers weiterhin der Domainname angezeigt wird.

    Wie man die Weiterleitung konfigurieren kann - da hab ich mal Gedanken gemacht:

    Es stehen insges. zwei verschiedene Weiterleitungsarten zur Verfügung:

    - als offene Weiterleitung der sogenannte Header-Redirect (301) und darüber hinaus die sogenannte versteckte Frame-Weiterleitung.
    - Der sogenannte Header-Redirect (301) ist im Grunde die allereinfachste und darüber hinaus auch die schnellste Art der Weiterleitung.

    Es ist dabei ja so, dass die Zieladresse der Weiterleitung -(also jene die nach der Umleitung in der Adresszeile des Browsers erscheint (Das bedeutet also dass es von der www.Ausgangs-url.com zu www.Ende-oder-auch-Ziel-url.de geht).

    Bei der sogenannten Frame-Weiterleitung kann der Webbetrachter und Webnutzer in der Adresszeile des Browsers überhaupt nicht erkennen, dass er weitergeleitet wird. Er bekommt nichts von diesem Vorgang mit. Einer der großen Vorteile dieser Art der
    versteckten Weiterleitung ist, dass diese Technik sehr sehr schnell ist. Es geht praktisch ausgesprochen schnell.

    Also - ich denke es ist so: ich kann das Thema ja auch so beschreiben: Sagen wir es also mal mit anderen Worten: es soll nur die TLD meiner Webpage dem User sichtbar sein. Wie mache ich das?

    Also, um mal ein Beispiel zu geben: anstelle von

    foo.com soll immer dann beim Betrachter nur
    bar.com stehen, egal welche Scriptseite gerade aktiv ist...

    Wie kann man das bewerkstelligen: ich denke dass das auch mit .htacces versucht werden kann.

    By the way: Mein Webserver ist ein Apache

    es gibt - so denke ich mehrere Ansätze:

    Ansatz: man leitet einfach alle Anfragen an eine index.php um und entscheide mit PHP, was geladen wird.
    Ansatz: zu mod_rewrite oder mod_dir Dokumentation?

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Ich hab noch weitere Infos gefunden - auch hier:

    https://httpd.apache.org/docs/current/mod/mod_rewrite.html

    Apache Module mod_rewrite
    mehr hierzu: https://httpd.apache.org/docs/current/mod/mod_rewrite.html

    Also - ich werde alles nochmals durchdenken und mir noch weitere Gedanken zu dem Thema URL-Weiterleitung machen. Also im engeren Sinne zu dem Thema Manuelles Weiterleiten oder Maskieren der Domain oder der Subdomain.

    Wie oben beschrieben ist die Architektur ja z.B so beschaffen:

    jobs_a.mysite.com
    jobs_b.mysite.com
    jobs_c.mysite.com

    Auf der - Sammelseite.Job.Mysite.com würde dann die ganze DB und die Logik sitzen. Und da eben dann auch der WP-Plugin Wp-job-manager.


    Werde mich nochmals mit dem 'Thema auseinandersetzen und dann wieder melden.

    VG Lin
     
  3. lin

    lin Well-Known Member

    Registriert seit:
    1. Dezember 2013
    Beiträge:
    799
    Zustimmungen:
    1
    hallo und guten Abend,

    hier nochmals ein Posting mit weiteren Ideen und Gedanken zum Thema.

    ich denke, dass ich das auch so machen koennte - unter Zuhilfenahme der wp-function "connect wpdb" um die Verbindung zu einer anderen Datenbank herzustellen. Also eine Instanz erzeugen und die DB-Daten name/username/password dann zu übergeben.

    die Architektur - der sieht so aus:

    Auf allen diesen Seiten läuft ein wp-plugin wp-job-manager. Also drei DB miteinander zu verbinden das ist kein normaler wordpress-setup.
    Wenn denn die drei Seiten alle auf demselben Server sind - und unter demselben hosting account erreichbar, dann - also unter diesem Umstand wird das Verfahren unterstützt. Dann könnte mir ein kleines custom code-script dabei helfen, einen Zugang zur DB direkt von einer anderen Seite zu erhalten.
    wpdb kann hierbei helfen - wenn instanziert um eine andere (fremde) Datenbank zu erreichen u. eine Query auszuführen.
    mit der wp-funktion "connect wpdb" kann man eine andere WP-Datenbank erreichen und die Verbindung dazu herstellen.

    Das wpdb Objekt sollte eingesetzt werden um den Zugang zu jedwedter DB auf dem Server zu ermoeglichen u. Abfragen zu ermoeglichen.
    Der große Vorteil dieser Methode ist, dass man alle generellen wpdb-Klassen und auch die Funktion, wie get_results und andere mehr einsetzen kann.

    Denke mal dass das dann etwa so aussehen könnte:

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Man kann dann sogar die vordefinierten Konstanten verwenden die in der wp-config.php stehen - um irgendwelche moeglichen
    Turbulenzen mit den hardcoded database-login Informationen der Site zu vermeiden.

    Es sollte auch mit dem folgenden Code gehen.

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Wenn die zusätzliche DB mit den db-access-credentials (also user/pass details to access') für unsere Haupt-Wordpress-Datenbank können wir den Datenbankname vor dem Tabellenname so aussehen: Wie sieht es aus mit dem Einsatz und Gebrauch der anderen custom features - also etwa mit

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    get_post_custom und anderen wordpress queries. Die einfache Lösung hier sieht so aus:


    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Wie sich alles verhielt: diese Funktion meckert etwas wp_get_post_terms() DB?? Alle Funktionen gehen get_post_meta(), get_posts() etc) diese liefen gut wp_get_post_terms() scheint sich auf den DB_NAME Database zu beziehen.

    by the way: was die Datenbank systemweit ändert (ein mysql select_db).

    nochmals: die Architektur:

    Ich werde nun einiges ausprobieren u. mich wieder hier melden .
     
    #3 lin, 7. Juli 2019
    Zuletzt bearbeitet: 7. Juli 2019
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden