aNieto2K Desarrollo web, Wordpress, y alguna cosilla más

La gente de WordPress nos ofrece una API nueva para almacenar datos transitorios como hacíamos con la Options API pero especificando el tiempo que estos están disponibles.

// Graba un transient
set_transient($transient, $value, $expiration);

// Obtenemos un transient
get_transient($transient);

// Borramos un transient
delete_transient($transient);

Básicamente se trata de una serie de funciones que nos permitirá cachear datos en nuestras creaciones para WordPress. Una buena herramienta que nos permitirá mejorar el rendimiento de nuestras aplicaciones.

set_transient()

• $transient identificador único de nuestros datos.
• $value datos a guardar, estos datos se serializarán.
• $expiration número de segundos que esperarán los datos en la caché.

Ejemplo:

set_transient('special_query_results', $special_query_results, 60*60*12);

get_transient()

• $transient identificador único de nuestros datos.

Ejemplo:

$value = get_transient("codigodeejemplo");

delete_transient()

• $transient identificador único de nuestros datos.

Ejemplo:

delete_transient("codigodeejemplo");

Ejemplo de uso

En WP-Engineer publican un ejemplo de sistema simple de caché con Transients API. En el ejemplo, nos muestra como cachear la nube de tags como ejemplo de uso para cachear datos de nuestras plantillas.

$tag_cloud = get_transient( 'tag_cloud' );
if ( false === $tag_cloud || '' === $tag_cloud ){
   $args = array('echo' => false);
   $tag_cloud = wp_tag_cloud( $args );
   set_transient( 'tag_cloud', $tag_cloud, 60*60*12 );
}
echo $tag_cloud;

Una herramienta muy útil para suavizar el impacto de nuestros trabajos sobre la base de datos de WordPress.

456 Berea St publica un pequeño script para convertir las url’s absolutas de nuestro WordPress en relativas. El script se basa en el uso de una expresión regular que elimina el protocolo y el dominio y nos deja la url recortada allá donde la usemos.

function make_href_root_relative($input) {
    return preg_replace('!http(s)?://' . $_SERVER['SERVER_NAME'] . '/!', '/', $input);
}

Esta función nos permitirá convertir cualquier url que le pasemos como parámetro, si además usamos el filtro asociado a the_permalink(), esto se propagará por la aplicación y reemplazará la mayoría de url’s que usen este método.

function root_relative_permalinks($input) {
    return make_href_root_relative($input);
}
add_filter( 'the_permalink', 'root_relative_permalinks' );

Una forma rápida de relativizar tus url’s 😀

Desde la versión 2.5, WordPress dispone de una funcionalidad que nos permite definir código que podrá ser ejecutado desde los artículos mediante código similares al BBCode. Esta funcionalidad la llamaron Shorcodes.

Ya vimos como funcionaban los shortcodes y como implementarlos en nuestros WordPress. Ahora en WPEngineer publican una interesante artículo en el que nos explican como usar shortcodes en nuestros themes sin necesidad de encontrarnos dentro del contenido de los artículos.

<?php echo do_shortcode('[myshortcode]'); ?>

Gracias a do_shortcode() podemos ejecutar nuestros propios shortcodes en donde queramos del código de nuestro theme. Muy útil 😀

Una de las funcionalidades incluidas en WordPress 3.0 es la posibilidad de definir tipos de posts personalizados. Esto que parece que ha pasado desapercibido por la comunidad de desarrolladores es realmente interesante y ofrece una gran capacidad para extender cualquier WordPress fácilmente.

¿Que son los Custom Post Types?

Hasta la versión 2.9.x de WordPress disponíamos de unos pocos tipos de posts disponibles para identificar nuestros artículos. Estos tipos de posts, indicaban el estado del mismo (draft, revision,…) o el tipo de usado (attachment, page,…).

Ahora con la nueva versión de WordPress, la 3.0, la posibilidad de definir tipos de posts personalizados abre un abanico de posibilidades.

¿Como definir un nuevo Custom Post Type?

La API de WordPress está muy bien documentada en WordPress Codex y allí podemos encontrar como definir un Post Type fácilmente.

Todo pasa por la función register_post_type(), que se encarga de registrar un nuevo tipo con una serie de características personalizadas.

add_action( 'init', 'create_post_type' );
function create_post_type() {
  register_post_type( 'super',
    array(
      'labels' => array(
        'name' => __( 'Supers' ),
        'singular_name' => __( 'Super' )
      ),
      'public' => true,
    )
  );
}

