ti-enxame.com

Podemos usar uma instalação do WordPress para vários bancos de dados, domínios e diretórios de conteúdo

Eu tenho visto algumas questões que parecem semelhantes, mas todos acabaram com multisite . Para facilidade de manutenção, desempenho e segurança, não quero usar multisite. Por favor tenha paciencia comigo.

É nisso que estou 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 você pode ver, cada domínio tem seu próprio banco de dados e diretório de conteúdo, mas apenas uma instância do WordPress. Agora, temas, plugins e bancos de dados se tornam menores e independentes. Então, seria muito mais fácil manter, dimensionar ...

Mas isso é possível? Se você já experimentou o mesmo problema antes, por favor, compartilhe seus pensamentos! Eu realmente aprecio sua ajuda.

9
MinhTri

Como @ tom-j-nowell disse em comentário ao OP, o multisite pode tornar isso mais fácil.

Desempenho e segurança não são realmente um problema para multisite (pelo menos, não mais do que são para instalações regulares), mas eu concordo que o multisite às vezes pode ser um problema, porque muitos plugins (personalizados ou de terceiros) podem não ser funcionar corretamente em vários sites, ou talvez porque você deseja manter os usuários de sites diferentes completamente separados.

Dito isso, o que você quer alcançar não é tão difícil.

O que você precisa mudar entre a instalação é:

  • pasta de plugins
  • pasta de temas
  • configurações do banco de dados

Essa configuração pode ser feita usando constantes em wp-config.php seu único problema é como alterná-las com base na URL.

A variável do servidor 'SERVER_NAME' deve funcionar para você, pelo menos se o seu servidor estiver configurado corretamente.

Por exemplo, você pode criar uma pasta chamada /conf no mesmo nível do arquivo wp-config.php e /WordPress.

Nesta pasta você pode adicionar alguns arquivos:

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

dentro de cada um deles você pode fazer algo parecido

$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 );

Isto irá mudar em cada arquivo de configuração de acordo com o "branch".

Depois disso, no seu wp-config.php único você pode algo assim:

$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);

O que acontece acima é que, com base no nome do servidor, você carrega um arquivo de configuração diferente (se encontrado) e se o arquivo de configuração não define nenhuma configuração padrão (ou se o arquivo não for encontrado), a configuração é definida por padrão.

O interessante é que, para adicionar uma nova ramificação, basta criar a pasta de ramificação e fornecer um .conf com o nome do novo domínio da ramificação, e pronto, não há nada a ser alterado no lado WP.

A linha:

 $Host = getenv('WORDPRESS_Host') ?: $_SERVER['SERVER_NAME'];

é onde eu recebo o nome de domínio. Como primeira opção estou usando uma variável de ambiente, pois há chances de que $_SERVER['SERVER_NAME'] não funcione em um contexto de linha de comando, como quando usamos WP CLI. Nessas situações, você pode definir uma variável de ambiente para forçar WP a usar as configurações de uma ramificação específica.

Observe que, em arquivos de configuração específicos de ramificação, estou alterando o WP_CONTENT_DIR e isso definirá automaticamente a pasta de plug-ins e temas para as subpastas de ramificação relacionadas /plugins e /themes.

Um possível problema aqui é se você quiser compartilhar a pasta /uploads (onde os arquivos são carregados).

Por padrão, essa pasta é uma subpasta do diretório de conteúdo, portanto, usar o fluxo de trabalho acima dela será uma subpasta /uploads de cada pasta raiz de filial.

Se isso não é um problema para você, então simplesmente a solução mais fácil seria tornar /uploads em cada pasta de filial um link simbólico para a pasta real uploads que você deseja compartilhar.

9
gmazzap

Isso é possível com um symlinking e um pouco de planejamento. Eu fiz algumas pesquisas na rede para a mesma coisa. Finalmente, juntamos todas as coisas e começamos a trabalhar.

Eu tenho executado alguns sites, todos eles compartilham o mesmo tema e pasta de plugins. Mesas pastas funcionam para sites com vários sites e sites. Mas você tem que ter cuidado com certos plugins que podem ser apenas do tipo Multi/Single e serem peculiares.

Eu fiz um diretório como master-tnp/themes e master-tnp/plugins. Então symlink para o seu diretório wordpress usando o comando ln -s.

As armadilhas também estão nas configurações do servidor. Certifique-se de seguir a diretiva symlinks está definida para permitir.

Se você quiser usar uma instalação única do WordPress, eu coloquei um guia detalhado sobre como eu fiz isso em https://vaish.co/multiple-sites-single-wordpress-directory

0
Cpyder