Actualizaciones automáticas de tus plugins desde tu Repositorio privado

SumaPress Boilerplate OOP

Completo boilerplate orientado a objetos OOP para que puedas crear tus propios plugins para WordPress del modo más eficiente, ya que está preparado para realizar tests, con namespaces, autoloader de clases y además trae integrado Webpack: es6, sass, live server, control estándares WP, uglify, minify, etc

Demo LIVE SERVER + control errores + tests

Este plugin base para WordPress es un buen punto de partida para crear tus propios plugins siguiendo una buena estructura de trabajo y buenas prácticas recomendadas.

Boilerplate

Se trata de un plugin base con la estructura necesaria para empezar a crear tu propio plugin bien organizado, siguiendo buenas prácticas y con potencial para crear cualquier desarrollo avanzado con WordPress.

OOP

Significa que está estructurado para seguir con PHP una programación orientada a objetos POO u OOP en inglés.

Es un «Boilerplate» que se basa en la API de plugins de WordPress, y trata de seguir los estándares de código WordPress Coding Standards y también los estándares de documentación.

En definitiva, es un plugin base para crear plugins avanzados para WordPress que se ha realizado desde cero siguiendo la idea del anterior boilerplate: WordPress Plugin Boilerplate OOP con el que se lanzaron nuestros primeros plugins subidos al repositorio WordPress.org, pero actualizado a un tipo de desarrollo y herramientas más avanzadas, y por tanto ya mucho más alejado del fork inicial realizado desde el mítico WPPB de Tom McFarlin


Estructura de carpetas y ficheros del plugin OOP:

Carpetas y ficheros de SumaPress Boilerplate OOP
  • /gutenberg –> aquí situaremos todo lo relacionado con el nuevo editor de WordPress para poder crear bloques para Gutenberg
  • /core –> integra todas las llamadas para conectarnos con el core de WordPress mediante los hooks: acciones y filtros, así como el autoloader de clases que evita que tengamos que incluir los ficheros del plugin
  • /admin –> para todas las funciones con destino el admin
  • /web –> para todas las funciones a presentar en la parte pública o visible de la web
  • /includes –> para situar todas las funcionalidades útiles tanto para el back-end como para el front-end, donde por ejemplo situar las funciones de ayuda y/o librerias externas
  • /setup –> incluye una clase donde poder configurar opciones base del plugin que aparecen disponibles en el resto de clases del plugin, así como las clases para las acciones de activación y desactivación
  • /assets –> en su interior están las carpetas CSS, IMG y JS con los ficheros finales que se cargan por el plugin y que son creados por webpack en base a los diferentes ficheros creados en el plugin
  • /languages –> para situar el fichero .pot de i18n
  • /tests –> carpeta preparada con los ficheros de WP necesarios para realizar tests del plugin con una base de datos aparte y varios tests de ejemplo
Tests de ejemplo incorporados en el plugin

Comandos de desarrollo disponibles:

Los siguientes comandos se lanzan desde la terminal y situados en la carpeta del plugin en desarrollo:

  • npm start –> este comando se encarga de inicializar todo el entorno de trabajo para desarrollo: instala lo correspondiente a composer, también los paquetes de node y por último realiza el setup de WP para seguir sus estándares en la parte de PHP
  • npm run updates –> es el comando que te permite actualizar en todo momento las dependencias instaladas con composer y node
  • npm test –> con solo escribir este comando se ejecutan todos los tests que estén preparados en la carpeta tests
  • npm run dev –> inicia el modo desarrollo abriendo el navegador como un LIVE SERVER que se refresca cada vez que guardas un fichero de PHP, SCSS o JS, lanzandose además todas las funciones de Webpack que crean los correspondientes ficheros en modo dev en la carpeta assets
  • npm run production –> prepara en la carpeta assets los ficheros unidos y minificados
  • npm -s run error:php NOMBRE CARPETA –> muestra en el terminal los errores PHP que siguiendo los estándares de WordPress considera que hay que arreglar en la citada carpeta
  • npm -s run fix:php NOMBRE CARPETA –> similar al anterior comando pero directamente trata de corregirlos de modo automático
  • npm -s run error:css NOMBRE CARPETA –> muestra en el terminal los errores CSS que siguiendo los estándares de WordPress considera que hay que arreglar en la citada carpeta
  • npm -s run fix:css NOMBRE CARPETA –> similar al anterior comando pero directamente trata de corregirlos de modo automático
  • npm -s run error:js NOMBRE CARPETA –> muestra en el terminal los errores JS que siguiendo los estándares de WordPress considera que hay que arreglar en la citada carpeta
  • npm -s run fix:js NOMBRE CARPETA –> similar al anterior comando pero directamente trata de corregirlos de modo automático
  • npm run pot –> si dispones de wp-cli instalado y preparado para ejecutarse como wp desde la terminal, este comando lanza la correspondiente instrucción para crear el fichero pot de i18n en la carpeta languages del plugin
  • php make zip –> crea un zip limpio del plugin (necesario que tengas añadido php al path de tu equipo) sin las carpetas y ficheros propios de desarrollo
  • php make class NOMBRE-CLASE NOMBRE-CARPETA –> crea un nuevo fichero con el nombre dado dentro de la carpeta indicada y con una base de código listo para trabajar en OOP. –> Recuerda que no es necesario incluir este nuevo fichero creado ya que de ello se encarga el autoloader del plugin nada más llames esta clase.
