Contents
Introducción
En WordPress un Custom Post Type (CPT) te permite crear tipos de contenido personalizados (por ejemplo: productos, eventos, portfolios). Para que esos contenidos puedan ser editados desde el editor de contenido de WordPress es imprescindible declarar el soporte a editor. Además, si quieres usar el editor de bloques (Gutenberg) debes exponer el CPT en la REST API mediante show_in_rest => true. En este artículo explico paso a paso cómo registrar un CPT con soporte al editor en PHP, con ejemplos prácticos y explicaciones de cada argumento importante.
Requisitos y consideraciones previas
- WordPress 5.0 para Gutenberg aún así el soporte clásico también funciona si el editor de bloques no está activo.
- Conocer dónde colocar el código: functions.php del tema hijo o, preferiblemente, un plugin propio.
- Si activas show_in_rest asegúrate de probar con editores de bloques y revisar permisos de la REST API.
- Si registras slugs o reglas de reescritura, recuerda refrescar las reglas de enlace permanentes (flush_rewrite_rules) apropiadamente (por ejemplo en la activación del plugin).
Pasos para registrar un Custom Post Type con soporte al editor
- Hookear la función de registro al init.
- Definir un arreglo labels para la interfaz.
- Configurar los args principales: public, supports (incluyendo editor), show_in_rest, rewrite, has_archive, etc.
- Llamar a register_post_type con el slug y los argumentos.
- Probar en el escritorio de WordPress: crear un nuevo item y comprobar que aparece el editor.
Ejemplo básico (mínimo necesario)
Este ejemplo registra un CPT llamado Libro con soporte al editor y al título. Se recomienda colocarlo en functions.php del tema hijo o en un plugin.
lt?php
// Registra el CPT book
add_action(init, my_register_book_cpt)
function my_register_book_cpt() {
labels = array(
name =gt Libros,
singular_name =gt Libro,
menu_name =gt Libros,
name_admin_bar =gt Libro,
add_new =gt Añadir nuevo,
add_new_item =gt Añadir nuevo libro,
edit_item =gt Editar libro,
new_item =gt Nuevo libro,
view_item =gt Ver libro,
search_items =gt Buscar libros,
not_found =gt No se encontraron libros,
not_found_in_trash =gt No hay libros en la papelera
)
args = array(
labels =gt labels,
public =gt true,
has_archive =gt true,
rewrite =gt array(slug =gt libros),
show_in_rest =gt true, // necesario para usar el editor de bloques (Gutenberg)
supports =gt array(title,editor,thumbnail), // editor habilita el área de contenido
menu_position =gt 5,
menu_icon =gt dashicons-book
)
register_post_type(book, args)
}
?gt
Explicación de los argumentos clave
- labels: conjunto de textos traducibles que se mostrarán en la interfaz.
- public: determina si el tipo es público (consulta frontal, UI en admin, etc.).
- show_in_rest: si es true, expone el CPT en la REST API requerido para el editor de bloques (Gutenberg).
- supports: lista de características soportadas para el editor añade editor. Otros valores comunes: title, thumbnail, excerpt, comments, revisions, custom-fields.
- rewrite: controla el slug de URL y reglas de reescritura.
- has_archive: si el CPT tiene archivo (ej. /libros/).
- menu_icon y menu_position: apariencia en el menú de administración.
Ejemplo avanzado: CPT con soporte completo, plantillas de bloques y activación como plugin
En este ejemplo se muestra cómo registrar el CPT dentro de un plugin simple, incluir capacidades básicas y definir una plantilla de bloques (block template) para el editor de bloques. También se ilustra flush_rewrite_rules en la activación del plugin.
lt?php
/
Plugin Name: CPT Libros Avanzado
Description: Registra el Custom Post Type book con soporte al editor (Gutenberg) y plantilla de bloques.
Version: 1.0
Author: Tu Nombre
/
// Registrar CPT
add_action(init, cpta_register_book)
function cpta_register_book() {
labels = array(
name =gt Libros,
singular_name =gt Libro,
menu_name =gt Libros,
add_new_item =gt Añadir nuevo libro,
edit_item =gt Editar libro
)
args = array(
labels =gt labels,
public =gt true,
show_ui =gt true,
show_in_menu =gt true,
has_archive =gt true,
rewrite =gt array(slug =gt libros),
show_in_rest =gt true, // habilita Gutenberg / REST
rest_base =gt libros, // endpoint REST /wp/v2/libros
supports =gt array(title,editor,excerpt,thumbnail,revisions),
capability_type =gt array(book,books), // ejemplo de capabilities personalizados
map_meta_cap =gt true,
menu_icon =gt dashicons-book,
)
// Definimos una plantilla de bloques (opcional) para el editor
args[template] = array(
array(core/paragraph, array(
placeholder =gt Añade una introducción sobre el libro...
)),
array(core/image, array())
)
// Evitar que el usuario elimine la plantilla (opcional)
// args[template_lock] = all
register_post_type(book, args)
}
// Flush rewrite rules al activar/desactivar el plugin
register_activation_hook(__FILE__, cpta_activate_plugin)
function cpta_activate_plugin() {
cpta_register_book()
flush_rewrite_rules()
}
register_deactivation_hook(__FILE__, cpta_deactivate_plugin)
function cpta_deactivate_plugin() {
flush_rewrite_rules()
}
?gt
Notas sobre la plantilla de bloques
La clave template permite definir bloques iniciales cuando se crea un nuevo item del CPT. Si estableces template_lock =gt all los usuarios no podrán añadir o quitar bloques fuera de la plantilla (útil para estructuras muy controladas).
Casos especiales y trucos útiles
- Solo editor clásico: si no deseas Gutenberg puedes usar el plugin Classic Editor o desactivar el editor por CPT mediante filtros. Para permitir solo el editor clásico aunque show_in_rest sea true puedes controlar con filtros de funcionalidades de usuarios.
- Eliminar soporte al editor condicionadamente: puedes usar remove_post_type_support en admin_init para ciertos roles o pantallas.
- Permisos y capacidades: para controlar quién puede editar o publicar utiliza capability_type y map_meta_cap o define capabilities específicas y así integrarlo con controles de roles.
- Seguridad: el contenido del editor debe sanitizarse y escaparse al mostrarse: usar the_content() o funciones de escape según contexto.
- Flushing: nunca llames flush_rewrite_rules en init en cada carga úsalo solo en activación/desactivación.
Ejemplo: eliminar el editor para un CPT en pantallas concretas
Si por ejemplo quieres quitar el editor para el CPT book en la pantalla de edición de ciertos tipos de contenido o según un campo, puedes hacerlo así:
lt?php
add_action(admin_init, cpta_conditional_remove_editor)
function cpta_conditional_remove_editor() {
post_type = get_current_screen() ? get_current_screen()->post_type :
if (post_type === book) {
// Elimina el editor para book en el admin
remove_post_type_support(book, editor)
}
}
?gt
Buenas prácticas y recomendaciones
- Registrar el CPT desde un plugin en vez del theme si el contenido debe sobrevivir a cambios de tema.
- Si dependes del editor de bloques, marca show_in_rest => true y prueba con la REST API y permisos.
- Define labels completas y traducciones para una mejor experiencia de usuario.
- Controla capacidades si necesitas flujo editorial más complejo (editores, revisores, autores).
- Si necesitas metadatos, usa metaboxes o el sistema de bloques de campos (ACF o Block-based fields) según convenga.
- Probar en distintos entornos: roles, dispositivos móviles, versiones de WP.
Resumen
Para registrar un Custom Post Type con soporte al editor en PHP necesitas, básicamente, añadir editor dentro del array supports y, si deseas utilizar el editor de bloques (Gutenberg), establecer show_in_rest => true. Lo ideal es encapsular el registro en un plugin, definir labels y argumentos apropiados, y gestionar las reglas de reescritura con cuidado. Con los ejemplos proporcionados tienes tanto una versión mínima como una implementación avanzada con plantillas de bloques y manejo de activación.
|
|
Acepto donaciones de BAT's mediante el navegador Brave 🙂 |