Tutoriales DWEB

AJAX entre dominios con el estándar CORS (Cross-Origin Resource Sharing)

Pablo — Sun, 13 Feb 2011 17:57:56 +0000

La generalización de AJAX ha supuesto un impulso gigantesco para el desarrollo de aplicaciones web cada vez más importantes. Avanzamos claramente hacia aplicaciones que integran, mediante AJAX, servicios o módulos desarrollados por terceros (Google, Yahoo, Facebook, etc). Sin embargo esta tendencia se ha topado con un problema importante: la política del mismo origen (Same Origin Policy), que impide que se puedan realizar peticiones HTTP desde JavaScript a un dominio diferente.

Además de diferentes hacks que se han ido desarrollando con el tiempo para rodear el problema, existe una especificación del W3C para solucionarlo: Cross-Origin Resource Sharing (CORS), que podriamos traducir como “Compartición de Recursos entre Origenes”.

Política del Mismo Origen

Same Origin Policy es una importante medida de seguridad que implementan actualmente todos los navegadores. Significa que una web sólo puede utilizar el objeto XMLHttpRequest para hacer peticiones HTTP AJAX al mismo domino desde el que se cargó la página original. Las peticiones a dominios diferentes serán descartadas.

Same Origin Policy impide comunicación AJAX entre origenes diferentes

¿Qué se entiende por un dominio diferente? además del evidente nombre del dominio, tampoco se permite comunicación si cambia el protocolo (por ejemplo de http a https) o el puerto.

Origen: protocolo, dominio y puerto

Esto quiere decir que tampoco nos funcionará una petición desde una página cargada de http:www.miweb.com a https:www.miweb.com. Aunque en este caso lo único que cambia es que utilizamos el protocolo seguro https, pero no es posible.

La necesidad de poder hacer estas peticiones como parte de las aplicaciones actuales ha llevado a buscar varias soluciones:

JSONP
Servidor Proxy
uso de iFrames
CORS

Las tres primeras son en realidad diferentes formas de ‘rodear’ el problema en vez de solucionarlo, sólo CORS trata de definir un estándar para crear una forma de comunicación por AJAX entre diferentes dominios.

¿En qué consiste el estándar Cross-Origin Resource Sharing?

El estándar propone incluir nuevas cabeceras HTTP en la comunicación cliente-servidor para saber si se debe enviar (servidor) o mostrar (navegador) un recurso concreto, en función del origen de la petición.

La idea es que mediante la información que se intercambia en las cabeceras HTTP el servidor y el navegador puedan decidir si esa petición, desde ese origen, puede permitirse.

EL navegador, cuando se va a realizar una petición asíncrona a un dominio diferente, debe incluir automáticamente la cabecera ORIGIN en la petición:

Origin: http://www.sitio1.com

Esta cabecera indicará al servidor el dominio desde el que se está haciendo la petición (desde el que se recibió la página original). El servidor tendrá una lista de dominios permitidos y, si este está en la lista, devolverá el recurso solicitado incluyendo en la respuesta la nueva cabecera Access-Control-Allow-Origin:

Access-Control-Allow-Origin: http://www.sitio1.com

Con esta cabecera el servidor indica el origen al que le permite leer este contenido. El navegador siempre comprobará esta cabecera. Si no se recibe o no indica el dominio correcto, bloqueará la respuesta para no permitir acceso al DOM a ningún script procedente de un dominio ‘extraño’.

Este es el funcionamiento básico. El estándar define también otro tipo de petición más compleja, que requiere un intercambio previo de cabeceras para decidir si puede enviarse. Vamos a ver a continuación los dos casos en detalle.

Petición simple

Una petición se considera simple cuando:

Utilizamos el método GET
Utilizamos POST para enviar datos pero el tipo de contenido (Content-Type) es: application/x-www-form-urlencoded, multipart/form-data, o text/plain
No incluimos cabeceras HTTP personalizadas en la petición

En este caso el procedimiento es tan simple como el que hemos descrito antes.

Supongamos que vamos a hacer una petición GET mediante AJAX, utilizando el objeto XMLHttpRequest, desde una página cargada de www.sitio1.com. El destino de la petición es www.sitio2.com/utilidad.php

El navegador incluirá automáticamente la nueva cabecera HTTP ORIGIN al detectar un intento de comunicación a un dominio diferente.

La petición HTTP, entre otras cabeceras, enviará:

GET /utilidad.php HTTP/1.1
Host: www.sitio2.com
   ...
Origin: http://www.sitio1.com

La última linea es la que incluyen los navegadores que soportan el nuevo estándar, indicando al servidor que esta petición llega desde contenido cargado desde otro dominio (www.sitio1.com).

El servidor comprobará que el dominio www.sitio1.com está en la lista de aceptados y enviará la respuesta, por ejemplo:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: http://www.sitio1.com

[Data]

La cabecera Access-Control-Allow-Origin se incluye como parte de CORS, para indicar al navegador que esta información puede ser leido por el origen indicado. Si esta cabecera no aparece o el origen indicado no es el de la página cargada, el navegador bloqueará la respuesta.

Este tipo de peticiones simples son soportadas por los navegadores mayoritarios (Internet Explorer 8+, Firefox 3.5+, Safari 4+, and Chrome) y pueden ser suficientes para utilizar servicios públicos de terceros.

Petición con verificación previa (preflighted)

El estándar propone que para peticiones más complejas, que incluyan cabeceras HTTP personalizadas, métodos HTTP diferentes de GET o POST o con Content-Type diferente de los tres listados anteriormente (por ejemplo application/xml), se haga una verificación previa.

La idea es utilizar este método para todas las peticiones que puedan implicar cambios en datos almacenados en el servidor. Este tipo de peticiones se hacen en dos pasos:

Determinar, utilizando la cabecera OPTIONS, si la petición se puede mandar
Enviar la petición

En la primera parte del proceso, el navegador informará al servidor, mediante cabeceras, de los métodos y cabeceras personalizadas que va a utilizar en la petición para ver si el servidor las acepta. También indicará si pretende enviar información de autenticación o cookies, pero esto lo veremos en otro apartado.

Un ejemplo de petición podría ser este:

OPTIONS /utilidad.php HTTP/1.1
Host: www.sitio2.com
...
Origin: http://www.sitio1.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-CUSTOM

OPTIONS no es en realidad una cabecera nueva, forma parte del estándar HTTP 1.1 y se utiliza para obtener más información sobre las opciones que soporta el servidor.

Las tres últimas cabeceras sí son particulares de CORS y, en este caso, indicarían que se pretende enviar una petición desde el origen www.sitio1.com, utilizando el método POST e incluyendo la cabecera personalizada X-CUSTOM. El servidor responderá indicando las cabeceras y métodos que permite para este origen.

La respuesta podría ser algo así:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: http://www.sitio1.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-CUSTOM
Access-Control-Max-Age: 1500000
Content-Type: text/plain

Viendo estas cabeceras el navegador sabe que puede enviar la petición y que el servidor la acepta. Access-Control-Max-Age sirve para indicar el tiempo, en segundos, durante el que esta misma petición puede hacerse directamente, sin el proceso de preflight.

A continuación se enviará la petición real, incluyendo la cabecera ORIGIN y el servidor enviará la respuesta incluyendo la cabecera Access-Control-Allow-Origin: http://www.sitio1.com como en una petición simple.

El nuevo XMLHttpRequest de nivel 2

Las peticiones AJAX se realizan a través del objeto XMLHttpRequest (XHR). Era necesario actualizarlo para permitir las comunicaciones inter-dominios en los casos y las condiciones que contempla el estándar Cross-Origin Resource Sharing. Estas nuevas capacidades, junto con algunas más, se definen en el estándar XMLHttpRequest Nivel 2.

Microsoft ha decidido, una vez más, no seguir los estándares e implementar la funcionalidad de CORS mediante un objeto diferente llamado XDomainRequest (XDR), en vez de aumentar las capacidades de XMLHttpRequest. Mas adelante veremos las limitaciones que esto supone.

Afortunadamente los métodos y propiedades que debemos utilizar son comunes por lo que sólo tenemos que decidir qué objeto instanciamos. El interface que podemos usar con cualquiera de los dos objetos es el siguiente:

abort() – detiene una petición en marcha
onerror – para asignar el callback que se dispara en caso de error
onload – para asignar el callback que se dispara en caso de éxito
open() – establece el método y URL para la petición HTTP
responseText – propiedad en la que se almacenan los datos de la respuesta
send() – Para enviar la petición

Un ejemplo sencillo de cómo podriamos usar el objeto XHR en una petición a un dominio diferente sería:

var xhrObject = new XMLHttpRequest();
xhrObject.open("get", "http://www.sitio2.com/utilidad.php");
xhrObject.onload = function(){
   alert(xhrObjet.responseText)
};
xhrObject.send(null);

El objeto XHR se crea normalmente, y se utiliza open() y send() igual que para peticiones normales. La diferencia es que el evento que se dispara cuando la petición se ha recibido con éxito es load. Por eso definimos nuestra función callback para manejar el resultado en xhrObject.onload. Para una llamada AJAX normal, en el dominio propio, definiriamos el callback en xhrObject.onreadystatechange

En este ejemplo, cuando la petición se completa, mostramos los datos que hemos recibido en xhrObjet.responseText con un alert().

El objeto XDomainRequest del IE se utilizaría exactamente igual:

var xdrObject = new XDomainRequest();
xdrObject.open("get", "http://www.sitio2.com/utilidad.php");
xdrObject.onload = function(){
   alert(xdrObjet.responseText)
};
xdrObject.send(null);

En un caso real no es necesario duplicar el código, símplemente tenemos que detectar qué objeto debemos crear.

Para saber si el navegador en el que estamos soporta el nuevo objeto XHR, con las capacidades CORS, comprobaremos si el objeto tiene definida la propiedad withCredentials, exclusiva del XHR nivel 2 y que más adelante veremos cómo se utiliza. Si el resultado es negativo debemos preguntar si existe el objeto XDomainRequest para saber si estamos en alguna versión del IE con soporte CORS. Si el resultado también es negativo, no tenemos soporte para peticiones AJAX inter-dominios.

El ejemplo anterior, con un código único sería:

