Actions e filters — personaliza o WP Staging

By , Founder · Updated

Quando o comportamento predefinido do WP Staging não se adequa ao teu site — excluir tabelas específicas, desativar Plugins no staging, lidar com valores da base de dados codificados em base64 — os filters e actions do PHP permitem-te ajustar cada passo a partir de um mu-plugin, sem modificar o próprio Plugin. Esta página é a referência completa de hooks do WP Staging, com um exemplo de copiar e colar para cada filter disponível.

Referência rápida: os 6 filters mais usados

Filter / Action O que faz Ir para
wpstg.resources.ignoreMemoryLimit Desativa o limite de 256 MB de memória Permitir utilização de memória ilimitada
wpstg.cloning.update_active_plugins Ativa ou desativa Plugins no staging após a clonagem Ativar ou desativar Plugins após clonagem
wpstg_clone_excl_folders Exclui diretórios do processo de clonagem Excluir pastas
wpstg.database.searchreplace.replace_extended_data Lida com valores da base de dados codificados em base64 ou com codificação personalizada Search & Replace personalizado para valores codificados
wpstg.pushing.update_active_plugins Ativa ou desativa Plugins em produção após o push Ativar ou desativar Plugins após push
wpstg_preserved_options Impede que linhas específicas de wp_options sejam sobrepostas no push Preservar dados em wp_options
Para usar os hooks e filters, recomendamos a instalação do nosso Plugin dedicado, chamado  WP STAGING Hooks, ou a utilização dos hooks e filters desta página num mu-plugin.
Caso contrário, nem todas as actions podem funcionar como esperado.

A maioria dos filters nesta página requer um dos planos WP Staging Pro.

Plugin WP Staging Hooks

Podes descarregar o Plugin WP STAGING hooks, que contém muitos dos filters mencionados neste artigo, para uma utilização fácil no teu site.

Nota: nem todos os filters mencionados neste artigo estão incluídos no repositório do github.

Se houver um filter mencionado nesta página que não está disponível no Plugin WP STAGING hooks, podes copiar o código específico desta página para um novo mu-plugin ou para um já existente, como o mu-plugin do WP STAGING que encontras em wp-content/plugins/wp-staging-optimizer.php

Consulta este artigo para "aprender a criar um mu-plugin" no teu site.

Copia o código completo para o início do mu-plugin e ajusta-o às tuas necessidades. Se precisares de ajuda, é só dizeres.

Contents

Quick-start: os filters mais usados

Todos os filters vão para um ficheiro mu-plugin para que carreguem automaticamente em cada pedido. O WP Staging processa os mu-plugins antes do seu próprio código, por isso os hooks aí registados são disparados no ponto correto do processo de clonagem, push ou Backup.

Os dois filters mais simples para copiar e colar de imediato:

Desativar o limite de memória — por predefinição, o WP Staging limita-se a 256 MB. Remove esse limite:

add_filter( 'wpstg.resources.ignoreMemoryLimit', function() { return true; } );

Substituir o limite de tempo de execução — aumenta o tempo máximo de execução do PHP que o WP Staging solicita (valor em segundos; mantém-no abaixo do max_execution_time real do teu servidor):

add_filter( 'wpstg.resources.executionTimeLimit', function() { return 100; } );

Para os restantes filters comuns — ativação de Plugins, exclusão de pastas, Search & Replace de valores codificados, preservação de opções — consulta as respetivas secções dedicadas abaixo. Cada secção tem o bloco de código completo, pronto a usar.

Permitir utilização de memória ilimitada

O WP STAGING limita o consumo máximo de memória a 256M, o que costuma ser suficiente para os processos de clonagem e Backup. Durante esses processos, todos os outros Plugins são desativados, mas isto não afeta as outras páginas do site.

Um limite de memória de 256M é normalmente suficiente para executar o WP STAGING com sucesso. Não recomendamos um WP_MEMORY_LIMIT ou um limite máximo de memória do PHP acima de 512M, porque ir mais alto pode indicar um problema com um dos Plugins ou demasiados Plugins ativos. Não é aconselhável ultrapassar estes limites porque o limite de memória está associado a cada processo PHP. Se for definido um consumo de memória permitido elevado em cada pedido WordPress, a memória disponível na máquina pode rapidamente ficar esgotada, tornando o site indisponível.

No entanto, em casos em que é necessário ultrapassar o limite de 256M, é possível desativar o limite de memória do WP STAGING. Atenção: não é recomendado, a menos que haja uma boa razão para o fazer e o servidor tenha memória disponível suficiente.

Para desativares o limite de memória, usa o filter fornecido para permitir consumo de memória ilimitado ao WP STAGING. O único limite, neste caso, é o limite máximo de memória do PHP.

PHP
add_filter('wpstg.resources.ignoreMemoryLimit', function() {
  return true;
});

Alterar o logótipo do WP Staging no formulário de início de sessão (versão Pro)

Por predefinição, o site de staging usa o logótipo padrão de início de sessão do WordPress. Substituí-lo por uma imagem personalizada ou pelo logótipo da tua empresa torna o ambiente de staging visualmente distinto do ecrã de início de sessão de produção, ajudando a evitar trabalho acidental no site errado.

Podes usar o código abaixo para alterar o logótipo do formulário de início de sessão do site de staging:

PHP
add_filter('wpstg_login_form_logo', function(){
  return 'https://example.com/path/to/custom/image.png';
});

Aumentar o tempo de requisição do WP STAGING e o tempo máximo de execução do PHP

Normalmente, o Backup e o restauro do WP STAGING funcionam até em fornecedores de Hosting menores. Se tens uma base de dados ou um site enorme com milhões de linhas, o limite predefinido de tempo de execução do PHP, de 30 segundos, pode ser demasiado baixo. Para que a criação/restauro do Backup funcione, define o valor PHP max_execution_time= 120 no teu php.ini.

Aumenta também o valor apache Timeout 120 ou define a diretiva Nginx fastcgi_read_timeout 120;

Depois disso, adiciona o filter abaixo a um mu-plugin como mu-plugin/wp-staging-optimizer.php.

PHP
​add_filter('wpstg.resources.executionTimeLimit', function(){
    return 100;
});

Garante que o valor de entrada é inferior ao tempo máximo de execução real permitido pelo PHP. Isto é necessário para que o tempo de requisição do WP STAGING nunca ultrapasse o tempo de execução do PHP.