Como vemos, debemos crear una función que se ejecutará en el action «init» de WordPress y que registrará el nuevo tipo. Disponemos de muchos parámetros que podemos usar para personalizar el nuevo tipo, pero los veremos más adelante.

(Ver Imagen)

Introduciendo este código en, por ejemplo, el fichero functions.php de tu theme o en un plugin. Obtendremos un resultado similar al que vemos en la imagen. Se trata de un nuevo menú con el nuevo tipo registrado.

En el nuevo menú descubrimos que podemos mostrar un listado de artículos del nuevo tipo o crear uno nuevo, siempre asociado al post-type definido previamente.

Detalles de register_post_type()

Los parámetros que esta función reciba condicionarán el panel de administración de nuestro nuevo post_type.

Labels

• name: El plural del nuevo tipo (películas).
• singular_name: Singular del nuevo tipo (película)
• add_new: Etiqueta de «Añadir nuevo»
• add_new_item: Cabecera del panel «Añadir nuevo»
• edit: Etiqueta de «Editar»
• edit_item: Cabecera del panel «Editar»
• new_item: Muestra en el menú favoritos
• view: Se utiliza como texto en un enlace para ver el post.
• view_item:Se muestra junto con el enlace permanente en la pantalla de edición posterior
• search_items: Botón de texto para el cuadro de búsqueda en la pantalla de edición de mensajes
• not_found: Texto para cuando no encuentre items
• not_found_in_trash:Texto para cuando no encuentre items en la papelera.
• parent: Se utiliza para definir el tipo padre. Solo útil en tipos heredados.

Ejemplo

'labels' => array(
	'name' => __( 'Super Dupers' ),
	'singular_name' => __( 'Super Duper' ),
	'add_new' => __( 'Add New' ),
	'add_new_item' => __( 'Add New Super Duper' ),
	'edit' => __( 'Edit' ),
	'edit_item' => __( 'Edit Super Duper' ),
	'new_item' => __( 'New Super Duper' ),
	'view' => __( 'View Super Duper' ),
	'view_item' => __( 'View Super Duper' ),
	'search_items' => __( 'Search Super Dupers' ),
	'not_found' => __( 'No super dupers found' ),
	'not_found_in_trash' => __( 'No super dupers found in Trash' ),
	'parent' => __( 'Parent Super Duper' ),
),

description

La descripción, es usada para explicar de que trata el nuevo tipo.

Ejemplo

'description' => __( 'A super duper is a type of content that is the most wonderful content in the world. There are no alternatives that match how insanely creative and beautiful it is.' ),

public

Se trata de un parámetro que permite personalizar todo lo referente al comportamiento público del nuevo tipo. En caso de estar activo (true) nos permitirá usar otros parámetros para personalizar nuestro post_type.

• show_ui: Mostrar en las pantallas de Administración
• publicly_queryable: Permitir que las consultas por este tipo estén disponibles a los usuarios.
• exclude_from_search: Eliminar de la lista de resultados de búsquedas.

'public' => true,
'show_ui' => true,
'publicly_queryable' => true,
'exclude_from_search' => false,

capability_type / capabilities

El tema de permisos es algo que también está reflejado en los Custom Post Types, permitiendo definir que capacidades tiene cada perfil de usuarios sobre el tipo.

Para ello usaremos el atributo «capabilities«:

• edit_post: Alguien puede crear y editar un post específico
• edit_posts: Capacidad de guardar los mensajes que permite la edición de este tipo de posts
• edit_others_posts: Capacidad que permite la edición de los posts de los demás.
• publish_posts: Capacidad de la concesión de la publicación de este tipo de posts.
• read_post: Capacidad que controla la lectura de un puesto específico de este tipo de posts.
• read_private_posts: Capacidad para permitir la lectura de los mensajes privados.
• delete_post: Capacidad que otorga el privilegio de la supresión de posts.

Ejemplo

/* Global control over capabilities. */
'capability_type' => 'super_duper',

/* Specific control over capabilities. */
'capabilities' => array(
	'edit_post' => 'edit_super_duper',
	'edit_posts' => 'edit_super_dupers',
	'edit_others_posts' => 'edit_others_super_dupers',
	'publish_posts' => 'publish_super_dupers',
	'read_post' => 'read_super_duper',
	'read_private_posts' => 'read_private_super_dupers',
	'delete_post' => 'delete_super_duper',
),

supports

Permite definir que cajas van a estar visibles a la hora de crear/editar un nuevo post del tipo definido. Para ello pasaremos un listado con los nombres de las mismas.

