Desarrollo WordPress para principiantes: temas, plugins y entorno local

Desarrollo WordPress para principiantes: temas, plugins y entorno local

Última verificación: 15 de octubre de 2026
15 min de lectura
Tutorial
500+ proyectos WP
Desarrollador full-stack

#Tutorial de desarrollo WordPress: guía completa para principiantes en 2026

Esta guía es el manual práctico que me habría gustado tener cuando empecé a entregar sitios WordPress en 2006. No da nada por supuesto salvo un equipo limpio y ganas de leer documentación. Al terminar tendrás un entorno local, un tema de bloques funcional, un plugin escrito por ti y una vía de despliegue. Sin magia y sin atajos que se rompen más adelante.

La siguiente etapa está en el pilar de servicios de WordPress headless y la capa de front-end en la guía de Tailwind CSS en el desarrollo WordPress.

#En resumen

  • WordPress 7.1 es la versión actual en octubre de 2026 y WordPress.org recomienda PHP 8.3 o superior.
  • Temas de bloques, theme.json y un poco de PHP forman el kit de inicio moderno.
  • Composer, WP-CLI y un entorno local basado en Docker no son opcionales.
  • Headless es una habilidad de segunda etapa, no un punto de partida.
  • La forma más rápida de aprender es entregar un sitio real (pequeño), no acumular un portafolio de tutoriales a medias.

#Qué es WordPress en 2026

WordPress es un sistema de gestión de contenidos de código abierto que impulsa una parte considerable de los sitios web del mundo. Funciona sobre PHP y guarda el contenido en una base de datos (normalmente MySQL o MariaDB). Sobre el núcleo conviven dos modelos de extensión: los temas (controlan la presentación y la experiencia editorial) y los plugins (añaden funcionalidades). El editor de bloques (Gutenberg), incluido en el núcleo desde WordPress 5.0 en 2018, es la interfaz editorial por defecto y el terreno principal del desarrollo nuevo.

Qué ha cambiado en 2026 respecto a 2018: el editor de bloques ha madurado hasta el Full Site Editing (FSE), los temas de bloques han sustituido a los clásicos en los proyectos nuevos, theme.json se ha convertido en la fuente de verdad de los tokens de diseño y la REST API junto con WPGraphQL ha hecho viables los front-ends headless a gran escala. La versión recomendada de PHP ha subido a la 8.3; la siguiente sección recoge los requisitos completos del servidor.

#Requisitos de servidor de WordPress en 2026

WordPress.org publica la configuración de hosting recomendada en su página de requisitos: PHP 8.3 o superior, MySQL 8.0 o superior o MariaDB 10.11 o superior, y soporte para HTTPS. La misma página indica que WordPress todavía funciona con PHP 7.4 y MySQL 5.5.5, y advierte de que esas versiones han llegado al final de su vida útil y pueden exponer el sitio a vulnerabilidades de seguridad. En la práctica: configura tu entorno local con las versiones recomendadas y, si el servidor de un cliente usa una versión de PHP más antigua, comunícalo antes de escribir código para él. En el momento de escribir esto (octubre de 2026), la versión actual es WordPress 7.1, según la API de versiones de WordPress.org.

#WordPress headless o tradicional para principiantes

Un error frecuente en 2026 es empezar por headless. No lo hagas. WordPress headless es una arquitectura por capas: un back-end (WordPress), un front-end separado (Astro, Next.js, etc.) y una plataforma de alojamiento (Cloudflare Workers, Vercel, etc.). Quien aprende las tres a la vez no entiende ninguna.

Empieza por el monolito. Construye algunos sitios en los que WordPress muestre tanto el editor como las páginas públicas. Cuando el modelo de datos, la experiencia del editor y el ciclo de despliegue te resulten familiares, añade un front-end headless. El orden importa porque los front-ends headless consumen lo que produce WordPress; no puedes razonar sobre el front-end sin entender antes la forma de los datos.

