Creación de un Custom Post Type en WordPress

WordPress incluye Posts y Pages de forma predeterminada, pero estos dos tipos de contenido no te llevarán muy lejos cuando un cliente necesita un directorio de propiedades inmobiliarias, una lista de personal o un archivo de recetas. Ahí es donde entra en juego un custom post type de WordPress — una estructura de contenido de primera clase que se integra limpiamente en el modelo de datos existente de WordPress sin necesidad de modificar los valores predeterminados.

¿Qué es un Custom Post Type?

Un custom post type (CPT) es un tipo de contenido nombrado que registras en WordPress. A pesar del nombre, no es una tabla de base de datos separada. Todos los tipos de post — tanto predeterminados como personalizados — comparten la tabla wp_posts, diferenciándose por la columna post_type. Este es un modelo mental importante: estás extendiendo una estructura existente, no creando una paralela.

Los tipos de post predeterminados incluyen post, page, attachment, revision y nav_menu_item. Cuando registras un CPT como property o recipe, WordPress lo trata con la misma consistencia: pantallas de administración, endpoints de la REST API, enrutamiento de URL y jerarquía de plantillas funcionan de la misma manera.

Custom post types ≠ custom fields. Un CPT define el tipo de contenido. Los custom fields (agregados mediante ACF o la API de metadatos) almacenan datos adicionales adjuntos a ese contenido. Son conceptos separados.

Registro de un Custom Post Type con register_post_type()

La forma canónica de crear un custom post type en WordPress es mediante la función register_post_type(), llamada en el hook init.

Aquí tienes un ejemplo limpio y funcional:

add_action( 'init', 'register_property_post_type' );

function register_property_post_type() {
    $labels = [
        'name'               => 'Properties',
        'singular_name'      => 'Property',
        'add_new_item'       => 'Add New Property',
        'edit_item'          => 'Edit Property',
        'not_found'          => 'No properties found.',
    ];

    $args = [
        'labels'       => $labels,
        'public'       => true,
        'has_archive'  => true,
        'supports'     => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
        'rewrite'      => [ 'slug' => 'properties' ],
        'show_in_rest' => true,
    ];

    register_post_type( 'property', $args );
}

Explicación de los Argumentos Clave

• public — Hace que el CPT sea visible en el administrador y en el front end. Establécelo en false para tipos de uso exclusivamente interno.
• labels — Controla todas las cadenas de texto de la interfaz de usuario en el administrador. Vale la pena completarlo correctamente para que los editores no se confundan.
• supports — Declara qué características del editor aparecen en la pantalla de edición. Valores comunes: title, editor, thumbnail, excerpt, custom-fields.
• has_archive — Habilita una página de archivo en /properties/. WordPress buscará una plantilla archive-property.php correspondiente (o recurrirá a archive.php).
• rewrite — Establece el slug de la URL. Los posts individuales aparecerán en /properties/post-name/.
• show_in_rest — Establécelo en true. Esto expone el CPT a través de la REST API de WordPress y es necesario para que el editor de bloques funcione correctamente con tu tipo de post. Sin esto, el editor vuelve a la interfaz clásica.

Plugin vs. Theme: ¿Dónde Debe Residir el Código?

Este es un punto de confusión común. Registra tu custom post type en un plugin, no en un theme.

Si el registro de tu CPT reside en functions.php y el cliente cambia de tema, todo el contenido de ese tipo se vuelve inaccesible — no se elimina, pero se vuelve invisible. Un plugin dedicado (incluso uno simple de un solo archivo) mantiene el CPT activo independientemente de los cambios de tema.

No limpies las reglas de reescritura en cada petición. Llama a flush_rewrite_rules() solo una vez — en la activación del plugin mediante register_activation_hook(). Limpiar en cada init es un problema de rendimiento.

Jerarquía de Plantillas para Custom Post Types

WordPress busca plantillas en este orden para una entrada individual de CPT:

1. single-{post-type}.php (por ejemplo, single-property.php)
2. single.php
3. singular.php
4. index.php

Para archivos, sigue: archive-{post-type}.php → archive.php → index.php.

Conclusión

Con register_post_type() correctamente enganchado a init, show_in_rest habilitado y el registro residiendo en un plugin, tienes una base sólida y portable. Desde aquí puedes agregar taxonomías personalizadas, campos meta mediante ACF o la API de metadatos, y columnas personalizadas en el administrador — sin tocar nada que pueda romperse cuando WordPress o tu tema se actualicen.

Preguntas Frecuentes

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.