Introducción a los sistemas de gestión de contenidos

¿Qué diablos es eso de un CMS?

Un CMS es un sistema de gestión de contenidos, Content Management System. Empecemos por el final, lo del sistema: se trata generalmente de un conjunto de herramientas, apoyado habitualmente por una base de datos, y que consisten en una serie de programas en un servidor web, y, opcionalmente, una serie de programas cliente que te permitan acceder fácilmente a esos programas en el servidor. Sigamos con lo de la gestión de contenidos: desde el punto de vista del usuario del sistema, se trata de gestionar, de forma uniforme, accesible, y cómoda, un sitio web dinámico, con actualizaciones periódicas, y sobre el que pueden trabajar una o más personas, cada una de las cuales tiene una función determinada; desde el punto de vista del cliente, se trata de un sitio web dinámico, con apariencia e interfaz uniforme, con un diseño centrado en el usuario, y que permite llevar a cabo fácilmenta las tareas para las que ha sido diseñado. Por lo tanto, un CMS tiene dos funciones principales: facilitar la creación de contenidos y la presentación de esos contenidos. Con respecto a la primera, provee una serie de herramientas para que publicar contenido sea tan fácil como rellenar un formulario, y haya, además, una sóla fuente para todos ellos; con respecto a la segunda, facilita la publicación de contenidos en múltiples formatos a partir de una sola fuente, y añade metadatos a los mismos, para facilitar la navegación en múltiples facetas (temporal, por categorías o por autor, son sólo tres ejemplos posibles). También habría que considerar otras dos fases: gestión de contenidos y mantenimiento de los mismos; aunque estas fases se pueden incluir en la anterior. En todo caso, un CMS provee las herramientas necesarias para gestionar el ciclo de vida de los contenidos: creación, gestión, presentación y mantenimiento y actualización.

Los CMS son relativamente recientes, aunque anteriormente había una serie de herramientas profesionales que permitían publicar información en intranets, tales como Lotus Notes, o herramientas más complicadas de gestión del conocimiento empresarial. La expansión de este tipo de sistemas provino de la existencia de herramientas baratas y fáciles de usar tales como Manila y Frontier, cuya versión 6.1 se publicó en 1999, cuando empezaron a usarse a nivel de usuario.

De todas formas, dentro de la clasificación anterior, caben muchos tipos diferentes de CMSs, con mayor o menor popularidad.

En resumen, un sistema de gestión de contenidos sirve para que la gestión de un sitio web, por pequeño que sea, no se te vaya de las manos: permite tener una apariencia y navegación uniforme en todo el sitio, y actualizar y gestionar el contenido fácilmente. Todos los sitios web deberían de tener su sistema de gestión, ea.

La principal forma de usarlo es, para el mantenedor, a base de formularios, aunque hay también clientes específicos que usan protocolos tales como SOAP, WebDAV o XML-RPC para actualizarlo. La ventaja de usar este tipo de clientes es que permiten hacer las cosas de forma mucho más agil. Con respecto al usuario, dado que uno de los objetivos del CMS es publicar en muchos formatos, se podrá usar el navegador habitual (preferiblemente el Firefox), pero también programas específicos de visualización de contenidos en otro formato: RSS o sistemas WAP, por ejemplo. Cuando tratemos cada tipo de contenido los veremos.

A continuación veremos dos tipos diferentes de sistemas de gestión de información: los wikis y un gestor de bitácoras.

Ejercicios

  1. Antes de empezar, y dado que estamos en un curso de arquitectura de la información, señalar, usando lo aprendido hasta el momento, problemas de usabilidad y de arquitectura de la información de este tutorial. El autor lo agradecerá eternamente.

Contenido de esta sección

Wikis

Un wiki es básicamente una página editable por el usuario; la palabra wikiwiki (o awiwi) significa, por lo visto, rápido en hawaiano. Lo mínimo que tiene un Wiki es un botón que dice "Edítame", que permite a quien lo pulse, editar el contenido de la página. Por eso se suele usar cuando hay muchas personas que estén trabajando sobre un documento determinado, o para dar ideas sobre algo. O, simplemente, para establecer disponibilidad de alguien para realizar alguna tarea.

Se le considera un sistema de gestión de contenidos porque la mayoría de los wikis tienen una forma de establecer plantillas y otras funcionalidades a lo largo de todo el sitio; también permiten gestionar permisos de usuario a nivel de sitio y de página; en general, para sitios muy dinámicos, o en los que haga falta una retroalimentación fuerte por parte de los usuarios, un wiki puede ser lo más adecuado. La mayor desventaja de los Wikis es que su énfasis es en editar el contenido, no la apariencia, con lo que en caso de que se quiera dar una experiencia de usuario particular, no suelen ser lo más adecuado.

Otra característica que tienen la mayoría de los wikis es el guardar la historia de edición de un documento, incluyendo metadatos como quién ha hecho la edición y porqué. Esta característica es esencial, porque permite recuperar versiones anteriores de un documento en caso de que se hayan hecho daños irreparables.

Aparte de eso, un wiki se organiza como una serie de nodos (documentos) unidos por enlaces. Los enlaces siguen un formato especial: cualquier palabra escrita en WikiCaps o CamelCase (mayúsculas al principio, otra mayúscula en el resto de la palabra) se convierte automáticamente en un nodo, inicialmente vacío, que se puede editar. En caso de que se quieran escribir cosas como GoogleNews sin que se conviertan en un nodo, se usa convenciones que dependen de la implementación del wiki. Una de ellas, por ejemplo, es escribir !GoogleNews.

