En mi corta experiencia en el mundo de las bibliotecas una cosa me ha quedado ya clara: la supremacía de los grandes proveedores de contenidos y de paquetes de software. La mayoría de las suscripciones a recursos electrónicos vienen dados por grandes editoriales que ejercen el control, haciendo y deshaciendo a su antojo.
Y en el mundo de los sistemas integrados de gestión bibliotecaria, tres cuartos de lo mismo. Los paquetes más completos son, por supuesto, privativos y con unos costes bastante interesantes (por no decir otra cosa…). También hay excepciones. Pero recalco lo de excepciones (incluso lo pongo en negritas, por si no ha quedado suficientemente claro ). Así que os podréis imaginar la dependencia de esos mastodontes de cara a modernizar o incorporar funcionalidades actuales. Ellos marcan los ritmos, que por supuesto, son más lentos que la frenética celeridad de la tecnología hoy en día.
¿Y qué hacer ante esto? Pues como el propio título del post indica: si la Mahoma no va a la montaña, será la montaña la que acuda a ayudar a Mahoma . En la biblioteca de la Universidad de Deusto llevábamos un tiempo buscando la herramienta ideal para publicar las nuevas adquisiciones de una manera amigable para el usuario final. Y hemos optado por un WordPress como CMS aliñado con un plugin de desarrollo propio: http://nuevasadquisiciones.deusto.es
Diariamente se publican las novedades, siendo cada post una ficha de libro. En esa ficha cargamos la información básica que dependerá de lo que se pueda obtener de manera automática de Open Library y/o WorldCat mediante su API. La ficha ideal, es decir, todos los campos que se buscan son: título, autor/es, editorial, fecha de publicación, número de páginas, ISBN, signatura, número de copia (éste es un número interno de nuestro SIGB), idioma y resumen.
Con la portada sucede lo mismo: se busca en Open Library y en LibraryThing, y si está, se carga. Si no, se pone una por defecto (dado que otras plataformas no dejan cogerlas por problemas de derechos). Escribiré un post contando de manera pormenorizada esto mismo.
Además, se añade un enlace directo de ese libro en las siguientes webs/redes sociales de lectura: WorldCat, LibraryThing, Google Books y BookFinder. Y también ponemos un enlace directo del ejemplar al catálogo de la biblioteca.
Al hilo de Google Books, si ese libro está cargado allí y permite el ojeo, aparecerá el visor del mismo en la ficha, para que se pueda acceder al contenido directamente. Eso sí, llevamos ya más de 1.500 fichas de libros publicadas y aún no he visto ninguno que lo permita .
Cada ficha lleva como etiquetas el Campus en el que está y la materia a la que pertenece, para que los usuarios puedan luego suscribirse vía RSS a un Campus en concreto, si así lo desean, o a una materia, logrando un mejor filtrado.
Gracias a otros plugins de WordPress, obtenemos más funcionalidades:
WP-PostRatings: nos permitirá que los lectores voten los libros y así mostrar los más valorados por ellos.
AZIndex: nos permite generar los típicos listados AtoZ que tanto se estilan en las bibliotecas .
Comentarios + Subscribe To Comments: con esto tenemos la herramienta ideal para generar conversación alrededor de los ejemplares.
La información de las novedades se carga mediante un csv que tan sólo necesita los ISBNs de los libros. El resto de información, como he comentado anteriormente, se carga automáticamente a través de Open Library y WorldCat. También tocará un post hablando de lo importante que sería impulsar proyectos como Open Library.
Como veis, no es un OPAC… pero casi . Una pequeña ventana de escapatoria a los paquetes convencionales que nos da cierta libertad. De hecho, hay una palabra clave en todo esto: RSS. Con él podemos redirigir los contenidos a muchas otras plataformas. Por ejemplo, publicar de manera automática esos ejemplares en Twitter o Facebook mediante Twitterfeed. O lo más importante: permitir que el usuario se suscriba a las temáticas que le interesan, mejorando el filtrado y quitando ruidos innecesarios.
Ahora la pregunto que os lanzo es clara: ¿tiene interés que libere el plugin para que otros lo usen y enriquezcan?.
Tras este desarrollo, Javier Leiva me puso sobre la pista de Scriblio: un WPopac, es decir, un catálogo en línea gestionado mediante WordPress. Aún no he podido analizarlo a fondo, pero seguro que hay muchas cosas aprovechables para el nuevo sistema. Incluso en una segunda versión, sería interesante trabajar con los custom post types que ofrece WordPress 3.0 y así ofrecer un buscador más robusto por cada campo de las fichas. Veremos cómo discurre la cosa .
Como es costumbre, aquí dejo el material usado en el cursillo del e-ghost+aprendices que he impartido esta semana sobre cómo convertir a nuestro WordPress en una página web y no tanto en un blog y cómo entender a fondo el funcionamiento de las plantillas.
La información está también recogida en el wiki que, por cierto, está de estreno. No porque esté descontenta con wikispaces… pero me gusta más tener mis datos bajo mi paraguas (manías de vieja ). Poco a poco iré migrando el resto de contenidos allí.
Internamente WordPress se compone de los siguientes ficheros y carpetas:
wp-config.php: fichero de configuración. Aquí está almacenado el usuario y el nombre de la base de datos, así como otros datos de seguridad. Es importante que este fichero no tenga lectura más que por el owner del mismo. Este fichero no se machaca con las actualizaciones de WP.
wp-admin y wp-includes: carpetas que guardan los ficheros php que hacen que funcione el blog. Ambas carpetas se machacan con las actualizaciones
wp-content: esta carpeta guarda los datos y configuraciones propias del blog. No se toca nada en la actualizaciones de WP. La estructura interna es la siguiente:
uploads: todas las imágenes, vídeos y archivos que se suban a la librería de wordpress. Normalmente se organiza por años y luego por meses. Ejemplo: uploads/2009/12.
plugins: todos los plugins que tenemos disponibles para el blog (aunque no estén activos).
languages: aquí van los ficheros .mo de los idiomas en los que queremos tener WP (tanto la parte visible como la de administración). Para indicar luego que el blog esté en un idioma u otro, habrá que añadir una línea en wp-config.php como la que sigue: define (‘WPLANG’, ‘es_ES’); donde es_ES es el nombre del fichero .mo (tienen que coincidir en nombre).
themes: todas las plantillas que tenemos disponibles para “vestir” al blog. Nosotros nos centraremos en esta carpeta.
Como podemos ver, una instalación de WordPress es muy portable. Si nos queremos cambiar de servidor o hosting, bastará con que nos llevemos estas carpetas y la Base de Datos exportada en un simple .sql. No requiere de otras configuraciones más complejas.
La estructura básica de un theme
Las plantillas o themes son la capa de presentación de los blogs o páginas web que se monten. Se puede cambiar esta capa sin que la información se vea afectada. WordPress reconoce automáticamente los siguientes ficheros y los interpreta:
header.php: aquí se define la cabecera de la página.
footer.php: aquí se define el pie de página.
sidebar.php: aquí se definen las diferentes barras laterales.
index.php: este es el fichero que carga de inicio el site. Desde aquí se invoca la carga de cabecera (get_header();), barras laterales (get_sidebar();) y footer (get_footer();) y en el cuerpo central, se ejecuta el bucle para cargar la información de los posts.
single.php: este es el fichero que se interpreta cuando se carga un post concreto.
archive.php: igual que single.php pero para las páginas de categorías y etiquetas.
category.php: plantilla para las categorías. Cuando un usuario pincha sobre el enlace de una categoría, WordPress prueba si existe el fichero category.php. Si no lo encuentra, carga archive.php. Y si éste tampoco lo encuentra, se va a por el index.php. Más adelante veremos un gráfico con la interpretación jerárquica que hace WordPress.
comments.php: plantilla de los comentarios.
searchform.php: formulario de búsqueda.
search.php: página donde se muestran los resultados de una búsqueda.
functions.php: aquí se recogerán funciones propias del theme. Por ejemplo, si queremos registrar varias barras laterales para que aparezcan en la sección de widgets, indicar a WP dónde están los ficheros de idiomas, quitar filtros, …
style.css: fichero con los estilos.
404.php: si creamos este fichero, cada vez que algo no se encuentre en el blog, se cargará esta página.
Desde el apartado de administración se podrá configurar la apariencia de una forma muy visual mediante widgets (en el apartado Apariencia –> Widgets). Aquí aparecen las barras laterales definidas y múltiples funcionalidades que se pueden colocar: comentarios recientes, posts recientes, buscador, una caja donde introducir nuestro propio código html, …
También desde el apartado de administración (Ajustes –> Lectura) podemos configurar que la portada que se carga de nuestra web sea una página y no el formato blog de entradas, dándole más carácter de página web.
Sidebars
Podríamos cargar diferentes sidebars con la misma metodología que los headers y los footers (explicada más adelante), pero existe una manera para que generemos un espacio dentro del apartado de los widgets.
Para que aparezcan en la sección de widgets las diferentes sidebars que queramos “alimentar” desde el panel de administración, hay que registrarlas en el fichero functions.php de la siguiente forma:
if ( function_exists(‘register_sidebars’) )
{
register_sidebar(array(
‘name’ => ‘Barra Lateral Derecha’,
‘before_widget’ => ‘código html que queremos que se cargue al inicio de la barra’,
‘after_widget’ => ‘código html que queremos que se cargue al final de la barra’,
‘before_title’ => ‘código html que queremos que se cargue al inicio del título de la barra’,
‘after_title’ => ‘código html que queremos que se cargue al final del título de la barra’,
));
register_sidebar(array(
‘name’ => ‘Barra Lateral Izquierda’,
‘before_widget’ => ‘código html que queremos que se cargue al inicio de la barra’,
‘after_widget’ => ‘código html que queremos que se cargue al final de la barra’,
‘before_title’ => ‘código html que queremos que se cargue al inicio del título de la barra’,
‘after_title’ => ‘código html que queremos que se cargue al final del título de la barra’,
));
}
Para usarlas posteriormente, la llamada será de la siguiente forma:
<?php if ( !function_exists(‘dynamic_sidebar’) || !dynamic_sidebar(‘Barra Lateral Izquierda’) ) :
echo “El usuario no ha puesto widgets en esta barra”;
endif; ?>
De esta forma tan sencilla podemos cargar ficheros php personalizados para mostrar diferentes footers o cabeceras según estemos en una categoría u otra. En el ejemplo, si estamos en la categoría de Cine se cargará footer-cine.php. Si no, se cargará footer.php.
Sería exactamente lo mismo para las cabeceras (header-cine.php vs. header.php):
Es decir, lo que WordPress busca es el fichero header-slug.php (el slug es el permalink. Es decir, la versión url del nombre: una cadena sin mayúsculas, sin tildes, con guiones en vez de espacios).
Categorías y etiquetas personalizadas
Para cargar diferentes presentaciones dependiendo de la categoría o la etiqueta sobre la que se pinche, podemos crear un php igual que lo hacíamos con las cabeceras, es decir category-slug.php o tag-slug.php o bien con el siguiente formato de nombre category-XX.php o tag-XX.php (donde XX es el id que tiene internamente esa categoría o etiqueta). De esta forma, podríamos ponerle una cabecera, un footer y un sidebar personalizados dependiendo de la categoría o la etiqueta en la que estemos.
Aquí vemos el orden en el que WordPress busca los ficheros y los carga:
Para cualquiera de las vistas que no tenga un archivo de plantilla separado, WordPress usará index.php de manera predeterminada. Si un visitante solicita un artículo individual, WordPress primero buscará un archivo llamado single.php. Si ese archivo existe, será utilizado para presentar el artículo. Si ese archivo no existe, WordPress utilizará index.php.
Templates
Podemos crear plantillas con comportamientos propios a los que luego asignar a cada página. Desde el editor de páginas estáticas hay una opción para aplicar plantillas. Para que un fichero php sea interpretado por WordPress como una template, hay que incluir al inicio del mismo el siguiente código:
/*
Template Name: Nombre-plantilla
*/
The Loop
El bucle es el proceso más importante de WordPress, aquel que nos devuelve y recorre todos los posts que corresponden al fichero desde el que se invoca:
Si se le llama desde index.php, nos devuelve los últimos posts que se hayan escrito (tantos como tengamos definidos que deberían formar parte de la portada en el apartado de administración).
Si se le llama desde archive.php, nos devuelve los posts de una etiqueta determinada o de una categoría concreta (dependerá de quién haga la llamada a ese fichero).
Por tanto, es en este bucle donde procesaremos la colección de posts.
<?php
get_header();
if (have_posts()) :
while (have_posts()) : the_post();
the_content();
endwhile;
endif;
get_sidebar();
get_footer();
?>
wp_query->current_post: nos devuelve el número del post en el que estamos dentro del loop. Un ejemplo de uso en el que mostramos el contenido para los tres primeros posts y sólo el título para el resto:
<?php if (have_posts()) :
while (have_posts()) : the_post();
if ($wp_query->current_post < 3) {
the_content();
}
else {
the_title();
}
endwhile;
endif; ?>
Sin embargo, nosotros también podemos controlar qué posts nos devolverá ese loop mediante la función query_posts. Esa función regenera la consulta y filtra los posts en base a los parámetros que le pongamos:
cat=ID: filtra por esa categoría. Si al id se le pone un guión por delante, muestra los posts de todas las categorías menos de esa.
tag=slug: filtra por etiqueta. En esta ocasión se le pasa el slug. Si queremos usar el ID de la etiqueta, pondremos el parámetro tag_id.
author=ID: filtra por usuario, usando el ID del mismo.
order=ASC u order=DESC: indica la ordenación de los resultados, ascendente o descendente.
//The Loop
if ( have_posts() ) : while ( have_posts() ) : the_post();
..
endwhile; else:
..
endif;
//Reset Query
wp_reset_query(); ?>
Funciones
the_permalink(): nos dará la url del post que estemos tratando dentro del loop. No tiene parámetros. Con get_permalink() tendremos que mostrarlo nosotros por pantalla con un echo, pero nos permite que, si tenemos el ID del post y se lo pasamos por parámetro, lo usemos fuera del loop: get_permalink($post->ID).
the_title($before, $after, $echo): muestra el título del post y también es necesario usarlo dentro del loop. Los parámetros $after y $before nos permite introducir cadenas de texto que irán delante y detrás respectivamente. Por ejemplo, si queremos que el título vaya con las etiquetas html <h3>, podemos hacer la siguiente llamada: the_title(‘<h3>’, ‘</h3>’). El parámetro $echo nos sirve para indicar si queremos que muestre el título por pantalla (si lo ponemos a true) o no para hacer algún tratamiento con ese título (si lo ponemos a false). Con get_the_title(ID) sucede igual que get_permalink pero para el título del post.
the_excerpt(): muestra lo que hayamos introducido en el campo Extracto. Se usa dentro del loop. Tiene su versión get_the_excerpt().
<?php if(!empty($post->post_excerpt)) {
// Si tiene extracto, lo muestra
the_excerpt();
} else {
// Si no, muestra el contenido del post
the_content();
} ?>
the_time(): muestra la fecha por cada post. Le podemos pasar por parámetro el formato de esa fecha:
l = Nombre completo del día de la semana.
F = Nombre completo para el mes.
j = Día numérico.
m = Mes con dos dígitos.
Y = Año con cuatro dígitos.
y = Año con dos dígitos.
Para escapar letras, usaremos la barra \. Por ejemplo, para poner la palabra “de” le pasaremos “\d\e”
the_author(): muestra por pantalla el autor que ha escrito ese post. Tiene su versión sin echo: get_the_author.
the_tags( $before, $separator, $after): muestra las etiquetas asociadas a ese post. Por parámetro se le puede pasar el texto que precederá a las etiquetas, los caracteres que queremos que separen las etiquetas y el texto que irá al final. Tiene también su versión get_the_tags que nos devolverá un array con las etiquetas, para que las procesemos nosotros.
<?php the_tags(‘Etiquetas:’, ‘ – ‘, ‘<br />’); ?>
posts_nav_link: muestra un enlace con el texto que le pasemos por parámetro a los posts que estén en páginas anteriores. Se usa en el index.php para que se pueda navegar a los contenidos anteriores a los posts que se muestran en la portada.
previous_posts_link: muestra un enlace con el texto que le pasemos por parámetro a los posts que estén en páginas anteriores. Se usa en el index.php para que se pueda navegar a los contenidos anteriores a los posts que se muestran en la portada.
next_posts_link: muestra un enlace con el texto que le pasemos por parámetro a los posts que estén en páginas posteriores. Se usa en el index.php para que se pueda navegar a los contenidos posteriores a los posts que se muestran en la página desde la que se invoca.
in_category($category): nos dice si ese post está en la categoría pasada por parámetro. Se puede pasar el ID de la categoría o bien el slug. Con esto también podemos hacer que tenga comportamientos distintos según la categoría y en un único fichero category.php.
Cuando estamos creando un post, justo debajo de la caja del texto podemos introducir campos personalizados introduciendo un nombre y un valor:
El Nombre será el identificador de nuestro campo personalizado y el Valor lo que queremos mostrar. Obtendremos el valor de ese campo dentro del loop con la siguiente llamada get_post_custom_values:
Estos custom fields son los metadatos extra de cada post (que se suman a los ya típicos autor, fecha, etiquetas, categorías, etc…). Así podría ser la canción que está escuchando el autor cuando escribió el post o su estado de ánimo, el precio (si usamos el blog como tienda virtual), etc…
Panel de administración del theme
Para crear un apartado de administración de nuestro theme, debemos incluir la siguiente llamada en functions.php (en este ejemplo estamos poniendo un textarea para que se almacene nuestro código de Google Analytics):
/* Meter código de Google Analytics */
function nombredeltheme_theme() {
if(isset($_POST['submitted']) and $_POST['submitted'] == ‘yes’) :
update_option(“google_analytics”, stripslashes($_POST['google_analytics']));
endif;
?>
<form method=”post” name=”update_form” target=”_self”>
<h1>Google Analytics</h1>
<table>
<tr>
<th>Google Analytics:</th>
<td><textarea name=”google_analytics” style=”width: 95%;” rows=”10″ />
<?php echo get_option(‘google_analytics’); ?></textarea><br />Copia el código Google Analytics aquí.</td>
</tr>
</table>
<p id=”jump_submit”>
<input name=”submitted” type=”hidden” value=”yes” />
<input type=”submit” name=”Submit” value=”Save Changes” />
</form>
<?php
}
function nombredeltheme_options() {
add_menu_page(‘Opciones del Theme’, __(‘Opciones del Theme’, ‘default’), ‘edit_themes’, __FILE__, ‘nombredeltheme_theme’);
}
add_action(‘admin_menu’, ‘nombredeltheme_options’);
Luego ponemos en el footer.php:
<?php echo get_option(‘google_analytics’); ?>
De esta forma se cargará en el footer lo que el usuario alimente desde el panel de administración.
Septiembre es el mes de la vuelta. De la vuelta de vacaciones, de la vuelta al cole (y los corticoles), a la rutina, al malvado a la par que olvidado despertador, …
Pero este año, gracias al e-ghost y aprendices vamos a convertirlo también en el mes de WordPress.
Si estás interesado/a en este gestor de contenidos cada día más completo, apúntate estas fechas en rojo:
10 de septiembre de 15:00 a 19:00 en la sala de videoconferencias de la Facultad de Ingeniería de la Universidad de Deusto: Iniciación a WordPress: este evento no es realmente una charla, sino un taller o ‘desconferencia’ en la que varios Aprendices pondremos en común lo que sabemos.
El objetivo es hablar sobre lo siguiente:
¿Qué es WordPress?
Cómo abrir un blog en wordpress.com
Breve repaso a funcionalidades básicas.
Comparación con otros sistemas de creación de blogs.
13 y 14 de septiembre de 18:00 a 20:00 en la Facultad de Ingeniería de la Universidad de Deusto: Cómo usar WordPress para montar una página web sin que parezca un blog: Curso para conocer a fondo el funcionamiento del sistema de plantillas de WordPress y conseguir así presentar este CMS como algo más que un gestor de blogs. Se aprenderá la estructura y el funcionamiento de los themes, cómo cambiar la forma de mostrar la información, crear un widget propio, etc… Éste sí que lo imparto yo de una manera clásica y ¡¡ATENCIÓN!! Es necesario inscribirse (aunque sea gratuito). Como requisito previo serán necesarias unas nociones básicas de PHP.
17 de septiembre de 15:00 a 19:00 en la sala de videoconferencias de la Facultad de Ingeniería de la Universidad de Deusto: Plugins, WordPress MU y BuddyPress. Al igual que el de introducción, se trata de una desconferencia en la que cada aprendiz pondrá sobre la mesa sus experiencias. Se hablará sobre:
Qué es un plugin y para qué sirve.
Repaso de plugins útiles.
Qué es WP MU y para qué sirve. Cómo instalar. Repaso funcionalidades básicas.
Qué es BuddyPress y para qué sirve. Cómo instalar. Repaso funcionalidades básicas.
Y por supuesto, no te pierdas el resto de cursos que organiza el e-ghost durante septiembre. Al final no va a ser tan mal mes .
Estamos a punto de llegar al apunte décimo de esta sección, pero antes toca el noveno, que no por ello va a ser menos importante:
Arrancamos la lectura breve con un vídeo no breve. Vamos: toda una contradicción . Joseba me ha descubierto una interesante exposición de David Weinberger (co-autor del conocido Manifiesto Cluetrain) a través del recién estrenadito blog de la biblioteca de Deusto. Habla sobre uno de sus libros (que ya he añadido a mi lista de deseos): Everything is Miscellaneous y de cómo las clasificaciones tradicionales como CDU están limitadas en el mundo digital porque trabajaban sobre la premisa del mundo físico. Es decir, un libro en la biblioteca sólo estaba contemplado que fuera a un único espacio o división porque sus átomos no se podía separar en diferentes etiquetas. Y cómo con estas clasificaciones tendemos a llevar todo a la “carpeta” del misceláneo.
La lectura en Internet suele convertirse en algo más superficial de lo que nos gustaría. Parte de culpa reside en las muchas distracciones que rodean a los contenidos. Readability se presenta como la solución a esto: elimina lo que flota alrededor del texto y lo pone en el tipo de letra y con el tamaño que nosotros decidamos.
El camino de la lectura electrónica se bifurca en dos ramas: las plataformas que trabajan en la nube, siendo necesaria la conexión para acceder a los contenidos, y las que te permiten la descarga del e-book o la compra del libro físico. A la guarda del esperado Google Editions (que dicen los mentideros de la Red que está ya muy cerca) tenemos a los archiconocidos tacañones propietarios: Amazon con su Kindle como lector, la Ibookstore de Apple (la alimentación para el Ipad), la Sony Reader Store, con el mismo esquema que las dos anteriores pero del proveedor tecnológico Sony y, por último, Safari basada en contenido de carácter tecnológico, fruto de la unión de O’Reilly Media y Pearson Technology Group.
Web 2.0, software libre y bibliotecas académicas: se acaba de publicar un paper que habla del uso de las herramientas 2.0 y el software libre en tres bibliotecas de la Universidades de Puerto Rico.
Y el vídeo de regalo en esta ocasión es un anuncio del futuro de la revista Sports Illustrated en un Tablet. Por fin una publicación ha entendido que ser digital no es trasladarse a la red o a la cacharrería tal y cómo se era en papel. Si no que existe una nueva manera de leer y mostrar los contenidos aprovechándose al máximo de la multimedia:
Hace unas semanas me tuve que preparar un mini-curso para los del departamento sobre WordPress, así que ya que el trabajo está hecho, lo mejor es compartirlo por si a más personas les puede ser de ayuda:
Es un CMS (Sistema de Gestión de Contenidos) especialmente pensado en la publicación de bitácoras pero que puede ser usado para la creación de webs de edición fácil y rápida. Tiene una serie de funcionalidades que vienen en su núcleo (gestión de feeds, búsquedas, etiquetas, categorías, …) y luego se le pueden añadir otras muchas a través de plugins (por ejemplo, un detector de spam).
Con WordPress tenemos dos opciones: crearnos un blog en su plataforma comercial (wordpress.com) o en nuestro propio servidor gracias a su software bajo licencia GPL (wordpress.org). En ambos casos el gasto es cero pero con excepciones. En el primero, determinadas funcionalidades son de pago (por ejemplo, la posibilidad de editar el css de nuestra plantilla) y en el segundo, el coste estará en el servidor en el que decidamos montar nuestro blog.
En 2003, el proyecto b2\cafelog, que contaba con unos 2000 blogs, se dividió en dos ramas: b2evolution y WordPress. De la mano de Matt Mullenweg y Mike Little, la plataforma ganó muchos usuarios coincidiendo con el cambio de licencia de Movable Type.
Es de código abierto, está escrito en php y usa MySQL como gestor de base de datos. Uno de sus puntos más fuertes es la enorme comunidad de desarrolladores que tiene a sus espaldas. Al ser software libre, cualquiera puede escribir un plugin para agregar una funcionalidad determinada: desde la más rara (que nos aparezcan frases del musical Hello, Dolly! en nuestro panel de administración) a la más avanzada. Por esta razón tenemos un gran repositorio de plugins y plantillas para personalizar tanto como queramos nuestro site.
Como curiosidad queda que cada nueva versión recibe el nombre de una leyenda del jazz: Miles Davis, Art Blakey, Charles Mingus, Billy Strayhorn,…
1.1. Pros y contras de WordPress.com y WordPress.org
Pros de WordPress.org: es software libre, lo que nos aporta una transparencia de su funcionamiento. Además cuenta con una gran comunidad de desarrolladores que mantienen el sistema vivo y en continua evolución. El contenido es completamente tuyo dado que eres tú el que almacena los archivos y la base de datos del blog. Se tiene un control total sobre el diseño. Permite importar contenidos de otras plataformas como Blogger, LiveJournal, Movable Type,… Se puede ampliar fácilmente la funcionalidad de este gestor de contenidos mediante extensiones.
Contras de WordPress.org: somos los responsables de la instalación y del mantenimiento del software y WordPress se caracteriza por las continuas actualizaciones para mejorar versiones anteriores y arreglar los fallos que éstas pudieran tener. Se necesita disponer de alojamiento y de dominio. Las copias de seguridad corren de nuestra cuenta.
Pros de WordPress.com la plataforma evoluciona al mismo ritmo que su hermana libre (WordPress.org), lo que hace que sea un sistema que se adapta a las novedades que aparecen en la cambiante Red. Nos ahorramos los gastos de un servidor y un dominio propio, así como el trabajo que supone actualizar la versión del software.
Contras de WordPress.com: si deseamos instalar plugins o hacer modificaciones sobre el diseño de nuestra bitácora, deberemos tirar de cartera. Lo mismo que para ampliar los 3 GB de espacio para el almacenamiento de imágenes y ficheros subidos.
WordPress tiene una parte visible para todo el mundo (a no ser que lo hagamos privado mediante un plugin) y una parte desde la que se administra los contenidos. Normalmente, el acceso a esa parte de administración está en la dirección http://urldelblog/wp-admin/
1.2. Tipos de usuarios
Por defecto, en WP, está desactivada la opción de que cualquiera pueda registrarse. Esa opción se habilita desde el panel de control, en Opciones Generales. Allí, conjuntamente se añade el rol por defecto que tomarían esos nuevos usuarios.
En WordPress existen cinco perfiles con diferentes privilegios (si queremos crear otros roles con permisos distintos, tendremos que instalar un plugin que nos provea de esa funcionalidad):
Suscriptor: es un mero lector que puede configurar su avatar, su dirección de correo, su página web, …
Colaborador: puede crear entradas pero no las puede publicar.
Autor: puede crear entradas y publicarlas.
Editor: puede crear, eliminar, modificar y publicar entradas (tanto suyas como de otros). Lo mismo con las páginas, las categorías y los enlaces del blogroll.
Administrador: a lo que hace el editor, se le suma la administración de usuarios, gestión de plantillas y plugins, así como opciones generales del blog.
Extraemos el .zip descargado y copiamos la carpeta en /var/www/blog (o el directorio desde donde se sirvan las páginas por el apache). La estructura de WordPress es la siguiente:
wp-config.php: fichero de configuración. Aquí está almacenado el usuario y el nombre de la base de datos, así como otros datos de seguridad. Es importante que este fichero no tenga lectura más que por el owner del mismo. Este archivo no se machaca con las actualizaciones de WP.
wp-admin y wp-includes: carpetas que guardan los ficheros php que hacen que funcione el blog. Ambas carpetas se machacan con las actualizaciones.
wp-content: esta carpeta guarda los datos y configuraciones propias del blog. No se toca nada en la actualizaciones de WP. La estructura interna es la siguiente:
uploads: todas las imágenes, vídeos y archivos que se suban a la librería de wordpress. Normalmente se organiza por años y luego por meses. Ejemplo: uploads/2009/12 (pero se puede configurar desde Opciones –> Misceláneas).
plugins: todos los plugins que tenemos disponibles para el blog (aunque no estén activos).
themes: todas las plantillas que tenemos disponibles para “vestir” al blog.
languages: aquí van los ficheros .mo de los idiomas en los que queremos tener WP (tanto la parte visible como la de administración). Para indicar luego que el blog esté en un idioma u otro, habrá que añadir una línea en wp-config.php como la que sigue: define (‘WPLANG’, ‘es_ES’); donde es_ES es el nombre del fichero .mo (tienen que coincidir en nombre).
Ponemos los permisos adecuados para la carpeta blog (como owner y group al usuario de apache):
chown -R www-data:www-data blog
Creamos una BD para wordpress ¡¡IMPORTANTE!! El nombre de la base de datos no puede tener guiones altos
mysqladmin -u root -p create nombrebd
Creamos un usuario con permisos para esa BD:
$ grant all on bd.* to user@localhost IDENTIFIED BY ‘pass’;
$ flush privileges;
Lanzamos desde el navegador la instalación ¡¡IMPORTANTE!! Cambiar el prefijo de las tablas SQL por defecto (wp_) durante la instalación por razones de seguridad
Si no vamos a importar ningún blog de otro sistema, borramos también: wp-admin/import/
3. Configuración
Tras la instalación es recomendable configurar las siguientes opciones:
Por razones de seguridad, cambiamos el nombre por defecto del usuario administrador (admin). Para ello, creamos un usuario con el rol de administrador, iniciamos sesión con esa nueva cuenta y borramos la de admin, asignando a ese nuevo usuario todo lo creado por admin.
Cambiar los permalinks: en personalizada ponemos /%postname%/ o la forma que más nos guste. A poder ser, que sean url’s “bonitas”.
En Opciones –> Discusión dejar sólo marcada la opción “El autor del comentario debe rellenar el nombre y el e-mail” para que no estén todos los mensajes moderados por defecto.
4. Plugins
Como hemos comentado anteriormente, WP tiene un núcleo con funcionalidades básicas que pueden ser complementadas por plugins. A continuación vamos a describir algunos de los más interesantes, aunque podremos descargarnos muchos más desde el repositorio de WP, alimentado por todos los usuarios que van haciendo pequeños desarrollos.
Akismet: la mejor lucha contra el spam creada por el propio equipo de WP.
Contact Form 7: para crear formularios personalizados en múltiples idiomas, con múltiples campos y diferentes validaciones. Por ejemplo, el de contacto.
xlanguage: si queremos tener nuestro site en varios idiomas.
All in One SEO Pack: para optimizar al máximo nuestro site frente a los buscadores. El complemento ideal es Google XML Sitemaps, que genera de forma automática nuestro sitemap cada vez que se publica algo nuevo.
Si queremos que nuestros artículos puedan ser mandados de forma fácil a redes sociales como Facebook, twitter, menéame, etc… Sociable es nuestro plugin.
Subscribe To Comments: para permitir a nuestros lectores recibir notificaciones vía correo cuando alguien deje comentarios en determinadas entradas.
Members Only – Permite que el blog sólo sea accesible por usuarios registrados (tanto a posts como a la parte de administración).
wpDirAuth: si queremos que los usuarios del site se validen contra un LDAP.
Yet Another Related Posts: para obtener artículos relacionados con uno ya escrito en base a datos coincidentes como etiquetas, categorías o aparición de palabras en común.
En WordPress es sumamente sencillo cambiar la apariencia de nuestra página. Tenemos miles de plantillas para elegir, pero también podremos crear la nuestra. Además, desde el apartado de administración se podrá configurar la apariencia de una forma muy visual mediante widgets (en el apartado Apariencia –> Widgets). Aquí aparecen las barras laterales definidas y múltiples funcionalidades que se pueden colocar: comentarios recientes, posts recientes, buscador, una caja donde introducir nuestro propio código html, …
La estructura básica de un theme es la siguiente:
header.php: aquí se define la cabecera de la página.
footer.php: aquí se define el pie de página.
sidebar.php: aquí se definen las diferentes barras laterales. Para que aparezcan en la sección de widgets para que puedan ser “alimentadas” desde el apartada de administración, hay que registrarlas en el fichero functions.php de la siguiente forma:
if ( function_exists(‘register_sidebars’) )
{
register_sidebar(array(
‘name’ => ‘Barra Lateral Derecha’,
‘before_widget’ => ‘código html que queremos que se cargue al inicio de la barra’,
‘after_widget’ => ‘código html que queremos que se cargue al final de la barra’,
‘before_title’ => ‘código html que queremos que se cargue al inicio del título de la barra’,
‘after_title’ => ‘código html que queremos que se cargue al final del título de la barra’,
));
register_sidebar(array(
‘name’ => ‘Barra Lateral Izquierda’,
‘before_widget’ => ‘código html que queremos que se cargue al inicio de la barra’,
‘after_widget’ => ‘código html que queremos que se cargue al final de la barra’,
‘before_title’ => ‘código html que queremos que se cargue al inicio del título de la barra’,
‘after_title’ => ‘código html que queremos que se cargue al final del título de la barra’,
));
}
index.php: este es el fichero que carga de inicio del site. Desde aquí se invoca la carga de cabecera (get_header();), barras laterales (get_sidebar();) y footer (get_footer();).
single.php: este es el fichero que se interpreta cuando se carga un post concreto.
archive.php: igual que single.php pero para las páginas de categorías y etiquetas.
functions.php: aquí se recogerán funciones propias del theme. Por ejemplo, si queremos registrar varias barras laterales para que aparezcan en la sección de widgets, indicar a WP dónde están los ficheros de idiomas, quitar filtros, …
Templates: podemos crear plantillas con comportamientos propios a los que luego asignar a cada página. Desde el editor de páginas estáticas hay una opción para aplicar plantillas. Para que un fichero php sea interpretado por WP como una template, hay que incluir al inicio del mismo el siguiente código:
/*
Template Name: Nombre-plantilla
*/
style.css: fichero con los estilos.
404.php: si creamos este fichero, cada vez que algo no se encuentre en el blog, se cargará esta página.
Tanto en WordPress.com como en la versión instalada en nuestro servidor, la opción de exportar se encuentra en la sección de “Herramientas” de la columna lateral de configuración. Hay que pinchar en el botón “Descargar el archivo de exportación”, lo que nos genera un archivo XML con todos los posts, comentarios, campos personalizados, categorías y etiquetas. Este fichero se puede utilizar para ser importado en otro sitio creado con WordPress. También se puede importar desde otras plataformas, como Blogger, Posterous, LiveJournal y Movable Type, entre otros.
Estamos en el apunte capicúa: el quinto capítulo de las cinco lecturas breves. Así que pueden ustedes empezar por el principio o por el final (como más les plazca).
La Biblioteca Abierta (Open Library) es un proyecto de la organización sin ánimo de lucro Archive.org (esos que guardan el backup de Internet ), que pretende generar una página web a modo de registro por cada libro que se haya publicado jamás. Es un proyecto abierto: el software es libre, los datos son públicos, la documentación es pública y abierta, y el sitio es público.
Muchos se quieren liberar de la pesada carga que supone la tinta electrónica. Así que no extraña ver movimientos como el de la compra de Touchco (empresa especializada en pantallas táctiles) por parte de Amazon.
A través de Centinel llego a la plataforma YouKioske, un lugar donde leer online un montón de revistas (no preguntéis por la legalidad del lugar…): desde la Cosmopolitan hasta las mejores revistas de ciencia, pasando por el mundo del comic, el cine, los graffittis, … Yo me he echado un buen rato ojeando esta revista sobre Banksy.
Interesante la aplicación que me pasa la gente de Iradoki: Calibre. Es un programa para la gestión de bibliotecas de e-books: no sólo sirve como conversor; también descarga noticias de la web y las convierte al formato adecuado, funciona con muchos dispositivos, gestiona la colección de libros electrónicos, … y encima es open source.
Interesante infografía publicada por Consumer sobre la tinta electrónica. Para saber cómo funciona esa tecnología, qué limitaciones tiene (la velocidad de refresco) y qué ventajas (una vez cargada la imagen o el texto, no consume energía).
Y como en la anterior ocasión, un vídeo de regalo. Ojito con cómo vienen los nativos digitales :
Ando embarcada en varios proyectos sustentados por el gestor de contenidos WordPress y uno de los requisitos imprescindibles es la navegación multi-idioma. Así que dejaré por aquí mi experiencia, por si a alguien le sirve de ayuda o puede ser enriquecida por otras personas (y a ver si así podemos devolver algo de todo lo que nos ofrece este tipo de paquetes de software libre).
Lo primero de todo, necesitamos un plugin que consiga gestionar correctamente ese sistema multi-idioma. Para ello, y tras probar unos cuantos, el vencedor ha sido xlanguage. Las características que le hacen caballo ganador:
Se encarga de la administración de tantos idiomas como queramos manejar. Esa gestión afecta a los contenidos del blog (tanto posts como páginas estáticas), a las categorías, etiquetas, feeds, theme, etc, …
En el theme sólo será necesario contar con una carpeta donde almacenar los ficheros de idioma: un .mo con el nombre del idioma. Si tenemos plugins que generan contenidos, también podremos traducirlos y dejar aquí sus .mo.
Una funcionalidad muy interesante es que gestiona el cambio de idioma mediante cookies, así que si cambiamos el lenguaje que arranca por defecto, en próximas navegaciones recordará nuestra preferencia. También detecta el idioma del navegador, para mostrarnos directamente esa opción.
Por cada idioma genera una url diferente, lo que hace que los buscadores indexen los contenidos en todos los idiomas. Esa fue una de las razones por las que me decanté por xlanguage y no por qtranslate, que usa la misma dirección para todas las traducciones.
¿Y cómo conseguimos traducir nuestro theme y nuestros plugins? Sencillo: todas las llamadas php que muestren cadenas de texto, tendrán que ir con la función _e() o bien con la función __() (la diferencia entre ambas es que _e hace un echo de la cadena. Es decir, echo __(“Hola mundo”); es lo mismo que _e(“Hola Mundo”); ). De esta manera, con las herramientas que nos ofrece WordPress para la localización e internalización, podremos generar un .pot del theme donde introducir las traducciones pertinentes para luego generar el .mo que entenderá nuestro xlanguage.
.pot: este fichero se genera de manera automática y recoge todas las cadenas de texto que aparecen en nuestro site. Por cada una de ellas, aparece justo debajo el espacio donde se debe dejar su traducción. Este es un ejemplo donde aparece primero el lugar en el que está dentro del código, la cadena en sí y el espacio donde se dejará la traducción correspondiente:
.mo: fichero binario que entienden las máquinas generado a partir del .po.
Expliquemos el proceso paso por paso.
Instalamos xlanguage y configuramos todos los idiomas en los que queremos que funcione nuestro blog. Mi recomendación es que usemos el código ISO3166 para identificar a cada uno.
Tendremos que repasar todos nuestros plugins y el theme para identificar dónde se generan cadenas de texto y comprobar que se usa o la función _e() o __(). WordPress usa la librería de internacionalización (i18n) gettext. Si dentro de una cadena de texto aparece una variable, no podemos usar sin más _e(“Tenemos $num amigos”); pero sí printf(__(“Tenemos %d amigos.”), $num);
Después de marcar todas las cadenas a traducir, ahora toca generar el .pot con ellas. Para ello, nos bajamos el script add-textdomain.php de WordPress. Lo lanzamos de la siguiente manera:
php add-textdomain.php -i domain phpfile.php
El domain marca el ámbito de lo que traducimos. Podemos poner default, por ejemplo, para el theme y el nombre del plugin para cada uno de ellos. Luego generamos el .pot mediante makepot.php:
En el caso de un plugin ponemos wp-plugin en vez de wp-theme. Para usar todas estas herramientas tenemos que tener el paquete gettext en nuestro servidor.
Para optener el .mo (fichero binario que entienden las máquinas) del .po (fichero con texto que entendemos las personas), lanzamos el siguiente conjuro desde bash:
msgfmt fichero_idioma.pot -o fichero_idioma.mo
Ahora sólo falta que el theme sepa dónde encontrar esos ficheros .mo. Para ello usaremos el fichero de funciones de los themes de wordpress: functions.php. Allí agregaremos lo siguiente, teniendo en cuenta que hemos dejado los ficheros .mo en la carpeta languages y que el domain del theme es default:
function theme_init(){
load_theme_textdomain(‘default’, get_template_directory() . ‘/languages’);
}
Si además queremos traducir algún plugin:
function theme_init(){
load_theme_textdomain(‘default’, get_template_directory() . ‘/languages’);
//Aquí ponemos el plugin cuyo domain es plugin1:
load_theme_textdomain(‘plugin1′, get_template_directory() . ‘/languages/plugin1′);
}
Para introducir contenidos, en el título, las categorías y las etiquetas, se separa cada idioma con un carácter definido en la parte de administración de xlanguage. Por defecto se usa el carácter | (el pipe que está en la tecla del uno y la exclamación). Por ejemplo, publicaríamos “Etiketak|Etiquetas” para crear un contenido cuyo título en euskera sería Etiketak y Etiquetas en castellano (siempre se usa el orden de creación de los idiomas). En los contenidos, en el editor de WordPress tenemos unos botones para marcar el idioma de cada parte. Y si lo queremos manejar desde la parte html, sólo tendremos que marcarlo con la etiqueta <span lang=”idioma”></span> (una etiqueta estandarizada por el W3C)
Enlaces de interés:
Más información sobre internalización y localización en WordPress.
Qué mejor forma de celebrar el Software Freedom Day que colgando el audio del primer programa “De las Ondas a la Red“, en el que pudimos charlar con Pablo Garaizar “Txipi” sobre software libre y educación 2.0 (con los controvertidos portátiles que se implantarán en primaria). Una forma estupenda de inaugurar la nueva sección de Hoy por Hoy Bilbao, de la mano de Azul Tejerina.
Gracias a la inestimable ayuda de Jon Laiseca, redactor de Radio Bilbao, podré ir colgando aquí todos los programas. Finalmente he seleccionado como plataforma para albergar este material ivoox, que me recomendaron los expertos en podcasting a través de Twitter. Desde aquí cualquiera podrá descargar el archivo mp3 para escucharlo en su reproductor. Si lo necesitáis en cualquier otro formato (ogg, wma, …), me lo pedís a través de los comentarios. Que ustedes disfruten del buen criterio de Pablo.
Llevamos ya un tiempo pergeñando el proyecto de Open Deusto y una de las cosas que más me preocupa y que más nos va a marcar su trayectoria va a ser su propio nombre: Open; abriendo la Universidad a la Red.
Y me preocupa precisamente el grado de esa apertura. Para mí es claro cuál tiene que ser: total. No me vale un agujerito a medida por el que sólo mostrar lo que nos interesa que se vea. Se trata de dejar todas tus vergüenzas al aire: las buenas, las no tan buenas y las peores. Ahora bien, para eso hay que estar preparado y tener una idea muy clara: que te critiquen no tiene por qué ser un problema. Tienes que convertirlo en una ventaja:
si te critican sin razón y estás a la escucha, podrás contestar (antes ya lo hacían y muchos terminarían creyendo eso porque nadie les corregía).
Si te critican con razón, acabas de descubrir que tienes un problema y podrás ponerle remedio. A veces, desde nuestros puestos de administración hay muchas cosas que pasan desapercibidas a nuestros ojos. Si yo no uso el coche para nada, nunca sabré si hay problemas en el tráfico.
Y todo esto me viene ahora a la cabeza con la excelente crítica de Txipi tras el chasco que todos nos hemos llevado con la apuesta de humo de Patxi López hacia el software libre. Es una crítica impecable, pausada, con argumentos y sin intenciones partidistas. ¿Y cuál ha sido la respuesta desde el Open Gobierno Vasco? Ninguna. No se ha dado ni una sola explicación de por qué se han tomado las medidas que se han tomado. No pido una comparecencia pública, con una simple respuesta en forma de comentario me hubiese bastado para intentar entender la postura. El método avestruz ya no funciona: callar, meter la cabeza bajo la tierra y esperar a que el temporal pase. Tengo una mala noticia: a las palabras se las lleva el viento pero a los bytes no.
Acompaño la lectura con este excelente post de Txetxu: crítica y gobierno.
El miércoles pasado, en la semana paréntesis de mis vacaciones, di la charla “Web 2.0 y Software Libre. Una relación de amor-odio“, dentro de los cursillos de julio del e-ghost. Las sensaciones tras la misma fueron muy positivas, dado que hubo un interesante debate entre los asistentes (Mario, muchas gracias por tu activa participación ).
Como siempre, aquí tenéis la presentación y un poco de letra para que se entienda:
Arrancamos poniendo cara a cara a dos de los baluartes de ambos mundos: Tim O’Reilly por la web 2.0 y Richard Stallman por el mundo del software libre, con dos posiciones bastante diferenciadas y extremistas.
Por un lado Tim, que en la única conferencia en la que le he visto en directo, preguntó al auditorio si usaba software libre. Se trataba de un evento organizado por Empresa Digitala y los asistentes eran de lo más variopinto, así que pocos fueron los que levantaron la mano. Justo después preguntó quién usaba google para hacer búsquedas. Ahí sí se levantaron todas las manos. Entonces, dijo Tim, todos usáis software libre, porque los servidores de google están montados con herramientas libres. Es un planteamiento cogido con pinzas (es como decir que tú ayudas a los indígenas del Amazonas porque compras un producto que destina el 1% de sus ventas a ayudarles), pero viene genial para analizar las tripas de la Red. Por ejemplo, si miramos las estadísticas de netcraft de junio de 2009, vemos como Apache sigue siendo el servidor web más usado (a pesar de que, desde 2006, momento en que Goddady decidió cambiar sus servidores apache por IIS, no ha dejado de bajar).
Y en el otro polo tenemos a Richard Stallman, que en septiembre de 2008, hizo unas declaraciones para The Guardian en las que indicaba:
[...] “Una razón por la cual no deberían usar aplicaciones web es porque se pierde el control. Es tan malo como usar software propietario. Haz tu trabajo en tu propio ordenador con un programa que respete tus libertades. Si utilizas un software propietario o el servicio web de otra persona, estás sin defensas. Estás en las manos de la persona que desarrolló ese software.”
Como decía antes, una posición un poco extremista pero no falta de razón (como indicó Mario, en ocasiones, necesitamos este tipo de tirones de orejas, que aunque son un poco alejados del realismo, nos hacen plantearnos cosas).
Está claro que estamos ya metidos en el ciclón del cloud computing y es muy difícil salir de él. Nos reporta tremendas ventajas: acceso a nuestros datos desde cualquier parte, necesitando sólo una conexión a Internet y un navegador, usando servicios que son más fiables que nuestro propio ordenador (con su propio sistema de backups y mayor disponibilidad)… O al menos eso creemos, porque luego suceden casos como el de Magnolia, un sistema de marcadores sociales que hizo crack y perdió todos los datos de sus usuarios, dando de lado a los que tenían cuenta gratuita y devolviendo el dinero a los de pago (pero… ¿cómo se recompensa el tiempo y el conocimiento generado hasta entonces?). Además, siempre hablamos de cajas negras (nadie sabe cuál es el código fuente de google ni qué hace por debajo… igual que sucede con windows). Tampoco conocemos quiénes son los administradores de una plataforma ni cuáles son sus intenciones. Yo, como bofh de Nireblog, tengo acceso a los usuarios y contraseñas y estoy convencida de que más del 50% de ellos usarán ese mismo login y password en otros sitios. Por tanto, nadie nos puede asegurar que se monte una plataforma-trampa para recoger esos datos. Tampoco podemos cambiar esas plataformas y amoldarlas a nuestras necesidades (una de las razones que hicieron a Richard Stallman ponerse en pie de guerra e iniciar el proyecto GNU). La única libertad es la que nos otorgan las APIs. Por tanto, cada vez somos más esclavos de las plataformas: ¿y si cierran? ¿y si cambian de manos y por tanto, de filosofía? ¿y si pierden nuestros datos? ¿y si cambian las condiciones de uso? (bueno, de algunas plataformas, no hace falta que cambien porque ya hemos aceptado términos abusivos desde el inicio). No hay más que echar un vistazo a Twitter cuando se cae GMail para ser conscientes de nuestro nivel de dependencia. De hecho, es la mejor forma de ilustrar la diferencia de significado de la palabra inglesa free. El software libre es free como la libertad de expresión. La web 2.0 es free como la cerveza gratis. Aunque lo que es indudable es que ambos tienen la misma filosofía por detrás: la de generar conocimiento abierto y compartir con la comunidad.
Y entonces, ¿cuál es la solución ante esto? Sólo hay una salida: los estándares abiertos que nos permitan la portabilidad de nuestros datos de un lugar a otro. De esta forma, seremos capaces de movernos de una plataforma a otra, sin tener ese yugo. Para hablar de esa portabilidad, tenemos que diferenciar entre tres tipos de información que generamos en la Red: los contenidos propiamente dichos, la identidad con la que nos autenticamos en los lugares y las interacciones o relaciones que establecemos. Aunque pudiera parecer que los tres nos pertenecen, casos como el de Robert Scoble nos alertan de lo contrario. A este conocido bloguero americano le cerraron su cuenta en Facebook por intentar exportar los nombres, emails y cumpleaños de SUS contactos a plaxo mediante un script. En un alegato a la incoherencia, Facebook puede rastrear la libreta de direcciones de tu cuenta de correo para buscar contactos pero te prohíbe que los saques de allí (es lo que se conoce como walled garden o jardín cerrado). Y es que el mejor truco del ilusionista 2.0 es hacernos creer que nuestros datos nos pertenecen. Por ejemplo, diariamente alimento mi cuenta de last.fm con las canciones que escucho, participando en una base de conocimiento global que ayudará a otros usuarios a descubrir grupos relacionados. Hasta ahora, todo muy bonito y con un lazo rosa. Pero, ¿puedo obtener mis datos para, por ejemplo, pasárselos a Amazon y que me muestre esos discos y así poder comprarlos? NO.
DataPortability
Se trata de una plataforma que trata de plantear una serie de estándares abiertos para generar redes sociales abiertas:
OpenID: sistema de autenticación descentralizada. Ya en un post anterior contaba los pros y contras de esta tecnología que nos evita volver a introducir nuestros datos cada vez que nos queremos dar de alta en un servicio.
OAuth: protocolo de autorización. Una aplicación web puede acceder a la información de un usuario en otra sin tener que informarle del login y contraseña. Twitter, recientemente, ha adoptado oauth para comunicarse con otras plataformas que usan su api. De esta manera, podemos usar servicios como el de twitterfeed sin pasarle nuestra contraseña de Twitter.
OPML: formato xml para esquemas que nos permite exportar colecciones de RSS. Por ejemplo, podemos exportar todos los blogs a los que estamos suscritos en nuestro bloglines y luego importar ese fichero a Google Reader.
APML: mapa de intereses de un usuario. Es decir, una forma de almacenar todo lo que nos resulta interesante en una web: una canción en blip.fm, un estado en facebook, un enlace en del.icio.us, …
Microformatos: agregando significado semántico a los contenidos. Una forma de que las máquinas puedan interpretar como lo haría una persona. Ejemplos: hCard, XFN, …
Existen otras tecnologías como OpenSocial que, aunque en su nombre lleva la parte de Open, no nos puede llevar al engaño, puesto que no es un protocolo de comunicación entre redes, sino un estándar para el diseño de gadgets, de forma que si se crea uno, pueda funcionar en Google, LinkedIn, MySpace, Plaxo, Yahoo, … Pero como comentaba antes, lo de open lo limita luego cada plataforma. Por ejemplo, en LinkedIn se reservan el derecho de admisión de gadgets hechos con OpenSocial (por ahora sólo permiten una serie de aplicaciones).
En la línea de la interoperabilidad también está el open cloud manifesto, firmado por grandes nombres como AMD, eyeOS, Sourceforge, Sun, IBM, … pero sin el apoyo de Google, Microsoft, Amazon, … Y es que el gigante Google suele darnos cal y arena. Está claro que lo que hace, lo hace muy bien. Y su aportación al mundo del software libre no se puede desdeñar: su navegador google chrome basado en chromium (licencias BSD y CC-by 2.5), el sistema operativo para móviles android (apache license 2.0 y GPLv2) y muchas otras aplicaciones que podemos encontrar en google code (gears, jaiku, …). Por no hablar del próximo tsunami de Internet: Google Wave, que nos indican que será libre (cualquiera lo podrá instalar en su servidor), usará un protocolo libre (cualquiera podrá hablar con él) y tendrá una api abierta para desarrollar gadgets usando OpenSocial. De hecho, harán una apuesta arriesgada apostando por el HTML5 (que ahora mismo no funciona en Internet Explorer). Pero a pesar de todos estos regalos que nos hacen los chicos de Mountain View, tenemos que ser conscientes de que un único dueño y señor de Internet es nefasto.
Licencias en la web
GPL: es una licencia copyleft que está más pensada para el mundo del software que para el de la web. Lo que se cree derivado de algo con GPL tiene que mantener la misma licencia. Sin embargo, se pueden hacer modificaciones y no ponerlas a disposición del mundo, dado que al usuario final, lo que le llega es el código HTML. Paquetes con esta licencia: WordPress, MediaWiki, Drupal, Joomla, …
Affero Public License (AGPL): a diferencia de la GPL, todas las modificaciones que se hagan deben ser puestas a disposición de todo el mundo. Es curioso como Google tiene vetada esta licencia en Google Code (cada uno ate sus cabos ).
Apache License: es la que utiliza la Apache Foundation. No es copyleft (los productos derivados no tienen por qué tener esa licencia) y es mucho más laxa que las anteriores. Las obras se pueden modificar, se pueden redistribuir y se puede usar para cualquier propósito. Productos con esta licencia: Lucene, Android, …
MIT, BSD, … : licencias aún más laxas que permiten usar, copiar, modificar, integrar con otro software y sublicenciar.
En mi corta experiencia en el mundo de las bibliotecas una cosa me ha quedado ya clara: la supremacía de los grandes proveedores de contenidos y de paquetes de software. La mayoría de las suscripciones a recursos electrónicos vienen dados por grandes editoriales que ejercen el control, haciendo y deshaciendo a su antojo. 
). Así que os podréis imaginar la dependencia de esos mastodontes de cara a modernizar o incorporar funcionalidades actuales. Ellos marcan los ritmos, que por supuesto, son más lentos que la frenética celeridad de la tecnología hoy en día. 
.
Septiembre es el mes de la vuelta. De la vuelta de vacaciones, de la vuelta al cole (y los corticoles), a la rutina, al malvado a la par que olvidado despertador, … 
:
Esto funciona gracias a 