Widgets de WordPress: un enfoque orientado a objetos

Hace años, creé WordPress Widget Boilerplate con el objetivo de ser lo siguiente:

Un modelo organizado y mantenible para crear widgets utilizando las mejores prácticas de WordPress.

Desde entonces, no ha cambiado mucho con respecto a la API de Widgets (que veremos más adelante en esta publicación), pero lo que considero "mejores prácticas" ha cambiado. Además, el grado en que creo que esta API es una sólida ejemplo de introducción a la programación orientada a objetos en WordPress es alto.

No es porque use muchos principios orientados a objetos, no es porque use estándares modernos (al menos en lo que se refiere a PHP moderno), sino porque usa algunas cosas que nos ayudan a reconocer algunas, digamos, Señales con respecto a la programación orientada a objetos en WordPress.

Y esto es algo que no debe subestimarse: si está buscando ejemplos de programación orientada a objetos en WordPress, busque API que la empleen.

Además, si está buscando formas de medir su propio nivel de evaluación de una pieza de código (por no hablar de una base de código) para el uso de clases y algunas de las características más avanzadas de OOP, ¿por qué no tener algún tipo de de una prueba de fuego para ver cómo te va?

Y la API de Widgets hace precisamente eso.

Widgets de WordPress: una introducción

Entonces, en una serie más pequeña que la última, mi objetivo es ver la API de Widgets y hacer algunas cosas:

1. mostrarle el esqueleto básico de un widget y por qué está orientado a objetos,
2. discuta qué cosas debería poder notar y por qué,
3. primero actualice el modelo de widget directamente en este sitio y luego envíelo a GitHub,
4. construya un widget utilizando la API con el modelo como base para nuestro trabajo.

Y en esta publicación, vamos a comenzar con el primer punto anterior.

Pero primero…

Antes de entrar en este artículo, recomiendo leer los siguientes artículos:

1. Dos pilares de la programación orientada a objetos: Parte 1 de 2
2. Dos pilares de la programación orientada a objetos: Parte 2 de 2
3. Clases abstractas, Parte 1: Comportamiento de abstracción
4. Clases abstractas, Parte 2 – Clases abstractas e interfaces

Una vez hecho esto (o si siente que ya domina los temas), entonces estamos listos para comenzar.