Headless tiene sentido como habilidad de segunda etapa. El pilar de servicios de WordPress headless explica cuándo compensa esa complejidad.

#Cómo configurar un entorno local de desarrollo WordPress

La base para 2026:

  • Instala Docker Desktop (u OrbStack en macOS).
  • Instala Lando o DDEV para tener una pila reproducible de WordPress y base de datos.
  • Añade Composer para gestionar las dependencias de PHP.
  • Añade WP-CLI para operar WordPress desde la línea de comandos.
  • Usa una terminal de verdad: zsh en macOS, PowerShell moderno en Windows o cualquier shell de Linux.

Evita XAMPP y MAMP en proyectos nuevos. Ambos funcionan la primera tarde y fallan de forma sutil la primera vez que colaboras con otro desarrollador o despliegas en un hosting real.

Comprueba la configuración levantando un sitio nuevo con WordPress 6.7+, iniciando sesión, instalando un plugin con WP-CLI y editando un bloque en el editor. Si las tres cosas funcionan en menos de quince minutos, el entorno está listo.

#Cómo crear tu primer tema de bloques de WordPress

Los temas de bloques son el estándar en 2026. El modelo mental mínimo:

  • El editor de bloques lee los tokens globales (colores, fuentes, espaciados, anchos de diseño) desde theme.json.
  • Las plantillas y las partes de plantilla son archivos HTML con marcado de bloques, no archivos PHP.
  • Los patrones (patterns) son composiciones de bloques reutilizables, registradas mediante hooks de PHP o incluidas como archivos PHP en /patterns.
  • Los bloques a medida (cuando de verdad hacen falta) son componentes de JavaScript y React compilados a partir de block.json y un bundle JS.

Primer proyecto práctico: crea un tema de bloques de una sola página con un hero en la portada, tres tarjetas de características y un pie de página. Nada de PHP: WordPress reconoce un tema de bloques por dos archivos, style.css (que contiene la cabecera del tema) y templates/index.html, y functions.php es opcional según la documentación sobre la estructura de temas. Haz evolucionar el diseño solo a través de theme.json y del marcado de bloques. Este único proyecto enseña temas de bloques en aproximadamente una semana.

Para la capa del sistema de diseño, Tailwind v4 con WordPress 6.7+ es el patrón estable de producción en 2026, explicado en detalle en la guía de Tailwind CSS en el desarrollo WordPress.

#Cómo crear un bloque personalizado con create-block

Cuando un patrón no basta y necesitas un bloque propio de verdad, no empieces desde una carpeta vacía. La guía de inicio del Block Editor Handbook usa la herramienta oficial de andamiaje: con Node.js y npm instalados, ejecuta npx @wordpress/create-block@latest todo-list dentro de wp-content/plugins. El slug que indiques se convierte en el nombre de la carpeta del plugin y en el nombre interno del bloque. El plugin generado trae dos scripts de npm: npm run start (wp-scripts start) recompila el bloque mientras editas y npm run build (wp-scripts build) genera los archivos optimizados para producción. Activa el plugin, inserta el bloque en el editor, cambia una línea del código fuente y comprueba que el editor recoge la recompilación.

#Cómo escribir tu primer plugin de WordPress

Los plugins amplían WordPress con funciones que no deben pertenecer al tema. Ejemplos: un tipo de contenido personalizado para “case study”, un endpoint REST que sirve un catálogo en JSON, una tarea Cron que purga una caché.

Esqueleto mínimo de un plugin:

<?php
/**
 * Plugin Name: My Site Utilities
 * Description: Site-specific helpers for My Site.
 * Version: 0.1.0
 * Requires PHP: 8.3
 */

declare(strict_types=1);

namespace MySiteUtils;

add_action('init', static function (): void {
    register_post_type('case_study', [
        'public' => true,
        'label' => 'Case studies',
        'supports' => ['title', 'editor', 'thumbnail', 'custom-fields'],
        'show_in_rest' => true,
        'rest_base' => 'case-studies',
    ]);
});