//Función para encapsular la detección del objeto que tenemos que usar para AJAX inter-dominios, según el navegador en el que estemos.
function createCorsObject(){

//Inicialmente creamos XHR
var xhrObject = new XMLHttpRequest();
    //comprobamos si XHR tiene capacidades CORS o es el antiguo
    if ("withCredentials" in xhrObject){
        return xhrObject;
    }
    //si es el antiguo, comprobamos si el navegador soporta el objeto XDR
    else if (typeof XDomainRequest != "undefined"){
         xhrObject = new XDomainRequest();
    } else {
    xhrObject = null;
    }
return xhrObject;
}

//obtenemos un objeto para AJAX cross-dominio
var xhrObject = createCorsObject();

//si tenemos un objeto válido...
if (xhrObject){

//definimos los parámetros de la petición HTTP
xhrObject.open("get", "http://www.sitio2.com/utilidad.php");

//definimos un callback para tratar los datos que recibamos
xhrObject.onload = function(){
alert(xhrObjet.responseText)
};

//definimos un callback para tratar el caso de error
xhrObject.onerror = function(){
    // código para caso de error
};

//Enviamos la petición
xhrObject.send(null);
}

Creo que los comentarios del código son suficiente para explicarlo. En este caso la novedad es que hemos definido también una función para tratar errores.

Peticiones con cookies o autentificación

Las cookies o la información de autentificación (certificados SSL o cabeceras HTTP de autenticación) no se envía nunca por defecto para este tipo de comunicación. Existe una propiedad del objeto XHR nivel 2 (el que implementan los navegadores que soportan CORS) que sirve para indicar que queremos enviar y recibir este tipo de información:

XHR.withCredentials = true;

Si el servidor permite el envío de este tipo de información para peticiones desde este origen lo indicará en la respuesta incluyendo una cabecera HTTP especial:

Access-Control-Allow-Origin:  http://www.sitio1.com
Access-Control-Allow-Credentials: true

Para estos casos, la cabecera Access-Control-Allow-Origin debe indicar el origen exacto, no puede indicarse un origen genérico mediante ‘*’.

El Internet Explorer 8 no soporta esta funcionalidad. El objeto XDR, propietario del IE, ni siquiera incluye la propiedad withCredentials. Nunca se enviarán cookies ni información de autenticación para este tipo de comunicación.

Las limitaciones de XDomainRequest (IE)

El Internet Explorer sólamente implementa una parte del estándar Cross-Origin Resource Sharing. Puede utilizarse para peticiones sencillas (obtener datos RSS o widgets para presentar en nuestra página) pero para comunicaciones complejas presenta las siguientes limitaciones importantes:

En ningún caso permite comunicación entre HTTPS y HTTP o viceversa
En ningún caso permite enviar cookies o información de autentificación
No permite peticiones con verificación previa (preflighted)
Sólo soporta Content-Type: text/plain
No permite añadir cabeceras HTTP personalizadas

Puedes obtener información más detallada en los documentos: XDomainRequest – Restrictions, Limitations and Workarounds y Client-side Cross-domain Security. En este último, Microsoft intenta explicar las razones por las que han elegido esta implementación y estas limitaciones.

¿Que seguridad aporta CORS?

En principio puede parecer que CORS no aporta mucha seguridad. Se basa en una cabecera ORIGIN que el servidor comprueba y en otras cabeceras de respuesta que el comprueba navegador. Enviar una cabecera ORIGIN falsa es algo trivial, al alcance de cualquiera y utilizar un navegador modificado que no bloquee las respuestas, también.

Sin embargo, el propósito de este estándar, es proteger al usuario que está navegando en su ordenador, con su navegador, de scripts maliciosos que intentarán acceder a páginas web sin que lo sepa, suplantando su identidad. Supongamos un caso con los siguientes actores:

Inocencio, el usuario que navega tranquilamente por internet desde su ordenador
Malone, un hacker con su propio sitio web de descargas www.pelisgratis.es
La tienda online www.tienda.com en la que Inocencio tiene una cuenta

Inocencio visita la web www.pelisgratis.es que le ha recomendado un amigo. La página inicial de ‘Pelis Gratis’ presenta el listado de películas e incluye también un script en JavaScript que, sin que Inocencio lo sepa, intenta utilizar AJAX para conectarse a la conocida tienda online www.tienda.com.

Si el hacker tiene suerte y el usuario ha abierto sesión en la tienda recientemente, aún tendrá la cookie de sesión válida y el servidor le reconoce como Inocencio. Malone puede utilizar su script para realizar cualquier cosa o robar cualquier información de la cuenta de Inocencio. Esto es lo que trata de impedirse mediante la Política del Origen Común y el estándar Compartición de Recursos entre Origenes

El caso del hacker usando un navegador modificado no presenta los mismos problemas porque no tendría la cookie del usuario para suplantarle. El acceso se protegería mediante la comprobación de credenciales (usuario/password).

La modificación de cabeceras en el trayecto de la información, entre el usuario y el destino, puede protegerse utilizando HTTPS.

CSS Float: Tutorial Visual (II)

Pablo — Fri, 19 Nov 2010 17:43:51 +0000

En la primera parte de este tutorial vimos los conceptos básicos de la propiedad float, ejemplos de cómo se comportan los elementos flotantes y cómo afectan a su entorno en el documento. Vamos a continuar viendo, también a través de ejemplos, cómo podemos modificar ese comportamiento.

Clear: Para no estar al lado de un float

Como ya hemos visto, un elemento flotante modifica el comportamiento de otros elementos de bloque, que suben para ocupar su sitio y su contenido se desplaza para dejarle hueco . Este comportamiento se puede evitar con la propiedad clear, que puede tomas los valores: left, right, both, none o inherit.

Clear se aplica a elementos de bloque no flotantes o a cualquier elemento flotante, forzándolos a desplazarse debajo de un float anterior si están al lado. Los valores indican a que lado del elemento no permitimos que haya un float: a la derecha, a la izquierda o a ambos.

Clear se aplica a elementos de bloque no flotantes o a cualquier elemento flotante, forzándolos a mostrarse debajo de un float

Vamos a retomar algunos ejemplos y aplicar clear para ver cómo afecta al resultado.

En la siguiente imagen tenemos 3 bloques con dimensiones diferentes y con float:left:

Los tres bloques con float:left

Si no queremos que el bloque azul se quede donde está, podemos ponerle clear:left. Con esto estamos indicando que este bloque no puede tener ningún float a su izquierda. Si hubiera alguno debe bajar hasta colocarse debajo. Y esto es lo que hace:

div#azul {
clear: left;
}

Bloque azul clear:left

Si en vez de eso aplicamos clear:left sólo al naranja:

div#naranja {
clear: left;
}

Bloque naranja clear:left

El naranja baja, porque no puede tener a su izquierda ningún bloque flotante y el azul se coloca a su lado. Si al bloque naranja le ponemos clear:both significa que no puede tener ningún elemento flotante a su izquierda ni a su derecha, pero si lo aplicamos veremos que no ocurre nada. Este ejemplo nos sirve para resaltar que la propiedad clear obliga a un elemento a colocarse debajo de un float anterior. Como el bloque azul está declarado despues en el HTML, no cambia nada.

Para desplazar el bloque azul podemos añadirle también clear:left:

div#naranja {
clear: left;

div#azul {
clear: left;
}

Bloque naranja y bloque azul con clear:left

Cuando tratamos con elementos no flotantes, la propiedad se aplica sólo a bloques, los elementos de línea no se ven afectados. En este ejemplo tenemos tres imágenes, el pez azul es flotante a la izquierda:

Pez azul float:left

Podriamos pensar que si le ponemos a la mariquita clear:left bajará a la siguiente línea, pero no es así, al ponerlo no cambia nada porque es un elemento de línea y no es flotante. Sin embargo, si tenemos imágenes dentro de bloques, sí podemos utilizarlo. En el siguiente ejemplo teníamos el pez azul con float:left y las otras dos imágenes en un div con borde rojo. El div ha subido al ser flotante la imagen del pez azul y las dos imágenes se han desplazado para dejarle sitio.

Pez azul con float:left. Las otras dos imágenes en un bloque

Si ahora le ponemos al div con borde rojo clear:left:

pez float:left, div con imágenes clear:left

El bloque no puede tener un float a su izquierda por lo que se desplaza abajo.

La propiedad clear es muy útil también para controlar como se coloca el texto alrededor de una imagen. En el siguiente ejemplo tenemos una imagen flotante a la izquierda y dos parrafos que hemos marcado con borde rojo:

imagen con float:left

Si no queremos que el segundo párrafo empiece a la derecha de la imagen le ponemos clear:left:

Imagen float:left, segundo párrafo con clear:left

Todo el bloque del párrafo baja para colocarse debajo del elemento flotante.

Si tenemos varias imágenes podemos utilizar clear para controlar cómo se colocan. En el siguiente ejemplo tenemos tres imágenes y a continuación 2 párrafos con el borde marcado en rojo. Ninguno es flotante:

Como queremos que el texto quede alrededor de las imágenes, vamos a hacerlas flotantes a la derecha, las tres ( float:right ). El resultado es:

Ejemplo con las imágenes flotantes a la derech

Si queremos que el corazón quede debajo del caballo, le ponemos clear: right:

Las tres imágenes float:right, Corazón clear:right

Como el corazón no puede tener ningún elemento flotante a su derecha, bajará para colocarse por debajo. El periódico, que es flotante a la derecha, como los otras imágenes, quedará al lado del corazón, y no del caballo porque los elementos flotantes se desplazan a derecha o izquierda en su línea. El corazón a bajado y, para el periódico, declarado en el HTML después del corazón, esta es ahora su linea.

Es muy importante tener en cuenta que para lograr la disposición que queramos tenemos que jugar con float/clear y con el orden en que declaramos los elementos en el HTML. Si queremos que el periódico quede al lado del caballo y el corazón debajo, tenemos que cambiar el orden de las imágenes en el HTML. Ponemos primero el caballo, después el periódico y después el corazón. Las tres imágenes con float:right y el corazón, ademas con clear:right. Nos quedaría:

Las tres imágenes float:right. Corazón clear:right

Igualmente, si queremos que el primer párrafo quede por encima de las imágenes, tendría que estar declarado antes.

Es muy importante tener en cuenta que para lograr la disposición que queramos tenemos que jugar con float/clear y con el orden en que declaramos los elementos en el HTML

Para que las tres imágenes queden en vertical tendríamos que poner clear:right a la segunda y la tercera:

Las tres imágenes con float:right. Periódico y corazón con clear:right

