Einrichten eines WordPress-Netzwerks mit Domänen der dritten Ebene

Ich habe versucht, eine WordPress-Netzwerkinstallation einzurichten. Alles lief ziemlich reibungslos, bis ich an den Punkt komme, an dem mein gewünschtes Domain-Layout nicht mehr gut passt.

Ich hätte gerne ein Layout wie folgt:

Blog. *. stackexchange.com

So möchte ich beispielsweise mehrere Standorte in einem Netzwerk haben, die wie folgt aussehen:

blog.wordpress.stackexchange.com
blog.apple.stackexchange.com
blog. $ site.stackexchange.com

Ich denke, ich könnte dies mit einigen kreativen Regeln zum erneuten Schreiben und manuellen DNS-Eingriffen zum Laufen bringen, aber ich hätte lieber ein Setup, in dem ich die Erstellung von allem außer dem DNS an jemand anderen weitergeben kann (wir haben bereits einen Prozess für automatisch Erstellen aller in DNS benötigten Subdomains)

Wenn ich herumspiele und WP lese, möchte ich wirklich, dass die Websites die Domain der nächsten Ebene sind. In meinem obigen Beispiel möchte ich, dass sich das Haupt-WP-Blog auf stackexchange.com und die Netzwerk-Blogs unter wordpress.stackexchange.com befinden.

Gibt es eine Möglichkeit, meinen gewünschten Effekt zu erzielen, oder sollte ich einfach blog.stackexchange.com/$site ausführen?

Sie können hierfür das Domain Mapper- Plugin verwenden. Nachteil ist, dass Sie jedes Subblog manuell konfigurieren müssten.

Sie können dies mit einer angepassten Datei sunrise.php tun. Dies ist im Wesentlichen die Funktionsweise des Domain-Mapping-Plugins, bietet jedoch ein hübsches Frontend. Für etwas Benutzerdefiniertes können Sie ein einfaches PHP schreiben, um im Grunde das Gleiche zu tun.

Die Essenz von Multisite besteht darin, herauszufinden, welcher Standort bedient werden soll. Das Domain-Mapping-Plugin erstellt dazu eine Tabelle wp_domain_mapping und speichert die Informationen darin. Wenn es also eine Anfrage für xxx.com erhält, sieht es in dieser Tabelle nach, dass dies blog_id 123 entspricht.

Erstellen Sie zunächst ein WordPress-Setup und machen Sie es multisite. Es spielt keine Rolle, wo es wirklich lebt, denn wir werden das alles ändern. Der Einfachheit halber würde ich es auf blog.stackexchange.com setzen und es zu einer Site vom Typ Unterverzeichnis machen (diese sind einfacher). Die erstellten Unterverzeichnisse wären wahrscheinlich die Slugs. / WordPress, / Apfel, / was auch immer.

Also ja, zunächst einmal machen Sie es tatsächlich live unter blog.stackexchange.com/wordpress. Betrachten Sie dies als Ihre Staging-Umgebung. Wenn Sie jede Site erstellen, können Sie hier etwas tun, bis Sie das Mapping aktivieren.

Um das Domain-Mapping selbst ohne das Plugin durchzuführen, gehen Sie wie folgt vor:

Schritt eins: define( 'SUNRISE', 'on' );Fügen Sie oben in Ihrer Datei wp-config.php hinzu.

Schritt zwei: Erstellen Sie eine sunrise.php-Datei im Verzeichnis wp-content. Zunächst <?phpoben platzieren.

Schritt drei: In der Datei sunrise.php wird Ihre Logik sein, um zu bestimmen, welche Site geladen werden soll.

Sie werden dies auf der $_SERVER[ 'HTTP_HOST' ]Variablen basieren. Wie Sie das genau machen, ist einfach: wie auch immer Sie es wollen. Wenn Sie nur einen regulären Ausdruck schreiben möchten, nach dem gesucht werden soll, '/blog\.(.*)\.stackexchange\.com/'und dann nach diesem Bit in der Datenbank suchen möchten , können Sie dies tun.

Da Sie hier denselben Slug wie im "Unterverzeichnis" verwenden, benötigen Sie keine separate Tabelle. Sie können einfach in der Haupttabelle wp_blogs nach der gewünschten Site suchen. Ähnliches:

$current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );

Sobald Sie den $ current_blog haben, benötigen Sie den folgenden Code:

$current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
$current_blog->path = '/';
$blog_id = $current_blog->blog_id;
$site_id = $current_blog->site_id;
$current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
$current_site->blog_id = $current_blog->blog_id;

Dadurch werden die globalen Variablen $ current_blog und $ current_site vordefiniert, anstatt die MU-Funktionen von WordPress ausführen zu lassen.

Dies würde ausreichen, um die Site zum Laufen zu bringen (nachdem Ihr DNS darauf verwiesen und das virtuelle Hosting-Material aussortiert wurde). Die meisten statischen URLs, die im HTML-Code verwendet werden, verweisen jedoch weiterhin auf blog.stackexchange.com / wordpress, da dort die Seite wirklich wäre. Außerdem würde die Canonical URL-Funktion die URL wahrscheinlich nicht mögen und Sie auch umleiten.

Um diese Probleme zu beheben, möchten Sie wahrscheinlich auch mehrere der mit der Site verknüpften URLs vordefinieren. Dinge wie WP_SITEURL und WP_HOME. Außerdem WP_CONTENT_URL, WP_PLUGIN_URL und WPMU_PLUGIN_URL. Dies sollte die meisten Fälle abdecken, in denen die URLs angepasst werden.

Schließlich möchten Sie die 'COOKIE_DOMAIN' festlegen. Da Sie wahrscheinlich möchten, dass Anmeldungen für das gesamte Objekt freigegeben werden, können Sie sie auf stackexchange.com oder sogar höher einstellen, wenn Sie nicht möchten, dass sie freigegebene Anmeldungen sind.

Wenn Sie über die Integration des normalen Stackexchange-Anmeldesystems in WordPress sprechen möchten, kann ich auch Fragen dazu beantworten, aber es wäre eine etwas detailliertere Antwort. :) :)

Sie können mir gerne eine E-Mail senden, wenn Sie weitere Hilfe benötigen. Gerne helfen: otto bei wordpress.org.