Este plugin registra un tipo de contenido personalizado, lo muestra en el editor y lo pone a disposición vía REST. Con diez líneas de PHP, un principiante tiene en sus manos toda la primitiva de modelado de contenido sobre la que está construido WordPress.

El siguiente paso son los hooks. WordPress tiene actions (eventos a los que respondes) y filters (valores que transformas). Lee el Plugin Handbook para el modelo de referencia. La idea clave: no modifiques archivos del núcleo; usa hooks.

#Cómo sanear, validar y escapar datos en un plugin de WordPress

El plugin anterior no lee nada del exterior, y por eso es seguro. En cuanto tu código lee un campo de formulario, un parámetro de la URL o un valor de la base de datos y lo vuelve a mostrar, se aplica la primera regla de la documentación de seguridad de WordPress: no confíes nunca en los datos del usuario. El manual divide el trabajo en tres pasos. Valida la entrada cuando puedas (rechaza una cantidad que no sea un entero positivo), sanéala cuando no puedas (elimina lo que no corresponde) y escapa todo en la salida.

El escapado se hace lo más tarde posible, idealmente en el momento de imprimir el dato. La referencia de escapado asigna una función a cada contexto: esc_html() para texto dentro de un elemento, esc_attr() para valores de atributos, esc_url() para href y src, esc_js() para JavaScript en línea y esc_textarea() para el contenido de un textarea. Cuando tiene que sobrevivir algo de HTML, wp_kses_post() conserva solo las etiquetas permitidas en el contenido de las entradas y wp_kses() conserva solo las etiquetas y atributos que enumeres. Elige la función según el contexto de salida; esa elección cubre casi todo lo que un principiante necesita para evitar el cross-site scripting.

#Cómo proteger formularios de WordPress con nonces

Un nonce es un token que WordPress añade a formularios y URL para confirmar que una petición sale de tu sitio de forma intencionada. La documentación sobre nonces explica que ayudan a proteger frente a varios tipos de ataque, entre ellos la falsificación de peticiones en sitios cruzados (CSRF). Se crean con wp_nonce_field() dentro de un formulario, con wp_nonce_url() para un enlace o con wp_create_nonce() cuando necesitas el valor en bruto. Se verifican con check_admin_referer() en las pantallas de administración, con check_ajax_referer() en los controladores AJAX o con wp_verify_nonce() en cualquier otro caso.

Dos detalles pillan a los principiantes. WordPress no comprueba que un nonce se use una sola vez, así que no frena los ataques de repetición, y su vida útil por defecto es de un día, que en la práctica significa entre 12 y 24 horas. La documentación también dice que nunca hay que confiar en los nonces para autenticación, autorización o control de acceso. Acompaña cada comprobación de nonce con current_user_can() y la capacidad que requiere la acción.

#Tablas de la base de datos de WordPress que todo desarrollador debe conocer

Muchos principiantes evitan la base de datos durante los primeros seis meses. Ese es el error. WordPress guarda casi todo en wp_posts, wp_postmeta, wp_options, wp_users y wp_usermeta. En cuanto estas cinco tablas cobran sentido, ningún plugin ni tema vuelve a parecer magia.

Ejercicio práctico: abre wp shell (una consola interactiva de PHP con WordPress cargado) e inspecciona algunas filas. Busca la entrada que acabas de publicar. Mira su post_content. Mira sus metadatos. Escribe una consulta que liste todas las entradas del tipo de contenido personalizado por estado. Veinte minutos de esto enseñan más que una semana leyendo código de plugins.

#Cómo depurar WordPress con WP_DEBUG