Y este es un buen punto para retomar la explicación de los elementos contenedores que se encogen sin tener en cuenta los floats…

El increíble contenedor menguante

La razón por la que el bloque contenedor se va encogiendo es sencilla: para los elementos de bloque (como el div contenedor) los elementos con float no ocupan espacio en la página, por lo tanto no los tiene en cuenta. En alguno de los ejemplos que hemos visto, con todos los elementos flotantes, el bloque no contiene nada. La única razón por la que no desaparece completamente es que tiene un padding declarado de 10px.

Este comportamiento a veces no es lo que queremos (ya veremos como se evita) y puede parecer un bug, un error de diseño, pero no lo es. Es una decisión consciente de los desarrolladores del estándar CSS y tiene una razón de ser: el texto que fluye alrededor de las imágenes flotadas.

Para entenderlo nos sirve un ejemplo similar al del apartado anterior. El siguiente documento tiene dos párrafos, y el primero de ellos contiene también una imagen:

Imagen y texto, ninguno flotante

Si hacemos la imagen flotante a la izquierda, todo queda como debe, el texto se coloca alrededor de la imagen como en los medios impresos tradicionales:

Imagen con float:left

Cada párrafo es un elemento de bloque que ha subido para recolocarse como si el float no estuviera ahí. El contenido de los bloques, al ser elementos de línea que quedan al lado de un float, acortan su longitud para dejarle sitio. El pez azul está dentro del párrafo 1, pero éste no le tiene en cuenta y se ha encogido hasta encerrar sólo al texto. Si el contenedor no ignorara al elemento flotante el resultado sería este:

Que, obviamente, no sería aceptable.

Soluciones al problema del contenedor

Vamos a partir de un ejemplo con una imagen y un bloque de texto, los dos dentro de un div contenedor (#wrapper) que hemos marcado con borde negro.

Ponemos la imagen flotante a la izquierda y el bloque de texto flotante a la derecha. El texto está dentro de un div al que hemos puesto borde rojo y al que hemos fijado una anchura de 365 pixels para que quepa al lado de la imagen. Estos serían los estilos aplicados a cada elemento:

div#wrapper {
   padding: 10px;
   width: 500px;
   border: 1px solid black;
}

img {
   float:left;
}

div#texto {
   float:right;
   border: 1px dotted red;
   width: 365px;
}

El resultado visual es:

imagen float:right, bloque de texto float:left

Como el texto y la imagen son flotantes, el contenedor no los tiene en cuenta y queda vacío. No desaparece por completo porque tiene un padding de 10px. Hay varias formas de solucionar esto, vamos a ir viéndolas una por una.

1.-Hacer el contenedor flotante

Si el contenedor es también flotante sí abarcará a los elementos flotantes dentro de él. Si le ponemos, por ejemplo, float:right :

Contenedor con float:right

Naturalmente esta solución no siempre puede aplicarse, porque muchas veces necesitamos que el contenedor no sea flotante. Si lo tenemos centrado en la página, por ejemplo, al ponerlo flotante se nos desplazará estropeándonos el diseño. Afortunadamente hay más soluciones.

2.- Poner un elemento con clear después de los flotantes

Esta solución es muy utilizada porque no tiene ‘efectos secundarios’. Si tenemos un elemento de bloque después de los flotantes es perfecto, le ponemos clear:both, y el contenedor, al tener que contener a este elemento, incluirá también a los que están por encima (los flotantes). Recuerda que clear se aplica a elementos de bloque.

Cuando no tenemos ningún elemento más, como en nuestro ejemplo, tenemos que incluir uno vacío, normalmente un div, sólo para ponerle el clear y arreglar el contenedor. Debajo del bloque que contiene el texto, añadiríamos el siguiente:

Definimos clear como una clase porque podemos utilizarla sobre otros elementos si los tenemos disponibles:

.clear {
clear: both;
}

Este div sería invisible, en la imagen de abajo le hemos puesto unos pixels de padding y borde verde para que se vea:

Div vacío con clear:both

El bloque contenedor se ha tenido que extender incluyendo a los float. El único problema de esta solución es que a veces tenemos que incluir elementos vacíos, que no tienen un significado real (semántico) en la página.

3.- Utilizar la propiedad CSS overflow

Si ponemos overflow:hidden o overflow:auto en el elemento padre (el contenedor en este caso) se expandirá siempre para abarcar a los elementos flotantes. Esta solución también es muy utilizada, sólo hay que tener en cuenta que esta propiedad implica también algo más, para saber si podemos aceptarlo:

overflow: hidden – Significa que el contenido que exceda de las dimensiones del div (si las tiene) se oculta, no habrá barra de desplazamiento ni se verán por fuera del div.

overflow: auto – Significa que si el contenido excede las dimensiones del div, aparecerán unas barras de desplazamiento para hacer scroll.

Algunos navegadores (IE6 por ejemplo) necesitan que el contenedor tenga fijada una anchura o altura para que la solución funcione bien.

Existen otros métodos, como el llamado clearfix hack que utiliza la pseudo clase CSS :after para generar un elemento dentro del contenedor con clear:both, como hicimos en el primer caso. No vamos a entrar en detalle en esta solución porque falla en algunos navegadores y necesita un poco más de código para hacerla funcionar.

Float para diseñar la estructura de una página

En la actualidad el esquema de posicionamiento float es muy utilizado para hacer el diseño general de una página o para disponer los elementos dentro de una parte de una página, normalmente un div.

Ahora que sabemos como funcionan, no es muy dificil ver cómo podemos utilizarlos para el diseño visual. No hay en realidad nada nuevo que explicar, sólo se trata de aplicar lo que sabemos para organizar los bloques generales que vamos a tener en la página.

¿Cómo podríamos hacer un diseño con una cabecera, un contenido principal, una columna a la derecha y un pie de página?. Bueno, pues así, por ejemplo:

Estructura de un documento con Floats

Hay varias formas posibles de hacerlo, la que vemos en la imagen es sólo una de ellas. De todas formas, veremos más adelante algún tutorial monográfico sobre disposición de elementos en formularios y en páginas utilizando floats.

Esto es todo por ahora, puedes plantear sugerencias, mejoras o dudas en los comentarios. También puedes decirnos si te gusta o no te gusta el tutorial.

Consejos SEO desde GOOGLE

Pablo — Mon, 15 Nov 2010 15:28:07 +0000

El 20 de Mayo del 2010 Matt Cutts y su equipo, del departamento de calidad de Google Search, hicieron una presentación sobre errores comunes y consejos a tener en cuenta para mejorar el posicionamiento de una web en buscadores.

En la charla Matt revisa páginas que la gente le ha enviado comentando errores y aciertos para conseguir un buen puesto en las búsquedas. Este artículo es un resumen de esa conferencia.

Web: Phoenician Stone

Web de Phoenician Stone

El error más notable de esta web (pensando en su posicionamiento) es que no tiene texto. Todas las palabras que vemos son imágenes, incluso el menú. Es imposible para Google saber su contenido. El único texto está en el código HTML, en las meta keywords:

desgraciadamente, este es casi el único texto que Google no indexa. Hay demasiada gente que utiliza las keywords para incluir todos los términos que creen que pueden llevar tráfico a su web, aunque no estén relacionados con el contenido. Google ya no se fía de esa etiqueta, la descarta.

El título de la página es también Phoenician Stone, y este es otro punto a mejorar. Aprovecha el título para dar una idea del contenido de tu página. Piensa en lo que los usuarios van a teclear cuando busquen los servicios que ofreces y pon esas palabras en tu página.

La herramienta para buscar palabras clave de Adwords puede ayudarte. Puedes teclear una frase de búsqueda y te mostrará búsquedas relacionadas que hace la gente.

Web: RodsBot

Web de RodsBot

Es una página que muestra sitios extraños capturados en Google Earth. ¿Como podríamos hacer que un sitio así puntúe alto en Google?. El principal problema es otra vez que la página tiene muy poco texto. ¿Cómo podríamos solucionarlo fácilmente? En un sitio como este, la mejor solución es hacer que los propios usuarios del sitio sean los que generen el texto: añadir comentarios y valoraciones de los usuarios y, por supuesto, utilizar twitter y facebook para promocionarlo un poco.

El mismo autor tiene otras 5 ó 6 webs más listadas al final. En general da mucho mejor resultado tener un solo sitio muy cuidado y trabajado que cinco sitios mediocres.

Web: Android And Me

Web de Android And Me

Lo primero que llama la atención al entrar en esta página es que, en la primera pantalla, apenas se ve contenido útil. Nos perdemos entre publicidad, menús, contenido relacionado, etc. No es malo mostrar todo esto pero podemos organizarlo de forma que no haya que desplazarse para ver algo de lo que ofreces, porque algunos visitantes no van a hacerlo.

Si utilizas WordPress en tu web (o Joomla, Drupal, etc) es importantísimo tenerlo siempre actualizado porque si no tu sitio sera infectado o hackeado.

El formato de las URLs que utiliza es bueno:

http://androidandme.com/2010/11/news/another-gingerbread-sighting-at-the-googleplex/

Incluye el título de los artículos como parte de la URL. Esos pequeños detalles, como usar palabras clave del artículo en la url y en el título, son importantes en SEO.

El título de Android And Me es Android And Me. No es muy buena idea. Estamos desperdiciando un lugar importante sin decir nada nuevo sobre la página. Podriamos poner, por ejemplo, Android News and reviews o algo similar.

Web: Surprises Galore (Hackeado)

Es un ejemplo de página que ha sido atacada y modificada. La página muestra uno de esos anuncios ‘Your computer is infected, click here to desinfect‘. Cando pulsas es cuando realmente te instala el virus. A veces el ataque puede ser también para que tu sitio muestre spam.

Puedes utilizar Google Webmaster Central para comprobar si tu web está infectada con algún tipo de software malicioso (malware). Si es así te informará y te propone una serie de pasos a seguir para solucionarlo. Es muy importante hacerlo porque si Google detecta que tu sitio contiene malware te bloqueará en los resultados de las búsquedas.

También te puedes llevar una sorpresa con el contenido de tu página si no moderas o revisas los comentarios. Puedes encontrarte que, debido a los comentarios spam, las palabras que más aparecen tu página pueden no ser las que tu quieres.

Web: The hookup

Web de The HookUp

Es una web sobre audio para el coche y las entradas son de este tipo:

