El Theme Builder de Elementor construye el tema completo sin tocar PHP: el header y el footer diseñados visualmente, las plantillas de entrada individual, las de archivo, las de búsqueda y error, cada pieza del sitio que antes exigía editar archivos del tema ahora armada en el constructor con sus condiciones de visualización, qué plantilla aplica a qué contenido, el sistema que reemplaza en la práctica al child theme para la mayoría de proyectos, la personalización completa sin heredar archivos ni mantener código, la guía que arma el tema entero pieza por pieza, porque el constructor dejó de ser una herramienta de páginas sueltas hace años, y el sitio del stack se construye completo en su Theme Builder, el control total con la zona verde de esta serie intacta.
Tabla de Contenidos
¿Qué es el Theme Builder y qué reemplaza?
El Theme Builder es el constructor de las piezas globales: las partes del sitio que se repiten en todas las páginas o en familias de ellas, el encabezado, el pie, la plantilla que viste a cada entrada del blog, la que presenta los archivos de categoría, las piezas que en el WordPress clásico viven en los archivos PHP del tema, y que el builder traslada al diseño visual, cada pieza como plantilla con sus condiciones de aplicación. Lo que reemplaza se nombra claro: el child theme para personalizaciones de presentación, la edición de archivos del tema, los hooks para insertar elementos, las tareas que pedían desarrollador convertidas en diseño, con su límite honesto, las personalizaciones funcionales profundas siguen siendo territorio de código, el Theme Builder cubre la capa de presentación completa, que es lo que la mayoría de proyectos necesita, la frontera práctica que esta serie traza. El tema base queda mínimo: el tema liviano de soporte con el constructor encima, el patrón del stack donde el tema aporta poco y el builder lo define todo, el marco de qué es Elementor y cómo funciona con el servicio en diseño web.
Paso 1: el header y el footer, las piezas universales
El header se construye como plantilla de sitio: el tipo de plantilla de encabezado creado, el contenedor con su logo dinámico, el menú del sitio, los elementos de contacto del patrón peruano, el WhatsApp visible que esta serie recomienda, el header pegajoso evaluado con criterio, la versión que acompaña el scroll con su altura reducida, y el responsive trabajado en serio, el menú móvil probado al primer toque, la guía de exclusiones de esta serie recordada cuando el delay de JS llegue, el header como la pieza más vista del sitio entero recibiendo el cuidado proporcional a esa exposición. El footer completa la pareja universal: los bloques de información, los enlaces legales del marco peruano, el reclamaciones visible, los datos de contacto consistentes con las señales de esta serie, el cierre de página que también es señal de confianza, y las condiciones de ambos configuradas, todo el sitio como regla general, las excepciones donde el diseño las pida, la landing de campaña sin distracciones con su condición de exclusión, el control fino de dónde aparece cada pieza, la primera muestra del poder de las condiciones que el paso tres explota completo.
Paso 2: las plantillas de contenido, single y archive
La plantilla de entrada individual viste al blog entero: el single post diseñado una vez, el título dinámico, los metadatos con criterio, el autor enlazado a su entidad de esta serie, la fecha visible que la confianza pide, el contenido del editor fluyendo en su zona, los bloques alrededor diseñados, los relacionados por categoría con la query de esta serie, los llamados de conversión del blog, el puente del lector al negocio, la plantilla que multiplica su diseño por cada artículo publicado, las quinientas entradas del blog vestidas por una sola pieza mantenible. Las plantillas de archivo ordenan los listados: el archivo de categoría con su grilla de loop de esta serie, el título dinámico de la taxonomía, el texto introductorio donde el SEO de esta serie lo pida, las páginas de categoría como páginas reales, la plantilla de búsqueda con sus resultados dignos, y la página de error de esta serie diseñada, el 404 útil con sus caminos de salida, cada estado del sitio con su plantilla intencional, el conjunto que convierte las zonas heredadas del tema en territorio diseñado, [DATO-KOM: el set de plantillas estándar de los proyectos KOM, las piezas del manual de construcción].
Paso 3: las display conditions, el cerebro del sistema
Las condiciones de visualización deciden qué plantilla viste qué contenido: la lógica de aplicación configurada por plantilla, todo el sitio, el tipo de contenido, la categoría específica, la página puntual, las inclusiones y exclusiones combinadas, y los patrones útiles se documentan, el single general del blog más el single especial de una categoría, la plantilla distinta para los casos de éxito, la condición específica ganando sobre la general, los archivos por taxonomía con diseños propios donde el rubro lo pida, el header alternativo de las landing, la exclusión que limpia la página de campaña, las jerarquías de condiciones que resuelven los sitios reales con sus excepciones. Las reglas de orden evitan el caos: las condiciones revisadas como sistema, la tabla mental de qué aplica dónde, los conflictos de plantillas entendidos, la específica sobre la general como principio, la documentación de esta serie en la ficha del sitio, el mapa de plantillas y condiciones anotado, y el mantenimiento del tema visual, las piezas revisadas tras actualizaciones mayores, el sistema completo del Theme Builder como el tema real del sitio, versionado en respaldos y documentado como el activo que es, el reemplazo práctico del child theme funcionando con todas las disciplinas de esta serie operando encima.
Preguntas frecuentes
¿Ya no necesito child theme para nada?
Para presentación, prácticamente no: el header, el footer, los singles y archivos cubiertos por el builder, y el child theme conserva su nicho funcional, los snippets de código del sitio, las personalizaciones profundas, el territorio que los plugins de código o el child mínimo atienden. La frontera práctica: el diseño en el builder, la función en su lugar correcto, cada capa del sitio con su herramienta correcta.
¿Qué pasa con mis plantillas si cambio de tema base?
Sobreviven por diseño: las plantillas del builder viven en Elementor y no en el tema, el tema base liviano intercambiable debajo, la portabilidad dentro del ecosistema del constructor, y el cambio de constructor sí las rehace, la frontera de esta serie. La arquitectura del stack lo asume: el tema mínimo de soporte elegido exactamente porque el builder es el tema real del proyecto.
¿El Theme Builder pesa más que un tema tradicional bien hecho?
El benchmark de esta serie ya respondió: el constructor agrega su capa con el método controlándola, los experiments, los contenedores, el DOM presupuestado, los verdes alcanzables documentados, y el tema artesanal perfecto gana puntos finos que cuestan la edición visual. La cuenta completa de esta serie decide: el rendimiento competitivo más la autonomía del dueño contra el óptimo absoluto sin ella.
¿KOM construye sus proyectos con Theme Builder completo?
Es el estándar de construcción del stack: el set completo de plantillas, las condiciones documentadas, el tema base mínimo, la zona verde del cliente sobre todo el sistema, dentro de los proyectos cotizados en el cotizador online con los precios públicos de siempre. El sitio entregado es tema visual completo: cada pieza del sitio editable visualmente sin tocar una sola línea de PHP.
Tu siguiente paso: inventaría las piezas heredadas de tu tema actual, el single que nunca diseñaste, el archivo de categoría con el diseño de fábrica, el 404 genérico, la lista de zonas sin intención que el Theme Builder convertiría en territorio propio. El proyecto completo se cotiza en el cotizador online: el tema entero sin tocar PHP dejó de ser promesa hace años, y esta guía es el mapa completo de cómo se construye pieza por pieza.