Alterar o título do site de staging

Por predefinição, o site de staging partilha o mesmo título do teu site em produção. Definir um nome distinto — por exemplo [STAGING] O Meu Site ou DEV — torna o ambiente óbvio na barra de administração do WordPress e no separador do navegador, reduzindo o risco de publicar ou editar conteúdo na instalação errada.

PHP
function wpstg_get_title(){
   return 'DEV';
}
add_filter('wpstg_staging_site_title', 'wpstg_get_title');

Alterar o caminho para a pasta de cache

Por predefinição, o WP Staging escreve os ficheiros temporários de Backup dentro da tua instalação WordPress. Mudar a pasta de cache — por exemplo, para um diretório temporário do sistema fora da raiz web ou para um caminho em armazenamento mais rápido — pode melhorar o desempenho do Backup em servidores com I/O lento na raiz do documento e satisfaz políticas de segurança que restringem as escritas a diretórios específicos.

Para alterares a pasta usada para guardar ficheiros temporários de Backup, passando-a para a pasta temporária global do PHP ou para outro local, podes usar o código abaixo:

PHP
​add_filter('wpstg.directory.cacheDirectory', function(){
        return trailingslashit(sys_get_temp_dir()) . 'wpstagingcache';​
​});

Guardar os ficheiros de Backup fora da raiz do WordPress

Por predefinição, o WP STAGING guarda os ficheiros de Backup dentro da tua instalação do WordPress. Os nomes dos ficheiros contêm um hash aleatório, por isso são difíceis de adivinhar, mas o diretório continua a estar sob a tua web root e poderia, em teoria, ser solicitado por HTTP. Para uma proteção mais forte, podes mover o diretório de Backup para um local fora da web root, de modo que os ficheiros nunca fiquem acessíveis a partir de um navegador, mesmo que alguém adivinhe o nome do ficheiro com hash.

Usa o filtro wpstg.backup.directory para devolver um caminho absoluto que esteja acima da tua pasta web pública:

add_filter('wpstg.backup.directory', function ($dir) {
    return '/var/www/example.com/my-backups';
});

Garante que o caminho já existe, que o utilizador do servidor web (PHP) tem permissão de escrita nele e que está fora da document root (por exemplo, ao lado de public_html ou htdocs, e não dentro). O WP STAGING irá então ler e escrever todos os Backups a partir desse local.

Excluir tabelas da operação de Search & Replace

Usa isto se o processo de Search & Replace consumir grande parte da memória disponível e os processos de clonagem ou de push falharem com um erro de memória esgotada. Também podes usar isto para melhorar a velocidade dos processos de clonagem e push.

Exclui tabelas que não precisam de qualquer Search & Replace de links! Podem ser tabelas que contenham estatísticas de visitantes, endereços IP ou algo semelhante. Depois de excluíres essas tabelas, podes aumentar o limite de DB Search & Replace nas definições do WP STAGING para um valor mais alto e obter melhor desempenho.

PHP
function wpstg_searchreplace_excl_tables($default){
    $tables = array('_posts', '_postmeta'); 
    return array_merge($default, $tables);
}
add_filter('wpstg_searchreplace_excl_tables','wpstg_searchreplace_excl_tables');

Search & Replace personalizado para valores codificados na base de dados

Usa este filter para executar operações de Search & Replace sobre dados codificados em base64 na tua base de dados (muitas vezes usados por construtores de páginas ou definições complexas de Plugins). Isto garante que URLs e outras strings são corretamente atualizados, mesmo quando guardados num formato codificado durante a clonagem, push ou restauro.

// Replace URLs inside base64-encoded database values during cloning/pushing/restore.
add_filter('wpstg.database.searchreplace.replace_extended_data', function ($data, $search, $replace) {
    $plain = base64_decode($data, true);
    if ($plain === false) {
        return $data;
    }

    $replaced = str_replace($search, $replace, $plain);
    if ($replaced === $plain) {
        return $data;
    }

    return base64_encode($replaced);
}, 10, 3);

Podes usar este filter para substituir todo o tipo de dados personalizados na base de dados que não possam ser tratados automaticamente pelo WP Staging.

Outro exemplo: alguns Plugins guardam URLs ou outros valores dentro de strings JSON codificadas, em vez de texto plano. Um exemplo comum é JSON que contém valores de propriedades codificados em base64.

Nesses casos, o Search/Replace normal do WP Staging não consegue detetar o URL original, porque está escondido dentro do valor codificado.

Para suportar estes casos, o WP Staging disponibiliza o filter:

wpstg.database.searchreplace.replace_extended_data

Este filter permite aos developers modificar o valor de uma coluna da base de dados após o Search/Replace normal já ter sido executado.

Pode ser utilizado durante:

  • clonagem
  • push do staging para produção
  • restauro de Backups

Quando devo usar este filter?

Usa este filter quando um Plugin ou Theme guarda dados num formato como:

  • JSON com valores codificados em base64
  • estruturas JSON aninhadas que contêm strings codificadas
  • formatos de dados personalizados em que os URLs não estão guardados em texto plano

Sem este filter, os URLs dentro desses valores codificados ficam inalterados.

Parâmetros do filter

O filter recebe três parâmetros:

Parâmetro Tipo Descrição
$data string O valor da coluna da base de dados após o Search/Replace normal
$search array As strings de pesquisa
$replace array As strings de substituição

Ideia base

O teu callback pode:

  1. inspecionar o valor da base de dados
  2. detetar se contém dados codificados
  3. descodificar o valor
  4. executar str_replace() com os arrays de pesquisa e substituição
  5. voltar a codificar o valor
  6. devolver o resultado modificado

Se o valor não corresponder ao formato esperado, basta devolvê-lo inalterado.

Exemplo: Search/Replace dentro de valores JSON codificados em base64

O exemplo de mu-plugin a seguir mostra como substituir URLs dentro de valores JSON cujas propriedades estão codificadas em base64.

Cria este ficheiro:

wp-content/mu-plugins/wpstg-base64-search-replace.php

Adiciona este código:

<?php

/**
 * Decode base64-encoded values inside JSON database columns during
 * WP Staging search/replace so that URLs within them are replaced.
 */
add_filter('wpstg.database.searchreplace.replace_extended_data', function ($data, $search, $replace) {
    // Only process JSON-looking data
    if (empty($data) || ($data[0] !== '[' && $data[0] !== '{')) {
        return $data;
    }

    $decoded = json_decode($data, false);
    if (json_last_error() !== JSON_ERROR_NONE) {
        return $data;
    }

    $changed = false;

    // Recursively walk JSON to find base64-encoded string values at any depth
    $walk = function ($node) use (&$walk, &$changed, $search, $replace) {
        if (is_array($node)) {
            foreach ($node as $item) {
                $walk($item);
            }

            return;
        }

        if (!is_object($node)) {
            return;
        }

        foreach ($node as $key => $value) {
            if (is_array($value) || is_object($value)) {
                $walk($value);
                continue;
            }

            if (!is_string($value) || $value === '') {
                continue;
            }

            $plain = base64_decode($value, true);
            if ($plain === false) {
                continue;
            }

            $replaced = str_replace($search, $replace, $plain);
            if ($replaced !== $plain) {
                $node->$key = base64_encode($replaced);
                $changed = true;
            }
        }
    };

    $walk($decoded);

    return $changed ? wp_json_encode($decoded) : $data;
}, 10, 3);

Como funciona este exemplo

Este exemplo faz o seguinte:

  1. Verifica se o valor da base de dados se assemelha a JSON.
  2. Descodifica o JSON.
  3. Percorre recursivamente todos os arrays e objetos aninhados.
  4. Tenta descodificar cada valor de string em base64.
  5. Aplica os valores de Search/Replace do WP Staging sobre o conteúdo descodificado.
  6. Se algo mudou, volta a codificar o valor modificado em base64.
  7. Devolve a string JSON atualizada.

Dados de exemplo

Imagina que um Plugin guarda isto na base de dados:

{  "title": "Example",  "url": "aHR0cHM6Ly9vbGQtc2l0ZS5jb20vcGFnZQ=="}

O valor de url está codificado em base64. Descodificado, contém:

https://old-site.com/page

Durante um clone, push ou restauro do WP Staging, o Search/Replace normal não consegue ver esse URL diretamente, porque está codificado.

Com o filter acima, o WP Staging vai:

  • descodificar o valor
  • substituir https://old-site.com por https://new-site.com
  • voltar a codificá-lo
  • gravar de novo o valor atualizado na base de dados

Resultado

Depois do filter correr, o valor guardado passa a ser a versão codificada em base64 de:

https://new-site.com/page

Onde devo colocar este código?

A opção mais segura é colocá-lo num mu-plugin para que carregue automaticamente em cada pedido.

Caminho recomendado:

wp-content/mu-plugins/wpstg-base64-search-replace.php

Se o diretório mu-plugins ainda não existir, cria-o manualmente.

Notas importantes

  • Este filter destina-se a formatos personalizados na base de dados que não são tratados pelo Search/Replace predefinido.
  • O teu callback deve devolver sempre o $data original inalterado se não corresponder ao formato esperado.
  • Mantém a lógica o mais específica possível para evitar alterar dados não relacionados.
  • Testa isto primeiro num site de staging antes de o usares em dados de produção.

Resumo

Usa wpstg.database.searchreplace.replace_extended_data quando URLs ou outros valores estão escondidos dentro de conteúdo codificado na base de dados.

Isto é especialmente útil para Plugins que guardam valores em:

  • JSON codificado em base64
  • objetos JSON aninhados
  • outros formatos codificados personalizados

Dá aos developers controlo total sobre como esses valores são descodificados, substituídos e gravados novamente.

Filters de clonagem e staging

Executar uma action no site de staging após a clonagem

Usa esta action para executar uma operação única na base de dados de staging na primeira vez que o site de staging é aberto — por exemplo, para eliminar dados de teste do site em produção, limpar uma tabela de logs ou inserir linhas de configuração específicas do staging. A action é disparada exatamente uma vez no carregamento inicial do site de staging.

O exemplo abaixo executa uma query SQL assim que o site de staging é aberto pela primeira vez:

PHP
add_action('wpstg.clone_first_run', 'wpstg_execute_after_cloning', 10);

function wpstg_execute_after_cloning() {
   
global $wpdb;

$sql = "DELETE * FROM wpstg0_tablename WHERE ....";

$wpdb->query($sql);
}

Esta query só será executada quando se trata de um site de staging e apenas nesse site, mas, por segurança adicional, recomendamos que codifiques os nomes das tabelas com o prefixo de staging em concreto, como no exemplo, para garantir que esta query nunca possa causar danos no site em produção caso seja executada lá por acidente.

Podes adicionar todo o tipo de código a essa action e ele será executado uma única vez na abertura inicial do novo site de staging.

Ativar ou desativar Plugins específicos no site de staging após clonagem

Para ativar ou desativar alguns Plugins no site de staging depois da clonagem, usa o filter wpstg.cloning.update_active_plugins assim:

PHP
php
function wpstg_cloning_update_active_plugins($currentActivePlugins) {
// snippet to deactivate
$pluginsToDeactivate = array('plugin1-basename', 'plugin2-basename');
foreach ($pluginsToDeactivate as $pluginToDeactivate) {
  $key = array_search($pluginToDeactivate, $currentActivePlugins, true);
  if (false !== $key) {
    unset($currentActivePlugins[$key]);
  }
}

// snippet to activate
$pluginsToEnable      = array('plugin3-basename');
$currentActivePlugins = array_merge($currentActivePlugins, $pluginsToEnable);

return $currentActivePlugins;

}
add_filter('wpstg.cloning.update_active_plugins','wpstg_cloning_update_active_plugins');

Excluir linhas do Search & Replace em wp_options

Usa este filter quando linhas de opções específicas têm de manter os seus valores do site de staging inalterados durante a passagem de Search & Replace da clonagem — por exemplo, chaves de licença, endpoints de API ou tokens de autenticação que apontam para serviços diferentes em staging e produção. O filter aceita um array de valores option_name a ignorar.