Un producto y una lista de características. ¿Es este el tipo de entradas normales de un blog?. Lo único que el autor está haciendo es coger notas de prensa de productos para coches y pegarlos en su blog. No hay ni una línea de contenido original, con lo que Google lo valorará muy bajo. Puedes crear sitios de este tipo, no hay problema, pero cuando una web no tiene contenido original que mostrar, no subirá muy alto en el ranking de Google.

Escribir contenido original realmente marca la diferencia. La gente no guarda nunca un sitio como este sitio en favoritos, no siente necesidad de volver.

Web: Kathy Toth (Agente Inmobiliario)

Web de Kathy Toth

La web tiene bastante contenido original, pero una vez más tenemos que parte del texto son realmente imágenes. Ese texto no va a existir para Google.

Si pulsamos en el blog aparecen algunas cosas que deben cuidarse un poco. Las entradas no son originales y en algunas se habla, por ejemplo, de ‘La tortura del beso de Hillary Clinton’. Es bueno que el blog muestre tu lado humano, pero hay que saber hasta donde llegar. En una web de empresa, frases como esta pueden ser ofensivas para algunos clientes.

La empresa aparece en Google Maps. Es bueno no centrarse únicamente en la página web, puedes crear vídeos, puedes añadir imágenes en Flicker, utilizar Facebook, twitter, etc. No te centres únicamente en ser el primero en una búsqueda concreta, porque la gente va a buscar de miles de formas diferentes.

Es bueno comprobar de vez en cuando las frases de búsqueda por las que llegan a ti y incluirlas en un par de sitios en tu contenido (si encajan bien, sin spam). Esto puede hacerte subir en las búsquedas.

Utilizando Google Webmaster Central puedes ver en que tipo de busquedas apareces y también en que página.

Web: APPBrain

Web de APP Brain

En este caso la estructura de las URLs es también buena:

http://www.appbrain.com/app/fruit-slice/com.droidhen.fruit

Puedes usar un punto o un guión como separador de palabras. Se pueden utilizar guiones bajos también pero Google tiende a indexarlos como términos separados: ‘artículo-sobre-seo’ se indexa junto mientras que ‘artículo_sobre_seo’ puede indexarse como 3 términos separados.

El sitio está bastante bien en general, tienen contenido original y bien organizado. Un detalle importante es que presentan una lista de artículos relacionados con el que estás viendo. YouTube, por ejemplo, recibe una cantidad increíble de tráfico de sus vídeos relacionados. Si el visitante tiene un poco de tiempo (incluso si no lo tiene) es muy tentador ver algo muy relacionado con el tema que te ha llevado hasta allí.

Al contrario que meta keywords, la etiqueta meta description sí es importante. En las búsquedas, es el texto que aparecerá debajo del enlace en la página de resultados. Una buena descripción puede hacer el link más atractivo y atraer más a los usuarios. Si no hay meta description o es la misma en todas las páginas, Google intenta generar una con partes del texto de la página, y el resultado no siempre es bueno.

Web: Grow In Style

Web de Grow In Style

Tiene URLs ‘no amigables’ (unfriendly URL’s), ¿ Puede penalizarles eso en Google?

La imagen que vemos arriba tiene la URL:

http://www.growinstyle.com/shop/item.aspx?itemid=129

Si todo lo demás es bueno en la página no te preocupes mucho por las URLs. Si estas haciendo un sitio nuevo o no te supone mucho problema, cámbialo, pero no le des demasiada importancia, todos los motores de búsqueda trabajan bien con las URLs no amigables. Resumiendo, si puedes cambiarlas, es bueno, pero no debes preocuparte demasiado si no puedes.

Web: Jim Dantona

Web de Jim Dantona

Hay que tener cuidado que nuestros propios links estén bien organizados. A veces partes de nuestra web apuntan a contenido que tenemos en otro dominio, o tenemos contenido muy similar en dos páginas diferentes. Conviene evitar esto porque el page rank que conseguimos se divide en diferentes páginas o diferentes dominios. Es mejor tenerlo todo bajo el mismo dominio y que todas tus páginas sumen.

El título de la página es excelente:

Jim Dantona | Ventura County Clerk Recorder| Primary Election | Vote June 8th 2010

Es informativo, no contiene spam y tiene terminos que es facil que la gente interesada en las elecciones busque: Vote June 8th 2010, Primary Election, etc.

No es el caso de este sitio, pero hay veces que los autores quieren tomar un atajo para conseguir links a sus webs y en vez de tener contenido de calidad y esperar a que la gente les enlace, deciden compran links. Esto en general no es una buena idea porque los links suelen venir de páginas de muy mala calidad que no van a aportar visitas y Google puede incluso penalizar.

Nada más por hoy, si tienes más curiosidad puedes ver la charla original, en ingles: SEO Site advice form the experts

Puedes dejarnos algún comentario con tus impresiones

CSS Float: Tutorial Visual (I)

Pablo — Tue, 09 Nov 2010 20:06:40 +0000

Float es una propiedad CSS que define un tipo de posicionamiento de los elementos de una página web. En el estándar se definen tres esquemas de posicionamiento para presentar elementos:

Normal. (y aquí se incluye también el posicionamiento relativo).
Absoluto.
Flotante.

El flotante es, quizá, el menos intuitivo de los tres y el que presenta particularidades más ‘extrañas’ que intentaremos aclarar completamente en esta serie de dos tutoriales.

Conceptos Básicos

Para que un elemento flote utilizamos la propiedad float que puede tener los siguientes valores:

left – Flota a la izquierda
right – Flota a la derecha
none – No flota, valor por defecto
inherit – Hereda el valor del padre. No se utiliza porque en IE no funciona

Como vemos, un elemento no puede ser simplemente flotante, tiene que ser flotante a la derecha o flotante a la izquierda:

#elemento1 {
    float: right;
}
#elemento2 {
    float: left;
}

Que un elemento flote significa que intentará siempre desplazarse a la izquierda o a la derecha sobre la línea actual hasta chocar con el borde de su caja contenedora o de otro elemento flotante. Sólo otro elemento float puede interponerse entre él y el borde del contenedor. Veremos muchos ejemplos en los próximos apartados para entender todas las implicaciones de este comportamiento.

Hay cuatro reglas importantes que debemos tener en cuenta. Conociéndolas podremos siempre predecir dónde quedará un elemento si lo flotamos:

Las 4 reglas de oro de los float

Veremos también que este comportamiento se puede modificar con propiedades como clear o overflow.

Flotando Bloques

Vamos a empezar viendo cómo se comportan los elementos de bloque (divs en este ejemplo) cuando los flotamos. Trabajaremos con un documento con tres divs, cada uno con un fondo de color diferente.

En el HTML simplemente hemos declarado el título y tres divs vacíos dentro de un div (#wrapper) que los envuelve a todos:

	
		Sólo Bloques (Divs)

Y en la hoja de estilos CSS les hemos puesto un borde punteado, altura, anchura y un color de fondo diferente para cada uno:

		div#verde, div#naranja, div#azul {
			width: 130px;
			height:130px;
			border:1px dotted black;
		}
		div#verde {
			background-image: url(./images/verde.png);
		}
		div#naranja {
			background-image: url(./images/naranja.png);
		}
		div#azul {
			background-image: url(./images/azul.png);
		}

La página se verá así en pantalla:

Tres bloques (div) sin float

Si asignamos float:right al bloque naranja se desplazará a la derecha y saldrá del flujo de elementos de la página para los otros elementos de bloque, que ocuparan su lugar como si no existiera:

Div naranja float:right

¿Y si lo flotamos hacia la izquierda?

div naranja float:left

¿Qué ha pasado? Lo mismo que antes, el bloque flotante (naranja) sale del flujo de elementos de la página, los bloques que están debajo ocupan su lugar como si no existiera (el azul sube). El naranja se coloca en su línea hacia la izquierda hasta el borde del contenedor tapando el bloque azul.

Para los elementos de bloque, las cajas flotadas están fuera del flujo de elementos de la página, no ocupan espacio

¿Y si flotamos también el bloque azul?¿qué ocurrirá?

Bloque naranja y azul con float:left

Como siempre, los bloques que están por encima no se ven afectados, el título (h1) y el bloque verde siguen en su sitio, pero por debajo nos llama la atención que el bloque contenedor (#wrapper) se ha encogido dejando fuera los dos bloques con float:left. La razón es sencilla, para los elementos de bloque (como el div contenedor, con borde negro en la imagen), los elementos flotantes no ocupan espacio en la página, por lo tanto no los tiene en cuenta. Veremos esto en detalle mas adelante y veremos también varias formas de evitarlo.

Para saber en que orden quedan los bloques es importante saber cómo están declarados en el código HTML. En este caso el naranja está primero, flota hacia la izquierda y sále del flujo de elementos, por lo que el azul sube a su misma línea, después éste también flota hacia la izquierda por lo que se intentará colocar al lado del borde o de otros elementos flotantes anteriores. En este caso le toca detrás del naranja.

Si flotamos también el verde el resultado es:

Los tres bloques float:left

¿Y si flotamos también el título, al fin y al cabo es otro elemento de bloque (h1)?

Todos los elementos float:left

Como el título es el primer elemento, flota en su línea a la izquierda, los demás elementos van subiendo y flotando en su misma línea detrás de él. Cuando no hay sitio en la misma línea se desplazan a la siguiente, donde hay hueco para seguir colocándose. Y mientras tanto, el div contenedor a lo suyo, encogiendo hasta casi desaparecer.

Cuando un elemento fotado cambia de línea por falta de espacio, es muy importante tener en cuenta la altura de las cajas de cada uno, porque el elemento se quedará donde tenga un hueco y puede quedar colocado de forma extraña:

Ejemplo de bloques descolocados. Los tres bloques son flotantes a la izquierda

El bloque azul ha quedado ‘enganchado’ en el verde porque es unos pixels más alto que el naranja. Al cambiar de línea quedará en el primer lugar que quepa, tocando al bloque de arriba. En este caso el problema se ve muy claro, pero cuando no tenemos fondos de color y un borde marcado, los elementos quedan descuadrados y el problema no se ve fácilmente.

La siguiente situación es parecida pero ahora el bloque azul es más ancho que la distancia que queda entre el verde y el borde del contenedor, como no cabe debajo del naranja, se irá hasta el extremo:

Ejemplo de bloques desordenados. Todos los bloques con float:left

Elementos de Línea. Imágenes y Texto

Las líneas de texto, y cualquier elemento de línea en general (span, em, strong, etc), adaptarán su longitud al colocarse al lado de un elemento flotante, para dejarle hueco.

Vamos a empezar viendo como se comportan las imágenes, que actúan como elementos de línea aunque en realidad son una mezcla, inline-block, porque fluyen en la línea pero tienen altura y anchura definible con width y height.

Veamos un documento con tres imágenes:

Ningún elemento flotante

¿Qué ocurrirá si flotamos el pez azul hacia la izquierda?

img#pezAzul {
    float:left;
}

