Advertisement
  1. Code
  2. Widgets

Escribir widgets de WordPress mantenibles: Parte 1 de 2

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Luis Chiabrera (you can also view the original English article)

Lo mejor de Wptuts 2011: cada semana hasta enero, volveremos a visitar algunas de nuestras publicaciones favoritas de 2011. El desarrollo de complementos a menudo se puede sentir como el salvaje oeste si está creando algo desde cero sin una repetición o un complemento similar para funcionar from - La serie de partes de Tom's 2 sobre Widgets / Complementos de WordPress Mantenibles ofrece algunas pautas prácticas que deben mantenerlo en la pista.

Cuando se trata del desarrollo de software, los marcos y las bibliotecas son populares porque son útiles, ¿verdad? Proporcionan una forma coherente de escribir y organizar el código con la esperanza de facilitar el desarrollo y el mantenimiento.


La cuestión es que estos mismos principios que se aplican a sistemas más grandes de nivel empresarial son igual de aplicables a proyectos más pequeños, como los complementos de WordPress, desarrollados por pequeños equipos. Y así como los sistemas más grandes están llenos de partes móviles, tal es el caso de los complementos de WordPress.

Por ejemplo: tiene el código central que se encarga de comunicarse con WordPress (a través de filtros, acciones y enlaces), paneles de administración, vistas del lado del cliente, archivos JavaScript, hojas de estilo, archivos de localización, etc. Se logran utilizando al menos cuatro lenguajes de programación diferentes.

Durante mi tiempo dedicado al desarrollo de WordPress, he creado algunas placas de calderas que utilizo para comenzar cada uno de mis proyectos. Este tutorial le dará un vistazo a mi código de WordPress Widget Boiler, cómo aprovecharlo en nuevos proyectos, y una aplicación de ejemplo con la esperanza de ayudarlo a tener su próximo proyecto de WordPress con un comienzo sólido.


Un Widget repetitivo

Organización

Cuando se trata de desarrollo, normalmente trato de mantener las cosas lo más simples posible planificando solo las funciones necesarias; Sin embargo, este es un caso en el que pretendo ser exhaustivo. Casi siempre es más fácil comenzar a planificar una placa de calderas cuando conoce todos los componentes que pueden entrar en el sistema.

Un plugin puede consistir en lo siguiente:

  • Código del plugin del núcleo
  • Hojas de estilo
  • Scripts Java
  • Archivos de localización
  • Margen
  • Imágenes

Teniendo en cuenta todo lo anterior, el directorio de widgets de placas se presenta así:

Veremos cada directorio en detalle más adelante en este artículo.

El esqueleto

Además de la organización de archivos, también me gusta quitar el código utilizado para controlar el widget. El códice de WordPress [1] tiene una explicación detallada de la API de widgets [2] y, como hay una forma sugerida de crearlos, trato de seguirlo.

Además, soy un fanático de escribir mi código de manera orientada a objetos, junto con comentarios de código para ayudar a explicar lo que está sucediendo en cada área del código. Como tal, el código inicial del widget se ve así:

Observe que hay una serie de TODO en todo el código. Estos son útiles especialmente en el contexto de escribir su código en la parte superior de la placa de calderas.

Tenga en cuenta que también hay tres secciones principales de código:

  1. Constructor. Esta función es responsable de inicializar el widget, importar archivos de localización e incluir fuentes de JavaScript y hojas de estilo.
  2. Funciones API. Estas funciones son las tres funciones necesarias para administrar, visualizar y actualizar el widget.
  3. Funciones de ayuda. Estas son funciones privadas que utilizo para ayudar con tareas a menudo repetitivas o requeridas.

Las tres funciones más importantes mencionadas anteriormente, las funciones de la API son necesarias para desarrollar su complemento.

  1. widget () extrae los valores almacenados y representa la vista pública
  2. update () es responsable de actualizar los valores guardados previamente con los valores proporcionados por el usuario
  3. form () representa el formulario de administración y proporciona la funcionalidad necesaria para almacenar nuevos valores.

Debido a que los complementos a menudo se dividen entre la funcionalidad de administración y la funcionalidad orientada al cliente, divido mi fuente de JavaScript, las hojas de estilo y el HTML en consecuencia. Nombro estos archivos como corresponde y los apago apropiadamente:

Fuentes de JavaScript:

admin.js:

widget.js:

Hojas de estilo:

admin.css:

widget.css:

Puntos de vista:

Fácil, ¿verdad? Puede ver (¡y bifurcar!) Esta placa de repetición completa, incluidos los archivos de localización y el archivo README en GitHub.

Ahora hay un lugar para todo y cuando llega el momento de enviarlo, simplemente excluye ciertos archivos de la compilación final.


Un ejemplo de trabajo con tus redes sociales.

Cuando se trata de la programación, la práctica ayuda a aprender un nuevo idioma o sugerencia, así que aquí hay un ejemplo rápido de cómo usar la placa de arriba para crear un widget simple que facilita compartir tus enlaces de Twitter, Facebook y Google+.

Primero, listaremos los requisitos:

  • Una vista de administración para ingresar valores. Esto incluye marcas y estilos.
  • Una vista pública para mostrar enlaces a redes sociales. Esto también incluye marcas y estilos.
  • Opciones para almacenar un nombre de usuario de Twitter, nombre de usuario de Facebook e ID de Google+

En segundo lugar, abramos la placa de calderas y comencemos a retirar las piezas necesarias.

En primer lugar, definimos los nombres de los complementos, slug y valores locales. Estos se usan repetidamente a lo largo del código, por lo que es bueno almacenarlos como constantes para recuperarlos fácilmente. Localice la función init_plugin_constants () y asegúrese de que su código tenga este aspecto:

Después de eso, tenemos que preparar el constructor:

Y apaga las funciones de la API:

La versión final del plugin debería verse así:

A continuación, vamos a agregar algunos estilos al formulario de administración. Localice /css/admin.css y agregue el siguiente código:

Y escribamos el marcado que representará la vista del formulario de administración:

Por último, necesitamos escribir alguna marca para representar la vista pública del widget cuando esté en vivo en el blog real:

Hecho y hecho. No está mal, ¿eh? Una buena cantidad de trabajo y funcionalidad hecho relativamente rápido.

Puede descargar el código fuente de trabajo (incluido un README asociado) para este widget en GitHub o aquí mismo en Wptuts.

En última instancia, mantener un proyecto de software equivale a intentar organizar la complejidad. Aunque la placa de arriba no es * la * forma en que organiza o administra el código, es una forma * efectiva * de organizar el código y he encontrado que es extremadamente útil en muchos de mis proyectos y espero que le ayude en su trabajo futuro.

Recuerde, puede obtener una copia de la plantilla y del proyecto de ejemplo de sus respectivos repositorios de GitHub. También recomiendo encarecidamente marcar el códice de WordPress [1]. Es un recurso tremendo para cualquiera que busque hacer un desarrollo avanzado de WordPress.

  1. http://codex.wordpress.org
  2. http://codex.wordpress.org/Widgets_API

Pasando a la segunda parte ...

¡Echa un vistazo a la segunda parte de esta serie de tutoriales en la que profundizaremos en la creación de complementos mantenibles! Veremos cómo utilizar hooks dentro de WordPress, y luego usaremos nuestro boilerplate para crear otro complemento útil. Listo para la segunda parte?

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.