WPCS 3.4.0: chequeos hasta WordPress 7.0.0

En pocas palabras: WordPress Coding Standards 3.4.0 ya está disponible y, por primera vez, verifica código contra las funciones introducidas en WordPress 7.0.0. Esta actualización incluye nuevos sniffs para detectar APIs obsoletas y mejora la documentación de 14 reglas.

WordPress Coding Standards 3.4.0 llegó y trae soporte para verificar funcionalidades de WordPress hasta la versión 7.0.0. El equipo de WPCS actualizó los sniffs de detección de código deprecado, sumó un nuevo co-maintainer, agregó documentación de usuario para 14 reglas y metió ajustes en dependencias clave. Si venías usando versiones anteriores, esta actualización te permite realizar comprobaciones que antes no existían contra características nuevas del core.

WordPress Coding Standards (WPCS) es una colección de reglas de PHP_CodeSniffer que verifican automáticamente que tu código de WordPress —temas, plugins, snippets— cumpla con las convenciones oficiales del core. Funciona como un corrector automático de estilo y buenas prácticas: detecta desde funciones deprecadas hasta errores de seguridad, pasando por la nomenclatura de variables globales. La versión 3.4.0 extendió esos chequeos para cubrir características introducidas en WordPress 7.0.0.

WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg y Mike Little, desarrollado por una comunidad global, utilizado para crear y administrar sitios web y blogs.

¿Qué son los WordPress Coding Standards y por qué importan en 2026?

WPCS es, en criollo, el inspector de calidad que te dice si tu código sigue las reglas del ecosistema WordPress. Se apoya en PHP_CodeSniffer —el motor que parsea PHP y ejecuta las reglas— y te escupe warnings y errores cada vez que te desviás de lo que el core espera. La versión 3.4.0 no es un cambio de paradigma (no esperes una reescritura total), pero sí afina la puntería para que las verificaciones se alineen con lo último que salió en WordPress 7.0.

Si alguna vez heredaste un plugin legacy y lo pasaste por WPCS, sabés que da miedo la cantidad de cosas que salen. Pero también sabés que después de limpiar todo, el código queda más mantenible y menos propenso a romperse cuando WordPress avanza de versión (y creedme, avanza).

¿Cuáles son las principales novedades de WordPressCS 3.4.0?

El changelog de esta release no es kilométrico, pero tiene varios ajustes puntuales que suman. Acá va lo que cambió, sin adornos. Esto se conecta con lo que analizamos en conocer la comunidad de WordPress.

Soporte de detección de features deprecadas hasta WP 7.0.0

El valor por defecto para los sniffs que detectan características deprecadas de WordPress se actualizó a la versión 7.0.0. Esto significa que WPCS ahora te avisa si estás usando funciones, clases o constantes que WordPress marcó como obsoletas en cualquier release hasta la 7.0. El sniff WordPress.NamingConventions.PrefixAllGlobals también se actualizó para reconocer funciones pluggables introducidas en el core hasta WP 7.0.0. O sea: si tu plugin usa wp_rand() o alguna otra función pluggable nueva, WPCS lo sabe y no te va a gritar por prefijarla mal.

Nueva propiedad en ArrayDeclarationSpacing

El sniff WordPress.Arrays.ArrayDeclarationSpacing estrena la propiedad allow_single_item_single_line_explicit_key_arrays. Esta reemplaza a la vieja allow_single_item_single_line_associative_arrays, que quedó deprecada. ¿El cambio? Ahora podés declarar arrays con keys explícitas en una sola línea sin que WPCS te llore, incluso si no son técnicamente asociativos en el sentido clásico. Un detalle chiquito pero que ahorra fricción cuando trabajás con arrays de configuración inline.

Documentación de usuario para 14 sniffs

Esta es de las que más valoro. WPCS históricamente tenía buena documentación técnica, pero la documentación de usuario —la que explica qué hace cada sniff y cómo configurarlo— dejaba bastante que desear. En 3.4.0 se agregó documentación de usuario para catorce sniffs, entre ellos:

• WordPress.Arrays.ArrayDeclarationSpacing
• WordPress.CodeAnalysis.AssignmentInTernaryCondition
• WordPress.DB.RestrictedClasses
• WordPress.DB.DirectDatabaseQuery
• WordPress.DB.RestrictedFunctions
• WordPress.DB.SlowDBQuery
• WordPress.PHP.DevelopmentFunctions
• WordPress.PHP.NoSilencedErrors
• WordPress.PHP.PregQuoteDelimiter
• WordPress.PHP.RestrictedPHPFunctions
• WordPress.Security.PluginMenuSlug
• WordPress.WP.AlternativeFunctions
• WordPress.WP.DiscouragedConstants
• WordPress.WP.GlobalVariablesOverride

