web-dev-qa-db-fra.com

Configuration de 3 sites pour se connecter à 1 base de données et partager des données

Comment configurer 3 installations Wordpress différentes sur 3 serveurs différents, qui se connectent tous à une même base de données et partagent les mêmes données?

J'aimerais installer 3 serveurs différents. Un pour le développement, l’assurance qualité/mise en scène et la production. Chaque site doit être isolé de l'autre et ils sont simplement utilisés pour afficher les mêmes données de la base de données, ce qui signifie:

  • Les développeurs travailleront sur le serveur de développement, ce qui signifie que cette installation évoluera constamment.
  • Le serveur d'assurance qualité/intermédiaire sera moins en état de changement, car les responsables de l'assurance qualité testeront les fonctionnalités ajoutées par l'équipe de développement.
  • La production ne sera mise à jour que périodiquement à partir de codes testés et fonctionnels validés via le serveur QA/Staging.

Veuillez noter que le partage de ressources "de téléchargement" n'est pas un problème, car je prévois d'utiliser le service AWS S3 pour stocker toutes mes ressources (par exemple, des images), tout en utilisant également AWS CloudFront pour agir en tant que CDN pour servir toutes lesdites ressources.

databasedevelopmentstaging
1
Corey

Pour élaborer sur ma suggestion, voici un code de travail:

// 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;
}

Pour basculer vers un thème utilisateur par utilisateur, utilisez ?usertheme=theme-slug

... et pour réinitialiser, utilisez simplement ?usertheme=reset

Puisque tout le code de thème est chargé en fonction de la feuille de style utilisée , vous pouvez configurer les répertoires Child Themes pour Live, Staging et Development (avec le même modèle parent). ) et passez d’un thème à l’autre en tant que développeur et visualisez immédiatement les résultats sur le même domaine. :-)

La seule réserve à laquelle je peux penser est de tester les mises à jour majeures de plugins. Vous aurez toujours besoin d'un environnement de développement à cette fin et peut-être synchroniser la base de données pour les tester avec le contenu actuel de la base de données. C’est uniquement parce que vous ne savez pas s’ils changeront la structure de la table de la base de données d’options (même s’ils sont rares, il n’y a pas lieu de revenir en arrière, vous pouvez donc casser un site actif de cette façon.)

Quelque chose de plus serait nécessaire pour tester la sortie du site pour utilisateurs déconnectés , mais cela pourrait être fait avec une chaîne de requête différente pour des charges ponctuelles, ou avec cookies au lieu de méta utilisateur pour un résultat persistant similaire.

Quoi qu’il en soit, l’avantage de pouvoir organiser les extraits de code dans des fichiers à des fins de test en développement et de transfert dans le même domaine, ce qui facilite l’insertion de nouvelles modifications entre eux, sans avoir à s’inquiéter de la synchronisation de la base de données (même si c’est un autre approche réalisable) en fait un moyen très pratique de faire les choses que je pense.

0
majick

Vous pouvez utiliser des sous-domaines pour vos installations de développement et d'assurance qualité. Tels que qa.domain.com et dev.domain.com. Lorsque les sous-domaines sont créés, les sous-répertoires sont également créés. Vous pouvez installer un wordpress supplémentaire dans chaque répertoire de sous-domaines. Créez ensuite 2 bases de données supplémentaires. Sauvegardez la base de données de production et chargez-la dans les 2 nouvelles bases de données. Configurez vos fichiers config.php pour cette nouvelle base de données et vous aurez 2 nouveaux serveurs. Vous devrez apporter des mises à jour aux bases de données. Au moins deux emplacements home et site_url dans la table _options. J'ouvre habituellement le fichier .sql dans un éditeur de texte et je cherche et remplace domain.com par sub.domain.com.

0
stoi2m1