Tipo de contenido personalizado que no aparece en el editor masivo: solución

9 December 2026

Un tipo de contenido personalizado que no aparece en el editor masivo es, casi siempre, un tipo que su plugin ha registrado como no público. WOLF rellena el desplegable de tipos de contenido solo con los tipos públicos, así que ahí están las entradas, las páginas y los Medios, pero no los grupos de cursos, las reservas o los elementos de menú de un plugin, aunque ese plugin les dé su propia pantalla de listado en wp-admin. Un único filtro los añade. A continuación verás por qué ocurre, qué código usar, qué cambia exactamente y cómo llevar a la tabla los campos del nuevo tipo.

Por qué un tipo de contenido personalizado no aparece en el editor masivo

Cada tipo de contenido se registra con un conjunto de indicadores. El indicador public determina si las entradas están pensadas para verse en el front end: con URL propia, archivos y resultados de búsqueda. Los plugins de reservas, cursos, restaurantes, directorios y formularios suelen ponerlo en false para sus datos internos, porque una reserva o un grupo de curso no debería tener una página pública. Las entradas siguen teniendo pantalla de administración, de modo que el tipo se ve en wp-admin como cualquier otro tipo de contenido personalizado.

WOLF construye su lista con get_post_types(array('public' => true)). Esa misma lista alimenta el selector de tipo de contenido del panel de herramientas del Posts Editor y las opciones de la columna Tipo de contenido (Post type), por lo que un tipo no público falta en ambos.

Para comprobar que es tu caso, abre la pantalla de listado del plugin. Si la dirección termina en edit.php?post_type=course_group (o en cualquier otro slug), las entradas son del tipo en cuestión y ese slug es lo que necesita WOLF. Escribir el slug en Tipos de contenido para editores del sitio (Site editors post types) no lo añade: ese ajuste solo restringe la lista para los usuarios que no son administradores, nunca la amplía.

Mostrar tipos de contenido no públicos con wpbe_post_type_args

Los argumentos de esa consulta pasan por el filtro wpbe_post_type_args. El cambio más limpio es listar todos los tipos de contenido que tienen pantalla de administración, sean públicos o no:

/*
 * WOLF: list every post type that has an admin screen,
 * including non-public types registered by plugins.
 * Child theme functions.php or a code snippets plugin.
 */
add_filter('wpbe_post_type_args', function ($args) {
    return array('show_ui' => true);
});

Recarga la página de WOLF y abre el selector de tipo de contenido: el tipo que faltaba ya está en la lista, junto a las entradas, las páginas y los Medios. También aparecen algunos tipos de WordPress que tienen su propia pantalla de edición, como los patrones sincronizados (wp_block); simplemente no los selecciones.

Si el tipo sigue sin aparecer, su plugin lo registró sin la pantalla de administración estándar y gestiona las entradas en páginas propias. En ese caso, elimina la restricción por completo:

/*
 * WOLF: list all registered post types.
 * Child theme functions.php or a code snippets plugin.
 */
add_filter('wpbe_post_type_args', function ($args) {
    unset($args['public']);
    return $args;
});

Esto lista todo, incluidos elementos internos de WordPress como revision, nav_menu_item y customize_changeset. No los toques: no son contenido, y los cambios masivos en ellos pueden romper menús o revisiones.

Puede que te encuentres también con el fragmento return array('public' => false);. Funciona al revés: lista solo los tipos no públicos, de modo que las entradas y las páginas desaparecen del desplegable hasta que lo quites. Úsalo únicamente si en WOLF no editas nada más.

Qué cambia el filtro y qué no

Solo cambia la lista de tipos de contenido de la página de WOLF. El tipo en sí no se modifica: no se vuelve público, no obtiene URL en el front end y no aparece en los resultados de búsqueda ni en los sitemaps.
WOLF lee el filtro al final del hook init, así que funcionan tanto el functions.php del tema activo (hijo) como los plugins de fragmentos de código.
La lista ampliada también la usa la columna Tipo de contenido (Post type), que permite mover una entrada a otro tipo. No muevas contenido a un tipo que solo has añadido para poder editarlo.

Añadir los campos del nuevo tipo de contenido como columnas

Un tipo de contenido de un plugin son sobre todo campos meta: fechas, precios, aforos, ajustes. No son columnas hasta que las añades.

Selecciona el nuevo tipo en el selector de tipo de contenido del Posts Editor.
Abre en wp-admin una entrada de ese tipo que tenga todos los campos rellenados y anota su ID (el número que sigue a post= en la dirección).
En la pestaña Campos meta (Meta Fields), introduce el ID en Obtener claves meta de cualquier entrada por su ID (Get meta keys from any post by its ID) y haz clic en Obtener (Get). WOLF lista todas las claves meta almacenadas en esa entrada.
Elimina las claves que no necesites, pon títulos legibles a las demás (el título pasa a ser el encabezado de la columna) y elige la vista y el tipo de cada una: número (number) para valores numéricos, casilla de verificación (checkbox) para valores 1/0, matriz (array) para datos serializados. Haz clic en Guardar campos meta (Save meta fields).
En la pestaña Ajustes (Settings), escribe los títulos en el buscador de columnas (columns finder), activa las columnas, arrástralas para ordenarlas y haz clic en Guardar todos los ajustes (Save all settings).

Si en los ajustes generales la opción Columnas y campos meta separados por tipo de contenido (Separate columns and meta for post types) está en Sí (Yes), cada tipo de contenido tiene su propia lista de campos meta y su propio conjunto de columnas. Selecciona primero el tipo y añade después sus campos meta; de lo contrario, se asignarán al tipo que estaba seleccionado antes.

La documentación de Meta Fields explica las vistas y los tipos, y la edición masiva de metadatos serializados trata los campos que guardan matrices. El filtrado y la edición masiva funcionan después como con cualquier otro tipo, tal como se describe en la edición masiva de tipos de contenido personalizados.

Los editores y otros usuarios que no son administradores siguen sin verlo

Los usuarios que no son administradores solo reciben los tipos de contenido indicados en Ajustes (Settings) → Tipos de contenido para editores del sitio (Site editors post types). Añade allí el slug, separado por comas y sin espacios, por ejemplo post,page,course_group, y haz clic en Guardar todos los ajustes (Save all settings). El ajuste solo permite elegir entre los tipos de la lista que generó el filtro, así que para un tipo no público el filtro sigue siendo necesario. Si un editor ve el mensaje Ningún tipo de contenido permitido para editar por los editores del sitio (No any post type permitted to edit for site editors), lee cómo decide WOLF qué tipos de contenido puede editar un usuario.

Si el tipo de contenido sigue sin aparecer

El código no se ejecuta. El fragmento está inactivo o está en el functions.php de un tema que no es el activo (por ejemplo, el tema padre mientras hay un tema hijo activo).
Las entradas no son posts. Si la pantalla de listado del plugin es admin.php?page=… en lugar de edit.php?post_type=…, lo más probable es que el plugin guarde sus registros en tablas propias de la base de datos. Esos registros no son posts y ningún editor de entradas puede listarlos.
El tipo aparece en la lista, pero la tabla sigue mostrando entradas. WOLF vuelve a cambiar el tipo de contenido cuando considera que tu cuenta es la de un editor del sitio, algo que también les ocurre a administradores cuyos roles ha modificado un plugin de gestión de roles. El artículo sobre los editores del sitio enlazado más arriba muestra cómo comprobar la cuenta.

Si el tipo está registrado como tipo de contenido y aun así no aparece con el segundo fragmento activo, abre un tema en el foro de soporte de WOLF indicando el slug del tipo de contenido y el plugin que lo registra.