--- title: "Cómo implementar un sistema de campos personalizados en WordPress sin plugins" description: "Olvídate de plugins para tareas que puedes resolver de forma limpia y eficiente. Aprende a crear y gestionar campos personalizados en WordPress sin sacrificar velocidad ni escalabilidad." url: https://webcbz.com/campos-personalizados-wordpress-sin-plugins/ date: 2025-05-14 modified: 2025-05-14 author: "Chema" image: https://webcbz.com/wp-content/uploads/como-implementar-un-sistema-de-campos-personalizados-en-wordpress-sin-plugins.webp categories: ["Códigos personalizados", "Diseño y desarrollo web", "Tutoriales", "WordPress", "WordPress avanzado"] tags: ["ACF", "Advanced Custom Fields", "Campos personalizados", "metaboxes", "WordPress sin plugins"] type: post lang: es --- # Cómo implementar un sistema de campos personalizados en WordPress sin plugins Aunque WordPress se adapta sorprendentemente bien a proyectos complejos, muchos/as usuarios/as se precipitan instalando plugins innecesarios para resolver problemas que pueden abordarse con un enfoque más limpio y técnico. Uno de los casos más comunes es el de los **campos personalizados**, donde la solución más inmediata es optar automáticamente por utilizar plugins como Advanced Custom Fields (ACF) sin evaluar antes si realmente son necesarios. En este artículo aprenderás a **crear y gestionar campos personalizados sin depender de plugins**, utilizando código limpio, controlado y fácil de mantener. Este enfoque no solo mejora el rendimiento de tu web, sino que te obliga a conocer más a fondo cómo funciona WordPress por dentro, lo que a la larga te hará trabajar mejor. Cómo implementar un sistema de campos personalizados en WordPress sin plugins 1. [¿Qué son los campos personalizados y para qué se utilizan?](#qué-son-los-campos-personalizados-y-para-qué-se-utilizan) 2. [¿Por qué evitar un plugin como ACF en ciertos proyectos?](#por-qué-evitar-un-plugin-como-acf-en-ciertos-proyectos) 3. [Cómo crear campos personalizados con código (y sin ACF)](#cómo-crear-campos-personalizados-con-código-y-sin-acf) 4. [Cómo mostrar los campos personalizados en el frontend](#cómo-mostrar-los-campos-personalizados-en-el-frontend) - [Mostrarlo en una plantilla personalizada](#mostrarlo-en-una-plantilla-personalizada) - - [Condiciones avanzadas de visualización](#condiciones-avanzadas-de-visualización) - - [Mostrar campos en bucles personalizados](#mostrar-campos-en-bucles-personalizados) - - [Compatibilidad con constructores visuales](#compatibilidad-con-constructores-visuales) 5. [¿Y si quiero algo más visual en el backend?](#y-si-quiero-algo-más-visual-en-el-backend) - [Mejora visual y experiencia de edición](#mejora-visual-y-experiencia-de-edición) - - [¿Cuándo vale la pena hacerlo?](#cuándo-vale-la-pena-hacerlo) [Errores comunes al trabajar con campos personalizados](#errores-comunes-al-trabajar-con-campos-personalizados)[Cómo conectar campos personalizados con taxonomías y relaciones](#cómo-conectar-campos-personalizados-con-taxonomías-y-relaciones)[Conclusión: campos personalizados bien pensados, webs que escalan bien](#conclusión-campos-personalizados-bien-pensados-webs-que-escalan-bien) ## ¿Qué son los campos personalizados y para qué se utilizan? Los **campos personalizados** —conocidos en inglés como *custom fields*— son una de las funcionalidades más potentes y a menudo subestimadas de WordPress. Permiten añadir información adicional a cualquier contenido (entradas, páginas o [Custom Post Types](https://webcbz.com/custom-post-types-wordpress/)) de una forma estructurada y extensible, algo crucial cuando queremos que nuestra web sea más que un simple blog o una serie de páginas corporativas estáticas. Por defecto, WordPress estructura cada contenido (por ejemplo, una entrada) mediante un conjunto de campos preestablecidos: título, contenido, imagen destacada, fecha de publicación, etc. Estos campos son comunes a todos los tipos de contenido, y aunque permiten cierta personalización básica, en realidad se quedan cortos cuando necesitamos organizar o mostrar información más específica. Aquí es donde entran en juego los campos personalizados. **Un campo personalizado permite almacenar datos adicionales en forma de pares *key-value* (nombre del campo y su contenido).** Un ejemplo: estás creando una web de reseñas de películas. Como información específica de la película, podrías necesitar mostrar la duración de cada película, el director/a, su calificación por edad, su puntuación media en IMDb o Filmaffinity… Ninguno de esos datos tiene cabida natural en los campos estándar de una entrada de WordPress, pero se pueden añadir fácilmente en forma de campos personalizados. Más allá de simples valores de texto, estos campos pueden admitir diferentes tipos de datos: números, fechas, listas desplegables, casillas de verificación, imágenes, enlaces a otros contenidos… Incluso pueden vincularse a funcionalidades condicionales, cálculos automáticos o integraciones con plugins externos. De hecho, muchos plugins avanzados, como [Advanced Custom Fields (ACF)](https://wordpress.org/plugins/advanced-custom-fields/), [Meta Box](https://es.wordpress.org/plugins/meta-box/) o [Pods](https://es.wordpress.org/plugins/pods/), se basan en la [REST API de *custom fields* de WordPress](https://learn.wordpress.org/tutorial/wp-rest-api-custom-fields-authentication-and-testing/) para permitir al usuario/a crear interfaces personalizadas de edición sin escribir código, pero con total control sobre los datos que se almacenan. En el plano técnico, cada campo personalizado se guarda como una fila en la tabla `wp_postmeta` de la base de datos, relacionada con la entrada o contenido correspondiente. Esto significa que son perfectamente accesibles desde funciones PHP como `get_post_meta()` o `update_post_meta()`, lo que permite mostrar su contenido en cualquier parte del theme o manipularlo de manera programada. Es decir, los campos personalizados no son solo útiles para enriquecer la experiencia de edición en el panel de administración, sino también para modular el front-end de forma inteligente. Su utilidad es especialmente evidente en proyectos donde se requiere una gran personalización de la estructura de contenidos: catálogos de productos no gestionados con WooCommerce, fichas de eventos, páginas de miembros de un equipo, portfolios, listados inmobiliarios, agendas culturales, etc. Cada uno de estos casos requiere mostrar información que no encaja en los campos predefinidos, y los campos personalizados ofrecen una solución elegante, escalable y perfectamente integrada con el [ecosistema WordPress](https://webcbz.com/categoria/wordpress/ecosistema-wordpress/). En definitiva, **los campos personalizados permiten transformar WordPress en un auténtico gestor de contenidos avanzado**, mucho más allá de su concepción original como plataforma de blogs. Saber utilizarlos correctamente —y más aún, saber planificar con criterio qué campos necesita cada tipo de contenido— marca una evidente diferencia entre una web rígida, basada en plantillas genéricas, y una solución profesional, flexible y perfectamente adaptada a las necesidades reales del proyecto. ## ¿Por qué evitar un plugin como ACF en ciertos proyectos? Advanced Custom Fields (ACF) es, sin duda, una de las herramientas más populares y versátiles del ecosistema WordPress. Su facilidad de uso, su interfaz visual y la [enorme cantidad de documentación disponible](https://www.advancedcustomfields.com/resources/) lo convierten en una opción atractiva tanto para profesionales del desarrollo como para usuarios/as intermedios que quieren extender WordPress sin escribir código complejo. Sin embargo, y a pesar de sus muchas virtudes, ACF no siempre es la mejor solución. Hay proyectos en los que su uso puede convertirse en un lastre a medio o largo plazo, y conviene saber por qué. Uno de los principales motivos para evitar ACF en ciertos casos es su **dependencia directa del plugin para acceder a los datos desde el front-end**. Aunque los valores de los campos personalizados se almacenan en la base de datos de forma estándar (en `wp_postmeta`), ACF introduce su propia lógica y funciones para mostrar estos valores en el tema. ¿Qué significa esto? Pues que si, en algún momento, decides prescindir de ACF, tendrás que reescribir buena parte del código del tema para sustituir funciones como `the_field()` o `get_field()` por funciones nativas como `get_post_meta()`. Esta dependencia genera un acoplamiento innecesario que puede dificultar el mantenimiento o la migración del sitio en el futuro. Además, ACF añade una **capa de complejidad y carga adicional** al back-end que puede ser excesiva para sitios donde lo único que se necesita son campos personalizados sencillos y/o limitados. El plugin carga sus propios scripts, estilos, interfaces y lógica de validación, lo cual puede ralentizar el panel de administración, especialmente en instalaciones con muchos usuarios, con muchos campos o con una infraestructura limitada. En proyectos ligeros o muy optimizados, donde cada recurso cuenta para arañar recursos que deriven en un rendimiento aún mejor, esta sobrecarga puede llegar a ser contraproducente. Otro aspecto importante es el **factor de rendimiento**. Aunque ACF es un plugin muy optimizado, su uso intensivo de campos repetidores, grupos flexibles y relaciones puede llegar a generar un número considerable de consultas a la base de datos, especialmente si se muestran muchos campos personalizados en el front-end. Si no se cachea correctamente o si el sitio tiene mucho tráfico, esto puede llegar a afectar a la velocidad de carga. En cambio, una solución personalizada con código hecho a medida, bien planteado y sin elementos innecesarios, puede ofrecer resultados mucho más eficientes desde el punto de vista del rendimiento. Tampoco hay que olvidar que ACF, en su versión gratuita, tiene limitaciones. Funcionalidades como los campos repetidores (repeaters), los grupos de campos condicionales o las relaciones entre posts están reservadas para la [versión Pro](https://www.advancedcustomfields.com/pro/), lo cual puede ser un problema si se quiere prescindir de gastos extra o si lo que se busca es una solución totalmente libre de dependencias externas. En cambio, un enfoque con código nativo o mediante MU-plugins puede resolver la misma necesidad sin depender de licencias comerciales ni de terceros. Por último, está la cuestión de la **filosofía del proyecto y su escalabilidad**. En desarrollos a medida para clientes con necesidades muy concretas, utilizar ACF puede ser una solución rápida y cómoda a corto plazo, pero poco alineada con una mentalidad de desarrollo limpio, sostenible y desacoplado. En sitios donde la arquitectura de contenido es clave (por ejemplo, marketplaces, intranets, aplicaciones web basadas en WordPress, etc.), es preferible implementar estructuras personalizadas con funciones como `register_meta()` y bloques o pantallas de edición propias mediante `add_meta_box()`, `register_post_type()` y `register_taxonomy()`. ACF es una herramienta poderosa y muy útil, pero no debe utilizarse automáticamente por defecto. Como siempre suelo comentar, ante cualquier dependencia externa conviene evaluar si realmente aporta valor diferencial al proyecto o si introduce una complejidad innecesaria que se puede resolver de una manera más cómoda o eficiente. En muchos casos, optar por una solución más liviana, nativa y personalizada —incluso aunque requiera algo más de tiempo de desarrollo y personalización— puede ser una decisión mucho más sólida y sostenible a largo plazo. ## Cómo crear campos personalizados con código (y sin ACF) Aunque el plugin ACF ha hecho muy accesible el uso de campos personalizados en WordPress gracias a su interfaz visual, no es indispensable para añadir metadatos personalizados a entradas, páginas o tipos de contenido personalizados (CPTs). WordPress incluye, desde sus primeras versiones, funciones nativas que permiten gestionar este tipo de campos sin necesidad de recurrir a soluciones externas. Esto no solo evita dependencias innecesarias, sino que también permite un mayor control, mejor rendimiento y una arquitectura de proyecto más limpia. El proceso comienza registrando una **metabox**, es decir, una caja que aparecerá en el panel de edición del contenido. Para ello, se utiliza la función `add_meta_box()`. Este método requiere especificar un ID único, un título, una función de callback que se encargará de mostrar el contenido de la caja, el tipo de contenido donde debe aparecer (por ejemplo, `post`, `page` o un CPT), y su ubicación dentro del editor. Un ejemplo básico sería este: ``` function cbz_add_custom_meta_box() { add_meta_box( 'cbz_subtitulo_meta', // ID único 'Subtítulo del artículo', // Título visible 'cbz_render_subtitulo_meta_box', // Callback que renderiza el campo 'post', // Tipo de contenido donde aparece 'normal', // Contexto: normal, side, advanced 'default' // Prioridad ); } add_action('add_meta_boxes', 'cbz_add_custom_meta_box'); function cbz_render_subtitulo_meta_box($post) { $valor_actual = get_post_meta($post->ID, '_cbz_subtitulo', true); ?> Escribe aquí el subtítulo: