Um debug.log de vários gigabytes e todas as linhas iguais: PHP Deprecated: Creation of dynamic property Meu_Widget::$config is deprecated. O aviso nasceu no PHP 8.2 e continua firme no 8.3: alguém atribui uma propriedade que a classe nunca declarou. Primeiro descubra o arquivo, depois decida entre corrigir e calar.
Isolar quem está reclamando
cd /var/www/rogertakemiya.com.br/html/wp-content
grep -o 'Creation of dynamic property [^ ]*' debug.log | sort | uniq -c | sort -rn | head
grep 'dynamic property' debug.log | grep -o 'in /var/www[^ ]*' | sort -u
A primeira linha mostra quais classes repetem mais, a segunda entrega o caminho exato do arquivo. Se cair em tema ou plugin que você mantém, a correção é declarar a propriedade e acabou:
class Meu_Widget {
public array $config = []; // antes era criada no voo
public function __construct() {
$this->config['modo'] = 'lista';
}
}
Para código de terceiro que você não vai manter, existe o atributo #[AllowDynamicProperties] em cima da classe. É o mesmo recurso que o core do WordPress usa em dezenas de classes próprias, como WP_Block_Type. Só que a próxima atualização do plugin apaga a sua alteração, então trate isso como remendo de emergência.
Calar sem perder erro de verdade
Botar error_reporting() no wp-config.php não adianta: o WordPress roda wp_debug_mode() logo no começo do wp-settings.php e reescreve tudo para E_ALL quando WP_DEBUG está ligado. Os mu-plugins carregam bem depois disso, e é ali que a mudança sobrevive:
// wp-content/mu-plugins/sem-deprecated.php
error_reporting( E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED );
Aviso disparado antes dos mu-plugins ainda entra no log, então isso corta a enxurrada, não tudo. Mantenha WP_DEBUG_LOG ligado e WP_DEBUG_DISPLAY em false, para nada vazar na tela do cliente. Depois trunque o arquivo antigo com truncate -s 0 debug.log, porque apagar com o PHP escrevendo nele deixa o inode ocupado e o disco não volta.
Se travou nisso e precisa de ajuda, me chama aqui.