Activa la depuración en wp-config.php de tu sitio local desde el primer día. La guía de depuración describe cinco constantes. WP_DEBUG activa el modo de depuración en todo WordPress y está desactivada por defecto. WP_DEBUG_LOG escribe los errores en wp-content/debug.log (o en la ruta que elijas) y solo funciona con WP_DEBUG activada. WP_DEBUG_DISPLAY controla si los errores se imprimen en el HTML de la página. SCRIPT_DEBUG hace que WordPress cargue las versiones de desarrollo sin minificar del CSS y el JavaScript del núcleo. SAVEQUERIES guarda cada consulta a la base de datos con su tiempo de ejecución y la función que la llamó en $wpdb->queries, con un coste de rendimiento.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Esta combinación registra todos los errores y no muestra ninguno a los visitantes. La guía no recomienda usar WP_DEBUG ni las demás herramientas de depuración en sitios en producción, así que mantenlas en los entornos local y de staging. Deja tail -f wp-content/debug.log abierto en una segunda terminal mientras trabajas y verás cada aviso de PHP en cuanto tu código lo provoque.

#Cómo comprobar código PHP con los estándares de WordPress

WordPress tiene sus propios estándares de código PHP, y el proyecto WordPressCS los convierte en reglas de PHP_CodeSniffer. Su README indica que la instalación con Composer es el único método admitido:

composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev wp-coding-standards/wpcs:"^3.0"
vendor/bin/phpcs -ps . --standard=WordPress

WordPressCS necesita PHP 7.2 o superior e incluye varios conjuntos de reglas. WordPress-Core cubre los estándares de código del núcleo, WordPress-Docs añade las reglas de documentación en línea, WordPress-Extra amplía Core con prácticas recomendadas y WordPress es el conjunto completo. Pásalo por el primer plugin de esta guía; los avisos que imprime enseñan las convenciones de nombres y formato sobre tu propio código y no sobre ejemplos.

#Cómo usar la REST API de WordPress

La REST API de WordPress forma parte del núcleo desde la versión 4.7, en 2016, y es estable en 2026. Por defecto, todos los tipos de contenido públicos, todas las taxonomías y todos los comentarios están disponibles en /wp-json/wp/v2/.... Los tipos de contenido personalizados se activan con 'show_in_rest' => true.

Para un principiante, la REST API importa porque:

  • Es la forma en que el editor de bloques habla con el back-end (el propio editor es un cliente REST).
  • Es la principal superficie de integración para front-ends headless (Astro, Next.js).
  • Es la vía por la que los sistemas externos (una app móvil, un agente de IA vía MCP, una herramienta de sincronización) leen el contenido de WordPress.

Ejercicio práctico: abre https://your-local-site.localhost/wp-json/wp/v2/posts en un navegador. Lee el JSON. Añade ?per_page=5&_fields=id,title,link. En diez minutos, la REST API deja de parecer abstracta.

#Fundamentos de seguridad en WordPress y Core Web Vitals

Dos áreas en las que los principiantes se queman durante el primer año si las ignoran:

Seguridad. Usa contraseñas de administrador largas y únicas, 2FA desde el primer día, un plugin de seguridad de confianza (Wordfence, Kadence Security o un WAF a nivel de hosting) y una solución de copias de seguridad de verdad. Nunca edites wp-config.php de forma que los secretos acaben en un repositorio público. No instales plugins pirateados (nulled); el riesgo de malware es real.

Core Web Vitals. Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift afectan directamente al posicionamiento en buscadores y a la percepción de los usuarios. Pasa PageSpeed Insights por tu sitio cada semana. Las mayores mejoras para un principiante: optimiza las imágenes (AVIF o WebP), evita maquetadores pesados en sitios donde el rendimiento es crítico y quédate en un hosting WordPress gestionado que se ocupe de la caché y la CDN.

La accesibilidad se trata en la guía de WCAG 2.2, BFSG y la Ley Europea de Accesibilidad. El techo de rendimiento se trata en el pilar de servicios de WordPress headless.