[restringir pagado="verdadero»]

Los conceptos básicos de la API de widgets

Si lee la página del manual sobre Widgets, verá una gran cantidad de contenido. Esto es algo bueno, pero no siempre es el mejor movimiento cuando se trata de destilar contenido para una audiencia como usted cuando busca consejos prácticos y orientados a objetos.

Así que seleccionaré las partes relevantes de la documentación de la API y luego las aplicaré al código que también se nos proporcionó.

¿Qué es un widget?

Creo que la mayoría de los que trabajamos con WordPress sabemos qué es un widget, pero es importante definir el término para que todos trabajemos con la misma idea. El manual dice:

Un widget es un objeto PHP que genera algo de HTML. El mismo tipo de widget se puede utilizar varias veces en la misma página (por ejemplo, el widget de texto). Los widgets pueden guardar datos en la base de datos (en la tabla de opciones).

Con esto en su lugar, echemos un vistazo al código de un widget personalizado, al menos un trozo de él, y veamos qué podemos deducir en lo que respecta a su naturaleza orientada a objetos.

La clase de widgets

Incluso antes de mirar el código, sabemos que habrá algún nivel de programación orientada a objetos simplemente porque la documentación nos dice que hagamos tres cosas:

1. Cree la clase de su widget ampliando la clase estándar WP_Widget y algunas de sus funciones.
2. Registre su widget para que esté disponible en la pantalla Widgets .
3. Asegúrese de que su tema tenga al menos un área de widgets en la que agregar los widgets.

En esta publicación, me centraré en el primer punto (aunque eventualmente veremos cómo introducimos nuestros widgets en un tema antes de que termine la serie).

Entonces, diseñemos el código tal como se presenta en la documentación y hablemos sobre lo que podemos aprender de él:

<?php
class AcmeWidget extends WP_Widget 
{ 
    public function __construct() 
    {
    }

    public function widget($args, $instance) 
    {
    }

    public function form($instance)
    {
    }

    public function update($newInstance, $oldInstance)
    {
    }
}

Primero, notamos que aunque definimos una clase (a la que podemos nombrar como queramos, a mi manera), debe extender WP_Widget. Esto significa que en el núcleo de WordPress hay una clase WP_Widget. Puede ver un desglose bien organizado del código fuente en esta página.

En segundo lugar, la palabra clave se extiende indica que estamos utilizando la herencia de PHP, que es un pilar fundamental de la programación orientada a objetos.

Tercero, hay cuatro funciones que debemos implementar, dos de las cuales requieren argumentos. Las funciones que debemos implementar son las siguientes:

• __construct() que es el constructor de clase básico. Aquí es donde tendremos que asegurarnos de que se llame al constructor de la clase principal, si lo hay, y luego inicializaremos las propiedades que consideremos necesarias para nuestro widget. Echaremos un vistazo a esto más adelante en la serie.
• widget() es responsable de generar los contenidos del widget que el usuario proporciona mediante la interfaz en el área administrativa. Acepta dos parámetros: $args y $instance. El parámetro $args es la información que se representará en la página, y $instance es una referencia a la instancia del widget (dado que se pueden representar varios widgets en una página).
• form() muestra la interfaz administrativa con la que interactúa el usuario para guiar lo que se genera en el front-end del sitio. También requiere el argumento $instance para que la información proporcionada sea para el widget real con el que está trabajando el usuario (frente a todas las instancias del widget).
• update() se usa para guardar los valores en la instancia actual del widget. Acepta dos argumentos. El primero es la nueva instancia del widget con valores actualizados que el usuario ha proporcionado (piense en actualizar el valor de un widget de texto activo) y el segundo argumento es el de la instancia anterior del widget o quizás la instancia anterior o quizás » la instancia que contenía los valores anteriores.»

Estas cuatro funciones deben implementarse como parte de la API de Widget, como parte de las funciones heredadas de la interfaz extendida y para producir la funcionalidad básica de un widget.

Esto no significa que no se pueda agregar más, pero de una buena manera orientada a objetos, probablemente sería mejor relegar ese comportamiento a otras clases. Pero veremos cómo hacerlo más adelante en la serie cuando estemos creando nuestro propio widget.

¿Cuáles son los puntos clave?

Para asegurarme de que tengo claro lo que se entendería de esta publicación, es lo siguiente:

• La API de Widgets está orientada a objetos. No solo está orientado a objetos porque usa una clase (aunque ciertamente es un buen punto de partida), sino también porque hereda la funcionalidad integrada en una clase base preexistente.
• Cada vez que heredamos el comportamiento de una clase base o una clase principal, obtenemos una funcionalidad predesarrollada de forma gratuita. Es realmente genial la programación orientada a objetos porque nos permite centrarnos específicamente en la lógica de programación que deseamos implementar.

Imagine por un momento que desea desarrollar un widget, pero cada vez que lo hace, tiene que escribir toda la funcionalidad para enganchar a WordPress para hacer la misma funcionalidad repetitiva repetitiva.

Aquí es donde entran en juego la herencia y la programación orientada a objetos. El código repetitivo se abstrae en una clase base, por lo que solo se escribe una vez y luego el código en el que queremos centrarnos queda para que lo implementemos.

Todo lo anterior es lo que debe entenderse al leer este paso inicial en el código fuente de una API básica orientada a objetos en WordPress.

¿Que sigue?

En la próxima publicación de esta serie, veremos la naturaleza orientada a objetos de la API de Widgets y qué cosas debería poder detectar de inmediato al leer el código.

Esto se debe a que es importante reconocer ciertos principios orientados a objetos en la práctica y esta es una buena manera de evaluar si puede hacerlo o no. Si lo eres, ¡genial! Luego continuará ayudando a desarrollar ese músculo. Si no, no te preocupes, todavía te ayuda a desarrollar ese músculo.

Y le será de gran utilidad a medida que continuamos avanzando más y más hacia el desarrollo de WordPress orientado a objetos a través de medios prácticos.

La teoría necesaria ha sido cubierta. Entonces, comencemos a ponerlo en práctica.