Esa documentación se expone con el flag --generator=... desde la línea de comandos. Si liderás un equipo de desarrollo, esto te permite generar HTML o Markdown con las reglas que aplican en tu proyecto y compartirlas sin tener que escribir una wiki a mano (que después nadie lee).

Actualización de dependencias y nuevo co-maintainer

PHP_CodeSniffer subió a la versión 3.13.5 (estaba en 3.13.4) y PHPCSUtils —la librería de utilidades que usa WPCS internamente— saltó de 1.1.0 a 1.2.2. Nada rompedor. Además, el equipo le dio la bienvenida a un nuevo co-maintainer (spoiler: el nombre no se cargó en el release de GitHub, pero la noticia está confirmada en el changelog). Sumar gente al proyecto es buena señal: más ojos para revisar reglas nuevas y menos riesgo de que el proyecto se estanque. En crear páginas de aterrizaje efectivas profundizamos sobre esto.

¿Cómo instalar o actualizar WordPressCS 3.4.0?

Si ya usás Composer en tu proyecto —y si no lo hacés, deberías—, actualizar es un comando de una línea. Abrí la terminal, parate en la raíz del proyecto y ejecutá:

composer require wp-coding-standards/wpcs:^3.4

Eso baja la versión 3.4.0 y la deja bloqueada dentro del rango ^3.4 (cualquier 3.x.x que no rompa compatibilidad). Para verificar que la instalación funcionó, corré:

vendor/bin/phpcs --config-show

Si phpcs no está en tu proyecto, instalalo con composer require squizlabs/php_codesniffer antes de meter WPCS. Después registrás el estándar con vendor/bin/phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs y listo.

Para entornos de CI/CD, meté el comando en tu pipeline de GitHub Actions o GitLab CI justo después del checkout. Algo así como vendor/bin/phpcs --standard=WordPress --extensions=php ./src/ y que el build falle si hay errores. Si tu proyecto está hosteado en un hosting WordPress con soporte para SSH, podés correr los chequeos directamente en el servidor antes de deployar a producción.

Comparativa: WPCS 3.3.x vs 3.4.0

Característica	WPCS 3.3.x	WPCS 3.4.0
Detección de features deprecadas	Hasta WP 6.x	Hasta WP 7.0.0
PHP_CodeSniffer	3.13.4	3.13.5
PHPCSUtils	1.1.0	1.2.2
Documentación de usuario	Limitada a unos pocos sniffs	14 sniffs documentados, generables con –generator
ArrayDeclarationSpacing	allow_single_item_single_line_associative_arrays	allow_single_item_single_line_explicit_key_arrays (la vieja deprecada)
PrefixAllGlobals	Funciones pluggables hasta WP 6.x	Funciones pluggables hasta WP 7.0.0

¿Cómo afecta WPCS 3.4.0 a los desarrolladores de temas y plugins?

La respuesta corta: si tu plugin o theme soporta versiones viejas de WordPress —ponele, WP 5.5 o 6.0— y también querés compatibilidad con WP 7.0, WPCS 3.4.0 te va a marcar funciones que usaste sin drama durante años pero que ahora están deprecadas. No es que tu código dejó de funcionar de golpe (las funciones deprecadas suelen mantenerse un tiempo largo), pero es mejor enterarte en desarrollo que en producción con un PHP deprecated notice llenando el log.

El sniff WordPress.WP.ClassNameCase también recibió ajustes (el changelog se cortó en GitHub, pero la mención está ahí). Si estás acostumbrado a llamar clases de WordPress con mayúsculas inconsistentes, WPCS te va a señalar el desastre. Y si tenés queries directas a la base de datos —todos tenemos alguna—, los sniffs RestrictedClasses, DirectDatabaseQuery y SlowDBQuery ahora tienen documentación clara que podés consultar sin ponerte a leer el código fuente del sniff. Cubrimos ese tema en detalle en usar un entorno de staging seguro.

¿Cómo generar reportes detallados con los nuevos sniff?

El flag --generator=... es el verdadero golazo de esta release para equipos. Funciona así: corrés vendor/bin/phpcs --standard=WordPress --generator=html y te genera un HTML con la documentación de todos los sniffs activos. También podés generar Markdown con --generator=markdown. Esto es utilísimo cuando tenés que onboardear devs nuevos o cuando querés que el equipo de QA entienda por qué el pipeline rechazó un commit.

Ponele que tenés un plugin con 200 archivos PHP y querés filtrar solo los errores de DirectDatabaseQuery. Corrés:

vendor/bin/phpcs --standard=WordPress --sniffs=WordPress.DB.DirectDatabaseQuery ./src/

