✅ Notícias, temas e plug-ins da WEB e do WordPress. Aqui compartilhamos dicas e as melhores soluções para sites.

Widgets do WordPress: Refatoração, Parte 7

6

Nas últimas postagens, trabalhamos muito para levar o código ao ponto de refatoração que será abordado neste artigo.

Especificamente, cobrimos:

Tudo isso vai desempenhar um papel no que vamos fazer hoje.

The WordPress Widget Boilerplate: Refatoração, Parte 7

Para aqueles que estão familiarizados com o WordPress Widgets API, então você provavelmente sabe que não mudou muito nos últimos anos.

Além disso, ele realmente consiste apenas em quatro funções (uma das quais é o construtor):

  1. O construtor é responsável por definir várias propriedades no widget, mais comumente seu nome e a descrição do mesmo.
  2. A função widget é responsável por renderizar o conteúdo do widget.
  3. A função de formulário é responsável por exibir o formulário na área de administração do WordPress ao trabalhar com o widget.
  4. A função de atualização é responsável por atualizar as opções que estão salvas no banco de dados (ou inicializadas e depois salvar as opções que ainda não existem no banco de dados).

O bom é que essa abordagem específica é alcançada herdando uma funcionalidade para a classe WP_Widget.

O problema, porém, é que é muito trabalho para uma única classe fazer.

Em vez disso, devemos separar cada uma das funções em sua própria área de funcionalidade.

Como acontece com qualquer coisa na programação, haverá maneiras pelas quais algumas coisas serão claras sobre como podem ser feitas e, em seguida, algumas coisas poderão ser feitas de várias maneiras.

O que vou apresentar é como estou abordando isso por enquanto. Isso pode mudar no futuro, ou talvez não, e outros podem ter uma opinião diferente sobre isso.

Independentemente disso, a implementação será muito mais orientada a objetos e dará a cada classe seu próprio conjunto de responsabilidades.

A primeira pergunta, porém, é como dividir uma classe com quatro funções e que herda de uma classe pai?

Atualizando o Bootstrap

Primeiro, há algumas coisas que precisamos ajustar no bootstrap do plugin. Ou seja, precisamos fazer o seguinte:

  1. instanciar o Registro e disponibilizá-lo através do projeto,
  2. atualize a classe Plugin para que ela aceite um registro e carregue os assinantes,
  3. revise o bootstrap

Aqui está uma olhada em todos os três acima.

1 Instanciar o Registro

Como já abordamos isso no início da série, deve ficar claro como fazer isso.

Primeiramente, veja o seguinte código :

Em seguida, observe que estamos instanciando o Registro (falaremos sobre seu namespace momentaneamente) e, em seguida, estamos conectando-o a um filtro personalizado que nos permite acessá-lo em todo o plug-in sempre que quisermos.

2 Atualize a Classe do Plugin

Em seguida, precisamos atualizar a classe do plugin principal (que reside no  diretório src) para que faça referência ao registro e carregue todos os assinantes registrados :

Observe, no entanto, que ainda não configuramos nenhum assinante. Começamos isso no início da série e agora é hora de voltar, mas faremos isso mais tarde.

No entanto, precisamos adicionar uma função – mesmo que temporária – para que possamos adicionar classes que não sejam assinantes de eventos explícitos:

Isso será reformulado posteriormente, pois transformaremos as classes principais em assinantes posteriormente.

3 Revise o Bootstrap

Antes de prosseguir, acho importante revisar o bootstrap. Embora o cabeçalho e a documentação possam variar, é importante observar que estamos fazendo o seguinte:

  • namespace do bootstrap,
  • impedindo que o arquivo seja acessado,
  • chamando o autoloader,
  • configurando o registro,
  • e iniciando o plug-in.

Parece muito, mas o código é bem curto :

Neste ponto, porém, é hora de ver como é dividir a classe filha da API Widgets padrão em algo que se encaixe no modelo de código com o qual estamos trabalhando.

Dividindo uma classe filha

Esta parte provavelmente abrangerá alguns posts, pois há um pouco de trabalho a ser feito, mas começaremos criando nossa própria classe de widget que herdará da classe Widget base.

Primeiro, vá em frente e crie um  diretório de API no diretório src e adicione um arquivo chamado Widget.php. É aqui que o básico do widget residirá. Entraremos em folhas de estilo administrativas e públicas e arquivos JavaScript na próxima postagem.

Neste ponto, o básico do arquivo deve ficar assim :

Observe que ele recebe um único argumento. Eu usei o nome do widget, mas você pode usar o que quiser, desde que represente seu widget.

Isso é para mostrar que a classe está sendo instanciada e carregada corretamente quando o plugin é ativado. Se você não vir isso, algo não está certo (o que revisaremos momentaneamente).

Em seguida, é importante garantir que essa classe seja adicionada ao Registro. Então adicione as seguintes linhas do código no bootstrap:

E agora, ao ativar o plugin, você deverá ver o seguinte:

Widgets do WordPress: Refatoração, Parte 7

Caso contrário, certifique-se de revisar o código na ramificação de desenvolvimento para garantir que você tenha tudo o que está descrito neste post.

Implementando assinantes

Nas próximas postagens, veremos como podemos implementar assinantes para o lado público do site (ou seja, onde o conteúdo do widget é exibido). E faremos o mesmo para a área de administração do site.

Por fim, voltaremos nossa atenção para o código responsável por proteger e serializar os dados (leia-se: atualizar nosso widget) e, em seguida, ver como é a versão final de um clichê atualizado.

Neste post, porém, a principal estratégia que estamos empregando é dividir uma classe filha para que ela ainda possa ser usada com outras classes usando interfaces e classes base que já estão definidas no código base.

Fonte de gravação: tommcfarlin.com

Este site usa cookies para melhorar sua experiência. Presumiremos que você está ok com isso, mas você pode cancelar, se desejar. Aceitar Consulte Mais informação