13. The WP Functions Library (II). El Custom Post Type

En nuestro mini proyecto, vamos a empezar, como dije en el anterior artículo, por el Custom Post Type, es decir, el tipo de post personalizado.

Para ello, primero, vamos a estudiar la instrucción register_post_type() a fondo, con todos sus parámetros, para acabar escribiendo nuestra función que creará la base para nuestras fichas de The WP Functions Library.

 

NOTA PREVIA: Para la redacción de este artículo, he consultado las siguientes fuentes:

• Artículo ’10. Custom Post Types’ de esta misma serie (sin autobombo, jeje).
• Custom Post Types y Taxonomías en WordPress, la forma correcta, de Dario BF.
• Codex de WordPress

 

La función register_post_type()

register_post_type( $tipo, $argumentos )

Registra un tipo de post. No se puede utilizar antes del gancho de acción ‘init’.

Parámetros:

$tipo cadena obligatoria de menos de 20 caracteres, con la clave del tipo de post.

$argumentos matriz opcional conteniendo los diferentes argumentos que necesita la función, que son:

• ‘label’. Cadena. Nombre del tipo, que se mostrará en el menú, generalmente plural.
• ‘labels’. Matriz, conteniendo una lista de diferentes etiquetas que veremos más adelante.
• ‘description’. Cadena. Breve resumen de que tipo de post es.
• ‘public’. Lógico. Si el post está destinado para uso público, bien en la parte administrativa o por los usuarios del front-end. Por defecto, falso.
• ‘hierarchical’. Lógico. Si el tipo de post es jerárquico (como las páginas, por ejemplo). Por defecto, falso.
• ‘exclude_from_search’.  Lógico. Si se excluyen los posts de este tipo de los resultados de las búsquedas en el front-end. Por defecto es el valor opuesto de ‘public’.
• ‘publicly_queryable’. Lógico. Si las consultas se pueden realizar en el front-end para el tipo de post como parte de parse_request(). Debe incluir: ?post_type={post_type_key}, ?{post_type_key}={single_post_slug} y ?{post_type_query_var}={single_post_slug}. Si no se indica, el valor por defecto será el de ‘public’.
• ‘show_ui’. Lógico. Si generar una interfaz de usuario para gestionar este tipo de post en el panel de administración.
• ‘show_in_menu’. Lógico. Si el tipo de post se mostrará en el menú de administración. Para trabajar, ‘show_ui’ debe ser true. Si es true, el tipo de post se muestra en el menú principal. Si es falso, no se muestra. Por defecto, coge el valor de ‘show_ui’.
• ‘show_in_nav_menus’. Lógico. Hace posible seleccionarlo en los menús de navegación. Por defecto, coge el valor de ‘public’.
• ‘show_in_admin_bar’. Lógico. Hace posible seleccionarlo en la barra de administración. Por defecto, coge el valor de ‘show_in_menu’.
• ‘menu_position’. Entero. La posición en el orden de menú que aparecerá el tipo de post. Para funcionar, ‘show_in_menu’ debe ser true. Por defecto, su valor es null, apareciendo abajo del menú.
• ‘menu_icon’. Cadena. La URL del icono que aparecerá en el menú. Por defecto, utilizará el icono de entradas.
• ‘capability_type’. Cadena. La cadena para utilizar en la construcción de las opciones ‘leer’, ‘editar’ y ‘eliminar’. Se puede pasar una matriz con el singular y plural (p.ej., array(‘story’,’stories’). Por defecto es post.
• ‘capabilities’. Matriz de permisos para este tipo. Por defecto, se utiliza ‘capability_type’. Ver más en get_post_type_capabilities().
• ‘map_meta_cap’. Lógico. Si usar el valor meta interno por defecto. Por defecto, falso.
• ‘supports’. Matriz. Un alias para ejecutar add_post_type_support() directamente. Por defecto, una matriz que contiene ‘title’ y ‘editor’.
• ‘register_meta_box_cb’. Provee una función de llamada de vuelta que crea los metaboxes para el formulario de edición. En la función, utiliza remove_meta_box() y add_meta_box(). Por defecto, es nulo.
• ‘taxonomies’. Matriz de identificadores de taxonomía que se registrarán para el tipo de post. Las taxonomías se pueden registrar más tarde con register_taxonomy() o register_taxonomy_for_object_type().
• ‘has_archive’. Lógico o cadena. Si será tipo de post archivos, o si es una cadena, el slug a utilizar para su archivado. Se generarán las reglas de rewrite adecuadas si ‘rewrite’ está activado. Por defecto es falso.
• ‘rewrite’. Lógico o matriz. Selecciona el manejo de reescritura para este tipo. Para evitar la reescritura, indicar falso. Por defecto es verdadero, utilizando ‘post_type’ como slug. Para especificar las reglas de reescritura, pasar una matriz con estas claves:

– ‘slug’. Cadena para personificar la estructura del permalink. Por defecto, la clave de ‘post_type’.

– ‘with_front’. Lógico. Si la estructura del permalink antepondrá con  WP_Rewrite::$front. Por defecto, verdadero.

–‘feeds’. Lógico. Si el feed de la estructura del permalink se creará para este tipo de post. Por defecto, el valor de ‘has_archive’.

– ‘pages’. Lógico. Si la estructura del permalink aceptará paginación. Por defecto, verdadero.

– ‘ep_mask’. Constante. Máscara de punto final para asignar.

• ‘query_var’. Cadena o lógico. Selecciona la clave de consulta para este tipo de post. Por defecto, la clave ‘post_type’. Si falso, un tipo de post no puede ser cargadao en ?{query_var}={post_slug}. Si se especifica como una cadena, la consulta ?{query_var_string}={post_slug} será válida.
• ‘can_export’. Lógico. Si permitir exportar este tipo de post. Por defecto, verdadero.
• ‘delete_with_user’. Lógico. Si borrar posts de este tipo al borrar un usuario. Si es verdadero, los posts de este tipo pertenecientes al usuario serán movidos a la papelera cuando se elimine el usuario. Si es falso, los posts de este tipo pertenecientes al usuario no se moverán a la papelera. Si no se indica (opción por defecto), los posts son enviados a la papelera según post_type_supports(‘author’). En cualquier otro caso los posts no son eliminados. Por defecto, nulo.
• ‘_builtin’. Lógico. SOLO PARA USO INTERNO. Verdadero si este tipo de post es nativo o creado. Por defecto, falso.
• ‘_edit_link’. Cadena. SOLO PARA USO INTERNO. Segmento de URL a usar para editar link de este tipo de post. Por defecto, ‘post.php?post=%d’.

 

La matriz ‘labels’

• ‘name’. Nombre general para el tipo de post, generalmente plural. Por defecto es ‘Posts/Pages’.
• ‘singular_name’. Nombre para un objeto de este tipo de post. Por defecto, ‘Post/Page’.
• ‘add_new’. Por defecto es ‘Add New’ tanto para tipos jerárquicos como no jerárquicos.
• ‘add_new_item’. Por defecto, ‘Add New Post/Add New Page’.
• ‘edit_item’. Por defecto, ‘Edit Post/Edit Page’.
• ‘new_item’. Por defecto, ‘New Post/New Page’.
• ‘view_item’. Por defecto, ‘View Post/View Page’.
• ‘search_items’. Por defecto, ‘Search Posts/Search Pages’.
• ‘not_found’. Por defecto, ‘No posts found/No pages found’.
• ‘not_found_in_trash’. Por defecto, ‘No posts found in Trash/No pages found in Trash’.
• ‘parent_item_colon’. Esta cadena no se usa en tipos no jerárquicos. En los jerárquicos el valor por defecto es ‘Parent Page:’.
• ‘all_items’. Cadena para el submenu. Por defecto, ‘All Posts/All Pages’.
• ‘archives’. Cadena para usar con archives en menús de navegación. Por defecto, ‘Post Archives/Page Archives’.
• ‘insert_into_item’. Cadena para el botón del marco de medios. Por defecto, ‘Insert into post/Insert into page’.
• ‘uploaded_to_this_item’. Cadena para el filtro del marco de medios. Por defecto, ‘Uploaded to this post/Uploaded to this page’.
• ‘featured_image’. Por defecto, ‘Featured Image’.
• ‘set_featured_image’. Por defecto, ‘Set featured image’.
• ‘remove_featured_image’. Por defecto, ‘Remove featured image’.
• ‘use_featured_image’. Por defecto, ‘Use featured image’.
• ‘menu_name’. Por defecto, lo mismo que ‘name’.
• ‘filter_items_list’. Cadena para la vista de tabla con cabeceras ocultas.
• ‘items_list_navigation’. Cadena para la paginación de tabla con cabeceras ocultas.
• ‘items_list’. Cadena para la tabla con cabecera oculta.

 

Nuestro Custom Post Type

Si bien toda la explicación previa parece más un manual de la función register_post_type(), me ha parecido oportuno hacerlo para tener siempre a mi disposición esta explicación que me permita utilizar los argumentos correctamente.

Ahora, vamos a generar el código (provisional, ya veremos si hay que cambiar o añadir algún parámetro) para nuestro Custom Post Type:

NOTA IMPORTANTE: Os habréis fijado que prefijo el nombre de la función de una forma muy rara, ‘stmtwpfl_’. Esto es así porque tanto funciones como variables, como lo que sea, empleo un prefijado que comienza con mis iniciales (stm) y el nombre del tema o plugin en cuestión (en este caso, ‘twpfl’-‘The WP Functions Library’). Luego, a continuación, indico si es función u otra cosa, y finalmente su nombre. Así, me aseguro no tener nombres comunes.

Veamos, finalmente, el resultado:

 

Conclusiones

Hasta aquí la creación de nuestras fichas. En el próximo artículo crearemos un formulario en metabox para añadir los metadatos de los campos personalizados.