#Cómo aprender desarrollo WordPress en el primer mes

Una lista práctica de hitos que supera cualquier enfoque basado solo en tutoriales:

  • Semana 1: entorno local, primer tema de bloques, primer plugin, una entrada publicada.
  • Semana 2: un tipo de contenido personalizado con tres entradas, una consulta REST que las devuelve, un patrón de bloques propio.
  • Semana 3: desplegar en un hosting gestionado, configurar HTTPS, configurar copias de seguridad, añadir un plugin de seguridad básico.
  • Semana 4: escribir una única entrada de blog de 1500 palabras sobre algo que hayas aprendido y publicarla.

Al final del mes habrás entregado un sitio real (pequeño), escrito código real (pequeño) y tendrás un resultado público. Esa es la puerta de entrada al trabajo profesional con WordPress en 2026, no un portafolio de ejercicios de tutoriales interactivos a medias que nunca salieron del entorno de pruebas.

#Qué aprender después de los fundamentos de WordPress

Después del primer mes:

A los seis meses ya no eres principiante. El camino a partir de ahí es la especialización: rendimiento, seguridad, headless, integración de IA, cumplimiento normativo de la UE. WPPoland trabaja en estas áreas desde 2006; la página de empleo explica cómo colabora con otros desarrolladores sénior e indica que no hay vacantes abiertas.

#Artículos relacionados

Siguiente paso

Transforma el artículo en una implementación real

Este bloque refuerza el enlazado interno y lleva al lector al siguiente paso más útil dentro de la arquitectura del sitio.

¿Quieres implementar esto en tu sitio?

Si quieres transformar el artículo en mejoras concretas, rediseño o un plan de implementación, puedo cerrar el alcance y ejecutar.

Explora otros servicios WordPress y base de conocimiento

Refuerza tu negocio con soporte técnico profesional en áreas clave del ecosistema WordPress.

Preguntas frecuentes

Respuestas prácticas para aplicar el tema en la ejecución real.

¿Necesito saber PHP para empezar a desarrollar en WordPress?#
Sí para crear plugins y temas a medida, menos para sitios basados en bloques con temas de bloques en WordPress 6.7+. Un conocimiento práctico de PHP 8.3 es el mínimo realista para un desarrollador WordPress en 2026. El editor de bloques y theme.json reducen el contacto con PHP el primer día, pero no lo eliminan en trabajo de producción.
¿Debo aprender primero temas clásicos o temas de bloques?#
Temas de bloques. Los temas clásicos siguen manteniéndose, pero desde WordPress 5.9 los proyectos nuevos usan temas de bloques por defecto. Aprende temas de bloques, theme.json y algo de PHP para hooks. Vuelve a los clásicos solo si un proyecto de cliente lo exige.
¿Es WordPress headless el punto de partida adecuado en 2026?#
No. Aprende primero WordPress monolítico, porque ahí viven el editor, la base de datos y el modelo de plugins. Cuando hayas entregado algunos proyectos reales, añade Astro 5+ o Next.js 15 para aprender la capa headless. Si te saltas este orden, construirás front-ends sin entender los datos que consumen.
¿Qué entorno local debería usar un principiante?#
LocalWP es el camino más sencillo; Lando o DDEV sirven para proyectos que necesitan la reproducibilidad de Docker. Evita XAMPP y MAMP en 2026. Incorpora Composer, WP-CLI y una terminal de verdad desde el primer día; los tres se amortizan en la primera semana.
¿Qué documentación de WordPress merece la pena leer?#
WordPress Developer Resources en developer.wordpress.org para las API del núcleo, el Block Editor Handbook para Gutenberg y los WordPress Coding Standards para nombres y estructura. La documentación de plugins concretos (ACF, WooCommerce) llega después.

¿Necesitas un FAQ adaptado a tu sector y mercado? Preparo una versión alineada con tus objetivos de negocio.

Hablemos

Artículos Relacionados