Setup 3 Sites zum Herstellen einer Verbindung mit 1 database und Teilen von Daten

Wie richte ich 3 verschiedene WordPress-Installationen auf 3 verschiedenen Servern ein, die alle mit einer einzigen database verbunden sind und dieselben Daten teilen?

Ich möchte 3 verschiedene Server einrichten. Eine für Entwicklung, QA / Inszenierung und Produktion. Jede Site sollte von der anderen isoliert sein und sie werden einfach verwendet, um dieselben Daten aus der database anzuzeigen, was bedeutet:

  • Entwickler werden im Entwicklungsserver arbeiten, was bedeutet, dass sich diese Installation in einem ständigen Wandel befindet.
  • Der QA / Staging-Server befindet sich in einem Zustand der Veränderung, da QA-Leute die vom Entwicklungsteam hinzugefügte functionalität testen werden.
  • Die Produktion wird nur in regelmäßigen Abständen von getestetem und funktionierendem Code aktualisiert, der über den QA / Staging-Server überprüft wurde

Bitte beachten Sie, dass das Teilen von “Upload” -Ressourcen kein Problem ist, da ich den AWS S3-Service zum Speichern aller meiner Ressourcen (z. B. Bilder) verwenden und AWS CloudFront als CDN verwenden möchte, um alle genannten Ressourcen zu bedienen.

Solutions Collecting From Web of "Setup 3 Sites zum Herstellen einer Verbindung mit 1 database und Teilen von Daten"

Um meinen Vorschlag zu erläutern, hier ist ein Arbeitscode:

 // hook in before theme is loaded add_action('plugins_loaded','custom_maybe_switch_themes'); function custom_maybe_switch_themes() { if (!is_user_logged_in()) {return;} if (!current_user_can('manage_options')) {return;} // check for query request eg. ?usertheme=theme-slug if (isset($_REQUEST['usertheme'])) { // sanitize request $usertheme = strtolower(sanitize_title($_REQUEST['usertheme'])); global $current_user; $current_user = wp_get_current_user(); // maybe reset user meta stylesheet if ($usertheme == 'reset') {delete_user_meta($current_user->ID,'stylesheet'); return;} // validate theme $theme = wp_get_theme($usertheme); if ($theme->exists()) { delete_user_meta($current_user->ID,'stylesheet'); add_user_meta($current_user->ID,'stylesheet',$usertheme); } } } // add filter to stylesheet option add_filter('pre_option_stylesheet', 'get_user_stylesheet'); function get_user_stylesheet($stylesheet) { if (!is_user_logged_in()) {return $stylesheet;} if (!current_user_can('manage_options')) {return $stylesheet;} // check user meta stylesheet global $current_user; $current_user = wp_get_current_user(); $userstylesheet = get_user_meta($current_user->ID,'stylesheet',true); // if we have a value use it instead if ($userstylesheet) {return $userstylesheet;} return $stylesheet; } 

Um zu einem Thema auf Benutzerbasis zu wechseln, verwenden Sie ?usertheme=theme-slug

… und zum Zurücksetzen einfach verwenden ?usertheme=reset

Da der gesamte Theme-Code abhängig vom verwendeten Stylesheet geladen wird , könnten Sie Child-Themes-Verzeichnisse für Live, Staging und Entwicklung (mit der gleichen Parent-Vorlage) einrichten und als Entwickler ganz einfach zwischen den Themes wechseln und die Ergebnisse sofort sehen Domain. 🙂

Die einzige Einschränkung, die ich mir vorstellen kann, ist das Testen wichtiger Plug-in-Updates. Sie benötigen dazu noch eine Entwicklungsumgebung und können die database möglicherweise synchronisieren, um sie mit dem aktuellen databaseinhalt zu testen. Dies liegt nur daran, dass Sie nicht wissen, ob sie ihre Optionsdatenbanktabellenstruktur ändern werden (obwohl es selten ist, dass es keine Zurücksetzung gibt, so dass Sie eine Live-Site auf diese Weise unterbrechen könnten.)

Zum Testen der Site-Ausgabe für ausgeloggte Benutzer wäre noch etwas anderes erforderlich, aber das könnte mit einem anderen Querystring für einmalige Ladevorgänge oder mit Cookies anstelle von Benutzermeta für ein ähnliches persistentes Ergebnis erfolgen.

Wie auch immer, der Vorteil, dass Code-Snippets in Dateien organisiert werden können, um in Entwicklung und Staging auf derselben Domain zu testen, neue Änderungen zwischen ihnen wirklich einfach zu machen und sich keine Sorgen über die databasesynchronisation machen zu müssen praktikablen Ansatz) macht dies eine sehr bequeme Art, Dinge zu tun, denke ich.

Sie können Subdomains für Ihre Dev- und QA-Installationen verwenden. Wie zum Beispiel qa.domain.com und dev.domain.com. Wenn die Subdomains erstellt werden, werden in der Regel auch Unterverzeichnisse erstellt. Sie können ein zusätzliches WordPress in jedem Subdomains-Verzeichnis installieren. Erstellen Sie dann 2 zusätzliche databaseen. Sichern Sie die Produktionsdatenbank und laden Sie sie in die zwei neuen databaseen. Richten Sie Ihre config.php-Dateien für diese neue database ein und Sie haben 2 neue Server. Sie müssen einige Aktualisierungen an den databaseen vornehmen. Mindestens zwei Standorte home und site_url in der Tabelle _options. Ich öffne normalerweise die .sql Akte in einem Texteditor und suche und ersetze domain.com mit sub.domain.com.