Uma das críticas comuns ao WordPress é que a base do código é uma bagunça.Há algo de verdade nisso, mas como o código principal é seguro e rápido, não deve ser uma grande preocupação porque a compatibilidade com versões anteriores é mais importante.
O código de terceiros (plugins e temas) emprega uma grande quantidade de metodologia de codificação de spaghetti ou cowboy e a metodologia “Eu faço o que eu quiser”. Comparado com uma plataforma orientada a objeto estrita como Laravel, o código escrito para WordPress geralmente é (nem sempre) pior em termos de qualidade.
Neste artigo, vou mostrar-lhe uma abordagem orientada a objetos (há muitos outros), o que espero que sirva de inspiração para limpar seu código. Este artigo é para a multidão avançada . Isso exige uma sólida base PHP, e uma compreensão rudimentar de OOP não vai doer. Se você é novo para OOP, pode ser uma boa idéia para ler um começou a receber guia. Você também deve estar familiarizado com a forma como os plugins funcionam e como os ganchos são usados para modificar a funcionalidade do WordPress.
Vamos usar um plugin que eu publiquei recentemente para o WordPress.org como exemplo: Publicações não lidas . O plugin contém um widget e uma facilidade para mostrar postagens não lidas em páginas únicas, mas também é uma base que outros plugins podem usar para obter posts não lidos. Isso funciona se um usuário está logado ou não, o que é limpo.
Vamos começar com a forma como as mensagens não lidas foram feitas.
Planejamento inicial
Planejar antes de digitar é sempre uma boa idéia, mais ainda ao criar objetos. Eu acho que nosso objetivo inicial deve ser criar uma instalação que possa lidar com postagens não lidas. Isso significa que devemos ser capazes de recuperar mensagens lidas / não lidas, definir postagens como lidas / não lidas e, talvez, excluir completamente a lista de posts de leitura de um usuário.
Funções Necessárias
Então, o primeiro passo que fiz foi planejar as funções que precisaremos, algo assim:
set_posts_as_read( $posts )Receberá uma ou mais postagens como um argumento e configurá-las como mensagens de leitura.set_posts_as_unread( $posts )Receberá uma ou mais postagens como argumento e configurá-las como mensagens não lidas (elas serão removidas da lista de leitura).get_read_posts()Irá recuperar todas as postagens lidasget_unread_posts()Irá recuperar todas as mensagens não lidasdelete_read_posts()Irá excluir todas as postagens lidas
Sabemos que o plugin terá que funcionar se alguém for convidado e se alguém estiver logado. Seria bom usar o banco de dados para armazenar mensagens de leitura quando o usuário estiver logado e para os clientes usaremos cookies.
Por que o código processual cai curto
Com base nessas informações, precisamos de dois conjuntos de funções, ou precisaremos de usar muito as afirmações. Obter / definir dados no banco de dados e em um cookie é radicalmente diferente. Se usarmos o código de espaguete, acabaríamos com um conjunto de funções como esta:
| Função get_read_posts () { | |
| Se (is_user_logged_in ()) { | |
| // Obter do DB | |
| } | |
| outro { | |
| // Obter do Cookie | |
| } | |
| } | |
| Função delete_read_posts () { | |
| Se (is_user_logged_in ()) { | |
| // Excluir do DB | |
| } | |
| outro { | |
| // Exclua o Cookie | |
| } | |
| } |
by Há duas questões aqui. Em primeiro lugar, você precisaria dessa lógica “se” para cada função que você escreve. O outro problema surge se você quiser adicionar um terceiro método de salvar os dados, talvez sincronizá-lo com uma API externa. Você precisaria passar por todas as suas funções, adicionando as terceiras opções usando outra declaração “if”.
Você poderia esconder algumas dessas lógicas chamando funções de forma dinâmica, algo assim:
| $ Type = ‘cookie’; | |
| Se (is_user_logged_in () $$ function_exists (‘some_api_plugins_function’)) { | |
| $ Type = ‘someapi’; | |
| } | |
| Elseif (is_user_logged_in ()) { | |
| $ Type = ‘db’; | |
| } | |
| Call_user_func (‘delete_read_posts_’. $ Type); |
Este é um passo na direção certa, mas ainda não é excelente. Você precisaria criar um monte de funções potencialmente confusas. Além disso, você provavelmente teria que globalizar a $typevariável se quiser usá-la dentro das funções.
Interfaces estão aqui para ajudar
Antes de entrar em interfaces, acho óbvio que usaremos aulas para nossa funcionalidade. As aulas nos permitem criar unidades autônomas e usar nomes de funções mais genéricos. O plano é criar uma classe separada que manipule as postagens de leitura no banco de dados e uma separada para os cookies.
Cada classe conterá as funções mencionadas acima, certificando-se de que o uso é o mesmo. Quando você tem várias classes com o mesmo propósito, implementando as mesmas funções apenas diferindo nos detalhes das funções, você está olhando para um cenário onde uma interface pode ser útil.
As interfaces parecem realmente assustadoras, mas são bastante simples. Entre outras coisas, eles permitem que você estabeleça um padrão comum para as aulas. Uma interface não contém e codifica, apenas funciona nomes e constantes. Ele define as funções que as classes que implementam a interface devem usar. Em certo sentido, isso torna nosso código auto-documentado, bem como super flexível, o que você verá um pouco mais tarde.
Vamos criar a interface, nomeando-a UP_Unread_Posts_Handler_Interface. “UP” é o prefixo para a classe que vem do nome do plugin (Mensagens não lidas). É altamente improvável que esta interface entre em conflito com outras pessoas, mas é melhor estar no lado seguro.
| Interface UP_Unread_Posts_Handler_Interface { | |
| / ** | |
| * Definir mensagens como lidas | |
| * | |
| * @param array | int $ posts post / posts para definir como lido | |
| * @author Daniel Pataki | |
| * @since 1.0.0 | |
| * | |
| * / | |
| Função pública set_posts_as_read ($ posts); | |
| / ** | |
| * Configura mensagens como não lidas | |
| * | |
| * @param array | int $ posts post / posts para definir como não lido | |
| * @author Daniel Pataki | |
| * @since 1.0.0 | |
| * | |
| * / | |
| Função pública set_posts_as_unread ($ posts); | |
| / ** | |
| * Receba mensagens lidas | |
| * | |
| * @author Daniel Pataki | |
| * @since 1.0.0 | |
| * | |
| * / | |
| Função pública get_read_posts (); | |
| / ** | |
| * Obter mensagens não lidas | |
| * | |
| * @author Daniel Pataki | |
| * @since 1.0.0 | |
| * | |
| * / | |
| Função pública get_unread_posts (); | |
| / ** | |
| * Excluir mensagens lidas | |
| * | |
| * @author Daniel Pataki | |
| * @since 1.0.0 | |
| * | |
| * / | |
| Função pública delete_read_posts (); | |
| } |
Como você pode ver, toda a interface é, é uma lista de funções. Eu adicionei alguns phpDoc para tornar as coisas ainda mais claras, tanta informação quanto possível pode ser adicionada aqui. Qualquer objeto que use (implementa) essa interface deve definir essas funções, caso contrário os erros serão exibidos.
Eu uso a convenção onde cada classe / interface vai em seu arquivo separado. Esses arquivos estão incluídos no arquivo do plugin principal.
Então, como conseguimos uma classe para implementar uma interface? Fácil, vamos criar nossa classe para interagir com o banco de dados.
| Classe UP_Unread_Posts_Handler_DB implementa UP_Unread_Posts_Handler_Interface { | |
| } |
Uso simples da implementspalavra-chave. Não se esqueça, uma vez que você faça isso, você precisará definir todas as funções definidas na interface.
A herança também está aqui para ajudar
Outra construção comum usada no OOP é a herança de classe. Este é um conceito simples, mas pode ser difícil de implementar corretamente. Gosto de pensar na herança como forma de generalizar a funcionalidade. Se criamos nossas duas classes – uma para interações de banco de dados, uma para interações de cookies – e achamos que algumas funções são exatamente o mesmo, é um bom sinal de que a herança poderia ser usada.
Vamos discutir como nossas classes e métodos funcionam, talvez possamos descobrir se devemos usar a herança ou não. Eu decidi logo que a melhor maneira de usar as classes é ter uma $this->read_postspropriedade que contenha uma série de IDs para as postagens de leitura.
Devido a isso, o get_read_posts()único trabalho da função é retornar o valor dessa propriedade. Em outras palavras, ficará assim em ambas as classes:
| Função get_read_posts () { | |
| Retornar $ this-> read_posts; | |
| } |
O mesmo get_unread_posts()é o mesmo para ambas as classes. O que eu quero fazer lá é para obter todas as postagens do banco de dados, exceto as que estão em $this->read_posts. Isso parece algo assim:
| Função get_unread_posts ($ args = array ()) { | |
| $ Padrão = array ( | |
| ‘Post_type’ => ‘post’, | |
| ‘Post_status’ => ‘publicar’, | |
| ‘Post__not_in’ => $ this-> get_read_posts (), | |
| ‘Fields’ => ‘ids’, | |
| ‘Posts_per_page’ => -1, | |
| ‘Orderby’ => ‘DESC’ | |
| ); | |
| $ Args = wp_parse_args ($ args, $ padrão); | |
| $ Args = apply_filters (‘up / unread_query_args’, $ args); | |
| $ Unread = new WP_Query ($ args); | |
| Se ($ unread-> found_posts == 0) { | |
| Array de retorno (); | |
| } | |
| outro { | |
| Retornar $ unread; | |
| } | |
| } |
Observe que a única informação que este método usa que vem de nossa classe é recuperada usando o get_read_posts()método, que já discutimos é o mesmo para ambas as classes.
Observe também que adicionei um filtro personalizado aos argumentos passados para a WP_Queryclasse, logo antes de ser chamado. Isso pode ser útil para outros desenvolvedores que desejam modificar a funcionalidade. Isso permitiria que eles adicionassem um tipo de postagem personalizado à consulta, por exemplo.
Em vez de ter duas classes para os nossos dois fins, vamos criar uma classe geral. Qualquer função que seja a mesma, independentemente do método de implementação, irá na classe geral. Todas as funções que diferem da classe para a classe permaneceriam nas sub-classes.
| Classe UP_Unread_Posts_Handler { | |
| Função get_unread_posts ($ args = array ()) {} | |
| Função get_read_posts () {} | |
| } | |
| Classe UP_Unread_Posts_Handler_DB extends UP_Unread_Posts_Handler implementa UP_Unread_Posts_Handler_Interface { | |
| Função set_posts_as_read ($ posts) {} | |
| Função set_posts_as_unread ($ posts) {} | |
| Função delete_read_posts () {} | |
| } | |
| Classe UP_Unread_Posts_Handler_Cookie se estende UP_Unread_Posts_Handler implementa UP_Unread_Posts_Handler_Interface { | |
| Função set_posts_as_read ($ posts) {} | |
| Função set_posts_as_unread ($ posts) {} | |
| Função delete_read_posts () {} | |
| } | |
Eu não adicionei o conteúdo de nenhuma função apenas para ter certeza de que está claro o que está acontecendo. As duas funções que são as mesmas serão definidas em UP_Unread_Posts_Handler. Outras funções serão definidas em ambas as sub-classes.
Observe que as interfaces levam em conta a herança. As funções definidas na interface podem ser definidas pela classe implementadora ou qualquer uma das suas principais ou sub-classes.
Diretrizes de Planejamento
Uma das mensagens de levar para casa aqui é parar de se preocupar com o que os usuários fazem. Não importa (pelo menos nesta fase)! Não nos importa como as postagens de leitura são adicionadas – o envio de um botão, o carregamento de uma única página de publicação, etc. O único que importa é o que você precisa absolutamente adicionar uma postagem à lista de leitura – o que é simples IDENTIDADE. Como essa identificação chega lá, há uma preocupação para mais tarde.
Outro aspecto importante é escrever código compreensível. Poderíamos fugir chamando nossa set_posts_as_read()função add()e nossa set_posts_as_unread()função, remove()mas isso seria um pouco ambíguo. Além disso, as funções estão fortemente documentadas no código-fonte, mesmo que tenha deixado esse bit nos exemplos aqui.
O objetivo é permitir que outros desenvolvedores leiam nosso código, assim como músicos podem ler partituras. Você precisa conhecer um monte de coisas como assinaturas-chave, equipes, comprimentos de notas e tal, mas uma vez que você aprende isso, você pode ler música como um livro. Deverá ser o mesmo com o código!
Criando funcionalidade
Este bit é relativamente direto, precisamos codificar as funções que temos e adicionar algumas novas no processo.
O manipulador de banco de dados
Vamos começar com o manipulador de banco de dados. Esta classe terá três propriedades.
$meta_fieldIrá conter a meta_key usada para armazenar as postagens de leitura na tabela usermeta para cada usuário.$user_idConterá o ID do usuário conectado no momento.$read_postsContém uma lista de mensagens de leitura.
A função do construtor – que é executada logo que um objeto é instanciado – preencherá essas três propriedades com dados. Isso é bastante direto:
| Classe UP_Unread_Posts_Handler_DB extends UP_Unread_Posts_Handler implementa UP_Unread_Posts_Handler_Interface { | |
| Public $ meta_field; | |
| Public $ user_id; | |
| Protegido $ read_posts; | |
| Função __construct () { | |
| $ This-> set_meta_field (); | |
| $ This-> set_user_id (); | |
| $ This-> set_read_posts (); | |
| } | |
| Função protegida set_meta_field () { | |
| $ This-> meta_field = apply_filters (‘up / meta_field’, ‘up_read_posts’); | |
| } | |
| Função protegida set_user_id () { | |
| $ Current_user = wp_get_current_user (); | |
| $ This-> user_id = $ current_user-> ID; | |
| } | |
| Função protegida set_read_posts () { | |
| $ Read_posts = get_user_meta ($ this-> user_id, $ this-> meta_field, true); | |
| $ Read_posts = (vazio ($ read_posts))? Array (): $ read_posts; | |
| $ This-> read_posts = $ read_posts; | |
| } | |
| } |
O que pode confundir você é como o campo meta está definido. Isso poderia ser simplesmente codificado como up_read_posts. Isso seria ótimo, mas eu queria fazer o plugin tão extensível quanto possível. O objetivo do up/meta_fieldfiltro é permitir que os usuários modifiquem o nome do campo meta. Se nenhum filtro estiver definido up_read_posts, será usado.
Em seguida, as três funções que adicionam / removem as postagens de leitura da lista e excluem completamente a lista completa de posts de leitura. Vamos começar set_posts_as_read(), o resto será fácil.
| Função set_posts_as_read ($ posts) { | |
| Se (is_numeric ($ posts)) { | |
| $ Posts = array ($ posts); | |
| } | |
| Se (array_intersect ($ this-> read_posts, $ posts) == $ posts) { | |
| Retorna ; | |
| } | |
| $ This-> read_posts = array_unique (array_merge ($ this-> read_posts, $ posts)); | |
| Update_user_meta ($ this-> user_id, $ this-> meta_field, $ this-> read_posts); | |
| } |
Nesta função, primeiro $postssanificamos o parâmetro. Se uma única ID foi passada, criamos uma matriz com o ID, pois é primeiro e único membro.
Para tornar o plugin eficiente, verificamos se as postagens de leitura já estão todas na nossa lista de leitura. Nós podemos fazer isso usando array_intersect. A idéia é que, se a interseção de todas as nossas postagens de leitura e as postagens que queremos marcar como lidas são exatamente as mesmas que queremos marcar, isto significa que todos os membros $postestão em $this->read_postsque significa que não precisamos Faça qualquer coisa.
Se precisarmos marcar alguns deles como lidos, mesclaremos os dois arrays, eliminando quaisquer itens duplicados no processo. É importante fazer duas coisas aqui: o novo meta meta do usuário deve ser salvo e $this->read_postsdeve ser atualizado para conter os novos itens, caso desejemos usar essa propriedade mais tarde durante a execução da página.
As duas funções restantes – set_posts_as_unread()e delete_read_posts()– são assuntos relativamente simples, aqui estão:
| Função set_posts_as_unread ($ posts) { | |
| Se (is_numeric ($ posts)) { | |
| $ Posts = array ($ posts); | |
| } | |
| $ This-> read_posts = array_diff ($ this-> read_posts, $ posts); | |
| Update_user_meta ($ this-> user_id, $ this-> meta_field, $ this-> read_posts); | |
| } | |
| Função delete_read_posts () { | |
| Delete_user_meta ($ this-> user_id, $ this-> meta_field); | |
| } |
O manipulador de cookies
O manipulador de cookies só precisa de duas propriedades:
$cookie_nameConterá o nome do cookie usado para armazenar as postagens de leitura.$read_postsContém uma lista de mensagens de leitura.
O construtor de classe define os valores para essas propriedades da mesma maneira, aqui está o código:
Há dois pontos importantes aqui. O nome padrão do cookie será site-title-up-read-postsonde site-titleé o título do site real, sanitizado com traços. Uma vez que o plugin pode ser usado em vários sites se nós up-read-postssimplesmente usarmos as chances de marcar postagens como lidas em dois sites diferentes é maior.
Ainda pode haver dois sites separados com o mesmo título usando este plugin – isso pode causar um problema. Apenas ocorreu-me que se usássemos o nome de domínio em vez do título do site, podemos ignorar o problema. Bem, como você pode ver o código, sempre pode ser melhorado!
O segundo ponto é a forma como o cookie é recuperado, especificamente: explode( ', ', gzuncompress( $_COOKIE[$this->cookie_name] ) ). Isto é devido a como o valor do cookie será salvo.
Uma lista separada por vírgulas de IDs seria idéia de usar como o valor do cookie, mas eles poderiam acabar ocupando muito espaço. Devido a isso, a gzcompress()função é usada para comprimir a string. A explode()função simplesmente leva a lista separada por vírgulas e converte-a em uma matriz agradável.
As três funções restantes que definem / removem mensagens de leitura e excluí-las são as mesmas. As funções set / remove são realmente exatamente as mesmas, exceto que elas usam setcookie()no final para salvar os dados, assim como a delete_read_posts()função para remover completamente o cookie.
Criando Nosso Objeto
Nesta fase, temos uma interface, uma classe principal de manipuladores e duas sub-classes que cuidam dos detalhes de trabalhar com posts de leitura. Agora é hora de usar o que criamos. Eu acho que essa é realmente a parte mais difícil – entendendo como criar nossos objetos.
A maneira mais fácil de começar seria simplesmente usar as classes que temos diretamente, algo assim:
| Se (is_user_logged_in ()) { | |
| $ Read_posts = UP_Unread_Posts_Handler_DB; | |
| } | |
| outro { | |
| $ Read_posts = UP_Unread_Posts_Handler_Cookie; | |
| } | |
| $ Read_posts-> set_posts_as_read (12); |
Isso funcionaria bem, mas é um pouco menos flexível do que eu gostaria. Eu também preciso criar outra classe que irá lidar com outras operações, como criar o widget de pastas não lidas e criar a página de configurações. Esta classe usará nossos manipuladores, é claro, então vamos criá-lo agora!
Codificação para uma interface
Por enquanto, esta classe declara uma única propriedade – $handlerque será uma instância de uma das nossas classes de manipuladores que deve ser passada para ela no construtor. Eu tenho tipo sugerido isso para torná-lo super-claro o que se esperava: __construct( UP_Unread_Posts_Handler_Interface $handler = null ).
| Classe UP_Unread_Postts { | |
| Manipulador público $; | |
| Função __construct (UP_Unread_Posts_Handler_Interface $ handler = null) { | |
| $ This-> handler = $ handler?: Novo UP_Unread_Posts_Handler_Cookie; | |
| } | |
| } |
Observe que não esperamos nenhuma classe específica. Esperamos que qualquer classe que implementa interface manipulador. Esta é uma prática extremamente poderosa conhecida como “codificação para uma interface”. Ele desacoplará nosso aplicativo de qualquer implementação específica.
Enquanto um objeto for aprovado, implementa a UP_Unread_Posts_Handler_Interfaceinterface, todos somos bons. Isso nos permite passar com uma das nossas classes pré-existentes além de aceitar qualquer classe criada por terceiros.
Isso permitiria que os desenvolvedores criassem uma classe que usasse oarmazenamento local HTML 5, por exemplo, sem ter que tocar em nosso código existente .
Instanciação final
No final do dia, usamos uma única função definida no arquivo principal do plugin para obter nossa funcionalidade. Deixe-me mostrá-lo primeiro e explique depois.
| Add_action (‘plugins_loaded’, ‘up_initialize_plugin’); | |
| Função up_initialize_plugin () { | |
| Global $ up_unread_posts; | |
| $ Up_unread_posts_handler = (is_user_logged_in ())? “UP_Unread_Posts_Handler_DB”: “UP_Unread_Posts_Handler_Cookie”; | |
| Add_filter (‘up / handler’, $ up_unread_posts_handler); | |
| $ Up_unread = new UP_Unread_Postts (novo $ up_unread_posts_handler); | |
| $ Up_unread_posts = $ up_unread-> handler; | |
| } |
Quando os plugins foram carregados, disparamos a up_initialize_plugin()classe. Nós definimos imediatamente uma variável global – $up_unread_posts. Uma vez finalizado, esta variável será uma instância do nosso objeto manipulador, disponível globalmente para qualquer um.
Em seguida, determinamos qual manipulador queremos usar. Se o usuário estiver logado, usamos UP_Unread_Posts_Handler_DB, caso contrário usamos UP_Unread_Posts_Handler_Cookie.
O próximo filtro é crucial para permitir que outros passem seus próprios manipuladores. O up/handlerfiltro permite que outros substituam o manipulador de mensagens e passem para a UP_Unread_Postsclasse.
Em seguida, criamos uma instância da UP_Unread_Postsclasse, passando um novo objeto manipulador. Este objeto pode ser acessado através da $handlerpropriedade dentro do objeto. Fazemos $up_unread_postsigual a isso para permitir que outros utilizem a funcionalidade.
Eu faço uso da UP_Unread_Postsclasse no plugin um pouco, vou mostrar um vislumbre disso em um momento. Por enquanto, no entanto, acabamos com nossa implementação básica!
A $up_unread_postsvariável agora contém nosso manipulador e pode ser usada em qualquer lugar – dentro de um tema ou outro plugin. Os usuários não precisam se preocupar sobre qual manipulador está sendo usado. Tudo o que precisa de saber é que eles podem usar o set_posts_as_read(), set_posts_as_unread, etc. métodos.
Aproveitando a funcionalidade de leitura pós-publicação
Para mostrar o quão fácil é usar o que construímos, vamos criar dois novos plugins que irão interagir com nosso plugin de base.
Postagens de leitura automática
Vamos adicionar automaticamente um artigo à lista de leitura se o usuário visitar a página do artigo único. Essa funcionalidade realmente existe no plugin por padrão, mas vamos assumir que não é e criar um novo plugin.
Aqui está o código completo para um plugin que adicionaria uma postagem à lista de leitura automaticamente, desde que o widget Mensagens não lidas esteja ativo.
| / * | |
| Nome do plugin: Auto Adicionar postagens de leitura | |
| Descrição: Um plugin que adiciona postagens de leitura à lista de leitura do usuário – requer o plugin Unread Posts | |
| Versão: 1.0.0 | |
| Autor: Daniel Pataki | |
| Autor URI: http://danielpataki.com/ | |
| Licença: GPLv2 ou posterior | |
| * / | |
| Add_action (‘wp’, ‘auto_add_post_to_read_list’); | |
| Função auto_add_post_to_read_list () { | |
| Global $ up_unread_posts; | |
| Se (is_singular ()) { | |
| $ Global; | |
| $ Up_unread_posts-> set_posts_as_read ($ post-> ID); | |
| } | |
| } |
Simples, certo? Note que usei o wpgancho que talvez não seja a escolha óbvia. A razão pela qual eu escolhi isso foi que precisamos usar algo que é acionado antes de qualquer saída HTML ser enviada. Isto é devido ao uso setcookieque sempre deve ser chamado antes da saída HTML.
Widget de mensagens não lidas
Isso também é parte do plugin real, mas vamos esquecer isso por enquanto e criar um novo plugin para ele. Novamente, o código completo:
| / * | |
| Nome do plugin: widget de pastas não lidas | |
| Descrição: um plugin exibe uma lista de mensagens não lidas | |
| Versão: 1.0.0 | |
| Autor: Daniel Pataki | |
| Autor URI: http://danielpataki.com/ | |
| Licença: GPLv2 ou posterior | |
| * / | |
| Add_action (‘widgets_init’, ‘unread_posts_widget_init’) | |
| Função unread_posts_widget_init () { | |
| Register_widget (‘UP_Unread_Posts_Widget’); | |
| } | |
| Classe UP_Unread_Posts_Widget estende WP_Widget { | |
| Função pública __construct () { | |
| $ Widget_details = array ( | |
| ‘Classname’ => ‘up-unread-posts-widget’, | |
| ‘Description’ => __ (‘Um widget personalizável que exibe mensagens não lidas’, ‘posts não lidos’) | |
| ); | |
| Parent :: __ construct (‘up-unread-posts’, __ (‘Mensagens não lidas’, ‘posts não lidos’), $ widget_details); | |
| } | |
| Formulário de função pública ($ instância) { | |
| $ Title = (! Empty ($ instance [‘title’]))? $ Instance [‘title’]: ”; | |
| ?> | |
| < Div class = ‘ unread-posts ‘ > | |
| < P > | |
| < Label for = ” <? Php echo $ this -> get_field_name ( ‘ title ‘ ); ? > “ > <? Php _e ( ‘ Título: ‘ , ‘ mensagens não lidas ‘ ) ? > </ Label > | |
| ? > “ /> | |
| </ P > | |
| </ Div > | |
| <? Php | |
| } | |
| Widget de função pública ( $ args , $ instance ) { | |
| Global $ up_unread_posts ; | |
| $ Query_args = array ( | |
| ‘ Posts_per_page ‘ => 5 , | |
| ‘ Fields ‘ => ‘ all ‘ | |
| ); | |
| $ Unread = $ up_unread_posts -> get_unread_posts ( $ query_args ); | |
| Se ( $ unread -> found_posts == 0 ) { | |
| Retorno ; | |
| } | |
| Echo $ args [ ‘ before_widget ‘ ]; | |
| Se ( ! Empty ( $ instance [ ‘ title ‘ ])) { | |
| Echo $ args [ ‘ before_title ‘ ] . Apply_filters ( ‘ widget_title ‘ , $ instance [ ‘ title ‘ ], $ instance , $ this -> id_base ) . $ Args [ ‘ after_title ‘ ]; | |
| } | |
| $ Output = ‘ <ul> ‘ ; | |
| Enquanto ( $ unread -> have_posts ()) { | |
| $ Unread -> the_post (); | |
| $ output . = ‘ <li> <a href=”‘. get_permalink( get_the_ID()). “> ‘ . The_title ( ‘ ‘ , ‘ ‘ , false ) . ‘ </a> </ li> ‘ ; | |
| } | |
| $ Output . = ‘ </ Ul> ‘ ; | |
| Echo $ args [ ‘ after_widget ‘ ]; | |
| } | |
| } |
Conclusão
Embora isso possa parecer saltar através de aros no início, começar a cabeça em torno de uma mentalidade orientada a objeto é uma das melhores coisas que você pode fazer. Na verdade, eu demoro menos tempo para criar o plugin dessa maneira do que usar o código processual.
Isso ocorre porque há muito pouco pensamento envolvido, o que é bom. O pensamento é gasto na fase de planejamento, a partir daí é apenas uma questão de programação das funções que você precisa.
Um estilo orientado a objetos assegurará que seu código seja flexível, uma prova futura e uma alegria para trabalhar com outros codificadores.
Se você quiser dar uma olhada no código fonte completo das publicaçõesnão lidas, veja o Repositório do WordPress ou o Repositório Github . Há mais alguns ganchos lá e funcionalidades para adicionar posts não lidos abaixo do conteúdo de uma única publicação, mas passamos pelas partes mais importantes.
Se você tiver alguma dúvida ou conhece alguns plugins que empregam práticas orientadas a objetos, informe-nos nos comentários abaixo.