Y si querés la documentación de ese sniff específico, --generator=html --sniffs=WordPress.DB.DirectDatabaseQuery te escupe un HTML enfocado en esa regla. ¿Alguien lo pidió? No sé, pero ahora que existe, vas a ver cómo lo adoptás sin darte cuenta.

Errores comunes al usar WPCS (y cómo evitarlos)

No configurar el installed_paths correctamente

El error más clásico: instalás WPCS con Composer, corrés phpcs y te dice que el estándar «WordPress» no existe. Es porque no registraste el path. Solución: phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs. Hacelo una vez y phpcs lo recuerda en su configuración global.

Correr WPCS contra código legacy sin phpcs.xml

Sin un archivo de configuración, WPCS aplica todas las reglas por defecto. Si tenés un plugin que nació en la época de WordPress 3.2, te van a saltar 4000 errores. Creá un phpcs.xml.dist en la raíz del proyecto, configurá el estándar base y excluí los sniffs que no apliquen a tu contexto. La documentación nueva de los 14 sniffs justo ayuda a decidir cuáles dejar y cuáles no. Relacionado: reparar enlaces rotos fácilmente.

Ignorar los warnings de deprecación de la propiedad de ArrayDeclarationSpacing

Si tu phpcs.xml usa allow_single_item_single_line_associative_arrays, WPCS 3.4.0 te va a tirar un aviso de que esa propiedad está deprecada. No es un error que rompa el build, pero si lo ignorás, cuando saquen la propiedad en una versión futura tu configuración va a fallar silenciosamente. Cambiala a allow_single_item_single_line_explicit_key_arrays ahora.

Preguntas Frecuentes

¿Qué es WordPress Coding Standards 3.4.0?

Es la versión más reciente del conjunto de reglas de PHP_CodeSniffer para WordPress. Incluye verificaciones de código actualizadas hasta WordPress 7.0.0, documentación nueva para 14 sniffs, una propiedad de configuración renombrada en ArrayDeclarationSpacing y actualizaciones de dependencias internas.

¿Cómo actualizar a WPCS 3.4.0?

Con Composer: composer require wp-coding-standards/wpcs:^3.4. Si no usás Composer, descargá el release desde GitHub y actualizá manualmente la carpeta de estándares en tu instalación de PHP_CodeSniffer. Verificá la versión con vendor/bin/phpcs --version.

¿WPCS 3.4.0 es compatible con PHP 8?

Sí. WPCS 3.x requiere PHP 7.4 o superior y es totalmente compatible con PHP 8.x, incluyendo 8.2 y 8.3. Las dependencias PHP_CodeSniffer 3.13.5 y PHPCSUtils 1.2.2 también tienen soporte completo para PHP 8.

¿Vale la pena actualizar a WPCS 3.4.0 si mi proyecto usa WordPress 6.x?

Vale la pena por dos razones. Primero, la documentación de usuario nueva para 14 sniffs te va a ahorrar tiempo cuando necesités entender qué regla falló y por qué. Segundo, tener la detección de features deprecadas hasta WP 7.0.0 te prepara para la migración antes de que sea urgente —y en WordPress, las migraciones urgentes nunca salen bien.

¿Cómo solucionar errores de WPCS 3.4.0 en CI/CD?

Lo más común es que la actualización active nuevos sniffs en tu pipeline y el build rompa. Revisá el log de phpcs, identificá los sniffs que fallan, y decidí si corregís el código o ajustás la configuración en phpcs.xml.dist. La documentación nueva con --generator=html te ayuda a entender qué espera cada sniff.

Conclusión

WPCS 3.4.0 no es un terremoto, pero sí un ajuste necesario. La ampliación de cobertura hasta WordPress 7.0.0, la documentación de usuario para 14 sniffs y el recambio de la propiedad deprecada en ArrayDeclarationSpacing son cambios chicos con impacto real en el día a día. Si mantenés código de WordPress en 2026, actualizar es un trámite de cinco minutos que te va a ahorrar dolores de cabeza cuando tu equipo empiece a tocar features nuevas del core.

Lo que me gusta de esta release es que no intenta reinventar nada. Afina lo que ya existe, documenta lo que estaba oscuro, y se prepara para lo que viene. En un ecosistema donde cada release de WordPress puede romper cosas, tener un estándar de código que evoluciona al mismo ritmo es un lujo que no todos los CMS tienen (mirá a Drupal, sin ir más lejos).

Fuentes

• Release oficial de WordPress Coding Standards 3.4.0 en GitHub — changelog completo con cambios, dependencias y nuevos sniffs
• Repositorio oficial de WordPress Coding Standards — documentación del proyecto, guía de instalación y configuración
• PHP_CodeSniffer en GitHub — motor subyacente que ejecuta las reglas de WPCS