¿Podemos usar una instalación de WordPress para múltiples bases de datos, dominios y directorios de contenido?

He visto algunas preguntas que parecen similares, pero todas terminaron en varios sitios . Por mantenimiento, rendimiento y seguridad, no quiero usar multisitio. Así que por favor tengan paciencia conmigo.

Esto es lo que estoy pensando:

.
|_____branch1 // for branch1.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch2 // for branch2.domain.com
|  |_____themes
|  |_____plugins
|
|_____branch3 // for branch3.domain.com
|  |_____themes
|  |_____plugins
|
|_____index.php
|_____WordPress
|_____wp-config.php

Como puede ver, cada dominio tiene su propia base de datos y directorio de contenido, pero solo una instancia de WordPress. Ahora, los temas, complementos y bases de datos se vuelven más pequeños e independientes. Entonces, sería mucho más fácil de mantener, escalar ...

Pero es posible? Si ha experimentado el mismo problema antes, ¡comparta sus pensamientos! Realmente aprecio tu ayuda.

Como @ tom-j-nowell dijo en un comentario a OP, multisitio puede hacer esto más fácil.

El rendimiento y la seguridad no son realmente un problema para multisitio (al menos, no más de lo que son para instalaciones regulares), pero estoy de acuerdo en que multisitio a veces puede ser un problema, porque muchos complementos (ya sea personalizados o de terceros) pueden no serlo. funciona correctamente en varios sitios, o tal vez porque desea mantener a los usuarios de diferentes sitios web completamente separados.

Dicho esto, lo que quieres lograr no es tan difícil.

Lo que necesita cambiar entre la instalación es:

• carpeta de complementos
• carpeta de temas
• configuración de la base de datos

Esa configuración se puede hacer usando constantes enwp-config.php su único problema es cómo cambiarlos en función de la URL.

La variable del servidor 'SERVER_NAME'debería funcionar para usted, al menos si su servidor web está configurado correctamente.

Por ejemplo, puede crear una carpeta /confcon el mismo nivel de wp-config.phparchivo y /WordPresscarpeta.

En esa carpeta puede agregar algunos archivos:

• branch1.domain.com.conf
• branch2.domain.com.conf
• branch3.domain.com.conf

dentro de cada uno de ellos puedes hacer algo como

$branch = 'branch1';
$base_dir = dirname( __DIR__) . "/{$branch}";

defined( 'WP_CONTENT_DIR' ) or define( 'WP_CONTENT_DIR', $base_dir );

// be sure WP understand URLs correctly
defined( 'DB_HOME' ) or define( 'DB_HOME', "{$branch}.example.com" );
defined('WP_SITEURL') or define('WP_SITEURL', "{$branch}.example.com/WordPress");

// adjust DB settings  as needed
defined( 'DB_NAME' ) or define( 'DB_NAME', $branch );
defined( 'DB_USER' ) or define( 'DB_USER', $branch );
defined( 'DB_PASSWORD' ) or define( 'DB_PASSWORD', '********' );

unset( $base_dir, $branch );

Esto cambiará en cada archivo de configuración de acuerdo con la "rama".

Después de eso, en su único wp-config.phppuede algo así como:

$defaults_conf = [
  'WP_CONTENT_DIR' => __DIR__ . '/branch1',
  'DB_HOST'        => 'localhost',
  'DB_NAME'        => 'branch1',
  'DB_USER'        => 'branch1',
  'DB_PASSWORD'    => '********',
];

$host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

if ($host && file_exists(__DIR__."/conf/{$host}.conf")) {
  require __DIR__."/conf/{$host}.conf";
}

array_walk($defaults_conf, function($value, $name) {
   defined($name) or define($name, $value);
});

unset($defaults_conf, $host);

Lo que sucede arriba es que, en función del nombre del servidor, carga un archivo de configuración diferente (si se encuentra) y si el archivo de configuración no define ninguna de las configuraciones predeterminadas (o si no se encuentra el archivo), las configuraciones se establecen de manera predeterminada.

Lo bueno es que para agregar una nueva rama, solo necesita crear la carpeta de la rama y proporcionar un .confnombre después del nuevo dominio de la rama, y ​​listo, no hay nada que cambiar en el lado de WP.

La línea:

 $host = getenv('WORDPRESS_HOST') ?: $_SERVER['SERVER_NAME'];

es donde obtengo el nombre de dominio. Como primera opción, estoy usando una variable de entorno, porque hay posibilidades de $_SERVER['SERVER_NAME']que no funcione en un contexto de línea de comando, como cuando usamos WP CLI. En esas situaciones, puede establecer una variable de entorno para obligar a WP a usar la configuración de una rama específica.

Tenga en cuenta que en los archivos de configuración específicos de la rama, estoy cambiando la WP_CONTENT_DIRcarpeta y que automáticamente configurará los complementos y la carpeta de temas a los relacionados /pluginsy/themes subcarpetas rama.

Un posible problema aquí es si desea compartir la /uploadscarpeta (donde se cargan los archivos).

De manera predeterminada, esa carpeta es una subcarpeta del directorio de contenido, por lo que el uso del flujo de trabajo anterior será una /uploadssubcarpeta de cada carpeta raíz de rama.

Si eso no es un problema para usted, simplemente vaya con él, de lo contrario, la solución más fácil sería hacer que /uploadsen cada carpeta de sucursal un enlace simbólico a la carpeta de cargas reales que desea compartir.

Esto es posible con un enlace simbólico y un poco de planificación. Hice un poco de búsqueda en la red por lo mismo. Finalmente, junte todas las cosas y póngalo a funcionar.

He estado ejecutando algunos sitios web, todos comparten el mismo tema y carpeta de complementos. Las mismas carpetas funcionan para sitios múltiples y únicos. Pero debe tener cuidado con ciertos complementos que pueden ser solo sitios múltiples / únicos y ser extravagantes.

He creado un directorio como master-tnp / themes y master-tnp / plugins. Luego enlace simbólicamente a su directorio de wordpress usando el comando ln -s.

Las trampas también están en las configuraciones del servidor. Asegúrese de que la directiva seguir enlaces simbólicos esté configurada para permitir.

Si desea utilizar una instalación única de WordPress, he reunido una guía detallada sobre cómo lo hice en https://vaish.co/multiple-sites-single-wordpress-directory