Nosso objetivo é criar dois sites WordPress que irão compartilhar logins e os mesmos usuários. Uma vez que um usuário tenha subscrito um site, ela poderá acessar o outro site com a mesma função e as mesmas capacidades.

Para alcançar este objetivo, devemos ser capazes de editar o arquivo de configuração do WordPress e atualizar as tabelas do banco de dados. Um entendimento geral da arquitetura do WordPress e da estrutura do banco de dados é essencial, assim como um conhecimento básico do desenvolvimento do WordPress. Não te preocupes se não és um profissional. Basta seguir as diretivas deste post e fazer as suas perguntas nos comentários.

Antes de começarmos a codificar, precisamos saber onde o WordPress armazena as funções e capacidades do usuário. Portanto, o nosso primeiro passo é mergulhar fundo nas tabelas da base de dados.

Importante: O seguinte não funcionará fora da caixa no ambiente Kinsta, devido ao fato de só permitirmos uma instalação do WordPress para cada site (a menos que você esteja executando o WordPress multisite). Pode ser possível pôr isto a funcionar na nossa plataforma, mas isso exigiria alguma configuração ou desenvolvimento adicional. Recomendamos discutir isso com um desenvolvedor de WordPress.

Dados e Metadados do Usuário

Por padrão, o WordPress armazena dados relacionados ao usuário em três tabelas: {$pref}options, {$pref}users e {$pref}usermeta.

  • A tabela de {$pref}options armazena a lista completa de funções e capacidades disponíveis em uma linha cujo campo de opção é {$pref}user_roles.
  • A tabela de {$pref}users armazena dados básicos do usuário, como login, senha, e-mail, url, etc.
  • A tabela {$pref}usermetaa armazena os metadados do usuário.

Ao trabalhar em novas instalações do WordPress, não temos que nos preocupar com a linha {$pref}user_roles na tabela de {$pref}options, porque o campo option_value correspondente tem sempre o mesmo valor. Devemos considerar esta linha no caso de estarmos a trabalhar em instalações existentes onde as funções ou capacidades tenham sido alteradas.
Não se preocupe também com a tabela de {$pref}users, pois ela armazena dados básicos do usuário que não serão alterados quando compartilharmos usuários entre sites.
A tabela {$pref}usermeta é a única tabela que vamos atualizar para atingir o nosso objetivo.

utilizadores e estrutura da tabela usermeta
utilizadores e estrutura da tabela usermeta
(fonte: Codex Database Description)

{$pref}usermeta armazena os metadados do usuário em pares chave/valor. Nesta tabela, cinco linhas armazenam os dados que temos de considerar.

Cinco linhas na tabela usermeta armazenam dados relativos às capacidades do utilizador, nível e definições do painel de instrumentos
Cinco linhas na tabela usermeta armazenam dados relativos às capacidades do utilizador, nível e definições do painel de instrumentos

A primeira linha tem o campo meta_key definido como {$pref}capacidades, e o campo meta_value correspondente é um array serializado contendo a função do usuário. A segunda linha armazena o nível de usuário (note que os níveis de usuário são depreciados do WordPress 3.0). As três filas restantes dizem respeito às configurações do painel de instrumentos em que não vamos mergulhar neste posto. A função, nível e configurações do usuário são específicos para a instalação do WordPress e são identificados pelo mesmo valor de $pref. É uma informação importante quando o nosso objetivo é partilhar utilizadores entre websites, porque teremos de duplicar estas linhas e alterar o campo meta_key em conformidade.

É tudo o que temos de saber sobre tabelas de utilizadores quando pretendemos partilhar logins e utilizadores entre as novas instalações do WordPress. Ao trabalhar em sites existentes, devemos considerar que muitos plugins adicionam linhas extras ao {$pref}usermeta, e podemos ser obrigados a ter uma visão mais profunda das tabelas de banco de dados.

Dito isto das tabelas de utilizadores, podemos dar um passo em frente. Agora temos de definir duas constantes específicas no ficheiro wp-config.php.