• title: Caja de título
• editor: Editor donde va el contenido del post
• comments: Posibilidad de activar/desactivar los comentarios
• trackbacks: Capacidad de activar/desactivar los trackbacks
• revisions: Permitir ver las revisiones
• author: Caja para definir el autor
• excerpt: Caja de excerpt.
• thumbnail: Caja para definir la miniatura del post.
• custom-fields: Caja de Custom Fields
• page-attributes: Atributos de páginas

Ejemplo

'supports' => array( 'title', 'editor', 'excerpt', 'custom-fields', 'thumbnail' ),

rewrite

La URL también puede ser personalizada mediante un simple parámetro que especificará el enlace usado. Para ello debemos especificar estos parámetros:

• slug: El prefijo del post
• with_front:  Si el prefijo ha de estar en el frontend.

Más información

• Custom Post Types << WordPress Codex
• Custom Post Types in WordPress
• Custom Post Types in WordPress 3.0
• Extending Custom Post Types in WordPress 3.0
• register_post_type() << WordPress Codex

Actualización

1. Custom Post Types UI, plugin que nos genera un cómodo interface web donde personalizar nuestros tipos de posts. Via.
2. Magic Fields, plugin que permite generar interfaces amigables para todas las opciones de WordPress, inlcuye la opción de Custom Post Types.Via judas.

David Walsh, publica un artículo donde nos muestra una serie de opciones, en diferentes lenguajes, para detectar el iPad desde nuestra aplicación web.

Básicamente se encarga de comprobar el userAgent que el dispositivo deja impreso en las cabeceras en las que solicita la página para detectarlo y condicionar la respuesta al usuario.

Continua —>

Perdonarme por la pedazo de frikada que voy a poner ahora, pero me ha hecho gracia y no quiero ser el único que la ha sufrido 😀

Ojo!, Spoiler, si no has visto el capítulo 6×04 no sigas.

Continua —>

Aunque sin él yo no podría escribir mis artículos, es posible deshabilitar el editor HTML de nuestro WordPress de una forma sencilla con alguna de estas opciones:

1) CSS: La opción con más estilo (¿lo pillais? :P)

Sin duda se trata de la solución más rápida y sencilla ya que simplemente tendremos que añadir un estilo CSS al panel de administrador.

// Añadir el CSS directamente
function removeHTMLEditorCSS(){
 echo '<style type="text/css">#editor-toolbar #edButtonHTML, #quicktags {display: none;}</style>';
}

add_action('admin_head', 'removeHTMLEditorCSS');

// Añadir un fichero CSS externo
fichero: removeHTMLEditor.css
#editor-toolbar #edButtonHTML, #quicktags {display: none;}

wp_register_style('removeHTMLEditorCSS', '/ruta/css/removeHTMLEditor.css');
wp_enqueue_style('removeHTMLEditorCSS');

2) Javascript: La más rápida

Desde Javascript podemos borrar directamente el botón y no permitir usar esta opción:

function removeHTMLEditorJS(){
 echo 'jQuery(document).ready(function($) {
         $("#edButtonHTML").remove();
       });';
}

add_action('admin_footer', 'removeHTMLEditorJS');

3) PHP: La más limpia

En las dos anteriores, aunque son efectivas, dejamos la opción de recuperar la opción directamente desde el mismo navegador, desde PHP podemos eliminar el botón dejando la opción perfectamente deshabilitada.

function my_default_editor() {
 $r = 'tinymce'; // html or tinymce
 return $r;
}
add_filter( 'wp_default_editor', 'my_default_editor' );

// Versión reducida
add_filter( 'wp_default_editor', create_function('', 'return "tinymce";') );

Conclusión

Siempre que puedas estas cosas, deberían ir en un fichero de configuración alojado en el servidor y todas las opciones son igual de válidas.

Un módulo del estandar RDF, concretamente el destinado sobre la frecuencia de sincronización, que este próximo año cumplirá 10 años de su aparición nos permite especificar la frecuencia con la que los agregadores de noticia deben comprobar si el feed ha cambiado.

Por defecto WordPress, asume que eres una máquina y que no paras de actualizar en todo el día:

<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>

WordPress nos añade dos filtros para modificar esta frecuencia a nuestro gusto. Para ello bastará con incluir estas líneas en el fichero functions.php de nuestro theme para conseguir una frecuencia de sincronización de 4 veces al día.

add_filter( 'rss_update_period',    create_function( '', 'return "daily";' ) );
add_filter( 'rss_update_frequency', create_function( '', 'return 4;' ) );

Via