Hay otras formas de crear enlaces. En general, todos los wikis suelen usar los corchetes [] para crear explícitamente enlaces. [enlace explícito] se convertiría en un enlace a un nodo llamado enlace explícito (si es el que el sitema de wikis lo permite). También se pueden crear enlaces externos: [http://a.otro.sitio A otro sitio]. Estas convenciones suelen variar, pero vienen a ser similares en casi todos los sitios.

Muchos wikis permiten listar los nodos que enlazan a uno determinado, o hacer también búsquedas; algunos permiten usar menús comunes u otros patrones de navegación. La navegación, hasta cierto punto, es autoorganizada: se va creando según se crea el contenido, por eso es bastante adecuada para ir elaborando documentos.

El resto de las etiquetas HTML tienen también su equivalente, habitualmente simplificado. En este documento, por ejemplo, explica todas las reglas que se usan en el programa Kwiki.

Usar un wiki, tal cual, no es fácil, hay que establecer algún tipo de protocolo; sobre todo, si dos personas están trabajando en un documento, puede que uno pise el trabajo del otro. Hay que establecer algún sistema de turnos para que se pueda llevar a cabo la labor correctamente; por ejemplo, trabajar en nodos diferentes o usar un nodo de caja de arena para ir escribiendo cosas antes de pasarlas al lugar definitivo.

En todo caso, los wikis sirven sobre todo para colaboracion esporádica y espontánea. Puedes dejar una web abierta para que, si hay algún error, la gente (o tú mismo) la vayáis actualizando. La ventaja de poder editar una página web con sólo pulsar un botón hace que la barrera de acceso a la colaboración en un sitio sea bastante baja.

Hay aplicaciones tales como jotspot que añaden una serie de funcionalidades a un Wiki: modificación por correo elctrónico y adjuntos multimedia a las páginas. Otros sistemas de gestión de contenidos como Rhizome tienen funcionalidades similares, aunque están basados en RDF.

Ejercicios

  1. En equipos de tres personas, diseñar y elaborar un prototipo de un sitio web de una banda de rock'and'roll. Usad alguno de los wikis disponibles (como eApuntes). Estableces un protocolo de colaboración, y especificarlo también en el wiki. En este sitio da algunos consejos sobre cómo editar un wiki, aunque es algo incompleto. Alguno de ellos: edita sin miedo, usa páginas meta, y trata de llegar a un consenso sobre el contenido.

Contenido de esta sección

Introducción a las bitácoras

Una bitácora o weblog, desde el punto de vista del diseñador de contenidos o autor, es un sistema de gestión de información en el que los contenidos se organizan cronológicamente, y, eventualmente, a lo largo de otras facetas habitualmente llamadas categorías. Una bitácora tiene una página principal, en la que aparecen las últimas historias enviadas en orden cronológico inverso, y un archivo en el que las historias aparecen organizadas a lo largo de los diferentes ejes: cronológicos, y por categorías.

La bitácora suele ir respaldada por un sistema de gestión de bases de datos, que almacena las historias y todos los demás contenidos, y suele tener una serie de características adicionales:

Una bitácora es un medio ideal cuando lo único que se desea es publicar información semiestructurada (la única estructura que se impone es cronológica y categórica); también si la fuente de información es principalmente una persona o grupo de personas, y lo que se desea es interacción por parte de otro grupo (los lectores, o clientes, o lo que sea).

Hoy en día hay cientos de programas para gestionar bitácoras en el servidor; sólo hay que elegir lenguaje y tipo de servidor con el que uno se sienta más cómodo (PHP, Perl, hasta Python si me apuras). Incluso, si no tienes acceso al servidor, puedes alojarlo en alguno de los miles de sitios de alojamiento que hay: BlogSpot y ExtreBlogs, por ejemplo.

Sin embargo, para un uso profesional se aconseja alojarlo en el propio servidor. Como se ha dicho, se necesitará usar un alojamiento que permita bases de datos (aunque algunos funcionan con bases de datos light, como SQLite ), y algún lenguaje de programación tal como el PHP o Perl, siendo el primero el más habitual. Si uno mismo maneja el servidor, habrá que currárselo.

Vamos a partir de la base de que ya tenemos el alojamiento listo. La mayoría de los CMS permiten diferentes permisos o roles a los diferentes usuarios; los administradores pueden hacer cualquier tipo de cambio sobre ellos; los usuarios, sólo algunos. El administrador tendrá que dar de alta al usuario, con un nombre de usuario, y asignarle una bitácora. A partir de ahora, vamos a usar para los ejemplos el sistema de gestión de bitácoras MovableType, de Six Apart. Es un sistema gratuito para pocos usuarios, y de pago para instalacioneos medianas o grandes; está escrito en Perl y usa como soporte varios tipos de bases de datos, entre ellos MySQL o PostgreSQL (aparte del SQLite visto anteriormente). Lo podemos ver en funcionamiento en la bitácora de este curso, o en la bitácora de Siniestro Total.

No voy a hacer un tour aquí de pantalla en pantalla, ni os voy a contar donde tenéis que pinchar, que ya sois mayorcitos. Eso sí, os muestro la pantalla de edición, y os explico qué es cada cosa. A partir de ahí, humo.

Como se ha dicho, la información en una bitácora está estructurada, y responde más o menos a una noticia. Por tanto, tiene un título y un body, que serán la parte de la noticia que aparezca en la portada del sitio. MT permite además asignarle una categoría; algunos sistemas permiten asignarle varias categorías simultáneamente a cada noticia. En este caso, sólo una; desde el mismo menú se pueden crear o asignar nuevas categorías. También se le pueden asignar categorías múltiples a cada entrada.

Las otras dos partes de la noticia, extended entry aparece sólo en la página de la noticia, donde aparecerán también los comentarios y los trackbacks (enlaces desde otras bitácoras, más sobre esto más adelante), y un excerpt o resumen que será lo que aparezca precisamente cuando nosotros hagamos trackback.

El resto son opciones de publicación: publish (publicar) o dejar como borrador (draft), permitir comentarios y pings (es decir, que si alguien publica algo relacionado con esta noticia y te enlaza pueda avisarte, aunque puede dar lugar a abusos); convertir retornos de carro a <br> (lo que puede ser incoveniente, por ejemplo, si insertamos una tabla o una lista), y finalmente los URLs de los sitios a los que queramos hacer ping, es decir, avisar de que los estamos enlazando.

El resultado se puede previsualizar (preview) o guardar directamente. A partir de ahí, hay que tener en cuenta que MT es un sistema de publicación estática: todas las páginas se generan estáticamente, con lo cual cada vez que se haga un cambio habrá que regenerar las páginas a las que haya afectado el cambio. Cuando se salva una página, evidentemente, se hace, pero otros cambios más sutiles tendrán que estar acompañados de una reconstrucción manual.

A partir de ahí, se pueden hacer varias cosas: reconfigurar este formulario de entrada (para eliminar aquellos campos que usemos poco a menudo), dándole a Customize the display of this page o bien pasar al menú Edit Entries y activar el Power Editing mode, que te permite listar todas las entradas que corresponden a un criterio determinado y cambiarles cosas. Por ejemplo, qué se yo, cerrar los comentarios de un montón de historias antiguas, o cambiarles las categorías.

Ejercicios

  1. Publicar una noticia en la bitácora MT que se habrá abierto al efecto (o, para el caso, en cualquier otra bitácora), y hacer trackback a la bitácora del profe, en la noticia que se indique.
  2. Modificar la(s) plantilla(s) de MT usando hojas de estilo, tal como se ha explicado en el resto del curso.

Pero usar formularios webs no es la única forma de publicar en una bitácora; la mayoría tiene un API, o interfaz remoto, habitualmente basado en XML-RPC. Estos interfaces consisten en construir una llada a un procedimiento remoto (de ahí el XML-RPC) a base de un documento XML, de esta forma:

<?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> En este caso, examples se refiere al nombre del API; cada uno tiene su nombre: por ejemplo, dos de los más usados en bitácoras con metaWeblog y blogger; tras el punto viene el nombre de la función, y a partir de ahí los parámetros que se le pasan. En este caso, el parámetro es un entero (i4, también se puede usar int). Se pueden usar estructuras más complejas, como structs.

En cualquier caso, habitualmente no hay que preocuparse por todo esto, salvo que se quiera escribir un programa que lo haga; incluso en estos casos, ya hay librerías que convierten este interfaz a un interfaz funcional o dirigido a objetos. Lo más normal es usar programas que escriben todo el XML que uno pueda desear, tales como W.bloggar (para Windows) o BloGTK (para Linux, basado en Python). Estos clientes permiten, sobre todo, ahorrar ancho de banda, dan un interfaz más amigable que un simple formulario para envío de historias, y permiten funciones adicionales, como almacenamiento de las historias en el cliente, edición y borrado de historias, y gestión de muchas bitácoras simultáneamente. Aparte, usar programillas puede servir, por ejemplo, para enviar posts de una fuente periódicamente, o mandar historias en algún punto en el futuro, o miles de cosas más. Sólo es cuestión de ponerse a pensar un poco.

Para configurar estos programas, primero hay que averiguar la dirección del proxy, es decir, el programa en el servidor usado para recibir las llamadas XML-RPC; normalmente está en la documentación del sitio; también los sitios de alojamiento estándar, tales como Blogspot, tienen un sitio por defecto. Segundo, hay que averiguar el id de la bitácora. En MT es fácil: basta mirar al URL del menú que aparece para editar la bitácora, que será algo así: http://misitio.ag/cgi-bin/MT/mt.cgi?__mode=menu&blog_id=21 En este caso, el id seguiría a blog_id, o séase, 21. El resto es el nombre de usuario y la clave, que se supone que se conoce.

Ejercicios

  1. Descargar algún programa cliente de bitácoras, como los indicados anteriormente, y enviar un par de historias a la bitácora creada anteriormente u otra creada al efecto.

Como todas las bitácoras tienen el mismo formato, resulta fácil publicarlo de forma alternativa, incluyendo sólo aquellos campos que sean comunes, y eliminando toda la información adicional del sitio web, como navegación y otro tipo de historias. Para ello se suele usar un formato basado en el XML, que tiene múltiples formas, pero que en todas ellas incluye campos tales como el título, la descripción, es decir, el cuerpo de la noticia, el enlace permanente y metadatos adicionales como el autor y la fecha de publicación. Esto es lo que hace un formato denominado RSS, really simple sindication, y que tiene la pinta siguiente: <?xml version="1.0" encoding="iso-8859-1"?><backslash xmlns:backslash="//barrapunto.com/backslash.dtd"> <story> <title>Sklyarov, en libertad bajo fianza</title> <url>//barrapunto.com/article.pl?sid=01/12/15/1636251</url> <time>2001-12-15 16:33:06</time> <author></author> <department>ya-era-hora!!!</department> # <topic></topic> <comments>2</comments> <section>ciberderechos</section> # <image></image> </story> <story> <title>¿El vídeo de Bin Laden trucado?</title> <url>//barrapunto.com/article.pl?sid=01/12/15/1547240</url> <time>2001-12-15 15:40:04</time> <author></author> <department>fakes</department> # <topic></topic> <comments>43</comments> <section>articles</section> # <image></image> </story>

Este es el código de barrapunto, que se entretiene el jodío en no ser muy estándar, pero bueno, correcto es. Tiene lo típico en estos casos: título, URL; por cierto, es lo mínimo estrictamente necesario para cada entrada. A partir de ahí, tiene algunas cosas que no son muy estándar (department, por ejemplo), pero otras que están bien, pero que no todo el mundo tiene: la fecha, por ejemplo. Veamos otro ejemplo, quizás más típico:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" > <channel rdf:about="http://www.blogalia.com/rdf.xml"> <title>Blogalia</title> <link>http://www.blogalia.com/</link> <description>Noticias generales de Blogalia.com</description> <dc:language>es-ES</dc:language> <dc:rights>Copyright rvr</dc:rights> <dc:publisher>rvr</dc:publisher> <dc:creator>rvr</dc:creator> <items> <rdf:Seq> <rdf:li resource="http://www.blogalia.com//historias/11789" /> <rdf:li resource="http://www.blogalia.com//historias/11540" /> </rdf:Seq> </items> </channel> <item rdf:about="http://www.blogalia.com//historias/11789"> <title>Premios blogueros</title> <link>http://www.blogalia.com//historias/11789</link> <description>...</description> </item> <item rdf:about="http://www.blogalia.com//historias/11540"> <title>Blogalia Reloaded</title> <link>http://www.blogalia.com//historias/11540</link> <description>...</description> </item> </rdf:RDF>

En este caso, por lo menos, se incluye al principio las declaraciones de una serie de espacios de nombres, que hacen claro que se trata de RSS 1.0, una de las versiones. También se usan la 0.9x, y la 2.0. En realidad todas se usan simultáneamente, y los programas lectores de ellas suelen entenderlas todas. Esta RSS 1.0 es, en realidad, equivalente al RDF, es decir, que incluye una serie de aserciones de la forma sujeto-predicado-objeto. En este caso son aserciones sobre recursos: los URLs permanentes de las historias. Tras una Seq de todos los URLs de los que vamos a hablar, después va al turrón con cada uno de los URLs, dedicándoles un item y lo mismo que en el caso anterior: título, enlace; no hay fecha, y además el campo description incluye el contenido completo de la historia. A destacar también las etiquetas procedentes del Dublin core, que permiten añadir información sobre autoría de forma estándar.

Un tercer formato alternativo es el Atom. Es por el estilo, pero más chuli. La verdad es ni los más avezados saben apuntar las diferencias entre los mismos. Eso sí, Blogspot tiene Atom para fastidiar a Dave Winer, que es el del RSS. En fin...

En general, desde el punto de vista de los CMSs, un autor del mismo lo puede usar para publicar sus contenidos (lo cual suele hacerse automáticamente), o bien para consultar diferentes fuentes de información, que puede o no insertar como contenidos alternativos en su sistema, tras un proceso o a pelo.

Ejercicios

  1. Comprobar si la bitácora creada anteriormente tiene feed RSS. Si no tiene, activarlo. Ver el resultado.
  2. Usar algún servicio de suscripción de RSS, como FeedMania, para suscribirte a varios feeds.
  3. Incluir en la plantilla de la bitácora un feed RSS externo, usando alguna utilidad o un PlugIn
  4. Examinar la plantilla del feed RSS de las bitácoras creadas, y cambiarla según convenga.
  5. Realizar una hoja de estilo CSS para presentar directamente el feed RSS en el navegador.

Generalmente, un sistema de gestión de contenidos forma parte de una conversación distribuida por la contenidosfera. Los autores hablan de temas, se refieren a una noticia en un sitio determinado. También interesa saber si alguien está hablando de lo mismo, y más en concreto, si está enlazando alguna de las noticias que se ha publicado. Una de las formas de averiguarlo es mediante los referrers, o enlaces entrantes; muchas páginas de alojamiento de estadísticas tales como Nedstat lo incluyen; por supuesto, se puede extraer de los registros de visitas del sistema. Sin embargo, para registrar un enlace entrante hace falta que efectivamente alguien pinche en él, lo que no siempre sucede o simplemente no pasa mientras uno está mirando. Por eso hay otras formas de ver los enlaces entrantes: sitios como Technorati recorren todas las bitácoras de las que se tiene noticia y toman nota de esos enlaces salientes y entrantes, y te permiten saber quién enlaza a una bitácora determinada. Sin embargo, tampoco es exhaustivo: muchas bitácoras, sobre todo si están autoalojadas, o bien están en algún sitio de alojamiento no estándar, pueden no aparecer.

Finalmente, hay otro mecanismo, el llamado pingback o trackback, que no son lo mismo, pero caso. Algunos sitios de publicación de bitácoras, especialmente el que nos ocupa, permite, al publicar una historia, hacer pingback a un URL de la historia a la que nos hemos referido o pensemos referirnos. Este URL no es el de la historia: generalmente aparecerá explícitamente como URL para trackback, por ejemplo. Y, al hacer pingback, si se hace correctamente, aparecerá un enlace desde la historia a la que hemos pingbackeado a nuestra historia.

Al interfaz que se usa en MT para hacer trackback, y a otros similares se les llama interfaces REST: son interfaces que permiten acceder al API (interfaz de programación de aplicaciones de un sitio) insertando todos los comandos en un URL, y haciéndolo mediante una sola transacción.

Los pingbacks se pueden hacer también a mano, al menos en Movable Type, usando una URL de este estilo:

http://foo.com/mt/mt-tb.cgi?tb_id=ID&title=TITLE&url=URL

donde ID se refiere a la historia a la que se quiere trackbackear, TITLE el título de nuestra historia, y URL su dirección permanente. La respuesta del servidor es en XML, indicando si se ha tenido éxito o no. Si ha tenido éxito, el URL y el título aparecerán en el apartado de trackback de la historia a la que se le ha hecho.

Ejercicios

  1. Publicar una historia en la bitácora creada con los defectos de usabilidad encontrados a este tutorial, y a la bitácora del curso. Hacer trackback a una historia de la bitácora que se anunciará.

Contenido de esta sección

Gestión de contenidos y presentación en bitácoras

Hasta ahora se ha visto sólo cómo podemos insertar nuevos contenidos en el sistema, y cómo publicarlos en diferentes formatos. Ahora veremos cómo podemos cambiar las plantillas, y qué tipo de cosas se pueden hacer con ellas. Movable Type (y la mayoría de los CMSs) usan un sistem basado en etiquetas propias, que constituyen casi un lenguaje, pero no del todo. Esas etiquetas se insertan en plantillas o templates, que se pueden editar desde el menú correspondiente, y que corresponden tanto al índice (la portada del sitio) como a cada una de las historias, como a casi todos los demás elementos: páginas resumen mensuales, y feeds de diferente tipo.

La forma más directa de cambiar las plantillas es insertando o quitando código HTML, u hojas de estilo. El código HTML saldrá, como es natural, tal cual. Pero lo interesante es que se puede insertar información directamente desde la base de datos, o hacer operaciones de agregación con la misma, como veremos a continuación.

Las etiquetas de Movable Type son tal como las etiquetas de HTML, salvo que suelen comenzar con el prefijo MT, y se pueden opcionalmente encerrar en el signo $: por ejemplo <$MTEtiqueta$>. Exactamente igual que sucede con las etiquetas HTML, cada etiqueta puede tener atributos que son específicos.

El uso de las etiquetas depende del contexto; algunas etiquetas son válidas en todas las plantillas, otras sólo validas en la plantilla de índice, o en la de una historia. En general, habrá que tener un poco de cuidado con el uso de estas etiquetas. Si no es válida, al actualizar la plantilla el sistema dará un error.

Las plantillas, en general, se corresponden con tablas en la base de datos, y hay plantillas correspondientes a cada una de ellas; los atributos suelen corresponder a campos de cada tabla. En general. Pero no siempre. De hecho, los nombres de las etiquetas corresponden al nombre de las tablas: MTEntryxxx corresponderá a la tabla mt_entries, y así sucesivamente. Conociendo las etiquetas se pueden conocer las tablas, y viceversa.

.

También, de forma general, las etiquetas individuales corresponden a contenidos sacados directamente de la base de datos, en un contexto determinado; sin embargo, las etiquetas pareadas suelen crear un un bucle que recorre todas las entradas de una tabla que correspondan; a la vez, crean un contexto que les da significado a las etiquetas dentro de las mismas. Por convención, las etiquetas pareadas no suelen llevar $, y las individuales si. Algunas también actúan como condicionales (tienen por medio la partícula if: en ese caso, incluyen el contenido si y solo si se cumple la condición.

<MTIFSucedeTalCosa> <$MTContenido$> </MTIFSucedeTalCosa>

Las etiquetas más simples que se pueden usar son las relativas a la propia bitácora, que se usan, sobre todo, en la plantilla principal. Incluyen lo obvio: títulos, URLs, pero también licencias, e incluso el código RDF correspondiente a la licencia. Conviene, al menos, conocerlos, aunque no necesariamente haya que incluirlos todos.

Ejercicios

  1. Incluir todas las etiquetas correspondientes a los datos de la bitácora en la página principal de la misma, sin que se resienta demasiado la usabilidad. Cambiar el diseño si es pertinente.
  2. Por parejas (o tríos), evaluar mutuamente la usabilidad del sitio resultante. Incluir una entrada en la bitácora con los resultados.

Otras etiquetas corresponden a bucles. Por ejemplo, MTEntries permite listar en la página de archivo o en la de las historias individuales historias procedentes de la tabla mt_entries. Es una orden bastante potente: permite listar, por ejemplo, las últimas 5 historias, o las historias de una categoría, o las de varias categorías, por ejemplo:

<ul> <MTEntries lastn="5" offset="5"> <li><a href="<$MTEntryPermalink$>"><$MTEntryTitle$><li> </MTEntries> <ul>

En este caso, se lista el enlace permanente a la historia, y el título de la historia solamente; el contenedor recorrerá una por una todas las historias que cumplan esa condición: la 5ª historia más antigua ( offset="5") y 5 historias a partir de ahí (lastn="5" ).

Hay entradas que funcionan de forma similar: MTComments, por ejemplo, que permite incluir los últimos comentarios insertados en la bitácora. La mayoría de estas etiquetas vienen en la plantilla por defecto, así que para ver un ejemplo basta mirarlas.

Ejercicios

  1. Incluir en la plantilla las últimas 7 historias, y de ellas, el título, el enlace permanente, el número de comentarios, y la fecha de envío.
  2. Incluir los últimos 10 comentarios, con su fecha, su autor, y un enlace a la historia en la que han sido insertados.

Movable Type es un sistema extensible a base de plugins, que no son otra cosa que programillas situados en un directorio específico, y a los que se puede acceder mediante etiquetas propias, o a veces, scripts propios. Los plugins añaden funcionalidades, o bien modifican el comportamiento del sistema de alguna forma determinada. Por ejemplo, uno de los plugins más famosos (y útiles) es MT-blacklist, un programa que impide el envío de comentarios y pingbacks con spam a base de una serie de filtros, y que permite también eliminarlos sobre la marcha. Es prácticamente imprescindible en cualquier instalación MT abierta.

Casi todos los plugins están listados en la página de Plugins correspondiente. Por ejemplo, este plugin para Flickr, el servicio de fotos online, permite usar el API de tal sitio web para presentar una serie de etiquetas de fotos relacionadas con el propio usuario en Flickr.

Para escribir plugins hay que tener cierto conocimiento de Perl, pero la idea es simplemente que se definen una serie de etiquetas propias, y para cada una de esas etiquetas, se establecen peticiones sobre la base de datos que está detrás del sistema. Uno puede ponerle a las etiquetas lo que le dé la gana, pero siempre se le añadirá el prefijo MT. Por supuesto, no es demasiado conveniente usar el mismo prefijo que alguna de las funciones del sistema.

Ejercicios

  1. Buscar entre los plugins de MT, uno que incluya una fuente externa RSS e indicar como se usaría.

Bibliografía y enlaces relacionados con sistemas de gestión de contenidos.

Se puede acceder a la biblia del CMS, usando la palabra "betatester". Es un libro un poco prolijo, pero válido como referencia.

Específico de Movable Type, está, como no, La biblia del Movable Type. No lo he leido, o sea que no sé cómo está.

Por otro lado, Essential Blogging está disponible en Safari, así que si tienes suerte, puedes consultarlo. Dedica un capítulo a Movable Type, que puede estar bien como introducción.


Juan Julian Merelo Guervos
Last modified: Mon Mar 14 16:37:22 CET 2005