Contents
Introducción
Este artículo explica en detalle cómo estructurar un mu-plugin (must-use plugin) en WordPress que utilice un autoload en PHP. Verás buenas prácticas, opciones (autoloader manual o Composer), ejemplos de código listos para usar y recomendaciones de despliegue y seguridad. No incluiré el título principal, ya que se añadirá por el sistema donde se publicará el artículo.
¿Qué es un mu-plugin y por qué usar autoload?
Un mu-plugin es un plugin que WordPress carga automáticamente desde la carpeta wp-content/mu-plugins. Se usan para funcionalidades que deben estar siempre activas, por ejemplo integraciones críticas, configuraciones de red multisite o funcionalidades de seguridad.
Usar un autoload permite organizar el código en múltiples clases y archivos sin necesidad de requires manuales por cada archivo. Facilita la modularidad, las pruebas y la carga bajo demanda de clases cuando se instancian.
Ventajas de estructurar un mu-plugin con autoload
- Organización: separas responsabilidades por clases y namespaces.
- Escalabilidad: puedes añadir módulos sin tocar un archivo bootstrap grande.
- Mantenimiento: integración más sencilla con herramientas como Composer y PSR-4.
- Compatibilidad: reduce conflictos al encapsular código en espacios de nombres (namespaces).
Requisitos y consideraciones previas
- Acceso a wp-content/mu-plugins para subir el mu-plugin.
- Conocimiento básico de namespaces y autoloading en PHP.
- Si usas Composer, debes desplegar también la carpeta vendor o ejecutar composer install en el servidor.
- Ten en cuenta que mu-plugins se cargan muy temprano: utiliza hooks apropiados (por ejemplo muplugins_loaded o init) para ejecutar código que dependa de recursos cargados posteriormente.
Estructura recomendada del mu-plugin
Una estructura recomendada, simple y organizada, es:
- wp-content/mu-plugins/mi-mu-plugin.php (archivo bootstrap visible en la raíz de mu-plugins)
- wp-content/mu-plugins/mi-mu-plugin/
- composer.json (opcional, si usas Composer)
- vendor/ (si usas Composer puede incluirse en despliegue)
- src/
- Bootstrap.php (o similar)
- Namespace/
- SomeClass.php
- Controllers/…
- readme.txt (opcional)
Reglas importantes
- WordPress solo incluye ficheros ubicados directamente en la carpeta mu-plugins. Si necesitas carga desde subcarpetas, usa un archivo bootstrap en mu-plugins que incluya o registre el autoloader y cargue la estructura.
- Protege el acceso directo a los archivos PHP con una comprobación como if (!defined(WPINC)) die o if (!defined(ABSPATH)) exit.
- Prefiere namespaces para reducir el riesgo de colisiones con otros plugins o con el core.
- Usa hooks de WordPress apropiados: muplugins_loaded se dispara justo después de cargar los mu-plugins.
Ejemplo 1 — Bootstrap sencillo autoloader SPL (manual)
Este enfoque registra un autoloader básico y carga clases por namespace prefijal. Coloca un archivo bootstrap en la raíz del mu-plugin y referencia el src/.
Archivo mu-plugins/mi-mu-plugin.php (bootstrap público):
lt?php
// Evitar acceso directo
if ( ! defined( WPINC ) ) {
die
}
/
Punto de entrada público del mu-plugin.
Incluimos el bootstrap de la carpeta del plugin.
/
require_once __DIR__ . /mi-mu-plugin/bootstrap.php
Archivo mu-plugins/mi-mu-plugin/bootstrap.php (registro del autoloader y arranque):
lt?php
if ( ! defined( WPINC ) ) {
exit
}
// Definir base path constante
if ( ! defined( MM_PLUGIN_DIR ) ) {
define( MM_PLUGIN_DIR, __DIR__ )
}
// Registrar autoloader simple PSR-4-like
spl_autoload_register( function ( class ) {
// Namespace raíz esperado
prefix = MiMuPlugin
base_dir = MM_PLUGIN_DIR . /src/
// ¿la clase usa el prefijo?
len = strlen( prefix )
if ( strncmp( prefix, class, len ) !== 0 ) {
return
}
// Obtener la parte relativa
relative_class = substr( class, len )
// Reemplazar namespace por directorios y añadir .php
file = base_dir . str_replace( , /, relative_class ) . .php
if ( file_exists( file ) ) {
require file
}
} )
// Registrar inicialización en hook apropiado
add_action( muplugins_loaded, function() {
// Instanciar el cargador principal o ejecutar bootstrap de la app
if ( class_exists( MiMuPluginBootstrap ) ) {
MiMuPluginBootstrap::init()
}
} )
Ejemplo de clase en src/Bootstrap.php:
lt?php
namespace MiMuPlugin
class Bootstrap {
public static function init() {
// Código de inicialización: registrar hooks, cargar dependencias, etc.
add_action( init, [ __CLASS__, on_init ] )
}
public static function on_init() {
// Código que necesita WP más cargado (taxonomías, CPTs, etc.)
}
}
Notas sobre este enfoque
- Simple de implementar, no depende de Composer.
- Admite PSR-4 básico si respetas el namespace y la estructura de carpetas.
- Si necesitas características avanzadas (autocarga de vendor, polyfills), mejor usar Composer.
Ejemplo 2 — Usando Composer (recomendado para proyectos complejos)
Composer facilita la autogestión de dependencias y el autoload PSR-4. La idea es tener el composer.json dentro de la carpeta del mu-plugin (o en el proyecto y ajustar rutas) y exponer un único archivo en la raíz de mu-plugins que incluya vendor/autoload.php.
Ejemplo de composer.json:
{
name: mi/mi-mu-plugin,
description: Mi mu-plugin con autoload PSR-4,
type: library,
autoload: {
psr-4: {
MiMuPlugin: src/
}
},
require: {}
}
Comandos para instalar dependencias en desarrollo (terminal):
composer install
Archivo público mu-plugins/mi-mu-plugin.php:
lt?php
if ( ! defined( WPINC ) ) {
die
}
plugin_dir = __DIR__ . /mi-mu-plugin
// Incluir autoload de Composer (asegúrate de que vendor exista o lo despliegues)
autoload = plugin_dir . /vendor/autoload.php
if ( file_exists( autoload ) ) {
require_once autoload
}
// Iniciar la aplicación
if ( class_exists( MiMuPluginBootstrap ) ) {
add_action( muplugins_loaded, function() {
MiMuPluginBootstrap::init()
} )
}
Bootstrap y clases quedan en src/ y se autoload con PSR-4. Con Composer puedes añadir dependencias externas de forma controlada.
Consejos de despliegue con Composer
- Opción A: Ejecutar composer install en el servidor (requiere composer en servidor).
- Opción B: Ejecutar composer install en tu entorno local y subir la carpeta vendor dentro de mi-mu-plugin al servidor.
- Evita incluir archivos innecesarios en producción puedes usar composer install –no-dev –optimize-autoloader.
Buenas prácticas y seguridad
- Comprobar definidos como WPINC o ABSPATH para evitar ejecución fuera de WP.
- Encapsular funcionalidad en namespaces y clases en lugar de declarar funciones globales.
- Evitar side-effects en tiempo de carga: preferir registrar hooks en lugar de ejecutar lógica intensa en el include.
- Si tu mu-plugin expone endpoints o callbacks, sanitiza y valida siempre entradas (escapar salidas con esc_html, esc_attr, etc.).
- Controla la compatibilidad con versiones de PHP: declara la versión mínima requerida en composer.json o documenta la compatibilidad.
Tests, debugging y mantenimiento
- Usa autoload para facilitar pruebas unitarias: separa lógica de presentación para poder testear clases mediante PHPUnit.
- Para debugging local, activa WP_DEBUG y logs. No publiques archivos de debug en producción.
- Mantén actualizado composer.lock y documenta el proceso de despliegue para que el equipo sepa cómo reinstalar dependencias.
Consideraciones finales y checklist de implementación
- Crear archivo público en wp-content/mu-plugins que actúe como bootstrap/entry-point.
- Registrar un autoloader (manual o Composer) desde el bootstrap.
- Estructurar src/ con namespaces y seguir PSR-4 si usas Composer.
- Proteger archivos con comprobación de constante WP (WPINC o ABSPATH).
- Registrar inicialización en hooks adecuados (muplugins_loaded, init, etc.).
- Empaquetar vendor o ejecutar composer install en despliegue.
Recursos útiles
Con la estructura descrita y los ejemplos provistos puedes construir un mu-plugin modular y mantenible que aproveche autoloading para facilitar escalabilidad y compatibilidad con prácticas modernas de PHP. Implementa nombres de espacio claros, protege tus archivos y elige Composer cuando tu proyecto lo requiera.
|
|
Acepto donaciones de BAT's mediante el navegador Brave 🙂 |