Por eso quería traer algunos ejemplos de cómo conseguir lo que necesitamos realizando algunas modificaciones directamente en nuestra plantilla de WordPress.

Uno de los ámbitos que más suelen preocupar y que más tiende a hacer un uso intensivo de plugins es el SEO. Aún no sé si escribiré artículos más avanzados, pero de momento empezaremos por lo básico: título y descripción de las páginas.

¿Qué necesitamos?

Esto no va a ser una clase de SEO, de modo que supondremos que ya sabemos cómo escribir y escoger los textos para las distintas partes de cada página.

Lo que necesitamos es que cada página pueda mostrar un título y una descripción diferentes. Por ejemplo, hay montones de plantillas que utilizan la misma descripción para todas las páginas del blog (la descripción del blog, configurada en Ajustes > Generales) o directamente no ponen descripción en ninguna página salvo la principal.

¿Cómo lo hacemos?

Con el título lo tenemos fácil, sobre todo porque seguramente la plantilla en cuestión ya lo esté haciendo bien (o más o menos bien). Mi método suele ser el siguiente:

<title>
<?php
	if(is_home() or is_front_page())
	{
		$site_name = get_bloginfo('name', 'display');
		echo $site_name;
	}
	else
	{
		wp_title('', True, 'right');
	}
?>
</title>

A veces puede ser suficiente con utilizar la función wp_title, pero en muchos casos aparecerá un título en blanco en la página principal.

Otro modo de hacer lo mismo pero más “elegante” sería añadir un filtro a wp_title:

function filter_wp_title($title)
{
	if(is_home() or is_front_page())
	{
		$site_name = get_bloginfo('name', 'display');
		return $site_name;
	}
	return $title;
}
add_filter('wp_title', 'filter_wp_title');

Pero personalmente prefiero dejar el fichero functions.php lo más limpio posible. Manías.

El resultado de la función wp_title es predecible (títulos de artículos, nombres de categorías…) y suele ser suficiente. En caso de querer algo muy sofisticado y completamente diferente a lo habitual, con las herramientas anteriores se puede hacer casi de todo.

Con la descripción tendremos que ser un poco más creativos. Mi opción favorita para esto son los “campos personalizados” que WordPress permite añadir tanto a los artículos como a las páginas.

Creo un campo personalizado llamado “meta_description” y lo añado en cada nueva página. Para los artículos, el propio WordPress permite añadir un “extracto”, que por alguna razón no se suele utilizar pero puede ser muy útil. WordPress también permite dar descripciones a las categorías.

De modo que para la página principal utilizo la descripción del blog, para las categorías su propia descripción, para los artículos el extracto y para las páginas el campo personalizado “meta_description”.

Todo esto traducido a código sería algo así:

$meta_description = '';
	if(is_home() or is_front_page())
	{
		$meta_description = get_bloginfo('description', 'display');
	}
	elseif(is_single() or is_page())
	{
		if(has_excerpt()) $meta_description = get_the_excerpt();
		else $meta_description = get_post_meta(get_the_ID(), 'meta_description', True);
	}
	elseif(is_category())
	{
		$meta_description = category_description();
	}
	if($meta_description)
	{ 
		$meta_description = strip_tags($meta_description);
		echo '<meta name="description" content="'.$meta_description.'" />'; 
	}

En los artículos sin extracto se intentará utilizar el campo personalizado igual que en las páginas.

¿Y las keywords?

Me sorprende que a estas alturas aún se siga hablando de las “meta keywords” junto con el título y descripción. Simplemente no deberían usarse, al menos no como antes.

Este artículo de Google (de Septiembre de 2009) deja bastante claro que en el mejor de los casos no sirven para nada y en el peor de los casos podría ser perjudicial. Desde el punto e vista de Google, claro.

Hasta la fecha no hay señales de que esto haya cambiado o vaya a cambiar, y personalmente no creo que otros buscadores den algún tipo de valor positivo a esta meta-información.

Digamos que el contenido de tu canvas va cambiando. Si se hace más grande que el canvas pintarás fuera. Si se hace demasiado pequeño se verá ridículo con todo el espacio disponible alrededor. También puede ocurrir que en lugar de variar el tamaño del dibujo, sea el tamaño del canvas lo que cambie.

Hay técnicas básicas para escalar el contenido del canvas mediante CSS, pero sólo son útiles en casos muy concretos y sencillos.

Yo utilizo un método bastante sencillo pero que funciona muy bien:

1. Coloco los elementos dentro del canvas con el tamaño que me convenga.
2. Mantengo una lista de “puntos clave” en el dibujo.
3. Calculo la escala óptima para que todos los puntos clave quepan dentro del canvas manteniendo el dibujo lo más grande posible.
4. Aplico la escala al dibujo.
5. Recoloco el dibujo, pegándolo a la esquina superior izquierda.
6. Cada vez que haya un cambio en el dibujo (o en el tamaño del canvas) habrá que recalcular la escala y mover de nuevo el dibujo a la esquina si es necesario.

Se este modo el dibujo se ve siempre lo más grande posible.

Es importante tener claro que todos los elementos tendrán una doble representación. Por una parte tendremos las coordenadas y medidas “reales” que manejaremos internamente y por otra parte las que utilicemos para pintarlos al aplicar la escala.

¿Por qué dos medidas diferentes?

Supongamos que tenemos una línea que representa una pared que mide 4 metros. Por comodidad decidimos que vamos a tomar como referencia 1px = 1cm, de modo que tenemos una línea de 400px.

Si va recta desde la esquina superior izquierda hacia la derecha, la línea comenzará en las coordenadas (0/0) y terminará en (400/0). Internamente es mejor guardar las líneas como puntos así que nos guardamos esas dos coordenadas como representación de nuestra “pared”.

Pero el canvas que tenemos para dibujar es muy pequeño, digamos que de 200 x 200 píxeles. La escala a aplicar se ve claramente que es 0,5. Sin embargo, sólo aplicamos la escala en el momento de dibujar la línea, sin modificar las coordenadas reales del elemento.

De este modo conservamos los valores reales para otros usos y al mismo tiempo evitamos arrastrar pequeños errores de redondeo, ya que la escala se aplica siempre sobre el valor original en lugar de sobre valores que ya se han escalado anteriormente.

Los puntos clave.

Lo que suelo hacer es guardarme una lista con la posición de cada uno de los puntos que definen los extremos de los objetos. Los dos extremos de una línea, los vértices de un polígono, las 4 esquinas de una imagen…

Normalmente estos puntos sirven también para otros propósitos. Pero si no los necesito para nada más, otra opción es guardar solamente los puntos más extremos del dibujo ya que son los que usaremos para decidir la escala. En este caso tendremos que estar seguros de mantener los puntos actualizados si los elementos se mueven.

La escala.

La función para calcular la escala dependerá de cómo desarrollemos la aplicación, pero en general es muy fácil.

Tenemos que localizar los “bordes” del dibujo, que vienen a ser los valores máximos y mínimos de las coordenadas X e Y. Son 4 valores que delimitan el dibujo y pueden pertenecer a 4 puntos diferentes (el valor mínimo de X y de Y por ejemplo, no tienen por qué ser del mismo punto):

Con los 4 valores encontrados, tendremos dos posibles escalas que calcular. El ancho del dibujo viene marcado por la distancia entre los valores mínimo y máximo de X. La relación entre el ancho del canvas y del dibujo nos da la escala óptima para el eje X, y lo mismo sucede con el alto para el eje Y.

Si no es necesario mantener la relación de aspecto en el dibujo podemos directamente aplicar la escala óptima a cada eje, de lo contrario nos quedaremos con la menor y aplicaremos la misma a los dos.

Por último sólo tenemos que mover todo el contenido del canvas para pegarlo a la esquina superior izquierda. Para ello calculamos la distancia entre la esquina superior izquierda (0/0 si no estamos dejando ningún margen) para ambos ejes y la restamos a la posición de todos los elementos.

En el caso de aplicar la misma escala a ambos ejes seguramente nos sobre espacio a un lado del canvas, así que podemos optar por centrar el dibujo en lugar de moverlo completamente a la esquina.

