Usando ganchos do WordPress para limpar código, ativar e desinstalar
Publicados: 2015-01-23Os autores de plugins dedicam tanto tempo e energia à funcionalidade principal de seus produtos, que permitem que coisas menos importantes sejam deixadas de lado.
Por exemplo, ativação e desativação. Embora os ganchos de ativação sejam difundidos – muitos plugins precisam adicionar algumas opções, liberar regras de reescrita, talvez criar uma tabela de banco de dados ou verificar diferenças de versão na instalação – os ganchos de desativação e desinstalação são muito menos comuns.
O ponto aqui? Muitos autores de plugins não têm tempo para limpar depois de si mesmos. A instalação do WordPress realmente precisa da tabela personalizada que você criou após a remoção do plugin? Por que não limpar algumas opções exclusivas do plugin antes de descartá-lo?
Neste artigo, mostrarei como usar ganchos de ativação, desativação e desinstalação para inicializar seu plug-in e limpar as coisas com mais facilidade depois que os usuários terminarem com seu produto.
- O Gancho de Ativação
- A Sequência de Instalação
- Liberando Regras de Reescrita
- Criando tabelas de banco de dados
- Verificações de dependência
- O Gancho de Desativação
- O Gancho de Desinstalação
- Segurança Adicional
- É hora de limpar
Nota: Se você planeja percorrer este artigo, sugiro fortemente dar uma olhada na seção “Segurança Adicional” no final, que complementa o código com algumas verificações de segurança valiosas. Além disso, se você precisar de ajuda com ganchos de plug-in do WordPress, aqui está uma rápida atualização sobre o uso de ganchos do WordPress e como ativar uma função no WordPress.
O Gancho de Ativação
Embora o gancho de ativação seja bastante simples, instalá-lo é um caso um pouco especial, portanto, precisamos prestar atenção à sequência de eventos. Antes de entrarmos em tudo isso, aqui está um exemplo simples:
A chave para tudo isso é a função register_activation_hook() . O primeiro parâmetro é o caminho para o arquivo de plugin principal; o segundo parâmetro define a função a ser executada. Internamente, a função register_activation_hook() é um wrapper para a ação “activate_[plugin_name]”, mas como é um pouco mais fácil de usar, é incomum ver o gancho em plugins.
A Sequência de Instalação
Compreender a sequência de instalação é importante porque evita o uso de métodos aos quais você pode estar acostumado. register_activation_hook() é chamado entre o usuário clicar no link de ativação e, consequentemente, ver o aviso de ativação. Ele é executado em uma página intermediária, que redireciona imediatamente antes que qualquer gancho possa ser executado.
Vejamos um exemplo para ver por que isso é uma grande chatice:
Liberando Regras de Reescrita
Vários plugins criam tipos de postagem personalizados. Liberar as regras de reescrita na ativação para garantir que os usuários não recebam um erro 404 ao visitar uma postagem do novo tipo de postagem personalizada é uma jogada inteligente.
O código abaixo parece lógico, mas falhará.
Parece perfeitamente bem. O tipo de postagem personalizado é criado e, na ativação, liberamos as regras de reescrita. O problema é que os tipos de postagem personalizados ainda não foram criados quando liberamos as regras de reescrita.
Veja como fica o fluxo do processo:
- O usuário instala o plugin.
- O usuário clica no link de ativação.
- Uma página intermediária executa apenas o gancho de ativação, nada mais. Isso libera as regras de reescrita.
- O plugin está ativo e o código é executado normalmente. O tipo de postagem personalizado é registrado.
Uma solução postada no Stack Overflow, que é oficialmente endossada pelo WordPress Codex, resolve nosso pequeno problema. A solução envolve adicionar uma opção para indicar que o plugin acabou de ser instalado.
Se essa opção existir, fazemos nossa ativação e a excluímos.
Algo assim:
Pessoalmente, não gosto muito desta solução. O problema é que a verificação na linha oito é executada em cada carregamento de página. Não há nada para se preocupar, pois não sobrecarregará seus servidores e não diminuirá a velocidade do site para seus usuários. É uma verificação muito rápida com um impacto insignificante no desempenho. No entanto, é desnecessário 99,9% das vezes.
Existe uma solução melhor mencionada no Codex na documentação para a função flush_rewrite_rules() . Nesta solução, usamos a modularidade de nossas funções para registrar o tipo de postagem personalizado na ativação separadamente:
Em vez de depender de uma verificação que precisa ser executada o tempo todo, usamos a função de ativação para registrar nossos tipos de postagem. Observe que uma vez que nosso plugin é ativado, os tipos de postagem sempre serão registrados a partir do gancho init .
Este é um triste exemplo do Codex estar em todo lugar. Geralmente, o WordPress tem uma boa documentação, mas se algo parecer inútil ou ilógico, não tenha medo de fazer sua própria pesquisa.
Criando tabelas de banco de dados
Outra tarefa que alguns plugins realizam é criar tabelas de banco de dados. Na maioria das vezes, isso é desnecessário, mas existem alguns casos de uso legítimos.
Este exemplo do artigo do Codex sobre Criação de tabelas mostra como várias chamadas de ativação podem ser usadas:
A primeira função, jal_install() cria uma nova tabela de banco de dados. A segunda função, jal_install_data , adiciona dados iniciais à tabela. Em vez de usar register_activation_hook() para adicionar uma função contendo todo esse código, podemos usar register_activation_hook várias vezes.
Esta é uma ótima prática para modularidade. Por um lado, você não precisa adicionar dados de teste iniciais – é tão simples quanto remover o gancho de ativação – para que você possa manter a função intacta. Por outro lado, você é livre para reutilizar essas funções em qualquer lugar, pois elas são separadas.
Verificações de dependência
Outra tarefa comum para a função de ativação é verificar dependências. Seu plugin pode contar com uma versão específica do WordPress, outro plugin ou até mesmo uma versão específica do PHP.
O código abaixo verifica se há uma versão mínima de WP e PHP e redireciona o usuário (sem ativar o plugin) se necessário:
O Gancho de Desativação
Os ganchos de desativação são executados quando um usuário desativou um plug-in, mas antes de ser desinstalado (excluído). Ganchos de desativação são usados da mesma forma que ganchos de ativação:
Desativação significa que o usuário desativou apenas seu plugin, então você não vai querer fazer tanto quanto faria durante uma desinstalação. Talvez você queira liberar as regras de reescrita, mas neste estágio, você não vai querer se livrar de todas as suas opções e sua tabela de banco de dados (se você tiver uma).
Isso é bastante simples, mas prestarei atenção especial à liberação das regras de reescrita, pois, mais uma vez, elas são problemáticas.
O codex recomenda fazê-los como mostrado abaixo, mas isso não funciona :
A razão pela qual isso não funciona é a mesma de antes. A execução de uma desativação executa o gancho init , o que significa que conforme estamos desativando nosso plugin, também estamos registrando nosso tipo de postagem personalizado. As regras de reescrita são liberadas, mas levam em consideração o tipo de postagem personalizado.
Um bilhete Trac está em vigor para resolver isso, mas até então, não posso lhe dar uma maneira muito boa de fazer isso. A única maneira que descobri que funciona é excluir completamente as regras de reescrita:
Embora isso tenha funcionado para mim no passado, eu não recomendaria. Ele introduz uma incerteza maior do que o problema de ter algumas regras extras de reescrita. Prefiro exibir uma nota aos usuários solicitando que eles visitem as configurações de permalink após a desativação, o que liberaria as regras de reescrita. Até que uma solução melhor seja implementada, estamos presos a isso... desculpe!
O Gancho de Desinstalação
Existem duas maneiras de executar o código ao desinstalar um plug-in. Você pode usar o gancho de desinstalação via register_uninstall_hook() ou pode usar um arquivo uninstall.php dedicado dentro do seu plugin. Vou mostrar os dois, mas o método preferido é usar o arquivo de desinstalação.
O principal problema com o gancho de desinstalação é que “ele impede que o arquivo principal do plug-in seja executado durante a desinstalação, o que pode ser problemático se o plug-in executar código no espaço global. Também é melhor porque o código de desinstalação é centralizado.” – Scott Riley
O código abaixo mostra o processo de desinstalação usando um gancho básico:
Conforme discutido, esta não é a melhor solução. Uma maneira muito melhor de lidar com desinstalações é usar o arquivo uninstall.php . Tudo que você precisa fazer é criá-lo e ele será usado se estiver disponível.
Como você pode ver, esta é realmente uma solução mais simples. O melhor de tudo é que é independente.
Segurança Adicional
Eu não queria complicar demais os exemplos mostrados até agora com problemas relacionados à segurança, mas você realmente deveria tomar algumas medidas para garantir que apenas aqueles que têm permissão para fazer isso possam executar essas ações.
Use o seguinte snippet na ativação e desativação:
Este bloco de código garante que o usuário tenha as permissões para realizar esta ação e que a ação se originou na página apropriada. Isso deve proteger contra a maioria das tentativas maliciosas.
O processo de desinstalação é especial, então precisaremos usar um código um pouco diferente:
É hora de limpar
Se o seu plug-in adiciona coisas ao WordPress, é seu dever como desenvolvedor removê-lo quando um usuário decidir excluir seu plug-in.
O uso dos métodos de ativação, desativação e desinstalação descritos acima permitirá que você construa um sistema que faça isso com segurança. Também recomendo a leitura deste tópico do Stackexchange, que descreve esses processos em ambientes OOP.
Se você ainda não é membro do WPMU DEV, inscreva-se hoje para uma avaliação gratuita, totalmente sem riscos. Como membro, você terá acesso a todos os nossos excelentes plugins e serviço de hospedagem extremamente rápido, além de suporte especializado 24 horas por dia, 7 dias por semana, para todas as suas dúvidas e problemas relacionados ao WordPress.
Tag: