Dic 04

MediaWiki es, probablemente, el motor para wikis más conocido del mundo. Originalmente creado para la Wikipedia actualmente es usado por una gran cantidad de wikis que nada tienen que ver con dicha fundación. La instalación por defecto del MediaWiki configura unas URLs no muy apropiadas en los tiempos que corren (con scripts PHP visibles y parámetros por GET) pero que tienen la ventaja de funcionar correctamente en un mayor número de servidores. Si dispones de mod_rewrite a continuación describo una forma de hacer estas URLs un poco más "bonitas" y cortas.

Acerca de este tema existe mucha documentación y en el apartado correspondiente del manual puedes encontrar varias alternativas. Después de haber trabajado con varias wikis en estos últimos años la que encuentro mejor es la siguiente.

Modificar LocalSettings.php

Se debe sustituir el valor de la variable $wgArticlePath por:

$wgArticlePath      = "/$1";

y si no tienes definida esta variable se debe añadir en un lugar cercano a la definición de $wgScriptPath.

Modificar .htaccess

Añadir las siguientes lineas a tu .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^$ http://www.ejemplo.com/Portada [R=301,L]
RewriteRule ^[^:]*\. - [L]
RewriteRule ^[^:]*\/ - [L]
RewriteRule ^(.+)$ /mediawiki/index.php?title=$1 [L,QSA]

Las URLs resultantes tienen la forma:

http://www.ejemplo.com/Portada para la Home.
http://www.ejemplo.com/Prueba para una página llamada "Prueba".

Consideraciones

Este método funciona correctamente en distintos escenarios aunque se han de tener en cuenta algunas consideraciones:

[1] La wiki debe estar instalada en el directorio "mediawiki". Si la tienes en otro directorio sustituye "mediawiki" por el nombre apropiado en las anteriores reglas de mod_rewrite.

[2] Si alguien accede a la raíz del dominio es redirigido a "/Portada" con una redirección permanente (301).

[3] Si el nombre de tu wiki contiene un punto (p.e. Ejemplo.com) fallarán los accesos a algunas páginas especiales. Para forzar que las páginas especiales que usan el nombre de la wiki en la URL se procesen correctamente es necesario añadir la siguiente regla justo después de la redirección a la Portada:

RewriteRule ^Ejemplo\.com(.+)$ /mediawiki/index.php?title=Ejemplo.com$1 [L,QSA]

Etiquetas:
Nov 05

Desde el nacimiento de la World Wide Web existe la costumbre de usar el subdominio "www" para las direcciones URL cuando en realidad, y siguiendo la definición oficial de la WWW, no es para nada necesario. Todos los navegadores web existentes asumen el protocolo HTTP y añaden "http://" automáticamente a las URL, ¿porque entonces muchos servidores siguen necesitando el uso del subdominio "www" para servir la web?

Actualmente podríamos decir que es una cuestión de gustos usar o no la WWW para nuestras URL, te encuentras con partidarios del NO, como la iniciativa no-www.org, y otros que exponen interesantes motivos de porque SÍ, como en HM2K.

Lo que sí es recomendable para SEO, y en mi opinión también para temas de Marketing, es decidirse por con o sin WWW y sólo usar un formato de URL. Siempre deberíamos difundir nuestra URL de la misma forma: en los enlaces de nuestra web, en enlaces de otras webs (las que podamos controlar), en anuncios en prensa e inet, etc. También se debería redirigir el tráfico que llega por el formato no deseado al bueno.

El comportamiento por defecto de muchos servidores de servir el mismo contenido en una URL con o sin WWW sin usar ninguna redirección es un error para SEO ya que crea contenido duplicado. Lo usual es que los buscadores interpreten las URL con o sin WWW como sitios web distintos.

Personalmente también encuentro importante la unificación del formato de las URL de cara a la comunicación, imagen de marca, difusión de contenidos, etc. Normalmente uno de nuestros objetivos es que los usuarios recuerden nuestra URL, ahora hablar con WWW ahora sin, no ayuda, a parte de la imagen que transmite.

Si por ejemplo decidimos que nuestras URL llevan WWW (como yo en este blog) podemos redirigir todo el tráfico que llega a URLs sin WWW con un .htaccess como:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^phpbsd\.net$ [NC]
RewriteRule ^(.*)$ http://www.phpbsd.net/$1 [R=301,L]

Como complemento a la redirección Google también nos permite indicar nuestra preferencia en las Webmaster Tools.

Mis conclusiones:

  • Imprescindible la unificación a un formato determinado (con o sin WWW) vía redirección tanto para SEO como para Marketing.
  • Normalmente siempre sin WWW a excepción de si se trata de una web dirigida a un público no muy técnico y más aún si pretendemos hacer campañas de publicidad en medios convencionales (tv, prensa, etc.), en estos casos encuentro mejor usar la WWW para indicar claramente que nos estamos refiriendo a una URL. Quizás si usamos TLDs comunes (.com, .net, .org y en nuestro caso .es) cada día es menos necesario, si usamos cualquier otro encuentro muy recomendable usar la WWW.

¿y tú de quién eres? ¿con o sin?

Etiquetas:
Oct 09

Los títulos de las páginas son uno de los factores más importantes de cara a la optimización de un sitio web para los buscadores (SEO). Si tenemos un blog con WordPress la responsabilidad de tener unos buenos títulos recae en el archivo header.php de nuestro tema. El tema por defecto de WordPress (Kubrick), y la mayoría de themes que corren por ahí, generan unos títulos no muy buenos para el posicionamiento, a continuación describo una manera fácil de solucionar esto sin necesidad de ningún plugin.

Se trata de sustituir el código para los Title Tags que normalmente será algo parecido a esto:

<title><?php bloginfo('name'); ?> <?php if ( is_single() ) { ?> &raquo; Blog Archive <?php } ?> <?php wp_title(); ?></title>

por esto si tenemos WordPress 2.3:

<title><?php
if (is_archive()) echo 'Archivo de ';
if (is_tag()) echo 'etiquetas de ';
echo trim(wp_title('',false));
if (is_search()) echo 'Resultados de b&uacute;squeda de '.$s;
if ( !(is_404()) and (is_search()) or (is_single()) or (is_page()) or (is_tag()) or (is_archive()) ) echo ' en ';
bloginfo('name');
if ( is_home() ) { echo ' &raquo; '; bloginfo('description'); }
?></title>

o por esto si tenemos versiones anteriores:

<title><?php
if (is_archive()) echo 'Archivo de ';
echo trim(wp_title('',false));
if (function_exists('is_tag') and is_tag()) echo 'Archivo de etiquetas de '.$tag;
elseif (is_search()) echo 'Resultados de b&uacute;squeda de '.$s;
if ( !(is_404()) and (is_search()) or (is_single()) or (is_page()) or (function_exists('is_tag') and is_tag()) or (is_archive()) ) echo ' en ';
bloginfo('name');
if ( is_home() ) { echo ' &raquo; '; bloginfo('description'); }
?></title>

Con esta modificación conseguimos los siguientes tipos de títulos:

  • En la home: "NOMBRE_DEL_BLOG » DESCRIPCIÓN_DEL_BLOG"
  • En las categorías: "Archivo de NOMBRE_CATEGORÍA en NOMBRE_DEL_BLOG"
  • En las etiquetas: "Archivo de etiquetas de NOMBRE_ETIQUETA en NOMBRE_DEL_BLOG"
  • En los resultados de búsqueda: "Resultados de búsqueda de TEXTO_BUSCADO en NOMBRE_DEL_BLOG"
  • Para todos los posts y páginas: "TÍTULO_ENTRADA en NOMBRE_DEL_BLOG"

Lo anterior está extraido del tema K2, traducido al español y con algún retoque. Podría haber hecho un plugin, pero es tan sencillo y como igualmente sería necesario modificar el tema para llamar al plugin, que mira, modificas el tema y directamente introduces el código de lo que sería el plugin.

Si quieres tomarte más en serio la generación de los títulos o si eres perezoso existen plugins muy avanzados como SEO Title Tag y All in One SEO Pack, este último también sirve para gestionar los Meta Tags "description" y "keywords" también muy importantes para SEO pero no tanto como los Title Tags.

Etiquetas:
Jun 18

Del.icio.us, el archiconocido servicio de gestión de marcadores sociales, ofrece una API para poder desarrollar aplicaciones que utilicen sus servicios. Hace tiempo que vi aparecer la clase Services_Delicious en el repositorio de las PEAR pero hasta ahora no le había podido pegar un ojo, es una clase que implementa un cliente para los servicios web basados en REST de del.icio.us.

La Transferencia de Estado Representacional (Representational State Transfer) o REST describe una interfaz web simple utilizando peticiones HTTP y datos XML pero sin capas adicionales como SOAP, frecuentemente usadas en los servicios web. Precisamente el otro día estuve charlando con mi colega Manuel Aguilar acerca de las ventajas de usar servicios REST en muchos escenarios frente a los clásicos servicios web basados en SOAP o basados en protocolos propios, tema que se trato en la pasada PHP Conference 2007 spring edition celebrada en Stuttgart a la que Manuel asistió.

Sin ánimo de entrar en más detalles de lo que es REST (puedes consultar la definición de la wikipedia que enlazo, está muy bien) vamos a ver como trabajar con del.icio.us desde PHP usando la clase Services_Delicious.

Services_Delicious es una clase todavía en fase beta que no implementa todo lo que nos ofrece el servicio web de del.icio.us, pero que ya permite hacer todas las operaciones básicas cómodamente, como guardar y borrar enlaces, listar los tags, cambiarles el nombre, etc. Son poco más de 400 lineas bastante bien escritas, aunque en PHP4, donde se utiliza HTTP_Request para realizar las peticiones HTTP y XML_serializer para trabajar con los datos XML.

A continuación describo como hacer una nube de tags de una cuenta determinada de del.icio.us y como guardar un nuevo enlace. Esto son sólo dos ejemplos de utilización de algunas de las funciones que nos proporciona Services_Delicious, puedes ver todas las funciones disponibles en el siguiente listado:

  1. getTags()
  2. renameTag($old, $new)
  3. getDates()
  4. getPosts($tags, $date)
  5. getRecentPosts($tags, $max)
  6. getAllPosts()
  7. addPost($url, $description, $extended, $tags, $date, $shared)
  8. deletePost($url)

Instalación de Services_Delicious

Asumiendo que tenemos las PEAR disponibles lo primero que hemos de hacer es instalar la clase en cuestión:

$ pear install --onlyreqdeps Services_Delicious-beta

Si estamos trabajando con la versión estable de las PEAR, lo más habitual, será necesario añadir "-beta" al nombre del paquete o cambiar la variable de configuración preferred_state. La instalación con el frontend web de las PEAR es igualmente sencilla, lo único a tener en cuenta es que necesita el paquete XML_Serializer que no se instalará automáticamente si tenemos preferred_state=stable ya que también se encuentra en fase beta.

Guardando un enlace en del.icio.us

El código necesario para guardar un enlace es el siguiente:

require_once 'Services/Delicious.php';
$username = 'usuario';
$password = 'contraseña';
$dlc = new Services_Delicious($username, $password);
$enlace = 'http://www.phpbsd.net/';
$titulo = 'PHPBSD.net';
$desc = 'Blog de programación PHP';
$tags = 'php, programación, webdev';
$result = $dlc->addPost($enlace, $titulo, $desc, $tags);
if (PEAR::isError($result)) {
  die($result->getMessage());
} else {
  echo 'OK';
}

Con los nombres de las variables se entiende perfectamente como funciona el tema.

Generando una nube de tags

A continuación una utilización un poco más divertida, generar una nube con todas las etiquetas de una cuenta determinada:

$tags = $dlc->getTags();
foreach ($tags as $key => $value) {
    echo '<a href="http://del.icio.us/'.$username.'/'.$key.'" title="'.$key.' ('.$value.')" style="font-size:'.(70+14*$value).'%">'.$key.'</a> ';
}

Lo anterior sólo es un ejemplo rápido, dependiendo de la cantidad de etiquetas y enlaces se debería hacer algo más con el font-size. Puedes ver funcionando el anterior código sobre mi cuenta en del.icio.us en este ejemplo de nube de tags.

Con Services_Delicious se ha de tener en cuenta que aunque podemos enviar datos con la clásica codificación iso-8859-1 las respuestas vienen en UTF-8, hemos de trabajar con UTF-8 o usar las funciones utf8_encode() y utf8_decode() según convenga, otra opción es modificar Services_Delicious y cambiar la forma de trabajar con XML_Serializer.

Aplicaciones

Aunque la API es muy sencilla nos permite añadir tags a prácticamente cualquier tipo de aplicación PHP, por ejemplo con el anterior código fácilmente nos curramos un pluguin para WordPress que cada vez que colgamos un post lo guarde en del.icio.us, que permita generar una nube de tags, etc. (si es que todavía no existe). Otro ejemplo es con una aplicación de comercio electrónico con stock online como un supermercado o una web de viajes, podemos hacer un script que recorra la BD de turno guardando todos los productos en del.icio.us y permitiendo trabajar con tags, que los usuarios puedan actualizarlos, generar nubes con ellos, etc.

Si a pesar de disponer de tu aplicación PHP en tus servidores o en tu servicio de hosting te gusta sacarte el trabajo de encima con servicios como FeedBurner para los RSS, Flickr para las imágenes, YouTube para los Vídeos... ¿porque no usar del.icio.us para tus tags?

Trabajar con del.icio.us para los tags de tu web tiene la ventaja de que del.icio.us en si es un buen sistema de promoción, mucha gente anda suscrita a RSS de determinados tags, se busca bastante directamente en del.icio.us, etc., y también tiene su efecto en SEO, cada nuevo tag representa un backlink hacia nosotros desde la página de dicho tag. El inconveniente de trabajar con un tercero está claro, que el usuario se pierda por del.icio.us y no vuelva a nuestra tienda o a nuestro blog, aunque siempre podemos usar del.icio.us y no enlazarlos.

A parte de añadir la dimensión de "tag" a nuestra aplicación otro ejemplo de uso de la API de del.icio.us es acceder a nuestros bookmarks de una forma totalmente personalizada y poder mostrarlos como queramos. Un ejemplo de esto es lo que hace Pau Iglesias en la sección de enlaces de su blog, aunque usando otra clase para acceder a la API de del.icio.us que también está muy bien, de hecho es un proyecto más maduro que Services_Delicious.

Esta otra clase es una modificación del mismo Pau Iglesias de la clase original de Dietrich Ayala, autor de las conocidas NuSOAP. En comparación Services_Delicious me gusta más porque básicamente me gusta trabajar con PEAR y usa XML_Serializer/HTTP_Request que, a parte de que ya me las conozco, hacen que el código sea muy limpio y fácilmente adaptable a tus necesidades, pero si no te gustan las PEAR el proyecto del.icio.us PHP API de Pau Iglesias se merece una ojeada, proporciona más o menos las mismas funcionalidades que Services_Delicious pero con el añadido de un interesante sistema de cache.

Etiquetas:
Jun 13

En muchas ocasiones disponemos de un servicio de hosting compartido que no tiene las PEAR instaladas, o que ofrece una instalación mínima que no incluye las clases que necesitamos. A continuación describo como realizar una instalación local de las PEAR en un servidor compartido usando la linea de comandos o un navegador web. A parte de instalaciones en servicios de hosting estos procedimientos resultan muy útiles en otras ocasiones, por ejemplo si queremos probar nuevas clases o distintas versiones de clases sin necesidad de instalarlas en el sistema.

Instalación por consola

Si disponemos de acceso SSH, Telnet, o directo a la consola del servidor este es el procedimiento a seguir.

[1] Iniciamos la sesión de usuario.

[2] Creamos una configuración por defecto para las PEAR:

$ pear config-create $HOME .pearrc

[3] Creamos un directorio temporal en nuestra cuenta para evitarnos problemas de permisos en el directorio "/tmp" del sistema:

$ mkdir $HOME/tmp

[4] Cambiamos las variables necesarias para que trabajen con nuestro directorio temporal:

$ pear config-set download_dir $HOME/tmp/download
$ pear config-set temp_dir $HOME/tmp

[5] Verificamos la correcta configuración:

$ pear config-show

[6] Instalamos el sistema base:

$ pear install -o PEAR

[7] Instalamos las clases PEAR que necesitemos:

$ pear install <clase>

o si queremos instalar alguna versión beta:

$ pear install <clase>-beta

Instalación vía web

Si sólo disponemos de acceso por FTP o Web (como yo con HostGator) o si no queremos trabajar con comandos estos son los pasos necesarios para realizar una instalación vía web.

[1] Vamos a http://go-pear.org/ y guardamos el script PHP que aparece como go-pear.php.

[2] Creamos un directorio en nuestro servidor, por ejemplo "pear", y copiamos go-pear.php dentro.

[3] Abrimos con un navegador la URL correspondiente, por ejemplo:
http://ejemplo.com/pear/go-pear.php

[4] Seguimos los pasos que nos aparecen por pantalla, las opciones por defecto son válidas en la mayoría de ocasiones.

[5] Posteriormente podremos gestionar las clases PEAR instaladas abriendo:
http://ejemplo.com/pear/
Allí nos encontraremos el Web-based PEAR Frontend que nos permitirá instalar, desinstalar y actualizar clases, buscar nuevas clases, cambiar la configuración, etc.

[6] Es importante proteger el directorio de las PEAR para que no sea accesible al público. Al estar dentro del DocumentRoot del servidor Apache cualquiera podrá acceder a la configuración de nuestras PEAR a no ser que protejamos el directorio con usuario+contraseña y/o filtrando por IP.

Snapshot del frontend web de las PEAR:

PEAR Frontend snapshot

Configuraciones finales

Una vez completado con éxito cualquiera de los dos procedimientos anteriores sólo nos faltará añadir el directorio que contiene las clases PEAR, en el ejemplo "pear/PEAR", al include_path del PHP para que funciones como include() y require() puedan encontrar las nuevas clases:

set_include_path(get_include_path().PATH_SEPARATOR.'/home/usuario/pear/PEAR');

Se ha de cambiar "/home/usuario" por la ruta física a tu home de usuario. En el último paso del proceso de instalación vía web se muestra la ruta física a las clases, si has realizado una instalación por consola teclea pwd en tu home y añade "pear/PEAR".

Etiquetas:
preload preload preload