Definindo tabelas personalizadas de usuários – Share Logins

O WordPress permite-nos definir tabelas personalizadas em vez de {$pref}users e {$pref}usermeta. Isto significa que se dois (ou mais) sites WordPress compartilham um banco de dados, podemos definir os mesmos usuários e tabelas usermeta para todos eles. Como consequência, todos os sites que partilham estas tabelas irão partilhar os mesmos utilizadores.

Nota: Para compartilhar os mesmos usuários e tabelas usermeta, as instalações do WordPress devem compartilhar o mesmo banco de dados.

Só precisamos definir CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE no arquivo wp-config.php, como mostrado no código a seguir:

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', 'my_users_table' );
define( 'CUSTOM_USER_META_TABLE', 'my_usermeta_table' );
Nota: Nos sites existentes é obrigatório fazer backup das instalações do WordPress antes de fazer qualquer alteração nos arquivos wp-config.php e nas tabelas de dados.

Agora que sabemos o que tem de ser feito, é altura de executar as nossas duas instalações WordPress.

Instalando o WordPress

Por conveniência, vou nomear as pastas raiz do WordPress primeiro e segundo. first_ e second_ serão os respectivos prefixos da tabela.
Agora vamos fazer a primeira instalação.

Neste exemplo, definimos o campo de prefixo da tabela como first_
Neste exemplo, definimos o campo de prefixo da tabela como first_
Nota: Todas as instalações irão compartilhar uma única base de dados, e devemos fornecer a cada instalação um prefixo de tabela único.

Quando o primeiro site WordPress estiver instalado e funcionando, podemos editar seu arquivo de configuração. Abra /first/wp-config.php e adicione as seguintes linhas acima do comentário ‘pare de editar’:

$table_prefix  = 'first_';

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', $table_prefix . 'users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix . 'usermeta' );

/* That's all, stop editing! Happy blogging. */

Nós ativamos o modo de debug forçando o WordPress a armazenar avisos de erro e avisos no arquivo debug.log (leia mais sobre este tópico em Uma visão aprofundada sobre como configurar o WordPress).
Depois, definimos as constantes CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE para as tabelas first_users e first_usermeta. Desta forma, não vamos alterar as configurações padrão do WordPress.

Terminamos com a primeira instalação. A seguir temos de copiar o wp-config.php da primeira pasta de instalação e colá-lo na pasta raiz da segunda instalação. Tenha o cuidado de alterar o valor $table_prefix de acordo:

$table_prefix  = 'second_';

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// custom users and usermeta tables
define( 'CUSTOM_USER_TABLE', 'first_users' );
define( 'CUSTOM_USER_META_TABLE', 'first_usermeta' );

CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE são definidos para os valores da primeira instalação: first_users e first_usermeta. Isso é tudo para a primeira instalação.

share logins
O WordPress está ciente dos usuários existentes e devemos definir um endereço de e-mail inexistente para o usuário administrador

Ao executar a segunda instalação, devemos definir um endereço de e-mail inexistente para o usuário administrador, pois o WordPress encontra um número de usuários existentes na tabela first_users.

WordPress cria um nome de usuário administrador para a segunda instalação
WordPress cria um nome de usuário administrador para a segunda instalação

Entre no segundo painel de administração da instalação como administrador e liste os usuários do WordPress. Você encontrará o novo usuário administrador e todos os usuários do primeiro site (isso permite que eles compartilhem logins). Neste ponto, os usuários de um site não poderão entrar no outro site.

Os usuários do segundo site não herdarão suas funções do primeiro site
Os usuários do segundo site não herdarão suas funções do primeiro site

Para conceder aos utilizadores as mesmas capacidades em ambos os sites, temos de atualizar a tabela {$pref}usermeta.

Papéis e Capacidades

Se você estiver executando novas instalações do WordPress, você não precisa se preocupar com a tabela de {$pref}options. Você só precisa atualizar a tabela {$pref}usermeta.