PHP
function wpstg_clone_searchreplace_excl_rows($default){
   $rows = array('siteurl', 'home'); 
    return array_merge($default, $rows);

add_filter('wpstg_clone_searchreplace_excl_rows','wpstg_clone_searchreplace_excl_rows');

Excluir linhas da clonagem

Este exemplo exclui linhas da tabela wp_options consoante o nome da opção ou exclui posts da tabela wp_posts com base no post_title e no post_status, e respetivos metadados.

Estão disponíveis estes operadores:

['=', '&gt;', '&gt;=', '&lt;', '&lt;=', '&lt;&gt;', '!=', 'LIKE', 'NOT LIKE']

PHP
function queryCloningRows($filters) {
	$filters = [
// Clone only options where option_name is not 'wpstg_is_staging_site'
		'wp_options' => [
			'option_name' => [
				'operator' => '<>',
				'value' => 'wpstg_is_staging_site'
			]
		],
// Clone only posts where post_title LIKE 'Hello%' AND post_status = 'publish'
		'wp_posts' => [
			'post_title' => [
				'operator' => 'LIKE',
				'value' => 'Hello%'
			],
			'post_status' => 'publish'
		],
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
	return $filters;
}

add_filter('wpstg.cloning.database.queryRows', 'queryCloningRows');

Excluir um custom post type da clonagem

Usa este filter quando um custom post type do teu site em produção não deve ser clonado para o staging — por exemplo, encomendas de loja, reservas ou posts de subscrição que sobrecarregariam a base de dados de staging com dados transacionais de produção.

Este exemplo exclui posts do custom post type "coupon", juntamente com os respetivos postmeta:

Estão disponíveis estes operadores:

['=', '&gt;', '&gt;=', '&lt;', '&lt;=', '&lt;&gt;', '!=', 'LIKE', 'NOT LIKE']

PHP
function queryCloningRows($filters) {
	$myFilters = [
// Clone only posts which do not belong to post_type coupon
		'wp_posts' => [
			'post_type' => [
				'operator' => '<>',
				'value' => 'coupon'
			]
		],
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];

	return array_merge($filters, $myFilters);
}

add_filter('wpstg.cloning.database.queryRows', 'queryCloningRows');

Excluir strings do Search & Replace

Usa este filter quando determinadas strings da tua base de dados têm de permanecer idênticas em staging e produção — por exemplo, um hostname de CDN ou um URL de serviço de terceiros que não deve ser trocado durante a substituição de URLs da clonagem. Adiciona cada string ao array de exclusão para impedir que seja modificada.

PHP
function wpstg_clone_searchreplace_excl(){
    return array('blog.localhost.com','blog1.localhost.com');
}
add_filter('wpstg_clone_searchreplace_excl','wpstg_clone_searchreplace_excl');

Alterar parâmetros do Search & Replace

Usa este filter quando os parâmetros predefinidos de Search & Replace de URLs não cobrem todas as strings que diferem entre o teu site em produção e o de staging — por exemplo, quando precisas de substituir um alias de domínio ou trocar valores adicionais não detetados automaticamente. Permite-te especificar as strings exatas de pesquisa e substituição e controlar as flags de substituição do PHP.

PHP
function wpstg_cloning_custom_params($args){
      // Default values - Can be changed
      $args['search_for'] = array_merge(
         $args['search_for'],
         array('SEARCHSTRING', 'SEARCHSTRING')
         );
         
     $args['replace_with'] = array_merge(
         $args['replace_with'],
         array('REPLACESTRING','REPLACESTRING2')
       );
       
      $args['replace_guids'] = 'off'; 
      $args['dry_run'] = 'off'; 
      $args['case_insensitive'] = false;
      $args['replace_guids'] = 'off';
      $args['replace_mails'] = 'off';
      $args['skip_transients'] = 'on';
      
      return $args;
}
add_filter('wpstg_clone_searchreplace_params', 'wpstg_cloning_custom_params');

Excluir ficheiros

Usa este filter para impedir que ficheiros específicos sejam copiados de produção para staging. Isto é útil para ficheiros de configuração específicos do ambiente, ficheiros de log grandes ou ficheiros de licença que não devem existir no site de staging.

PHP
/**
* Cloning: Exclude files from cloning
* Example: You can use a wildcard pattern like *.log to exclude all log files
*/
function wpstg_clone_excluded_file_names($default)
{
    $files = array('custom-file', '*LOG-*', '*.logs');
    return array_merge($default, $files);
}
add_filter('wpstg_clone_excluded_files', 'wpstg_clone_excluded_file_names');

Excluir ficheiros da clonagem usando o caminho completo

Por predefinição, o WP STAGING exclui estes ficheiros da cópia sempre que cria um site de staging:

  • .htaccess
  • Absolute/path/to/WordPress/directory/wp-content/db.php
  • Absolute/path/to/WordPress/directory/wp-content/object-cache.php
  • Absolute/path/to/WordPress/directory/wp-content/advanced-cache.php

Podes alterar este comportamento e modificar esta lista de ficheiros excluídos usando o filter abaixo:

PHP
/**
* Exclude files from cloning using full path 
*/
function wpstg_clone_excluded_files_full_path($default)
{
    $files = ['full/path/custom-file1', 'full/path/custom-file2']; 
    return array_merge($default, $files);
}
add_filter('wpstg.clone.excluded_files_full_path','wpstg_clone_excluded_files_full_path');

Excluir pastas

Usa este filter para excluir diretórios inteiros do processo de clonagem. Costuma ser usado para ignorar diretórios de Plugins ou Themes não necessários no staging, bibliotecas media grandes ou pastas de artefactos de build. Os caminhos são relativos ao diretório wp-content.

PHP
/**
* Excluded folders relative to the wp-content folder 
*/
function wpstg_exclude_folders_custom($args){
     $folders = array('plugins/wordpress-seo', 'custom-folder');
     return array_merge($args, $folders);
}
add_filter('wpstg_clone_excl_folders', 'wpstg_exclude_folders_custom');

Multisite: excluir pastas (Plugins) da clonagem num multisite

Se utilizas uma rede multisite, usa o filter wpstg_clone_mu_excl_folders para excluir pastas relativas à pasta wp-content. Isto é útil se queres excluir um Plugin.

PHP
**
* Excluded folders relative to the wp-content folder
*/
function wpstg_exclude_folders_custom($args){
   $folders = array('plugins/wordpress-seo', 'themes/custom-folder');
   return array_merge($args, $folders);
}
add_filter('wpstg_clone_mu_excl_folders', 'wpstg_exclude_folders_custom');

Evitar o Search & Replace do prefixo de tabelas numa opção da tabela wp_options

Por predefinição, o WP STAGING clona todas as tabelas e substitui valores começados pelo prefixo de tabelas da nova base de dados. Podes excluir opções desta operação de substituição para que não sejam modificadas durante a clonagem:

PHP
function wpstg_excl_option_name_custom($args){
     $cols = array('wp_mail_smtp', 'wp_mail_smtp_version');
     return array_merge($args, $cols);
}
add_filter('wpstg_data_excl_rows', 'wpstg_excl_option_name_custom');

Clonar multisites em rede e alterar o hostname de destino

O WP STAGING tem suporte para multisites baseados em domínios personalizados. Os sites da rede serão criados automaticamente no subdomínio especificado do site principal.

Exemplo:

Existe um site de rede com o site principal example.com e um subsite example.org e outro example.net:

Se clonares toda a rede para staging.example.com, os sites da rede serão clonados para:

  • staging.example.org
  • staging.example.net

Podes ajustar cada site usando o filter abaixo. É um filter genérico que pode ser usado para subsites baseados em subdomínio, em subdiretório ou até em domínio.

PHP
// Convert staging site with ID 2 to dev.example.com
add_filter('wpstg.cloning.multisite.subsite_info', function ($subsiteInfo, $blogId, $stagingSiteURL, $addWWWPrefix) {

if ($blogId === 2) {
    $subsiteInfo['domain'] = 'dev.example.com';
    $subsiteInfo['path']   = '/';
    $subsiteInfo['url']    = 'https://dev.example.com';
}

return $subsiteInfo;
}, 10, 4);

Preservar o valor "upload_path" na base de dados

Em sites WordPress Network antigos, podes precisar de impedir que o upload_path seja alterado; usa este filter para o conseguir:

PHP
add_filter('wpstg.cloning.preserve_upload_path',  '__return_true');

Filters de push

Ativar ou desativar Plugins específicos no site de produção após push de um site de staging

Para ativar ou desativar Plugins no site em produção depois de fazer push de um site de staging, usa o filter wpstg.pushing.update_active_plugins assim:

PHP
function wpstg_pushing_update_active_plugins($currentActivePlugins)
{
    // snippet to deactivate
    $pluginsToDeactivate = array('plugin1-basename', 'plugin2-basename');
    foreach ($pluginsToDeactivate as $pluginToDeactivate) {
        $key = array_search($pluginToDeactivate, $currentActivePlugins, true);
        if (false !== $key) {
            unset($currentActivePlugins[$key]);
        }
    }

    // snippet to activate
    $pluginsToEnable      = array('plugin3-basename');
    $currentActivePlugins = array_merge($currentActivePlugins, $pluginsToEnable);

    return $currentActivePlugins;
}
add_filter('wpstg.pushing.update_active_plugins','wpstg_pushing_update_active_plugins');

Alterar parâmetros do Search & Replace

Usa este filter quando o push requer substituições de URL adicionais para além das que o WP Staging deteta automaticamente — por exemplo, um subdomínio de CDN, um endpoint de API ou um domínio alias que difere entre staging e produção.

PHP
function wpstg_push_custom_params($args){
      // Default values - Can be changed
         $args['search_for'] = array_merge(
         $args['search_for'],
         array('SEARCHSTRING', 'SEARCHSTRING2')
         );
         $args['replace_with'] = array_merge(
         $args['replace_with'],
         array('REPLACESTRING','REPLACESTRING2')
       );
      $args['replace_guids'] = 'off'; 
      $args['dry_run'] = 'off'; 
      $args['case_insensitive'] = false;
      $args['replace_guids'] = 'off';
      $args['replace_mails'] = 'off';
      $args['skip_transients'] = 'on';
      return $args;
}
add_filter('wpstg_push_searchreplace_params', 'wpstg_push_custom_params');

Excluir tabelas do push

Usa este filter para impedir que tabelas específicas da base de dados sejam enviadas para o site em produção — por exemplo, uma tabela de logs personalizada, uma tabela de analítica ou qualquer tabela de Plugin que gira dados exclusivos de produção, independentemente do staging.

PHP
function wpstg_push_excluded_tables($tables){
    $customTables = ['options', 'posts']; 
    return array_merge($tables, $customTables);
}
add_filter('wpstg_push_excluded_tables','wpstg_push_excluded_tables');

Nota: os nomes de tabelas no código têm de ser indicados sem prefixos!

Este exemplo exclui as tabelas wp_posts e wp_options do push para o site em produção.

Excluir linhas do push. Copiar apenas linhas específicas

Este exemplo exclui certas linhas da tabela wp_options consoante o nome da opção, ou exclui posts da tabela wp_posts com base no post_title e no post_status, juntamente com os respetivos postmeta.

Estão disponíveis estes operadores:

['=', '&gt;', '&gt;=', '&lt;', '&lt;=', '&lt;&gt;', '!=', 'LIKE', 'NOT LIKE']

Atenção: o prefixo de tabelas precisa de ser wpstg0_, wpstg1_, wpstg3, etc., consoante o prefixo real do site de staging, por isso tens de substituir wpstg[int]_ pelo prefixo real.

PHP
function queryPushingRows($filters) {
	$filters = [
		// will only push options where option_name is not 'wpstg_is_staging_site'
		'wpstg0_options' => [
			'option_name' => [
				'operator' => '<>',
				'value' => 'wpstg_is_staging_site'
			]
		],
		// will only push posts where post_title LIKE 'Hello%' AND post_status = 'publish'
		'wpstg0_posts' => [
			'post_title' => [
				'operator' => 'LIKE',
				'value' => 'Hello%'
			],
			'post_status' => 'publish'
		],
    // will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wpstg0_postmeta' => [
			'join' => [
				'table' => 'wpstg0_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
	return $filters;
}

add_filter('wpstg.pushing.database.queryRows', 'queryPushingRows');

Nota: excluir esses post types significa que deixarão de estar disponíveis e não voltarão a ser incluídos no site em produção depois de copiares o site de staging para produção.

Excluir um post type específico do push

Usa isto quando certos post types do staging nunca devem sobrepor os seus equivalentes em produção — por exemplo, encomendas, subscrições ou outros dados transacionais que são geridos de forma independente no site em produção.

Este exemplo exclui posts com o custom post type "coupon", juntamente com os respetivos postmeta:

Estão disponíveis estes operadores:

['=', '&gt;', '&gt;=', '&lt;', '&lt;=', '&lt;&gt;', '!=', 'LIKE', 'NOT LIKE']

Atenção: o prefixo de tabelas precisa de ser wpstg0_, wpstg1_, wpstg3, etc., consoante o prefixo real do site de staging, por isso tens de substituir wpstg0_ pelo prefixo real.

PHP
function queryPushingRows($filters) {
	$myFilters = [
		// Push only posts where post_type is not 'coupon'
		'wpstg0_posts' => [
			'post_type' => [
				'operator' => '<>',
				'value' => 'coupon'
			]
		],
    // will push postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wpstg0_postmeta' => [
			'join' => [
				'table' => 'wpstg0_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];

	return array_merge($filters, $myFilters);
}

add_filter('wpstg.pushing.database.queryRows', 'queryPushingRows');

Excluir pastas do push

Por predefinição, o WP STAGING PRO não percorre nem envia para o site em produção nenhuma destas pastas:

  • cache
  • wps-hide-login
  • node_modules
  • nbproject
  • wp-staging

Podes adicionar pastas personalizadas a esta lista usando o filter abaixo:

PHP
function wpstg_push_directories_excl($default){
    $dirs = array('custom-folder', 'custom-folder2'); 
    return array_merge($default, $dirs);
}
add_filter('wpstg.push_excluded_directories', 'wpstg_push_directories_excl');

Excluir ficheiros do push

Por predefinição, o WP STAGING PRO não envia para o site em produção nenhum destes ficheiros:

  • .htaccess
  • .DS_Store
  • .git
  • .svn
  • .tmp
  • desktop.ini
  • .gitignore
  • .log
  • wp-staging-optimizer.php

Podes adicionar ficheiros personalizados a esta lista usando o filter abaixo:

PHP
function wpstg_push_excluded_files($default){
    $files = array('custom-file', 'custom-file2'); 
    return array_merge($default, $files);
}
add_filter('wpstg_push_excluded_files','wpstg_push_excluded_files');

Preservar dados em wp_options e excluí-los do push

Preservar dados significa que podes enviar o site de staging para o site em produção e excluir dados específicos de serem sobrepostos durante o push.

O exemplo abaixo preserva os valores das opções WordPress ‘siteurl’ e ‘home’ na tabela wp_options do site em produção.

Podes adicionar qualquer número de opções adicionais.

PHP
function wpstg_push_preserve_options($options){
       $preserveOptions = ['siteurl', 'home'];
       return array_merge($options, $preserveOptions );
}
add_filter('wpstg_preserved_options','wpstg_push_preserve_options');

Exemplo: como preservar a chave de licença do WPML após o push

Podes usar este código como ficheiro de mu-plugin:

PHP
<?php
/*
Plugin Name: mu-plugin to keep the WPML license of the live site
Description: After you push the staging site to the live site, the live site's WPML license won't change
Version: 1.0
Author: WPSTAGING
*/

function wpstg_push_preserve_options($options){
    $preserveOptions = ['wp_installer_settings'];
    return array_merge($options, $preserveOptions );
}
add_filter('wpstg_preserved_options','wpstg_push_preserve_options');

Executar uma action após push para o site em produção.

Esta action é disparada no site em produção imediatamente após a conclusão de um push de staging. Usa-a para limpar caches de produção, notificar um serviço de monitorização externo ou executar migrações de base de dados que dependam do conteúdo recém-enviado.

Podes usar este hook para chamar um método no site em produção após push de um site de staging para produção.

PHP
function pushingComplete()
{
// do something
}
add_action( 'wpstg_pushing_complete', 'pushingComplete' );

Filters de Backup

Restaurar um multisite completo noutro multisite (migração)

Se criaste um Backup a partir de uma rede multisite completa e queres restaurar o Backup noutro multisite existente, por exemplo para copiar o multisite para outro servidor, há algumas coisas a ter em conta consoante o tipo de multisite que operas. Lê este artigo, que explica em detalhe como fazê-lo e como usar um filter específico para essa operação.

Restaurar um site de uma rede multisite noutra rede multisite (migração)

Este filter permite-te excluir caminhos específicos da pasta de uploads de serem eliminados durante o passo de limpeza do restauro ao migrar um subsite de rede para outra rede multisite.

Recebe um array de caminhos (na pasta uploads) (ficheiro ou diretório) a excluir, durante o restauro do Backup, da limpeza. Exemplo de utilização:

PHP
add_filter('wpstg.backup.restore.exclude_media_during_cleanup', function ($pathsToExclude) {
    $pathsToExclude[] = '/full/path/to/a/directory';
    $pathsToExclude[] = '/full/path/to/a/file';
    return $pathsToExclude;
});

Por predefinição, o WP Staging preserva o conteúdo original (pasta language, mu-plugins, Plugins, Themes e outros ficheiros para além dos media) ao restaurar um Backup num subsite da rede. Em vez de preservar o conteúdo existente, podemos substituí-lo usando estes filters:

PHP
add_filter('wpstg.backup.restore.replace_existing_languages', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_mu_plugins', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_other_files', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_plugins', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_themes', '__return_true');

Alargar o Search & Replace para alterar URLs de todos os subsites na base de dados

Por predefinição, para acelerar o processo de restauro do Backup, só são substituídos os URLs que pertencem ao site atual. Se for um multisite e um site contiver URLs de outros sites da rede, podes usar um filter para substituir também esses URLs. Nota: quanto mais sites tens, mais demora a substituir todos os URLs dos sites.

PHP
add_filter('wpstg.multisite.full_search_replace', '__return_true');

Excluir uma extensão de ficheiro do Backup

Usa este filter para ignorar ficheiros de tipos específicos no Backup — por exemplo, assets compilados, arquivos temporários ou ficheiros de log que ocupam espaço mas não são necessários para um restauro.

Permite aos utilizadores excluir extensões de ficheiros específicas da exportação para Backup.

PHP
function wpstg_backup_files_ignore_extensions($default_excluded){
    return array_merge($default_excluded, ['zip', 'gz']);
}
add_filter( 'wpstg.export.files.ignore.file_extension', 'wpstg_backup_files_ignore_extensions');

Excluir ficheiros maiores do que um tamanho específico do Backup

Por predefinição, o WP Staging ignora todos os ficheiros maiores que 200MB na inclusão num Backup. Podes aumentar esse valor usando o filter abaixo:

PHP
function wpstg_backup_files_ignore_files_bigger_than($default){
    return 200 * MB_IN_BYTES;
}

add_filter( 'wpstg.export.files.ignore.file_bigger_than', 'wpstg_backup_files_ignore_files_bigger_than');

Excluir ficheiros com extensões específicas, maiores que um determinado tamanho, do Backup

Por predefinição, o WP Staging ignora ficheiros zip maiores que 50MB na inclusão num Backup. Podes alterar isto usando o filter abaixo para cada extensão individualmente:

PHP
function wpstg_backup_files_ignore_files_w_extension_bigger_than($default){
$ignoreFiles = [
    'gz' => 100 * MB_IN_BYTES, 
    'tar' => 200 * MB_IN_BYTES,
    'zip' => 200 * MB_IN_BYTES
];
return array_merge($default, $ignoreFiles);
}

add_filter( 'wpstg.export.files.ignore.file_extension_bigger_than', 'wpstg_backup_files_ignore_files_w_extension_bigger_than');

Excluir diretórios da inclusão num Backup

Usa este filter para ignorar diretórios inteiros no Backup — por exemplo, pastas que contenham ficheiros de log grandes, artefactos de build ou dados em cache que não precisam de ser copiados e inflariam desnecessariamente o tamanho do ficheiro de Backup.

PHP
function wpstg_backup_exclude_directories($excludedDirectories){
        $customExcludedDirectories = [
            'var/www/example.com/htdocs/wp-content/cache'
        ];
        return array_merge($excludedDirectories, $customExcludedDirectories);
    }

add_filter( 'wpstg.backup.exclude.directories', 'wpstg_backup_exclude_directories');

Excluir ficheiros do restauro

Este filter exclui ficheiros ou pastas completas do restauro do Backup. Podes passar um array de caminhos relativos à raiz da instalação WordPress e esses ficheiros ou pastas não serão extraídos do Backup quando inicias o restauro.

PHP
/**
 * Backup: Exclude files or folders from being restored.
 * If path is a folder, the entire folder including all contained files and subfolders will be excluded from backup restoration.
 */
function wpstg_backup_restore_exclude_paths($excludedFiles)
{
    $customExcludedFiles = [
        ABSPATH . 'documents', // a path
        ABSPATH . 'wp-content/share', // a path inside parent folder
        ABSPATH . 'wp-content/plugins/wp-crontrol', // a plugin 
        ABSPATH . 'wp-content/plugins/foo.php', // a file inside plugins folder
        ABSPATH . 'wp-content/themes/twentytwentyfour' // a complete theme
    ];

    return array_merge($excludedFiles, $customExcludedFiles);
}
add_filter('wpstg.backup.restore.exclude_paths', 'wpstg_backup_restore_exclude_paths');

Restaurar Backup e manter ficheiros media, Plugins ou Themes existentes

Estes filters impedem que o WP Staging sobreponha ou elimine tipos de ficheiros específicos durante o restauro de um Backup — útil quando queres manter os ficheiros atuais dos teus Plugins ou Themes e restaurar apenas a base de dados ou conteúdo específico.

Podes usar os filters abaixo para manter ficheiros existentes:

PHP
// Keep all plugins
add_filter('wpstg.backup.restore.keepExistingPlugins', function(){return true;});

// Keep all mu-plugins
add_filter('wpstg.backup.restore.keepExistingMuPlugins', function(){return true;});

// Keep all themes
add_filter('wpstg.backup.restore.keepExistingThemes', function(){return true;});

// Keep all media files in wp-content/uploads folder.
add_filter('wpstg.backup.restore.keepExistingMedia', function(){return true;});

// Keep all other files in wp-content folder.
add_filter('wpstg.backup.restore.keepExistingOtherFiles', function(){return true;});

Alterar o prefixo temporário de tabelas no restauro do Backup

É possível usar um prefixo temporário de base de dados personalizado durante o processo de restauro do Backup.

Utilização:

PHP
add_filter('wpstg.restore.tmp_database_prefix', function ($defaultTmpPrefix) {
	return 'wpstgt_';
});

Este exemplo substitui {WPSTG_TMP_PREFIX} por wpstgt_ em vez de usar o prefixo tmp predefinido wpstgtmp_. Isto reduz as hipóteses de erros no restauro se o nome da tabela, incluindo o prefixo temporário, ultrapassar 64 carateres, que é o limite do MySQL para identificadores na base de dados.

No exemplo acima, se já existir uma tabela com o prefixo wpstgt_ na tabela atual durante o restauro, volta-se a usar o prefixo tmp predefinido wpstgtmp_

Ativar Backups MultiPart

O WP Staging suporta a criação de Backups multipart que podes usar para limitar o tamanho de cada ficheiro de Backup. Esta funcionalidade pode criar vários ficheiros de Backup para Plugins, Themes, ficheiros media e a base de dados. É útil se tens um site muito grande e se não é possível criar ficheiros de Backup com vários gigabytes de dados.

Usa o filter abaixo para ativares esta funcionalidade e definires o tamanho máximo do ficheiro de Backup:

PHP
add_filter('wpstg.backup.isMultipartBackup', function() {
    return true;
});

// 256 MB 
add_filter('wpstg.backup.maxMultipartBackupSize', function() {
    return 256 * 1024 * 1024;
});

Excluir partes durante o processo de restauro do Backup

Às vezes não queres restaurar o Backup inteiro; em vez disso, podes usar este filter para restaurar apenas certas partes, como Plugins, Themes, base de dados, mantendo os dados existentes.

Exemplo

Este código restaura apenas os mu-plugins e exclui todas as outras partes:

PHP
//Will only restore mu-plugins
add_filter('wpstg.backup.restore.exclude_backup_parts', function ($partsToSkip)
{
    return [
        //'muplugins',
        'plugins',
        'uploads',
        'themes',
	      'lang',
        'wpcontent', // Doesn't include core wp directories inside wp-content (mu-plugins, plugins, themes, uploads, languages)
        'wproot', // Doesn't include core wp directories (wp-admin, wp-content, wp-includes)
        'wpstgdb' // database
    ];
});

Aumentar os blocos de upload de Backup para fornecedores cloud

Isto ajuda a reduzir os pedidos ao Google Drive (por exemplo), o que pode ajudar caso o IP do teu servidor tenha sido bloqueado pela Google. Espera 6 horas antes de voltares a tentar enviar o Backup para a Google. Esse é o tempo durante o qual o teu endereço IP fica bloqueado pela Google.

PHP
add_filter('wpstg.remoteStorages.chunkSize', function () {
    return 10 * 1024 * 1024; // 10 MB chunk size, try increasing the chunk size in multiple of 5 MB if this still fails.
});

Aumentar o atraso entre pedidos para fornecedores cloud

Usa este filter para aumentar o atraso entre pedidos feitos pelo teu servidor ao Google Drive durante o processo de Backup. Ajuda caso o teu IP tenha sido bloqueado pela Google. Espera 6 horas antes de voltares a tentar enviar o Backup para a Google. Esse é o tempo durante o qual o teu endereço IP fica bloqueado pela Google.

PHP
add_filter('wpstg.remoteStorages.delayBetweenRequests', function() {
    return 500; // 500ms, if this still fails, try increasing delay by multiple of 250ms.
});

Forçar o envio para armazenamento remoto FTP através da extensão FTP

Por predefinição, o WP STAGING envia ficheiros de Backup via extensão curl para FTP, mas podes mudar para curl usando este filter:

PHP
add_filter('wpstg.ftpclient.forceUseFtpExtension', '__return_true');

Restaurar um Backup criado num site HTTP para um site HTTPS ou vice-versa

Este filter é necessário quando precisas de restaurar um Backup de um site HTTP para um site HTTPS, ou ao contrário.

PHP
add_filter('wpstg.backup.restore.use_current_scheme_on_same_site', '__return_true');

Excluir ficheiros e diretórios da eliminação durante o restauro do Backup

Se restauras um Backup e queres impedir que ficheiros e pastas específicos sejam limpos e eliminados, podes usar este filter para bloquear esses ficheiros:

PHP
add_filter( 'wpstg.backup.restore.exclude_enqueue_delete',
	function($excludedFiles) {
		return array_merge(
			$excludedFiles,
			[
				ABSPATH . 'wp-content/db.php',
				ABSPATH . 'wp-content/database',
				ABSPATH . 'wp-content/wp-staging',
				ABSPATH . 'wp-content/plugins/wp-staging',
				ABSPATH . 'wp-content/plugins/wp-staging-pro',
				ABSPATH . 'wp-content/plugins/wpstg-sqlite-integration',
				ABSPATH . 'wp-content/mu-plugins/0-staging-url.php',
				ABSPATH . 'wp-content/mu-plugins/0-allow-wp-org.php',
				ABSPATH . 'wp-content/mu-plugins/1-pretty-permalinks.php',
				ABSPATH . 'wp-content/mu-plugins/2-deactivate-sqlite-plugin.php',
				ABSPATH . 'wp-content/mu-plugins/sqlite-database-integration-main',
			]
		);
	}
);

Substituir o collation da base de dados durante o restauro do Backup por um collation alternativo

Este filter permite-te substituir collations da base de dados em falta ou não suportados durante o processo de restauro do Backup. Se um collation não estiver disponível no servidor de destino, o WP STAGING tentará substituí-lo por uma variante genérica (e.g., utf8mb4_general_ci).

Usando este filter, podes definir os teus collations alternativos preferidos.

PHP
add_filter('wpstg.database.importer.replace_collation', function ($collationSearchReplace) {
    $collationSearchReplace['utf8mb4_uca1400_ai_ci'] = 'utf8mb4_0900_ai_ci';
    return $collationSearchReplace;
});

Parâmetros:

  • $collationSearchReplace (array): um array associativo de collations a substituir, em que a chave é o collation em falta e o valor é a substituição.

Exemplo:

Se o teu Backup contém utf8mb4_uca1400_ai_ci mas o servidor MySQL de destino não o suporta, podes substituí-lo por utf8mb4_0900_ai_ci usando o exemplo acima.

Excluir tabelas do restauro do Backup

Podes excluir tabelas específicas da base de dados do restauro usando o excerto abaixo:

PHP
add_filter('wpstg.backup.restore.exclude.tables', function ($excluded_tables) {
    $excluded_tables[] = 'users';
    $excluded_tables[] = 'usermeta';
    return $excluded_tables;
});

Ativar modo de desempenho seguro durante Backup/restauro

O modo seguro usa uma abordagem de I/O mais lenta mas mais compatível, que funciona em alojamento partilhado onde escritas de ficheiros agressivas desencadeiam erros 503. Ativa-o apenas se os Backups ou restauros falharem sem ele, pois reduz o desempenho em servidores capazes.

Usa o modo seguro para evitar erros 503 em servidores fracos. Afeta o desempenho do Backup. Não o uses se os Backups são criados corretamente.

PHP
add_filter('wpstg.job.performance_mode', function ($mode) {
    return 'safe';
});

Filters de Remote Sync

Os filters de Remote Sync permitem aos developers ajustar a forma como o WP STAGING trata os pedidos entre os sites de origem e de destino durante o Remote Sync. Estes filters são úteis para configurações com autenticação ao nível do servidor, regras de firewall, headers personalizados ou restrições de hosting que podem impedir a ligação de funcionar corretamente.

Contornar a Apache Basic Authentication

Se o site de destino estiver atrás de "Apache Basic Authentication" no servidor, tens de usar este filter para que a funcionalidade Remote Sync funcione corretamente. Isto contorna a proteção por palavra-passe do servidor:

add_filter('http_request_args', function ($parsed_args, $url) {

    $host = 'https://example.com/';
    $username = 'admin';
    $password = 'password';

    if (strpos($url, $expectedUrl) !== false) {
        $parsed_args['headers']['Authorization'] = 'Basic ' . base64_encode($username . ':' . $password);
    }

    return $parsed_args;
}, 10, 2);

Altera os valores de $allowedHost , $username e $password para as definições do teu servidor.

Updated on June 16, 2026

Rene Hermenau

Autor: Rene Hermenau

Sobre o autor: René Hermenau é o fundador do WP STAGING. Ele trabalha com backups do WordPress, ambientes de staging, migrações, gestão de bases de dados e fluxos de implantação seguros.