El código:

Podéis ver un ejemplo en el siguiente enlace: Ejemplo de escala en canvas.

Por comodidad está todo el código en la misma página, basta con ver el código fuente desde el navegador o guardarla y abrirla con un editor de texto.

La interfaz para facilitar los datos de la empresa y la tienda es clara. El problema viene al generar el fichero CSV con los datos de los productos. Ni siquiera queda claro cómo se deben de llamar los campos y terminas a base de prueba y error, corrigiendo poco a poco las cosas que te dicen que están mal, en un castellano que se ve que no es su primer ni su segundo idioma. Al menos esa es mi experiencia con ellos.

Tras preparar un módulo de Prestashop (1.5, pero no creo que haya mucho problema en pasarlo a 1.6) he pensado en compartirlo por si alguien quiere usarlo o adaptarlo a sus necesidades.

Los campos exportados para cada producto son:

• Categoría: El nombre de la categoría principal del producto en la tienda.
• Referencia interna: La referencia del producto en la tienda (no la del proveedor).
• Título: El nombre del producto.
• Descripción: La descripción corta del producto.
• Precio: El precio del producto base, sin contar los atributos.
• URL producto: La URL de la página del producto.
• URL imagen: La URL de la imagen principal del producto.
• Gastos de envío: Modificable en la configuración del módulo.
• Disponibilidad: Todos los productos se marcan como disponibles ya que el módulo solo exporta los productos disponibles.
• Plazo de entrega: Modificable en la configuración del módulo.
• Garantía: Este campo es obligatorio que aparezca, pero lo dejamos siempre vacío.

Es sencillito y se puede ampliar mucho, pero en mi caso es más que suficiente. Si alguien quiere usarlo es posible que necesite hacerle alguna modificación. Está probado con Mercamania, pero debería funcionar tal cual con el resto de servicios de LeGuide (Pikengo, choozen, dooyoo…).

Así es como se ve la pantalla de configuración:

Básicamente lo que hace es crear un CSV al vuelo al acceder a cualquiera de las URLs que aparecen al final, a partir de los parámetros configurados.

Está escrito siguiendo el estándar de codificación de addons.prestashop.com (que es diferente a mi estilo habitual) ya que hice el intento de publicarlo como si lo fuese a vender, para ver si pasaba el análisis técnico que hacen a los módulos (y lo pasó).

El módulo en cuestión lo podéis encontrar en Google Code. Cualquier aportación es bienvenida.

Logotipo de Hack, el nuevo lenguaje de programación creado por Facebook y basado en PHP.

Hace poco que Facebook ha liberado su lenguaje de programación Hack, un nombre desafortunado para buscar en Google (prueba a buscar “hack code sample”).

Para echarle un vistazo rápido, el pequeño tutorial (inglés) que han preparado es un modo de empezar. Para empezar a probarlo más en serio se puede instalar una máquina virtual de Vagrant (inglés) con HHVM (inglés). Googleando un poco se encuentran máquinas virtuales ya listas para utilizar.

En docs.hhvm.com está toda la documentación sobre HHVM y Hack. De momento toda la documentación es en inglés, pero supongo que con el tiempo la irán traduciendo.

Ya hay montones de artículos por ahí enumerando las características y novedades del lenguaje (y se pueden leer en la web oficial o en el mismo índice del manual, no hace falta irse más lejos), así que me centraré en dos reflexiones que seguramente estaremos haciendo muchos ahora mismo:

¿Vale la pena aprenderlo y utilizarlo?

Si ya controlas PHP y comprendes los nuevos conceptos añadidos por Hack de trabajar con otros lenguajes, realmente hay poco que aprender salvo algunas reglas más de sintaxis. El resto es como en todos los lenguajes, usarlo lo suficiente como para aprender a “pensar en Hack” para sacarle el máximo partido.

Usarlo o no supongo que depende del punto de vista. Si quieres trabajar en Facebook, ya estás tardando :D. Creo que no se pierde nada por probarlo en una pequeña aplicación, aunque sólo sea por curiosidad. Pero para un proyecto serio me lo tendría que pensar.