No nosso exemplo, quando um novo usuário é criado no primeiro site, o WordPress adiciona as first_capabilities e as first_user_level na tabela first_usermeta. Para dar acesso ao segundo site, estas linhas devem ser duplicadas, como mostra a imagem abaixo:

second_usermeta_fields

Quando um novo utilizador é criado no segundo website, as second_capabilities do segundo_utilizador e as linhas do second_user_level adicionadas à tabela first_usermeta. A
fim de dar as mesmas funções e limites aos usuários em todos os sites, as first_capabilities e linhas de first_user_level devem ser duplicadas em second_capabilities e second_user_level. Com estes dois pares de linhas na mesma tabela first_usermeta, os usuários poderiam acessar os dois sites com os mesmos privilégios.

Para atualizar todas as linhas de usermeta existentes você pode executar uma consulta SQL ou atualizar tabelas a partir do phpMyAdmin. Mas o que para os utilizadores que vão subscrever os nossos sites a partir de agora? De acordo com o Codex WordPress, nós usaríamos um plugin ou construiremos uma função personalizada.
E lá vamos nós!

Duplicar automaticamente tampas e níveis com uma função

set_user_role é um gancho de ação que aciona sempre que um novo usuário é criado ou que a função de um usuário existente foi editada. Graças a esta ação, podemos automatizar as atualizações da tabela usermeta.
Portanto, no arquivo principal de um plugin, adicione a seguinte função:

function ksu_save_role( $user_id, $role ) {

	// Site 1
	// Change value if needed
	$prefix_1 = 'first_';
	
	// Site 2 prefix
	// Change value if needed
	$prefix_2 = 'second_';
	
	$caps = get_user_meta( $user_id, $prefix_1 . 'capabilities', true );
	$level = get_user_meta( $user_id, $prefix_1 . 'user_level', true );

	if ( $caps ){
		update_user_meta( $user_id, $prefix_2 . 'capabilities', $caps );
	}

	if ( $level ){
		update_user_meta( $user_id, $prefix_2 . 'user_level', $level );
	}
}

add_action( 'set_user_role', 'ksu_save_role', 10, 2 );

A função de retorno mantém três argumentos, dois dos quais são necessários: $user_id e $role.
O que a função faz é bastante auto-explicativa. get_user_meta retorna o valor do meta-campo do usuário especificado. Chamamos esta função duas vezes para recuperar os campos first_capabilities e first_user_level. Depois utilizamos estes valores para adicionar os campos second_capabilities e second_user_level à tabela first_usermeta.

Carregue o anúncio para ativar este plugin no primeiro site.

Para que as instalações funcionem simetricamente, só precisamos carregar e ativar o plugin em qualquer instalação, mas definindo os valores corretos para prefixos. Por exemplo, se ativarmos esta funcionalidade no segundo site, só temos de declarar as variáveis como se segue:

$prefix_1 = 'second_';
$prefix_2 = 'first_';

Então, edite e instale o plugin no segundo site e crie um novo usuário ou altere uma função de usuário existente. Depois consulte o primeiro site. As funções do usuário serão exatamente as mesmas do segundo site.

Resumo

Neste post, eu expliquei como conceder os mesmos privilégios aos usuários em instalações WordPress independentes. Uma vez registrado em um site, o usuário poderá acessar todos os sites que compartilham os mesmos usuários e tabelas de usermeta.
É suposto eu trabalhar com novas instalações. Se você estiver trabalhando em sites existentes, você deve considerar que alguns plugins podem ter atualizado a tabela usermeta, ou mesmo criado novas tabelas armazenando dados relacionados ao usuário. Neste caso, uma análise mais precisa da base de dados seria apropriada.

Se você tiver alguma dúvida sobre como compartilhar logins no WordPress, ou se você gostaria de compartilhar sua experiência conosco, sinta-se livre para participar da conversa postando seus comentários.

O código completo do nosso plugin está disponível neste Gist público.

Carlo Daniele Kinsta

Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.