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

10

Já vi algumas perguntas semelhantes, mas todas foram concluídas com multisite . Para facilidade de manutenção, desempenho e segurança, não quero usar multisite. Então, por favor, tenha paciência 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, escalar ...

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

    
por MinhTri 13.06.2016 / 14:00

2 respostas

10

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

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

Isso disse que 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 alterá-las com base URL.

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

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

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

Isso mudará em cada arquivo de configuração de acordo com a "ramificação".

Depois disso, no seu wp-config.php exclusivo, você pode fazer algo 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);

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) .

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 de ramificação, e pronto, não há nada para alterar no lado do 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 existem chances $_SERVER['SERVER_NAME'] não funcionará em um contexto de linha de comando, como nós quando usamos o WP CLI. Nessas situações, você pode definir uma variável de ambiente para forçar o WP a usar as configurações de um ramo específico.

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 de temas para as subpastas de ramificação /plugins e /themes relacionadas.

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 da 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 de upload real que você deseja compartilhar.

    
por gmazzap 13.06.2016 / 18:35
0

Isso é possível com um symlinking e um pouco de planejamento. Eu fiz algumas pesquisas na rede para a mesma coisa. Finalmente, junte todas as coisas e faça-o funcionar.

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 plug-ins que podem ser apenas do tipo Multi / Single e ser peculiar.

Eu fiz um diretório como master-tnp / themes e master-tnp / plugins. Em seguida, faça uma ligação simbólica 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 enlace

    
por Cpyder 25.06.2017 / 11:00