Ejemplo corrección automática

Para que funcionen los anteriores comandos, es necesario que trabajes en local con un editor de código como Visual Studio Code que trae terminal integrada, pero también disponer de varias herramientas instaladas en el equipo de desarrollo: Composer, Node y opcionalmente wp-cli, además de un entorno de desarollo como: XAMPP, Laragon, Local by Flywheel, u otros como Vagrant o Docker.

Importante: para que en el modo npm run dev funcione el LIVE SERVER tienes que indicar la url de desarrollo donde se encuentra el plugin instalado en el fichero webpack.config.js en la parte proxy como se indica en la imagen:

Configuración proxy LIVE SERVER en fichero: webpack.config.js

Carpeta Gutenberg

La carpeta Gutenberg tiene de modo aislado y diferenciado todo lo necesario para crear bloques para el nuevo editor de bloques de WordPress existente desde la versión 5.0. y basándose en la referencia create-guten-block. Esto nos permite tener actualizaciones sin problemas de esta única dependencia cgb-scripts.

Puedes crear rápidamente nuevos bloques para Gutenberg basándote en los bloques de ejemplo proporcionados. Puedes copiar y pegar cada carpeta dentro de src que coincide cada una con un bloque:

  • Copiar desde –> \ gutenberg \ src \ basic
  • Pegar como -> \ gutenberg \ src \ nombre-bloque

IMPORTANTE: recuerda incluir las nuevas referencias a las nuevas subcarpetas en el archivo \ gutenberg \ src \ blocks.js y manten el nombre del archivo JS principal de cada nuevo bloque como index.js para una referencia más fácil desde el citado archivo blocks.js

Para que todo el código se compile correctamente hacia la carpeta de distribución situada en \ gutenberg \ dist es necesario:

  1. Situa el terminal en la carpeta \ gutenberg y ejecutar npm install
  2. npm-start para modo desarrollo: observa cualquier cambio cuando guardas un fichero, compila todo y te informa de cualquier error.
  3. npm run build para terminar el modo desarrollo y construir el codigo final para producción en la carpeta dist (la cual no debes tocar)

Todo el código compilado y comprimido que se situa dentro de la citada carpeta \ gutenberg \ dist ya está todo bien llamado/encolado (enqueue) por este plugin base que estamos presentado aquí. Puedes comprobarlo si miras el código de los siguiente ficheros:

  • \ core \ class-core.php
  • \ gutenberg \ class-gutenberg.php

En los citados ficheros también podrás observar como ya hay una serie de funciones preparadas para interactuar con este nuevo editor de bloques de WordPress:

  • Crea una nueva categoría donde se situan los bloques del plugin.
  • Ejemplo bloque dinámico y bloque con custom fields.
  • Función para definir plantilla de bloques en los custom post types.
  • Función para limitar los bloques dentro de un custom post type.
  • Función para limitar donde aparece o no el nuevo editor de bloques.

La parte de bloques se mantiene su funcionamiento en esta carpeta Gutenberg de modo separado al resto del plugin para aprovechar el desarrollo en base a las dependencias y modo de trabajo realizado por Create-guten-block de tal modo que se pueda trabajar con este plugin pero siguiendo este estándar que evoluciona con el desarrollo de Gutenberg & WordPress y sin interferencias con el resto del plugin y su configuración base.

IMPORTANTE: en el momento de centrarse en la parte de bloques recuerda pasar el terminal a la carpeta Gutenberg para poder seguir desde ahí el modo de trabajo planteado por Ahmadawais y todos su partners presentados en la página de Github enlazada.

Gracias a esta única dependencia que se actualiza en todo momento, puedes trabajar dentro del plugin en la carpeta Gutenberg con las últimas herramientas de desarrollo web como Sass, React, JSX y ES6 y de modo integrado con WordPress, pero sin interferencia con el resto del plugin.

NO te pierdas las novedades de este repositorio de plugins