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:

 

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()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()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:

custom-post-type-1

custom-post-type-2

custom-post-type-3

 

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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *