web-dev-qa-db-fra.com

Ignorer la configuration de la base de données pour le multiblog WordPress

Notre équipe a rencontré un problème avec multipress wordpress 3. Nous travaillons généralement avec une copie locale du site (localhost/testsite) mais avec la même base de données pour maintenir toutes les modifications à jour.

Cela fonctionne très bien en une seule installation car vous pouvez remplacer la configuration de la base de données depuis php avec:

define('URL',$path);  
define('WP_HOME',$path);  
define('WP_SITEURL',$path);  
define( 'WP_CONTENT_URL', $path.'/wp-content');

Mais cela ne fonctionne pas sur le multisite à cause des tables supplémentaires (wp_blogs, wp_site) et ils ont le chemin du blog dans leurs paramètres.

Est-ce que quelqu'un sait comment remplacer ces paramètres? Je voudrais que le site fonctionne sur le domaine localhost pour nos développeurs, developerdomain.com pour nos serveurs de test, puis realdomain.com lorsque le site est mis en ligne.

Il semble exagéré de devoir configurer différentes bases de données pour chacune d’entre elles et de modifier manuellement le domaine et le chemin, puis de copier la publication, le blog et les données utilisateur entre les bases de données pour effectuer le débogage et poursuivre le développement.

customizationmultisitestaging
1
Michael Lindfors

Eh bien, si vous voulez le faire correctement, vous aurez une base de données pour le développement, une base de stockage intermédiaire, puis la base de données dynamique. C'est juste que Wordpress n'est pas conçu pour vivre avec de tels biens communs en génie logiciel.

Le composant que je vois toujours publiquement manquant est un script de migration complet capable de convertir tous les paramètres et toutes les données WordPress de la base de données d'un domaine à un autre, car les noms de domaine sont codés en dur dans des publications et enterrés dans plusieurs valeurs d'option (souvent sérialisées) .

Tant que les quelques options que vous avez répertoriées vous préoccupent, vous pouvez vous connecter à des filtres pre_option_... et les modifier en fonction de votre configuration. Vous pouvez écrire une définition dans votre fichier de configuration et modifier les valeurs en conséquence. Cela peut fonctionner avec les configurations multisites et filtrer les valeurs réelles de la base de données.

Est-ce une direction?

2
hakre

Ce n'est pas aussi élégant que je le souhaiterais, mais cela fonctionne: vous pouvez modifier votre fichier hosts pour qu'il pointe www.realdomain.com sur localhost.

Votre demande à www.realdomain.com reviendra ensuite à votre ordinateur local, trouvera WordPress (si tout est configuré correctement), et WordPress fonctionnera normalement, car il ne réalise pas qu'il s'agit en aucun cas d'un environnement de développement local. .

Il y a des inconvénients, mais c'est une solution très rapide et sale.

0
Nabha

D'accord, c'est une autre solution géniale, mais cela semble fonctionner. Pour remplacer le contenu qui renvoie à www.realdomain.com, vous devez en faire plus.

Mettez ceci dans votre fichier wp-config.php après avoir défini les informations de votre base de données.

    if( 'example-local' == $_SERVER['SERVER_NAME'] ) {

        mysql_connect(DB_Host, DB_USER, DB_PASSWORD) or die(mysql_error());
        mysql_select_db(DB_NAME) or die(mysql_error());

        $queries[0] = <<<HEREDOC

        UPDATE wp_blogs
        SET domain="example-local"
        WHERE domain="www.example.org"; 

HEREDOC;

        $queries[1] = <<<HEREDOC

        UPDATE wp_options 
        SET option_value = replace( option_value, "www.example.org", "example-local" ); 

HEREDOC;

        for ($i = 4; $i < 9; $i++) {

            $queries[] = 'UPDATE wp_' . $i . '_options 
        SET option_value = replace( option_value, "www.example.org", "example-local" );';

        }   

        foreach( $queries as $query ) { 

            $result = mysql_query( $query );

            if (!$result) {
                die('Invalid query: ' . mysql_error());
            }

        }

    }
0
Nabha