Tiene desde luego un punto muy a favor: si Facebook lleva un tiempo utilizándolo, mal no debe funcionar. A esto se añaden todas las mejoras sobre PHP, que a simple vista parecen muy atractivas.

Sin embargo, hay que tener en cuenta un par de cosas. Supongamos que empiezas un proyecto nuevo y decides desarrollarlo con Hack. Supongamos también que dentro de dos años Facebook decide migrar a Python (por decir algo) y abandona el desarrollo de Hack y de HHVM. Como “la comunidad” no retome el proyecto y además lo haga bien (que puede pasar) vas a tener un problema.

También hay que tener en cuenta que HHVM y Hack están creados por Facebook para satisfacer sus necesidades específicas. Estas necesidades pueden coincidir con las tuyas o no.

¿Hack va a sustituir a PHP?

Pues no lo creo, al menos en mucho tiempo.

Supongamos por un momento que Hack es “superior” a PHP en todos los aspectos. Aunque fuese así, es muy difícil que los grandes frameworks y CMS se conviertan y mantengan dos versiones del software (Hack y PHP).

Por otra parte, el grueso de la comunidad de PHP está demasiado acostumbrado a buscar en Google cómo hacer X cosa en PHP y encontrar 40 implementaciones donde elegir. Por mucho que se pueda hablar de las bondades de PHP, su mejor carta es la enorme cantidad de código que ya hay escrito.

También es posible que con el tiempo PHP vaya adoptando características de Hack. Seguramente incluyendo el tipado gradual (la característica estrella de Hack) ya disuadiría a la mayoría de desarrolladores de “pasarse” a Hack, aunque no será lo que se dice una tarea fácil.

Estoy dando clases de desarrollo web a un amigo (y a mi padre, que ha aprovechado para apuntarse). Empezamos por HTML 4.01 (aunque tal vez debería haber ido directamente al XHTML) y me gustaría llegar al menos a lo más básico de bases de datos con MySQL, si esque no se me quedan por el camino.

La verdad es que conozco a muchas personas que desarrollan sitios web, desde páginas muy sencillas hasta complejas aplicaciones web, y por alguna razón las que (en mi opinión) lo hacen no sólo con mayor soltura, sino también con mayor corrección, son aquellas que han aprendido por sí mismas. De acuerdo, suena bastante raro viniendo de alguien que precisamente se encuentra enseñando a otras personas, pero es la verdad. Probablemente se deba a que los únicos que de verdad se leen las especificaciones y documentaciones oficiales son los autodidactas.

Yo personalmente prefiero leer la documentación completa en lugar de que alguien decida por mí qué partes son las que me interesan, y analizar qué es lo que más se utiliza (y si es bueno o no) leyendo código de otras personas.

En el caso concreto de HTML creo que la especificación se digiere bastante bien. Una vez leída y comprendida, si pasas a leer manuales y demás probablemente aprendas cómo los demás hacen cosas que no se te ocurrirían fácilmente, pero podrás distinguir quién hace las cosas bien y quién no. Es decir: sabrás de quién debes aprender. Bien es cierto que en este caso no estamos hablando exactamente de un estándar, sino de una recomendación del W3C, pero el mundo sería mucho más bonito si todos hiciésemos caso a estas buenas personas, y digan lo que digan creo que nadie me hará cambiar de opinión. Claro que hay otros casos en los que la especificación no es tan fácil de digerir (ECMAScript para mí fue un infierno), pero si uno sabe buscar siempre se encuentra algún punto por el que empezar.

Lo que quiero decir con todo esto es que cuando aprendes de otra persona, normalmente dependerá mucho de quién te enseñe, pero si decides aprender por ti mismo lo mejor es empezar siempre por la documentación oficial.

Los principales inconvenientes suelen ser el tiempo (generalmente es más rápido leer un manual que te explique lo que necesitas saber y deje de lado lo que sea prescindible) y el idioma (todos sabemos que en Internet la información de mayor calidad suele encontrarse en inglés) pero en este mundillo uno está prácticamente obligado a “aprender a aprender” (y a actualizarse) y al menos comprender el inglés escrito.