El pez azul se desplazará alegremente en su línea hacia la izquierda hasta el borde del contenedor (o hasta chocar con otro elemento flotante, pero en este caso no hay ninguno) y los otros elementos de línea (las otras dos imágenes), al estar al lado de un float, le harán hueco:

El pez azul con float:left

Si lo flotamos a la derecha:

Pez azul con float:right

La imagen se desplaza a la derecha hasta el borde y los otros elementos le dejan hueco.

¿Y si las imágenes estuvieran dentro de bloques, en un div?. Como siempre, para saber cómo van a quedar los elementos es importante saber en que orden están declarados en el código. Declaramos primero un título, luego la imagen del pez, y luego un div con borde rojo que contiene dos imágenes, la mariquita y el smiley:

	Imágenes en Divs

Las dos imágenes de abajo están contenidas en un div

Si ahora flotamos la imagen del pez hacia la izquierda:

Pez azul con float:left

Lo que ocurre es lo siguiente:

La imagen sále del flujo normal de elementos de la página por lo que no ocupa espacio (para los elementos de bloque)
El bloque de abajo (con borde rojo) sube para ocupar su espacio
Los elementos de línea (las 2 imágenes) se encuentran ahora al lado de un float y se desplazan para hacerle hueco

Este comportamiento se ve mucho más claro con las líneas de texto, que también son elementos de línea (faltaría mas) y normalmente están contenidas dentro de un párrafo (

…

) que es un elemento de bloque.

En el siguiente ejemplo tenemos un documento con un título, una imagen y un párrafo:

Sin floats

Si flotamos la imagen a la izquierda el bloque de texto subirá como si la imagen no existiera. Las líneas quedan ahora al lado de un float y se acortarán para fluir por el lado de la imagen:

Imagen con float:left

Si la flotamos a la derecha:

Imagen con float:right

Terminando por hoy …

Aqui vamos a terminar la primera entrega de este tutorial, en la segunda parte veremos:

Un amplísimo apartado sobre el uso de la propiedad clear, con numerosos ejemplos para ver cómo afecta a elementos de bloque y de línea, dependiendo de si son flotantes o no y cómo podemos utilizarlo para controlar la disposición de los elementos.
Porqué se produce el ‘problema’ del contenedor, que se encoge hasta desaparecer cuando contiene elementos flotantes. Veremos que esto no es un error, sino una decisión de diseño, sabremos el porqué y varias formas diferentes de evitarlo.
Cómo utilizar los floats para diseñar la estructura de una página.

Hasta el próximo tutorial! Deja tus comentarios si te ha gustado o si tienes alguna sugerencia.

Personalización Básica de una tienda en Magento

Pablo — Sun, 31 Oct 2010 13:03:10 +0000

En este tutorial nos vamos a centrar en personalizar la apariencia de una tienda de la forma más sencilla posible. Vamos a aprovechar que Magento tiene un excelente diseño en su tema por defecto y veremos como podemos darle un aspecto personalizado con cuatro pequeños cambios.

¿Qué vamos a hacer?

Vamos a crear una tienda de libros que se llamará Rosa de Papel. Partiremos del tema por defecto y veremos como hacer unos cambios sencillos para personalizar mínimamente la tienda.

El aspecto que presenta una tienda Magento por defecto es este:

Las categorías, banners y productos que ves debajo de la cabecera son solo datos de relleno que hemos cargado para que la tienda no aparezca completamente vacía. Estos datos de muestra pueden descargarse en un fichero comprimido de la página de Magento y cargarse en la base de datos, pero no son necesarios en absoluto.

El tema por defecto es elegante y está bien diseñado, vamos a cambiar sólo la cabecera para adaptarlo a nuestro negocio. Este es el logo que tenemos:

Lo mejor, si queremos tener más flexibilidad a la hora de utilizarlo con cualquier fondo, es tener una versión del logo con fondo transparente (fichero gif o png). De todas formas esto no es imprescindible para seguir este tutorial.

¿Dónde haremos nuestros cambios?

Los ficheros y carpetas del tema ‘default‘ se encuentran repartidos en estos dos directorios:

magento/app/design/frontend/default/default (plantillas y layouts si el tema los requiere)

magento/skin/frontend/default/default  (imágenes, css y javascript)

El primer ‘default‘ es el nombre del paquete y el segundo el nombre del tema. Un paquete (package) es una forma de agrupar temas relacionados, o más exactamente, variaciones de un mismo tema.

Cuando creemos un tema más complejo utilizaremos nuestra propia carpeta de paquete, pero como lo que vamos a hacer es realmente una pequeña variación sobre el original, vamos a colocar nuestro tema dentro del paquete ‘default‘. Nuestros ficheros estarán en:

magento/app/design/frontend/default/rosa_de_papel

magento/skin/frontend/default/rosa_de_papel

Esto nos permite aprovechar la jerarquía de temas de Magento para colocar en nuestras carpetas sólo 4 ficheros con los cambios sobre el original. Magento buscará el resto de ficheros siguiendo esta jerarquía:

default/rosa_de_papel → default/default → base/default

El segundo eslabón de esta cadena es siempre el tema ‘default’ del paquete en el que estemos.

Haciendo nuestros cambios de esta forma contaremos con las actualizaciones que el equipo de Magento haga para mejorar el tema y tendremos nuestras modificaciones separadas y fáciles de localizar.

Nunca debemos hacer nuestros cambios en el tema ‘default‘ directamente, porque si hacemos alguna actualización, todos nuestros cambios se perderán y tendremos que volver a hacerlos.

Cambiando la hoja de estilos

Para saber exactamente lo que cambiamos y no tener que andar tocando lineas en el fichero original, vamos a crear nuestra propia hoja de estilos y hacer que se incluya junto con las hojas de estilos que tiene el tema por defecto. Para esto tendremos que crear dos ficheros:

magento/app/design/frontend/default/rosa_de_papel/layout/local.xml (sólo para indicar a  Magento que coja nuestra hoja de estilos)

magento/skin/frontend/default/rosa_de_papel/css/local.css (nuestra hoja de estilos)

local.xml debe contener sólo las siguientes líneas:


      
          
              
              
                  css/local.css

La línea css/local.css es la que indica el fichero .css que debe cargarse.

Ahora podemos volver al problema que queríamos solucionar: la anchura del div con los enlaces de la derecha de la cabecera. Esta anchura está definida originalmente en los estilos del tema que estamos tomando como base (‘default’):

magento/skin/frontend/default/default/css/styles.css

sobre la línea 494 de la siguiente forma:

.header .quick-access { float:right; width:600px; padding:28px 10px 0 0; }

Lo único que queremos cambiar es la anchura, que vamos a pasar de 600px a 400px, así que en nuestro fichero local.css sólo tenemos que incluir:

.header .quick-access {width:600px;}

Y el resultado es:

Perfecto!. Justo lo que queríamos.

Estos cambios tan sencillos pueden ser suficiente para muchas tiendas. Podemos utilizar el tema por defecto u otro que nos guste, pero siempre tendremos que añadir nuestro logo para tener la tienda mínimamente personalizada.

Para diferenciarnos un poquito más de la instalación por defecto vamos a cambiar también el color de fondo de la cabecera.

Cambiando el fondo de la cabecera

Teníamos pensado nuestro logo sobre un fondo marrón y queremos que nuestra tienda tenga esos colores. Podemos cambiarlo con un par de líneas en el fichero css y una imagen que pondremos como fondo.

Como siempre, vamos a buscar primero como está definido el fondo de la cabecera en el tema default. En su hoja de estilos, sobre la línea 482 tenemos:

.header-container { border-top:5px solid #0d2131; border-bottom:1px solid #415966; background:url(../images/bkg_header.jpg) 50% 0 repeat; }

El fondo de la cabecera original es esta imagen:

magento/skin/frontend/default/default/images/bkg_header.jpg

Podemos copiarla y editarla con cualquier programa de edición gráfica para pintarla como queramos o podemos crear una imagen desde cero. El tamaño del original es 2000 x 150 pixels. La imagen final debemos colocarla en:

magento/skin/frontend/default/rosa_de_papel/images/bkg_header.jpg

Para nuestro diseño hemos utilizado varios tonos marrones y hemos conservado las dos sombras laterales que marcan el ancho de la tienda, pero puedes hacerlo tan sencillo o tan complicado como quieras.

Hay que tener en cuenta que si tenemos un logo muy alto esta imagen de fondo tendrá que repetirse verticalmente. Si prevés que esto puede ocurrir, tienes que hacer un diseño del fondo que quede bien al repetirse, como el original, con líneas horizontales, o con colores planos. En nuestro caso, el logo mide sólo 100 pixels de alto y el fondo no necesitará repetirse.

Para que coja nuestra imagen tendremos que copiar la línea que vimos antes en nuestra hoja de estilos (magento/skin/frontend/default/rosa_de_papel/css/local.css):

.header-container { border-top:5px solid #0d2131; border-bottom:1px solid #415966; background:url(../images/bkg_header.jpg) 50% 0 repeat; }

Realmente sólo necesitariamos incluir la parte de ‘background’ para que machaque la información de la línea original, pero la copiamos entera porque más adelante cambiaremos algún otro detalle. El resultado es:

Como podemos ver en la imagen, todavía nos quedan algunos detalles por cambiar para que el resultado sea aceptable. La caja de búsqueda en la parte superior todavía tiene una imagen azul de fondo y la zona con el menú de categorías también.

Como en este tutorial queremos hacer lo más sencillo posible, simplemente vamos a eliminar la imagen de fondo de la caja de búsqueda (utilizando nuestra hoja de estilos).

Sobre la línea 490 de la hoja de estilos original ( magento/skin/frontend/default/default/css/styles.css ) encontramos la línea que define el fondo y el estilo general del formulario de búsqueda:

.header .form-search { position:absolute; top:0; right:29px; width:315px; height:30px; background:url(../images/bkg_form-search.gif) 0 0 no-repeat; padding:1px 0 0 16px; }

Lo único que queremos cambiar es el fondo (background) por lo que en nuestro fichero local.css ponemos:

.header .form-search { background: none;}

Para cambiar la barra de color azul oscuro en la que aparecen las categorías podríamos hacer como antes, copiar y editar la imagen que tenemos por defecto:

magento/skin/frontend/default/default/images/bkg_nav0.jpg

pero en este ejemplo vamos a cambiarlo por un color plano, sin imagen, que queda muy bien para los colores que hemos elegido. En el css del tema default encontramos que el fondo de esta barra de navegación se define en la siguiente línea (513 aproximadamente):

.nav-container { background:#0a263d url(../images/bkg_nav0.jpg) 50% 0 repeat-y; }

En nuestro fichero local.css quitamos la referencia a la imagen, dejando sólo el código del color que queramos:

.nav-container { background:#4A2D07; }

Nota: El código del color que quieras puedes obtenerlo, por ejemplo en esta web:
http://www.colorpicker.com/

Ya lo tenemos casi listo. Si nos fijamos bien en la imagen, queda una línea muy fina de color azul entre la cabecera y la barra de navegación con las categorías. Esto podemos cambiarlo directamente en una línea que ya tenemos en nuestro fichero local.css:

.header-container { border-top:5px solid #0d2131; border-bottom:1px solid #415966; background:url(../images/bkg_header.jpg) 50% 0 repeat; }

Esta línea, además de la imagen de fondo de la cabecera, está definiendo una línea superior de 5px con color #0d2131 y otra línea inferior de 1px con color #415966. Esa línea inferior es la que queremos modificar. Vamos a cambiarla a color negro, quedando:

.header-container { border-top:5px solid #0d2131; border-bottom:1px solid #000000; background:url(../images/bkg_header.jpg) 50% 0 repeat; }

El resultado final es:

Naturalmente podríamos seguir cambiando cosas, todavía nos quedan tonos azules, podríamos cambiar el pie de la tienda, etc, pero la idea de este tutorial es mostrar que con sólo 4 cambios muy básicos, sin ninguna complicación, podemos personalizar la tienda.

JavaScript Orientado a Objetos

Pablo — Thu, 21 Oct 2010 11:19:04 +0000

JavaScript es un lenguaje orientado a objetos, pero es diferente de los lenguajes más populares como Java o C++. Basa su orientación a objetos en Prototipos (prototype-based) en lugar de Clases. Esta es la razón por la que presenta algunas particularidades que nos pueden resultar extrañas a la hora de utilizarlo.

La diferencia más importante de este tipo de lenguajes es que no tienen clases, todo son objetos. No existen clases pero existen funciones constructoras que pueden jugar un papel parecido en cuanto a crear una ‘plantilla’ para instanciar objetos.

En JavaScript prácticamente todo son objetos, incluso las funciones:

function sumar (a, b) {
    return a+b;
}

La función sumar es automáticamente un objeto, con sus métodos y sus propiedades, por ejemplo:

sumar.length contendrá el número de parámetros que acepta la función.
sumar.arguments es un array que contendrá los argumentos que se hayan pasado a la función.
sumar.call() es un método que permite definir un contexto de ejecución nuevo para la función.

Estos son métodos y propiedades definidos por defecto, pero tambien podemos añadir algunos nuevos:

>>> sumar.nivel = "sencillo"

No olvidemos que sumar() sigue siendo una función, si en una consola de JavaScript (recomiendo Firebug) llamamos a la función con dos parámetros nos dará la suma:

>>> sumar (3, 1)
4

pero tambien podemos utilizar la propiedad ‘nivel’ que acabamos de definir:

>>> sumar.nivel
"sencillo"

Algunos programadores consideran que es un lenguaje basado en objetos, pero no orientado a objetos. Simplemente es una forma de evitar llamar orientado a objetos a un lenguaje que los maneja de una forma diferente a la que estamos acostumbrados.

En JavaScript no existen las clases, todo son objetos

Creando Objetos

La tarea de crear un objeto nuevo es increiblemente sencilla en JavaScript:

>>> var miObjeto = {}

y ya tendriamos nuestro objeto. Obviamente está vacío pero podemos añadirle todo lo que queramos después de crearlo:

>>> miObjeto.nombre = "Prueba"

>>> miObjeto.metodo1 = function() {return "soy el objeto " + this.nombre}

Ahora nuestro objeto tiene una propiedad y un método:

>>> miObjeto.nombre
"Prueba"

>>> miObjeto.metodo1()
"soy el objeto Prueba"

this.nombre hace referencia a la variable nombre dentro del propio objeto.

También podíamos haber creado el objeto completo desde el principio:


var miObjeto = {

    nombre: "Prueba",
    metodo1: function () { return "soy el objeto " + this.nombre}
}

Y esto no impide que despues podamos añadir nuevos miembros a este objeto:

>>> miObjeto.metodo2 = function(parametro) {return "tengo un parámetro: " + parametro}

>>> miObjeto.metodo2("Hola")
"tengo un parámetro: Hola"

Esta forma rápida y sencilla de crear objetos se llama notación literal.

Usando Constructores

Tratándose de JavaScript podemos esperar que haya varias formas diferentes de hacer lo mismo, y en efecto, hay otra forma de crear objetos: usando una función constructora.

En realidad se trata de una función normal. Cualquier función en JavaScript puede utilizarse como constructor si la invocamos con el operador new, pero para que los objetos que creamos sean útiles, debemos hacer que tengan algún método o propiedad públicos, accesibles para los usuarios del objeto. Esto lo conseguimos añadiendo variables o funciones a this dentro de la función.


function Calcular () {
    this.version = "1";
    this.suma = function(a,b) { return a+b};
    this.multiplica = function (a,b) {return a*b};
}

Podemos utilizar Calcular como constructor para crear objetos capaces de sumar y de multiplicar dos números:

>>> var calculadora = new Calcular()

>>> calculadora.version
"1"

>>> calculadora.suma(3,2)
5

>>> calculadora.multiplica(3,2)
6

El constructor nos sirve de ‘plantilla’ para crear objetos similares, algo parecido a las clases en Java:

>>> var calculadora2 = new Calcular();

>>> var calculadora3 = new Calcular();

En este caso los 3 objetos serían iguales. El constructor sería mucho más útil si le podemos pasar algún parámetro a la hora de crear el objeto para inicializarlo de la forma que necesitemos:


function Mensajero (mensaje) {

    this.muestraMensaje = function () { return "Atención: " + mensaje}

}

Ahora podríamos crear varios objetos pasando un parámetro particular al constructor en cada caso:

>>> var mensajero1 = new Mensajero ("Error gordo");

>>> var mensajero2 = new Mensajero ("Bateria baja...");

>>> mensajero1.muestraMensaje()
"Atención: Error gordo"

>>> mensajero2.muestraMensaje()
"Atención: Bateria baja..."

Hemos visto que añadiendo variables y funciones de la forma this.variable o this.funcion creamos propiedades y métodos públicos, accesibles para cualquiera que utilice el objeto, pero también podemos crear miembros privados. Cualquier variable que declaremos de la forma var miVariable será sólo visible dentro de la función (y dentro del objeto que se cree con ella).

Vamos a añadir al constructor Mensajero un método privado que comprueba si el mensaje está vacio y, si es asi, coloca uno por defecto:


function Mensajero (mensaje) {

    //variable privada
    var defaultMsg = "Sin novedad";

    //método privado
    var compruebaMsgPrivado = function () {
        if (!mensaje) mensaje = defaultMsg;
    }

    //método público
    this.muestraMensaje = function () {
        compruebaMsgPrivado();
        return "Atención: " + mensaje;
    }
}

Ahora tenemos una propiedad privada (defaultMsg) y un método privado (metodoPrivado) que sólamente pueden ser utilizados internamente por el objeto.

Si ahora construimos un objeto sin mensaje:

>>> var mensajero1 = new Mensajero()

El método privado se encargará de asignarle un mensaje por defecto:

>>>mensajero1.muestraMensaje()
"Atención: Sin novedad"

¿Y que hay de la herencia?

Como vimos en la introducción, JavaScript es un lenguaje cuya orientación a objetos se basa en prototipos (prototype).

Básicamente se trata de que en vez de tener una clase base de la que heredan los hijos, creamos un prototipo, que es un objeto que tiene métodos y propiedades que pueden necesitar otros objetos, y lo vinculamos ( asignándolo a la propiedad prototype ) a esos objetos. Todos los objetos que tengan este prototipo habrán heredado todas sus propiedades y métodos y podrán usarlos como si fueran suyos.

Vamos a ver esto un poco más en detalle y con algunos ejemplos para entenderlo. Es muy importante tener en cuenta que prototype es una propiedad de las funciones (recuerda que las funciones también son objetos), no de los objetos en general. Por lo tanto un prototipo se asigna siempre a una función constructora y , si queremos acceder a él, por ejemplo para extenderlo, debemos hacerlo a través del constructor de nuestro objeto.

Supongamos que estamos creando una aplicación que necesitará varios objetos para realizar calculos particulares. Podríamos crear un objeto estadisticas que haría unos cálculos estadísticos complejos, otro tipo de objeto se utilizara para calcular unos códigos de producto, etc. Todos estos objetos , además de sus funciones complejas particulares necesitarán unas funciones básicas comunes (sumar, restar, multiplicar, etc).

Podemos crear un prototipo con las funciones básicas que luego heredarán los otros objetos. Nuestro objeto prototipo será este, creado con notación literal por simplicidad:

var calculosBasicos = {
    sumar: function (a,b) {return a+b},
    multiplicar: function(a,b) {return a*b}
}

Ahora creamos una función constructora para los objetos de estadísticas:

function Estadisticas (departamento) {

    this.dimeElResponsable = function () {
        return 'Estadísticas para el departamento: ' + departamento ;
    }

    this.calculaEstadisticas = function () {
        return " e = mc2 y mucho más";
    }

}

Y ahora realizamos la herencia, asignando como prototipo del constructor el objeto que hemos creado antes:

>>> Estadisticas.prototype = calculosBasicos

Nota: como hemos utilizado notación literal, directamente asignamos el objeto. Si hubiéramos creado un constructor , haríamos Estadisticas.prototype = new CalculosBasicos para asignar el objeto

Ahora todos los objetos de estadisticas que creemos tendrán acceso a los cuatro métodos:

>>> var estadisticasBiblioteca = new Estadisticas ("Libros")

>>>var estadisticasTienda = new Estadisticas ("Ventas")

>>> estadisticasBiblioteca.dimeElResponsable()
"Estadísticas para el departamento: Libros "

>>> estadisticasBiblioteca.multiplicar (2, 3)
6

>>>estadisticasTienda.dimeElResponsable()
"Estadísticas para el departamento: Ventas "

>>> estadisticasTienda.multiplicar (2, 2)
4

Igualmente podríamos crear ahora un constructor para otro tipo de objetos y asignarle el mismo prototipo para que disponga de las funciones básicas.

Extendiendo el prototipo

Todos los objetos tienen un prototipo vinculado, aunque por defecto será un objeto vacío {}. Podemos ir añadiéndole funciones poco a poco en vez de asignar un objeto completo como hicimos en el ejemplo anterior.

Si tenemos el siguiente constructor de futbolistas:


function Futbolista (nombre) {

    this.habla = function () { return "yo soy: " + nombre}
    this.bicicleta = function () {return "haciendo la bicicleta"}

}

Esta función construirá futbolistas:

>>> var futbolista1 = new Futbolista ("Pichichi")

>>> var futbolista2 = new Futbolista("Figura")

Pero hay varias funciones básicas que tendrán todos los futbolistas y que podríamos poner en nuestro prototipo: correr y escupir. Todo futbolista que se precie tiene que correr y, cuando le enfoque alguna cámara, escupir al suelo, si no nunca será nadie.

Podemos añadir ahora estas funciones al prototipo del constructor e inmediatamente estarán disponibles para los objetos instanciados, aunque hayan sido creados antes:

>>> Futbolista.prototype.correr = function () {return "run Forrest, run!"}

>>> Futbolista.prototype.escupir = function () { return "gargajo"}

Todos los objetos creados anteriormente ya disponen de estos métodos:

>>> futbolista1.correr()
"run Forrest, run!"

Aunque hayamos asignado un objeto nuevo como prototipo inicialmente también podemos extenderlo después con nuevas funciones. Lo que no debemos hacer es asignar un objeto nuevo completo (en vez de extender el existente) después de crear objetos, en ese caso los objetos ya instanciados seguirán teniendo la referencia al viejo prototipo y los que se creen nuevos tendrán referencia al nuevo.

No debemos asignar un objeto nuevo completo como prototipo (en vez de extender el existente) después de crear objetos, en ese caso los objetos ya instanciados seguirán teniendo la referencia al viejo prototipo y los que se creen nuevos tendrán referencia al nuevo.

Aquí terminamos esta introducción a la orientación a objetos de JavaScript. Si te ha gustado o no te ha gustado, por favor indícalo en los comentarios.

Patrones de diseño en PHP5: Singleton

Pablo — Sat, 16 Oct 2010 10:53:43 +0000

El Singleton es uno de los patrones de diseño más sencillos de implementar. Quizá sea esto lo que ha llevado a que se utilice en muchos casos de forma inapropiada y a que actualmente su uso esté siendo bastante cuestionado. En este tutorial veremos en qué consiste y cuales son las razones para que algunos desarrolladores consideren que es mejor no utilizarlo.

Definición

El patrón singleton se utiliza cuando necesitamos que exista una sola instancia de una clase determinada. Puesto que no podemos crear instancias nuevas (utilizando new), la clase debe proporcionar una forma de acceso global a la única instancia existente.

Las claves de su funcionamiento son las siguientes:

El constructor de la clase no debe ser accesible, para que no se puedan crear instancias libremente. Lo hacemos privado.
La clase debe proveer un método público para devolver la instancia única de la clase a quien la pida..

Implementación

El código básico para crear una clase que se ajuste al patrón que estamos tratando sería el siguiente:

Tenemos una variable privada para almacenar la instancia única que existe de esta clase:

private static $instance;

El constructor es privado para que no sea accesible por ninguna clase cliente:

  private function __construct()
    {}

Y proporcionamos un método público para obtener la instancia:

    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            self::$instance = new EjemploSingleton();
        }

        return self::$instance;
    }

La función getInstance() es estática, es decir, es una función de la clase, no de ninguna instancia en particular. Es la única forma de implementar un método de este tipo porque:

El método debe controlar el número de instancias de la clase que existen
Debemos poder acceder a él incluso cuando no haya instancias creadas de la clase (se encarga de crearla si no existe)

Lo que hace getInstance() es sencillo. Primero comprueba si ya existe una instancia creada de la clase (comprobando $instance) y si no existe la crea, después devuelve $instance al objeto/cliente que lo solicitó.

Al ser el punto de acceso una función estática, debe utilizarse de la siguiente forma:

$tengoElSingleton = ejemploSingleton::getInstance();

Ahora $tengoElSingleton contiene la instancia de la clase ejemploSingleton y podrá utilizar sus métodos y su funcionalidad.

Afinando un poco más

Con el código de arriba todavía no cerramos todas las puertas para que algún cliente obstinado pueda crear una instancia de nuestra clase. Podría utilizar el método clone() para obtener una cópia:

$tengoElSingleton = ejemploSingleton::getInstance();
$tengoOtraInstancia = clone($tengoElSingleton);

Para evitar este problema sólo tenemos que hacer que la función __clone() no pueda utilizarse, por ejemplo, lanzando un error:

    public function __clone()
    {
        trigger_error('Esta clase no puede clonarse', E_USER_ERROR);
    }

De una forma un poco más rebuscada podría conseguirse una copia utilizando las funciones serialize() y unserialize():

$tengoElSingleton = ejemploSingleton::getInstance();
$objetoSerializado = serialize($tengoElSingleton);
$yaTengoLaCopia = unserialize($objetoSerializado);

Para evitar que esto pueda ocurrir anulamos el método __wakeup() que se utiliza al deserializar:

    public function __wakeup()
    {
        trigger_error('Esta clase no puede deserializarse', E_USER_ERROR);
    }

¿Para qué puedo usarlo?

El ejemplo más clásico, que verás en cientos de tutoriales, pero que plantea algunas cuestiones, es una conexión a la base de datos de la aplicación, por ejemplo un objeto que llamaremos dbInterface(). Podemos pensar que la aplicación necesitará acceder muchas veces a la base de datos y desde muchas clases diferentes. Si creamos esta clase como un singleton nos aseguramos de que sólo habrá una conexión a la base de datos y esta será compartida por todos.

Es un buen ejemplo para entender las ventajas de este patrón, pero debemos asegurarnos de que realmente necesitamos que sólo exista una conexión a la BD antes de implementarlo de esta manera. El hecho de que el contexto de una aplicación web sea muy diferente del de una aplicación de escritorio, hace que no se utilice realmente el mismo objeto durante toda la ‘vida’ de la aplicación ya que los objetos creados en PHP sólo permanecen mientras se sirve la página actual, para la siguiente petición tendrán que crearse de nuevo. En el siguiente apartado veremos esto más en detalle y volveremos sobre este ejemplo.

Además de esto, para aplicaciones muy grandes, limitarnos a una sola conexión con la base de datos puede ser un cuello de botella innecesario. Si prevemos que en el futuro podemos necesitar más conexiones es mejor no utilizar un singleton, puede haber otros patrones más apropiados, como factory.

Otro ejemplo de uso es una clase de logging. Una clase que podemos llamar desde cualquier punto de la aplicación para enviar un mensaje a un fichero o a una consola. Puede utilizarse para estadísticas, mantenimiento, depuración, etc.

Una clase de configuración de la aplicación también puede implementarse utilizando este patrón. Aseguramos que el objeto con los datos de configuración es único y accesible globalmente desde cualquier punto.

Particularidades del contexto web

En aplicaciones instaladas, de escritorio, un singleton realmente asegura que se utiliza la misma instancia de la clase desde que arrancamos hasta que cerramos la aplicación. La conexión a la base de datos, por ejemplo, sería única y se haría una sola vez. En una aplicación web en PHP no es así. Todos los objetos y el entorno de la aplicación en el servidor se crean y se destruyen para cada petición HTTP. Para hacer una simplificación sencilla de entender, nuestro programa PHP sólo vive para servir una página (o una pequeña parte de una página para llamadas AJAX). Cuando el usuario haga otro click en el interface, todo se creará y se destruirá de nuevo. El singleton sólo nos asegura que existirá y se utilizará una única instancia mientras se sirve una petición HTTP concreta.

Cuando el usuario haga otro click en el interface, todo se creará y se destruirá de nuevo. El singleton sólo nos asegura que existirá y se utilizará una única instancia mientras se sirve una petición HTTP concreta.

Debemos pensar detenidamente si realmente necesitamos el patrón para nuestro diseño. En el ejemplo de dbInterface() sólo lo necesitamos si para servir alguna de nuestras peticiones hay varios objetos diferentes que acceden a la base de datos y necesitamos que sólo exista una conexión.

Un patrón desprestigiado

Últimamente se ha hablado mucho de este patrón y en la mayoría de los casos para advertir contra su uso excesivo y ciertos problemas que puede conllevar.

Básicamente las razones del movimiento anti-singleton son las siguientes:

Un singleton puede considerarse en algunos aspectos como una variable global (es una instancia global) y el uso de variables globales debe evitarse en lo posible. Lo que ocurre es que al utilizar algo de forma global, en vez de pasarlo como argumento, se ocultan las dependencias que tiene una clase, en vez de hacerlas visibles en su API.
Se viola el principio de responsabilidad única (cada clase debe ser responsable de una sola tarea). En este caso, además de las responsabilidades propias de la clase, debe controlar su creación y limitar sus instancias.
Hace el código dependiente de su entorno (la instancia global en este caso) lo que dificulta las pruebas de unidad (unit testing).

Son razones válidas pero siempre deben considerarse en el caso concreto de la aplicación que estamos desarrollando. Si, en nuestro caso, aplicar el patrón soluciona un problema de forma sencilla y no nos crea otros, no hay razón para no aplicarlo.

El Singleton es un patrón mas que debemos conocer y que, como todos, debemos aplicar cuando sea la mejor opción. El problema que resuelven es muy claro: sólo puede haber una instancia de una clase concreta. Si tenemos un recurso que sólo puede/debe utilizarse mediante un único punto de acceso, usa un Singleton.

Temas hijo: Cómo hacer modificaciones sencillas en un tema de WordPress

Pablo — Thu, 07 Oct 2010 13:59:09 +0000

Cuando buscamos temas para WordPress nos encontramos muchas veces con plantillas que nos gustan pero que tienen algún detalle que no nos convence. Pensamos: “si tuviera esto de esta manera sería perfecto”, y seguimos buscando. Podríamos personalizar el tema a nuestro gusto mediante un tema hijo (child theme).

Un tema hijo es un tema derivado de otro, que sólo incluye los cambios que necesitemos hacer. Heredamos toda la funcionalidad y el diseño del tema padre y sólo tenemos que incluir las modificaciones para personalizarlo. Es tan sencillo como crear nuestra hoja de estilos style.css y especificar ahí las propiedades que queremos cambiar.

Utilizar estos temas derivados es la forma recomendada en la documentación de WordPress para hacer cambios en un tema original.

Tienen la enorme ventaja de que los ficheros del tema que nos sirve de base no se tocan, todos nuestros cambios están claramente separados en su propio fichero, en la carpeta del tema hijo. Podemos actualizar el tema original sin perder nuestro trabajo.

Modificando el tema “Titan”

Para ver un ejemplo partiremos del excelente tema Titan, creado por The Theme Foundry y disponible en el directorio de temas gratuitos de WordPress.

Tema Titan de 'The Teme Foundry'

Supongamos que hemos encontrado este tema que se ajusta casi perfectamente a lo que buscábamos, pero… hay algunos detalles que no coinciden con la idea que teníamos. Los gustos de cada uno son muy particulares y, para colmo, el creador del tema tiene los suyos propios.

Para ver cómo adaptarlo a nuestras necesidades mediante un sencillo tema hijo, vamos a suponer que queremos hacer los siguientes cambios:

Nuestros posts van a ser extensos y el formato se queda un poco corto. Vamos a alargar todo el contenido del post hacia la izquierda para aprovechar el espacio vacío que queda debajo de la fecha.
El título de cada entrada queremos que sea un poco más grande y de color negro en vez de azul link.
Queremos una separación entre posts más clara

Evidentemente son pequeños detalles pero pueden hacer que descartes un tema que te gusta casi al 100%.

Vamos a ver como hacer estas modificaciones creando nuestro propio ficheros style.css con sólo unas líneas para obtener este resultado:

¿Dónde hago mis cambios?

Crear un tema hijo es tan sencillo como crear una carpeta con el nombre que le daremos al tema (yo lo he llamado titan-child ) y dentro de la carpeta crear un fichero style.css que será nuestra hoja de estilos para todo lo que queramos cambiar.

En WordPress todos los temas están en la carpeta wp-content/themes y ahí es donde colocaremos también el nuestro. Por supuesto tenemos que haber descargado el tema padre y haberlo colocado en la carpeta themes.

El nombre de la carpeta con nuetro tema puede ser cualquiera, no tiene que contener la palabra child por ser un tema hijo. El nombre de nuestra hoja de estilos sí tiene que ser style.css obligatoriamente.

La hoja de estilos de nuestro tema: style.css

Al principio de este fichero se incluyen siempre unas lineas de información con el nombre del tema, el autor, descripción, etc. Al ser un tema hijo debe incluirse también el campo Template para indicar cuál es el tema padre, ya que WordPress tendrá que coger los ficheros de esta plantilla para luego modificarlo con los nuestros.

Estas serían las líneas de la cabecera de nuestro fichero style.css:

/*
Theme Name: Titan Child
Theme URI: -
Description: Tema derivado de Titan
Author: Pablo L. Pastor
Author URI: -
Template: titan
Version: 1.0
*/

Las dos únicas etiquetas requeridas obligatoriamente son Theme Name y Template. En este último campo debe aparecer el nombre del tema padre tal como aparece en la carpeta que lo contiene, en el directorio themes.

Debemos tener en cuenta que nuestra hoja de estilos sustituye a la original. Normalmente, para no perder los estilos del tema base, se incluye la siguiente línea:

@import url('../titan/style.css');

que incluirá todas las reglas css del tema padre al principio de nuestro fichero css. Esta línea debe aparecer al principio del fichero, después del comentario con la información del tema.

debemos añadir @import siempre que queramos contar con el aspecto visual original y modificar a partir de ahí. Si no lo hacemos contaremos con el HTML puro y duro y tendremos que definir el diseño desde cero. Partiríamos de esto:

En nuestro caso esto no es lo que queremos, añadimos @import para partir del tema original tal como es.

Ahora empezamos con las reglas css para cambiar los detalles que nos interesan. Para saber que propiedades tenemos que cambiar, lo mejor es utilizar FireBug que nos permite ver cómo están definidas pinchando sobre el diseño original.

Para eliminar el desplazamiento a la derecha de las entradas y hacer el texto más ancho, incluiremos lo siguiente:

/* Eliminar el desplazamiento a la derecha de las entradas */
.entry {
    margin: 0 0 0 0px;
    width: 620px;
}

.post-footer {
    margin-left: 0px;
}

de esta forma eliminamos el margen que desplazaba la entrada y aumentamos su anchura.

Para aumentar el tamaño del título y cambiar el color:

/* Aumentar tamaño del título del post y cambiar color a negro */
.post-header h2 {
    font-size: 3em;
}

.post-header h2 a {
    color: #000;
}

Y por último, para marcar más la separación entre posts, incluyendo un cambio del color de fondo de las entradas:

/*Fondo blanco para los posts. Más padding y menos separación entre entradas */
.post {
    background-color:white;
    margin-bottom:20px;
    padding:0 10px 10px;
    border:1px solid #EFEAE4;
}
/* Borrar la línea de separación de entradas anterior */
.post-header {
    border-top: none;
}

Y ya está!. Sólo con estas líneas en el fichero style.css de nuestro tema hijo hemos conseguido adaptar el tema a nuestras necesidades.

¿Sólo para pequeños cambios?

En realidad no. Los temas hijo son perfectos para estos pequeños ajustes, pero permiten modificar prácticamente todo lo que queramos del tema original: css, imágenes, plantillas, funciones, etc.

Podemos crear un fichero functions.php para incluir funciones nuevas que aumenten las posibilidades de nuestro tema. Las funciones nuevas se sumarán a las que ya existen en el tema base.

Podemos definir plantillas nuevas para cualquiera de las partes de WordPress. Las plantillas que nosotros definamos sustituirán a la plantilla original del mismo nombre.

Modificando una plantilla

Para desarrollar un poco más nuestro ejemplo, vamos a modificar una de las plantillas de Titan.

La cabecera de este tema no incluye una caja de búsqueda:

Podemos modificar la plantilla de la cabecera (header.php) en nuestro tema hijo para incluirla.

Como las plantillas que creemos sustituyen a los ficheros originales, vamos a copiar

wp-content/themes/titan/header.php

en nuestro tema:

wp-content/themes/titan.child/header.php

Ya hora en este fichero hacemos la modificación para incluir la búsqueda.

Despues de la línea 71 añadimos el código que vemos entre los comentarios y :

Esto ya nos añadiría la caja, pero un poco descolocada:

Añadimos unos estilos en el fichero style.css para ajustarla:

/*Search*/
#header-search #search_form input.search {
    margin:40px 0 0 95px;
}

Y el resultado es:

Con la caja de búsqueda tal como la queríamos!. Para disfrutar de nuestros cambios sólo tenemos que seleccionar el tema que hemos creado como Tema actual en la pantalla de administración de WordPress.

…Y mucho más

Los temas hijo son una herramienta tan potente que incluso se han desarrollado temas especiales para ser utilizados únicamente como tema padre. Son temas muy completos, con un amplio abanico de funcionalidades, que dejan el diseño en manos del usuario/cliente para que lo personalice con el fichero style.css en un tema hijo.

Estos temas especiales a veces son considerados como un framework para desarrollo de temas. Proporcionan una base sólida y bien desarrollada sobre la que construir nuestro tema mediante los temas hijo. Esto puede hacer el desarrollo mucho más rápido y sencillo.

Ejemplos de este tipo de temas son: Thematic, The Buffet Framework, SandBox, WP Framework o Hybrid.

Tutoriales DWEB

AJAX entre dominios con el estándar CORS (Cross-Origin Resource Sharing)

Política del Mismo Origen

¿En qué consiste el estándar Cross-Origin Resource Sharing?

Petición simple

Petición con verificación previa (preflighted)

El nuevo XMLHttpRequest de nivel 2

Peticiones con cookies o autentificación

Las limitaciones de XDomainRequest (IE)

¿Que seguridad aporta CORS?

CSS Float: Tutorial Visual (II)

Clear: Para no estar al lado de un float

El increíble contenedor menguante

Soluciones al problema del contenedor

1.-Hacer el contenedor flotante

2.- Poner un elemento con clear después de los flotantes

3.- Utilizar la propiedad CSS overflow

Float para diseñar la estructura de una página

Consejos SEO desde GOOGLE

Web: Phoenician Stone

Web: RodsBot

Web: Android And Me

Web: Surprises Galore (Hackeado)

Web: The hookup

Web: Kathy Toth (Agente Inmobiliario)

Web: APPBrain

Web: Grow In Style

Web: Jim Dantona

CSS Float: Tutorial Visual (I)

Conceptos Básicos

Flotando Bloques

Sólo Bloques (Divs)

Elementos de Línea. Imágenes y Texto

Imágenes en Divs

Terminando por hoy …

Personalización Básica de una tienda en Magento

¿Qué vamos a hacer?

¿Dónde haremos nuestros cambios?

Lo más básico, cambiar el logo

Cambiando la hoja de estilos

Cambiando el fondo de la cabecera

JavaScript Orientado a Objetos

Creando Objetos

Usando Constructores

¿Y que hay de la herencia?

Extendiendo el prototipo

Patrones de diseño en PHP5: Singleton

Definición

Implementación

Afinando un poco más

¿Para qué puedo usarlo?

Particularidades del contexto web

Un patrón desprestigiado

Temas hijo: Cómo hacer modificaciones sencillas en un tema de WordPress

Modificando el tema “Titan”

¿Dónde hago mis cambios?

La hoja de estilos de nuestro tema: style.css

¿Sólo para pequeños cambios?

Modificando una plantilla

…Y mucho más