La Bitácora del Tigre en PDF con BlogBooker

A lo largo de la historia de este blog me he ocupado en varias ocasiones de las distintas técnicas y aplicaciones existentes para generar documentos estáticos a partir del contenido online, y también sobre la operación inversa, es decir, la de generar sitios web dinámicos a partir de páginas web estáticas. En artículos como Hélice 12 y otros documentos en PDF, Para conseguir una versión offline del blog, El blog offline, esta vez en formato ePub, Más utilidades para exportar un blog de WordPress, Para convertir un sitio web estático en un blog y Nueva vida para las reseñas de Lengua en Secundaria, he investigado sobre generadores de archivos PDF y ePub, conversores de formatos, herramientas de exportación, ripeadores de sitios web, importadores de HTML, etc.

Aunque en el segundo de los artículos que acabo de citar ya hice algunos experimentos de exportación de La Bitácora del Tigre a PDF, la verdad es que hasta hoy mismo no había dado el paso decisivo de arrojarme a la blogosfera con toda la impedimenta a cuestas, para dar un estentóreo bitacorazo sobre la mesa virtual del ciberespacio. El impulso decisivo para ello me lo ha proporcionado Celestino Arteta, compañero y jefe en el PNTE, con una entrada-regalo navideño publicada en su excelente blog Educación Tecnológica, la titulada Blogbooker: crea un libro con tu blog, de la que hemos estado hablando durante los dos últimos días.

Siguiendo la estela de Celestino, he utilizado el servicio online BlogBooker para crear un PDF con todo el contenido de La Bitácora del Tigre durante sus más de seis años y medio de existencia, lo cual supone más de 770 entradas y muchos centenares de miles de palabras. No sé cómo no han explotado los servidores de BlogBooker durante la generación del documento, porque el resultado de una larga, larguísima espera ha sido un tomazo de 2.363 páginas (solo el índice ya ocupa 26), que pesa sus buenos 28 MB. y pico. También siguiendo el ejemplo de Celes, aunque con una variante con respecto al servicio utilizado (pues él lo ha hecho con Box.com) he colgado el PDF en mi directorio público de Dropbox, a disposición de quienes tengan el par de bemoles para enfrentarse con este monstruo bloguero. Que ustedes lo disfruten, con salud, paciencia y unas cañitas.

También he transferido el PDF al flamante Sony Reader PRS-T1 que le regalé a Pilar por Reyes (por cierto, el lector lo maneja con agilidad). Dudo mucho que ella caiga en la tentación de volver a leerme en ese dipositivo, pues tiene el buen gusto de preferir la versión digital de la última novela de Donna Leon, pero por lo menos podremos deslumbrar a los amigos y parientes. Ah, y no descarto pasar a PDF otros sitios que tengo perdidos por ahí, con documentación diversa que va cogiendo polvo, pero que en algún caso aún puede ser aprovechable.

La Bitácora del Tigre en PDF, por cortesía de BlogBooker y Dropbox [28,4 MB.]

Entradas relacionadas

1. Para conseguir una versión offline del blog
2. El blog offline, esta vez en formato ePub

Índices de La Bitácora del Tigre

Tras la actualización del pasado 22 de diciembre, a WordPress 3.3, y la que acabo de completar hoy, a la versión 3.3.1, he descubierto que algunos elementos del blog no estaban funcionando como debían: por ejemplo, unos cuantos vídeos de YouTube incluidos en diversas entradas han desaparecido (supongo que por motivos relacionados con la infracción de los respectivos copyrights de las películas a las que pertenecen), y el índice general de la bitácora, elaborado con el plugin WP-dTree, mostraba un despliegue de las ramas del árbol de entradas más bien errático, y desde luego poco acorde con su diseño original.

Con respecto al primer problema poco puedo hacer, salvo encontrar otro material multimedia que no haya sido retirado/clausurado/suspendido, tarea en la cual no tengo demasiadas ganas de invertir tiempo y energía. En cuanto al segundo problema, ignoro si tiene que ver con las mencionadas actualizaciones o con la publicación de la última versión del citado plugin; sea como fuere, me he puesto enseguida a la labor de lograr un mejor comportamiento de la extensión.

En realidad, el problema con el plugin presenta dos aspectos o vertientes. La primera tiene que ver con su diseño, pues la extensión ha sido concebida para funcionar como un widget. Aunque el creador del plugin también ha previsto varias funciones que se pueden integrar en los ficheros de plantilla del tema, sin embargo ofrece una información tan sumaria sobre su uso que hay que examinar minuciosamente los hilos de los foros de WordPress dedicados al plugin WP-dTree y además realizar innumerables pruebas para dar con la combinación correcta que permita conseguir el efecto deseado. En mi caso, que los índices cronológico y de categorías aparezcan contraídos por defecto, de forma que sea el usuario quien los abra a voluntad.

Ahorraré a mis lectores los muy engorrosos detalles de mis experimentos. Solo les diré que el código necesario para conseguir que los índices por fechas y por categorías funcionen como yo quiero (por cierto, este código forma parte del fichero page-indice-general.php de mi tema-hijo, basado en el framework Hybrid) es el siguiente:

<div class="dtree">
<h2>&Iacute;ndice cronol&oacute;gico, por a&ntilde;os</h2>
<?php
	if(function_exists('wpdt_list_archives')) {
		wpdt_list_archives('type=yearly&useicons=1&opentoselection=0');
	}
?>
</div>
<div class="dtree" style="margin-top:30px">
<h2>&Iacute;ndice tem&aacute;tico, por categor&iacute;as</h2>
<?php
	if(function_exists('wpdt_list_categories')) {
		wpdt_list_categories('useicons=1&show_count=1&opentoselection=0&orderby=name');
	}
?>
</div>

La clave del código es la opción opentoselection=0, cuyo efecto es que los índices aparezcan contraídos al cargar la correspondiente página, tal como muestra la figura 1. Hasta ahora no me había hecho falta tener en cuenta dicha opción, lo cual me hace pensar que la última versión del plugin ha cambiado su comportamiento por defecto.

Figura 1 - Los índices, contraídos al cargar la página

El segundo aspecto del problema afecta al efecto visual de aquellas entradas cuyo título es tan largo que desborda el espacio de la caja de texto de la página o entrada en la que se insertan las funciones del plugin, con lo cual el título aparece truncado. Al final del artículo El árbol de índices del Tigre ya mencioné este pequeño inconveniente y la solución aportada en los foros de WordPress, pero la verdad es que, tras el cambio de tema del blog (véase La Bitácora del Tigre cambia de look y Adaptándome a Hybrid, 1), se me olvidó revisar este detalle, y ya no recuerdo si en su momento resolví el problema modificando los los estilos del tema Tarski o, simplemente, lo dejé correr.

Así que no me ha quedado otro remedio que volver a los experimentos y las probatinas, en este caso con la guía inestimable de la citada intervención en los foros de WordPress, que me ha servido de modelo para el código CSS que figura a continuación, y cuyo efecto es el que pueden ver todos mis lectores en la figura 2:

div .dtNode {
	white-space: normal !important;
}
.node {
	display: inline-block;
	vertical-align: top;
	max-width: 500px;
	min-height: 20px;
	/* padding-bottom: 10px; (desactivado, porque hace mal efecto) */
	/* Para IE 7 */
	*zoom: 1;
	*display: inline;
}

Figura 2 - Una entrada larga del blog, una vez desplegada en el índice

Espero que las funciones y los estilos que he incluido en esta entrada sirvan de referencia a otros sufridos blogueros que tengan algún problema parecido con el plugin WP-dTree (que, por otra parte, es de gran utilidad para un blog muy extenso y con muchas entradas). Si les ahorro las cinco o seis horas (contando por lo bajo) que he tenido que invertir en resolver mis cuitas, me doy por satisfecho.

Entradas relacionadas

1. El árbol de índices del Tigre
2. Los índices del Tigre, renovados
3. Problemas con los índices del Tigre
4. A vueltas con los índices del blog
5. DevPress y Clean My Archives: una nueva solución para la página de índices del blog

El sitio "Comentarios y reseñas de libros"

La serie sobre un proyecto de sitio web educativo realizado en WordPress mediante taxonomías, tipos de contenido y campos personalizados, de la que forman parte los artículos Sitios educativos fechos al taxonómico modo 1, Sitios educativos fechos al taxonómico modo 2, Sitios educativos fechos al taxonómico modo 3, y Sitios educativos fechos al taxonómico modo 4, llega con esta quinta entrega a su término. En este último artículo daré cuenta de las condiciones y circunstancias en las que es aconsejable utilizar este tipo de sitios web en la actividad educativa propia del área de Lengua Castellana y Literatura.

Conviene comenzar haciendo hincapié en el hecho de que no cualquier sitio web es adecuado para un tratamiento como el que se ha descrito en las entradas que forman parte de esta serie. De hecho, ocurre más bien al contrario, pues para la mayoría de sitios creados con WordPress, o al menos para aquellos con la estructura y disposición de un blog habitual, un trabajo semejante al descrito en esta serie constituiría el equivalente del clásico matar moscas a cañonazos. A mi modo de ver, solo un sitio que reúna la mayor parte de las características que se describen a continuación hace rentable el trabajo necesario para ponerlo en práctica.

a) Es un sitio cuyos elementos de contenido esenciales (es decir, los artículos individuales) son homogéneos y presentan rasgos que no se ajustan a las posibilidades de los tipos de contenido ya definidos en WordPress. En una instalación estándar de dicha aplicación, hay cinco tipos de contenido: entradas, páginas estáticas, adjuntos, revisiones e ítems de los menús de navegación; sin embargo, para los propósitos que aquí nos ocupan, solo merece la pena considerar si las entradas y las páginas estáticas ofrecen (o no) las funcionalidades deseadas.

b) Es un sitio en el que el etiquetado taxonómico del contenido, con arreglo a uno o varios criterios aporta un valor añadido a la hora de realizar clasificaciones y búsquedas. Si el marcado semántico es poco relevante o puede atenderse con las tres taxonomías ya presentes en una instalación estándar de WordPress –es decir, categorías, etiquetas y categorías de enlaces- no hace falta embarcarse en la tarea de definir taxonomías personalizadas.

c) Es un sitio cuyo contenido y estructura resultan homogéneos y no han de experimentar variaciones a lo largo del tiempo. Definir las taxonomías y los tipos de contenido personalizados, y ponerlos en relación con los campos personalizados, es un proceso costoso que, a diferencia de lo que ocurre con la estructura típica de un blog, se adapta con dificultad a modificaciones sustanciales.

d) Es un sitio con numerosos autores que crean contenido con arreglo a normas de edición y de publicación claramente definidas. Su resultado final, equivalente a una base de datos sobre un contenido específico –cuanto más acotado sea este, más precisa y útil resultará aquella-, ha de ser una cantidad significativa de artículos bien clasificados y etiquetados, cuya información puede ser indexada y recuperada con facilidad.

e) Es un sitio con un interfaz de edición adaptado a la estructura del contenido, de forma que los usuarios dispongan de un interfaz que les guíe en la realización de las tareas fundamentales de edición del contenido, y evite que se distraigan en tareas de formato o en recorrer los menús de la aplicación. Si los usuarios editores han de ser alumnos, esta característica resulta de particular importancia.

f) Es un sitio cuyos menús de navegación y estructura de presentación del contenido no son los típicos de un blog.

Sin ánimo de agotar las amplísimas posibilidades que ofrecen los sitios educativos creados mediante taxonomías, tipos de contenido y campos personalizados, a continuación ofrezco un posible listado, adaptado a los contenidos del área de Lengua Castellana y Literaria en Secundaria y Bachillerato:

• Creación de un catálogo de movimientos literarios.
• Recopilación, análisis y catalogación de figuras literarias.
• Elaboración de reseñas, comentarios y análisis de libros, películas y otras obras artísticas.
• Elaboración de una nómina de personajes de obras literarias.
• Elaboración de callejeros literarios.
• Creación de rutas literarias.
• Elaboración de antología literarias, en la que se clasifican textos literarios ya existentes, según diferentes criterios (véase, a este respecto, mi proyecto de antología textual).
• Creación de sitios web basados en la práctica por parte de los alumnos de un modelo textual predefinido, en función de diversos criterios: tipología textual (descripciones, diálogos, breves obras narrativas o teatrales), géneros literarios (cuentos y relatos, textos poéticos con sus diversas formas métricas), géneros periodísticos (noticias, reportajes, entrevistas), etc.
• Análisis comparativo de textos literarios y sus adaptaciones cinematográficas, televisivas, teatrales, etc.
• Elaboración de repertorios de textos no literarios.
• Elaboración de repertorios de podcasts y grabaciones de audio.
• Clasificación y análisis de textos audiovisuales.
• Elaboración de una nómina o catálogo de fenómenos gramaticales.
• Creación de catálogos de fenómenos lingüísticos, relacionados con las variedades diatópicas (fenómenos dialectales), diastráticas y diafásicas de la lengua.
• Creación de léxicos especializados o diccionarios para propósitos específicos.
• Y cualquier tipo de publicación online sobre un contenido específico que sea susceptible de ser etiquetado de acuerdo con uno o varios criterios de clasificación.

Montar un sitio web que responda a cualquiera de los propósitos y finalidades que se acaban de esbozar exige una serie de requisitos imprescindibles desde el punto de vista de la instalación y la administración de la aplicación:

a) Una instalación de WordPress en servidor propio que se pueda administrar sin restricciones, pues este tipo de sitios web exige instalar plugins y modificar a fondo los temas existentes, tal como se ha visto en los anteriores artículos de la serie. Hasta donde yo sé (pero puedo estar equivocado, por lo que agradeceré cualquier corrección al respecto), una instalación como la que he descrito en esta serie es imposible en plataformas de blogs como WordPress.com o Edublogs.

b) Conocimientos avanzados de administración de WordPress. Aunque las descripciones, instrucciones y recursos que he publicado a lo largo de la serie pueden servir de orientación (véase, a este respecto, el fichero ZIP que figura al final del artículo Sitios educativos fechos al taxonómico modo 3), cualquiera de los sitios web enumerados a título de ejemplo (o cualesquiera otros semejantes) hace necesario un cuidadoso trabajo previo de análisis y preparación.

c) Una adecuada administración de los roles de usuario. Es necesario analizar con detalle qué roles requieren los procesos de edición y publicación del contenido y qué capacidades deben estar disponibles para cada uno de ellos (a este respecto, resulta de obligada consulta el artículo Roles and Capabilities), porque no todo lo que puede ser necesario es factible con los roles estándar de WordPress, y por otra parte las capacidades adscritas a cada uno de dichos roles pueden no ser las más adecuadas a los flujos editoriales que el administrador de un sitio se haya fijado de antemano.

Pondré un ejemplo de las contradicciones a las que me acabo de referir. Puede interesar que los usuarios creadores de contenido (los alumnos) tengan perfil de colaborador, para que no les sea posible publicar directamente, de forma que solo un usuario con un rol de editor o administrador (generalmente su profesor) autorice la publicación después de revisar sus trabajos. Pues bien, esto sería imposible en un sitio como el descrito en esta serie de artículos, ya que requiere que los usuarios suban imágenes, capacidad que no está al alcance del rol de colaborador.

Afortunadamente, existen plugins que permiten solventar estos inconvenientes, como por ejemplo Members, con el cual se pueden modificar las capacidades de los diversos roles estándar de WordPress o, lo que todavía es mejor, definir roles de usuario que se ajusten como un guante a las necesidades funcionales del sitio.

d) Un buen diseño instruccional, y un adiestramiento previo de los usuarios en el manejo de los elementos fundamentales del sitio. Evidentemente, se requiere que los objetivos del sitio estén claros, que las tareas de los usuarios creadores de contenido hayan sido bien descritas y que se les brinden las ayudas adecuadas (en el sitio Comentarios y reseñas de libros, he incluido un par de páginas sobre Cómo escribir el contenido de los artículos y Cómo etiquetar los artículos, pero es obvio que un sitio web “real” debería incorporar un aparato de ayuda más amplio y unos andamiajes mucho más sólidos). A tenor de mi experiencia, la intervención de los alumnos en sitios web hace muy recomendables diversas ayudas:

• Instrucciones generales de manejo de WordPress: entrada y salida de la aplicación, acceso al editor, operaciones fundamentales de manejo del editor, técnicas de escritura, operaciones de visualización, guardado y edición de los artículos.
• Consejos sobre cómo se deben redactar los artículos, tanto desde el punto de vista de la corrección gramatical y ortográfica como desde la perspectiva de la adecuación pragmática.
• Instrucciones sobre un correcto manejo del editor de una aplicación online. Si hay alguna norma en la que se debe insistir es la relativa a la técnica correcta para copiar y pegar el contenido cuando ello es necesario, que consiste en pegar sin formato o en texto plano.
• Instrucciones sobre la cita de fuentes y referencias.
• Instrucciones sobre las tareas de subida e inserción de imágenes y otros elementos multimedia.
• Consejos con respecto a cómo se deben etiquetar los artículos en cada una de las taxonomías personalizadas definidas (por ejemplo, y por ceñirnos al sitio Comentarios y reseñas de libros, las etiquetas de la taxonomía “autores” deben llevar la inicial en mayúscula, pues corresponden a nombres propios, pero no así las etiquetas correspondientes a las taxonomías “géneros literarios” y “literaturas nacionales”) y cómo hay que introducir los metadatos que el tema del sitio pueda requerir.

El sitio "Comentarios y reseñas de libros"

Seguramente me dejaré más de un asunto de interés en el tintero, pero creo que con este último artículo está dicho lo fundamental en torno al caso que hasta aquí me ha venido ocupando en los dos últimos meses. En este 31 de diciembre, y a despecho de los negros presagios que nos cercan por doquier, solo queda desear a todos los lectores y lectoras de La Bitácora del Tigre un muy feliz y próspero año 2012.

Entradas relacionadas

1. Sitios educativos fechos al taxonómico modo 4
2. Sitios educativos fechos al taxonómico modo 3
3. Sitios educativos fechos al taxonómico modo 1
4. Sitios educativos fechos al taxonómico modo 2
5. Más sobre taxonomías y tipos de contenido personalizados: plugins para los tipos de contenido

También elaboré un documento en el que consta una relación completa de los plugins que tenía activados, pues sé por experiencia que es muy fácil olvidarse de alguno, y tras desactivarlos todos con la única excepción del plugin antispam Akismet, pulsé el botón de Actualizar. Aunque el proceso solo tardó uno o dos minutos en completarse, no pude evitar imaginar las más variadas catástrofes durante esos breves instantes en los cuales el sistema se gobierna a sí mismo.

Afortunadamente, casi todo salió bien. Digo “casi todo” porque al reactivar los plugins uno a uno, y comprobar sus efectos e interacciones, me encontré con que un par de widgets habían desaparecido: el creado por el plugin Query Posts, del que traté hace ya bastante tiempo en el artículo La magia de los widgets de WordPress 3, y otros dos asociados al megaplugin Jetpack. En el primer caso, no fue fácil recuperar la configuración, porque el widget tiene tantos parámetros que me costó un buen rato dar con la combinación adecuada. En el segundo, bastó con volver a introducir los datos de conexión con WordPress.com (no sé por qué se perdieron) para recuperar los widgets y volver a disfrutar de su funcionalidad.

Tiempo habrá de comprobar si WordPress 3.3 es tan bueno como dicen. El cambio más evidente del backend, que tiene que ver con los nuevos menús desplegables y la barra de administración obligatorios, no me hace demasiado feliz, pero estoy seguro de que en poco tiempo me acostumbraré. Por el contrario, el cargador multimedia unificado y su sistema de “arrastrar y soltar”, me parece una innovación muy acertada, pues supone para los usuarios menos expertos un gran ahorro de dolores de cabeza. Sobre los demás cambios, y a falta de una experiencia más consolidada, me reservo la opinión; cuando la tenga, ya habrá oportunidad de hacerla constar en mi cuenta de Twitter.

Aprovechando las tareas de mantenimiento en las que invertí buena parte de la tarde de ayer, y con el propósito de cumplir con una de las tradiciones de este blog, la de las felicitaciones y adornos navideños, he instalado un plugin de ocasión, denominado Christmas Ball on Branch, que hace justamente lo que su nombre indica: incluir en el ángulo superior derecho de la cabecera un motivo navideño. Como la imagen de la bola animada sobre la rama de un abeto no me gustaba demasiado, la he sustituido por una guirnalda, obtenida de la página Christmas Wreath Clip Art.

Seguro que su diseño no es el más elegante y afortunado del mundo, pero me sirve para desearles a todos ustedes, lectores y lectoras de La Bitácora del Tigre, unas felices navidades y un próspero año nuevo 2012.

Entradas relacionadas

1. Más recursos de escritura y Feliz Navidad para todos
2. Un plugin para actualizar a WordPress 2.3
3. Pues todavía no voy a actualizar a WordPress 2.3
4. Actualización de WordPress a la versión 2.3.2
5. Actualización de WordPress a la versión 2.0.6

Configuración para utilizar una página fija como inicio

Tras los artículos Sitios educativos fechos al taxonómico modo 1, Sitios educativos fechos al taxonómico modo 2 y Sitios educativos fechos al taxonómico modo 3, la cuarta entrega de esta serie sobre un proyecto de sitio web educativo realizado con taxonomías, tipos de contenido y campos personalizados, estará dedicada a detallar los elementos que proporcionan a Comentarios y reseñas de libros su funcionalidad y aspecto visual característicos, a saber: la configuración de la estructura del sitio, la disposición de los menús, la definición de los widgets de la barra lateral y el uso de ciertos plugins que permiten lograr ciertas funcionalidades que mejoran el uso de las taxonomías y tipos de contenido personalizados.

1. Configuración de la estructura del sitio.

La disposición habitual de un sitio web elaborado con WordPress es la típica de un blog, es decir, una página que contiene el listado de las últimas entradas (normalmente, diez), dispuestas en orden cronológico inverso. Ahora bien, WordPress ofrece otras muchas posibilidades: mostrar en la portada una página fija, con la información esencial del sitio a modo de presentación o saludo, combinar los contenidos fijos con resúmenes o/y miniaturas de las últimas entradas (disposición típica de los sitios al estilo revista o magazine), dividir la página principal en núcleos informativos orientados a actividades, tareas o conceptos (como ocurre en los sitios que adoptan la disposición de un portfolio), etc.

Para el sitio Comentarios y reseñas de libros, que pretende deliberadamente alejarse lo más posible de la manera habitual de presentar los contenidos propia de un blog, he optado por la disposición al estilo CMS, es decir, con una página estática de inicio, que presenta la información esencial sobre el sitio, y un menú superior y una barra lateral a la derecha, dispositivos ambos que permiten navegar con toda facilidad por el contenido. Los ítems del menú superior y de la barra lateral combinan distintos elementos: varias páginas estáticas, entradas o artículos pertenecientes a la única categoría existente en el sitio (“Instrucciones”) y diversas páginas que ofrecen el contenido personalizado, esto es, el tipo de contenido “Libros”, y las taxonomías “Autores”, “Géneros literarios” y “Literaturas nacionales”.

La estructura de contenido al estilo CMS es muy fácil de crear, pues basta con ir al menú Ajustes > Lectura, y definir los parámetros necesarios. Como puede verse en la figura 1, la página de inicio es la ya mencionada “Sobre este sitio”, mientras que el campo asociado al modo de presentación al estilo blog se ha dejado deliberadamente vacío, con lo cual se dificulta al visitante que pueda obtener un listado de los artículos del blog por orden cronológico (se dificulta pero no se impide, porque siempre es posible hacerlo mediante una URL de tipo cronológico; por ejemplo, http://www.elarequi.com/antologia1/2011/).

Figura 1 - Configuración del sitio para utilizar una página fija como inicio

2. Creación del menú de navegación superior.

Una de las mejoras más aplaudidas de WordPress 3.0 fue su nuevo sistema de menús personalizables, mucho más potente que el anterior y, lo que es mejor, muy fácil de utilizar. Desde el menú Apariencia > Menús, se accede a un interfaz basado en la técnica de “arrastrar y soltar”, mediante el cual se pueden organizar los ítems de los menús de la forma en que sea necesario. Para ilustrar la potencia y flexibilidad de este sistema de creación de menús, nada mejor que las figuras 2 y 3, que muestran la página de creación del menú en el backend del sitio (figura 2) y el aspecto que adquiere dicho menú en el frontend (figura 3).

Figura 2 - Configuración del menú del sitio en el backend

Figura 3 - Aspecto del menú superior en el frontend

Con respecto a la creación de este menú, conviene tener en cuenta las siguientes observaciones:

• Si se quiere tener a la vista todas las opciones del menú disponibles en la página de gestión de menús de WordPress, se debe pulsar sobre el enlace denominado Opciones de pantalla, que aparece en la parte superior de la derecha de la página (obsérvese el recuadro en rojo de la figura 2), y activar todas las casillas que hagan falta.
• La forma en que se ordenan los ítems de los menús suele estar relacionada con la estructura previamente establecida para el contenido y sus elementos constitutivos (páginas fijas/entradas/categorías/etiquetas/tipos de contenido/taxonomías, etc.), pero los menús no tienen por qué reflejar dicha estructura al pie de la letra. Por ejemplo, en el recuadro marcado en color marrón de la figura 2, puede apreciarse que los ítems de clasificación correspondientes a la taxonomía personalizada “géneros literarios” se han organizado jerárquicamente (solo por razones didácticas, ya que así es posible apreciar, de forma visual, que la novela histórica es un subgénero de la novela), aunque dicha jerarquía no existe en la organización del contenido.
• La forma en que WordPress presenta los menús depende enteramente del tema elegido para el blog. Si se quiere utilizar esta funcionalidad, es necesario contar con un tema compatible con WordPress 3.0, y que además disponga de zonas de menús. El tema Twenty Ten, escogido para el sitio Comentarios y reseñas de libros, tiene una única zona de menús, situada bajo la imagen de cabecera (véase la figura 3), pero hay otros temas que tienen dos, tres, e incluso más zonas de menús.

3. Diseño de la barra lateral.

En cuanto el administrador define y guarda un menú personalizado, WordPress crea automáticamente un widget que reproduce con total fidelidad dicho menú, lo cual resulta muy útil para replicarlo en las zonas de widgets donde habitualmente se sitúan las estructuras de navegación (casi siempre, en la barra o barra laterales). Incluso aunque un tema disponga de una única zona de menús, es perfectamente posible crear varios menús personalizados, lo cual da origen a los correspondientes widgets, que a su vez se pueden utilizar en las zonas donde aquellos sean requeridos. En la figura 4 puede observarse cómo se ha definido en el backend el widget correspondiente al “menú del sitio”, que forma parte de la barra lateral principal del tema Twenty Ten; por su parte, la figura 5 muestra el aspecto que dicho widget tiene en el frontend.

Figura 4 - Configuración del widget del menú personalizado

Figura 5 - Widgets de menú personalizado y de búsqueda por criterios de clasificación

Por defecto, WordPress añade los menús personalizados y las barras laterales a todas y cada una de las páginas del blog. Es posible alterar este comportamiento, aunque ello exige el uso de plugins o de técnicas especiales que no puedo tratar aquí (los interesados pueden consultar los diversos artículos que he dedicado al tema de los widgets condicionales). En todo caso, para un sitio como Comentarios y reseñas de libros, cuya finalidad y sentido vienen dados por el contexto educativo en el que se sitúa, la posibilidad de contar con dos menús idénticos, uno en la cabecera y otro en la barra lateral, que aparecen sistemáticamente en todas las páginas, no es un inconveniente, sino una clara ventaja, pues refuerza su coherencia interna y facilita la navegación por entre sus páginas.

Además del menú personalizado, a la barra lateral derecha se han añadido otros tres widgets, a saber:

• RSS del sitio. Se trata de un widget de texto que simplemente invoca la URL de la fuente RSS del sitio web. Gracias a las funciones añadidas al tema hijo (véase el epígrafe 2.6 del artículo Sitios educativos fechos al taxonómico modo 3), los artículos correspondientes al tipo de contenido personalizado “Libros” se integran en la fuente RSS del sitio.
• Búsqueda general. Es uno de los widgets estándar de WordPress. Cuando se definió el tipo de contenido personalizado “Libros” (véase el artículo Sitios educativos fechos al taxonómico modo 2), el parámetro “public” se estableció como “true”, lo cual significa, en la práctica, que la información que contienen sus artículos se puede buscar y encontrar desde este formulario.
• Búsqueda por términos de clasificación. Es un widget obtenido gracias al plugin Query Multiple Taxonomies, que resulta de gran utilidad en sitios elaborados mediante taxonomías personalizadas, pues permite realizar búsquedas mediante uno o varios criterios de clasificación. Cada vez que se elige un término de clasificación, el widget indica qué otros términos están disponibles para filtrar los resultados, con lo cual se pueden realizar búsquedas muy precisas, que resultan en URLs de este tipo: http://www.elarequi.com/antologia1/?autores=fernando-aramburu&generos=cuento&literaturas-nacionales=literatura-espanola. Es cierto que este tipo de búsquedas solo resultan verdaderamente útiles en sitios web que contengan muchos artículos, pero en cualquier caso animo a los interesados en esta funcionalidad a que experimenten con este widget y vean sus resultados.

4. Algunos plugins para tareas específicas.

Además de las extensiones utilizadas para gestionar los tipos de contenido, las taxonomías y los tipos de contenido personalizados (véase el artículo Sitios educativos fechos al taxonómico modo 2, en el que detallo el uso de los plugins Custom Post Type UI y Advanced Custom Fields), el sitio Comentarios y reseñas de libros utiliza los siguientes plugins:

• Antispam Bee, para evitar los comentarios-basura. Aunque el sitio tiene los comentarios desactivados, pues se trata de una web de demostración, me he lanzado a probar este plugin, que empieza a ser recomendado con cierta frecuencia (véanse, por ejemplo, Free Akismet Alternatives y To Fight Spam With Akismet Or Without Akismet), a causa de las peculiaridades de Akismet en relación con su método de filtrado del spam y su cada vez más cuestionada gratuidad.
• Multi-Column Taxonomy List, que se utiliza exclusivamente para crear una página de listado de criterios de clasificación, en la que aparecen, agrupados y ordenados, todos los términos de las taxonomías personalizadas.
• Query Multiple Taxonomies. Como ya se ha explicado en el epígrafe 3 de este mismo artículo, este plugin se utiliza para realizar búsquedas (por un único criterio, o por criterios combinados) entre las taxonomías personalizadas, es decir, por entre las etiquetas de clasificación de los libros.
• Rich Text Tags. Habida cuenta de que WordPress no permite por sí mismo utilizar etiquetas y atributos HTML en la descripción de las etiquetas o términos de las taxonomías personalizadas, y que dicha información puede ser muy interesante desde una perspectiva educativa (véase, por ejemplo, la página correspondiente a la etiqueta novela), se ha utilizado este plugin, sobre cuyo funcionamiento puede verse una captura de pantalla ilustrativa (la figura 3) en el artículo Sitios educativos fechos al taxonómico modo 1.

Y hasta aquí la cuarta entrega de esta serie, con la que tenía la intención de culminar la descripción del proyecto del sitio Comentarios y reseñas de libros. Sin embargo, me he dado cuenta de que el epígrafe final, en el que pensaba desarrollar algunas ideas relacionadas con la justificación y el uso educativo de este tipo de sitios web, merecía una entrada por sí mismo, que espero publicar en los próximos días. Como ya he dicho en todas las ocasiones anteriores, permanezcan atentos a sus pantallas.

Entradas relacionadas

1. Sitios educativos fechos al taxonómico modo 1
2. Sitios educativos fechos al taxonómico modo 5
3. Sitios educativos fechos al taxonómico modo 2
4. Sitios educativos fechos al taxonómico modo 3
5. Algunas capturas antológicas

Gestión del tipo de contenido "Libros", con taxonomías y campos personalizados

En los dos artículos anteriores de esta serie, Sitios educativos fechos al taxonómico modo 1 y Sitios educativos fechos al taxonómico modo 2, he mostrado las características esenciales de un sitio web de reseñas y comentarios de obras literarias, elaborado en WordPress por medio de taxonomías, tipos de contenido y campos personalizados, y asimismo he explicado las posibilidades de los plugins Custom Post Type UI y Advanced Custom Fields para definir, organizar y nutrir de contenido un sitio web de tales características.

No quiero asustar a mis lectores, pero lo cierto es que en esos dos artículos he descrito la parte fácil del proceso. En efecto, la traslación del contenido del sitio a la pantalla –es decir, la representación de los artículos correspondientes al tipo de contenido “libros”, que van acompañados por las etiquetas asociadas a tres taxonomías personalizadas y la información procedente de cinco campos personalizados- resulta una tarea bastante complicada, ya que requiere una laboriosa edición de los ficheros que forman parte del tema elegido para el blog. Para que los docentes interesados en este proyecto no tengan que pasar por los mismos suplicios que un servidor –cuyas habilidades como programador en PHP, ya lo he dicho más de una vez, tienden a cero- describiré a continuación los pasos que he seguido para crear un tema de WordPress que me permitiera representar la estructura de contenido del sitio.

1. La conveniencia de crear un tema hijo.

Según el Codex de WordPress, “un tema hijo es un tema que hereda la funcionalidad de otro tema, denominado tema padre, y que permite modificar, o añadir, la funcionalidad de dicho tema” (la traducción es mía). La gran ventaja de los temas hijo es que requieren un trabajo relativamente pequeño de desarrollo, pues toda su estructura y su presentación vienen dadas por aquel en el que están basados. Por otro lado, cuando el tema padre se actualiza, los cambios hechos en el tema hijo no se pierden, dado que este aprovecha las funcionalidades que haya aportado la nueva versión de aquel. En consecuencia, un tema hijo es una herramienta de gran utilidad para proyectos basados en el añejo método de la prueba y el error (al que, si he de ser sincero, debe su existencia el sitio Comentarios y reseñas de libros), ya que los posibles desastres siempre se pueden eliminar borrando el tema hijo, volviendo al tema padre y recomenzando, si es necesario, desde cero. 

No voy a explicar aquí cómo se crea y se instala un tema hijo, pues en la Red es fácil encontrar tutoriales sobre el particular. Por citar solo tres ejemplos, véanse artículos como Temas hijo: cómo hacer modificaciones sencillas en un tema de WordPress, Crear un tema hijo de WordPress o How to Create a WordPress Child Theme (Video). En cambio, me extenderé en detallar los ficheros de que consta el tema hijo del sitio Comentarios y reseñas de libros, basado en el tema-padre Twenty Ten. He escogido este tema porque está muy bien estructurado y es relativamente fácil de comprender; además, al tratarse del tema por defecto de la versión 3.0 de WordPress, ha sido exhaustivamente utilizado para ilustrar muchas tareas de transformación y adaptación, con lo cual la documentación y los ejemplos disponibles para trabajar con él son fáciles de encontrar.

Una advertencia previa: para no aburrir a mis lectores habituales, no voy a incluir a continuación ningún ejemplo de código. Quienes tengan interés en conocer las interioridades del sitio, pueden descargar el ZIP que aparece al final de este artículo, en el que se incluyen todos los ficheros del tema hijo elaborado para el proyecto; si editan dichos ficheros, podrán ver los comentarios e indicaciones que ayudan a entender su funcionamiento. En el ZIP también he incluido la copia de un documento publicado en Google Docs en el que constan todos los ficheros del tema hijo, sus relaciones con el tema padre, y las funciones que desempeñan en la construcción del sitio.

2. Los ficheros del tema hijo.

2.1. Ficheros style.css y screenshot.png.

El fichero style.css contiene en su cabecera la identificación y descripción del tema hijo, y las debidas referencias al tema padre, amén de unos cuantos estilos CSS que sirven para representar los distintos elementos de la página correspondiente a un comentario o reseña de libro, lo cual se logra mediante cajas de diferente color (beige, rosa, azul, verde y gris), tal como puede verse, por ejemplo, en la reseña de Los mares grises sueñan con mi muerte; el campo personalizado de ficha editorial, cuenta con un estilo adicional, encargado de presentar la información mediante una sangría francesa. Por su parte, el fichero screenshot.png es el mismo del tema padre Twenty Ten.

2.2. Ficheros archive-libros.php y loop-archive.libros.php.

Estos dos ficheros sirven para generar la página de archivo o índice mediante la cual se presenta el listado de artículos correspondiente al tipo de contenido “libros”. En WordPress no es difícil conseguir este tipo de listados, pues, de acuerdo con la jerarquía de plantillas, basta con tomar el fichero archive.php del tema padre, renombrarlo como archive-{post_type}.php (en el caso que nos ocupa, archive-libros.php) y llevar a cabo sobre él las modificaciones necesarias. Naturalmente, esto es la teoría, porque en la práctica el invento es algo más complicado, ya que las últimas líneas del fichero archive.php del tema Twenty Ten invocan el fichero loop.php, que es el que contiene el celebérrimo loop o bucle encargado de llamar a todas las entradas o artículos uno tras otro y mostrarlos en pantalla. Es necesario, entonces, construir un fichero de bucle especializado que se encargue de mostrar el bucle singular correspondiente al tipo “libros”. Y esa es justamente la tarea que realiza el fichero loop-archive.libros.php, cuyo bucle muestra el resumen o extracto de los artículos del tipo “libros”, precedido por una miniatura de 100×100 píxels, alineada a la izquierda.

2.3. Ficheros single-libros.php y loop-single-libros.php.

La función de estos ficheros es la de presentar las páginas individuales correspondientes a cada uno de los artículos del tipo de contenido “libros” (véanse, a modo de ejemplos, las páginas El sitio de Krishnapur y Los mares grises sueñan con mi muerte). De nuevo, es relativamente fácil construir en un tema de WordPress un fichero de plantilla de página individual para un artículo perteneciente a un tipo de contenido personalizado, pues la ya mencionada jerarquía de plantillas establece que tal objetivo se puede conseguir mediante un fichero denominado single-{post_type}.php (en nuestro caso, single-libros.php), para cuya elaboración basta con tomar como modelo el fichero single.php del tema.

Al igual que en el caso anterior, al final del fichero single-libros.php hay una llamada a loop-single-libros.php, que es la pieza del sistema realmente encargada de aportar los elementos específicos de esta plantilla, a saber:

• El contenido de los tres primeros campos personalizados.
• Los términos o etiquetas asociados a las tres taxonomías personalizadas.
• El contenido de los dos últimos campos personalizados.

2.4. Ficheros autores.php, generos.php y literaturas-nacionales.php.

Estos tres ficheros  están basados en la plantilla de página fija onecolumn-page.php del tema padre Twenty Ten, que ha sido modificada para adecuarla a las necesidades de las tres páginas fijas (autores, géneros literarios y literaturas nacionales) que deben listar los términos de las tres taxonomías personalizadas, con sus respectivas descripciones. El único cambio efectuado en cada una de las plantillas es una consulta personalizada para obtener el correspondiente listado de términos, junto con sus descripciones.

2.5. Ficheros taxonomy-autores.php, taxonomy-generos.php y taxonomy-literaturas-nacionales.php.

Estos tres ficheros se encargan de presentar cada uno de los términos o etiquetas de clasificación de las taxonomías personalizadas, junto con sus respectivas descripciones, como puede verse en páginas como J.G. Farrell, Cuento, o Literatura española. De acuerdo con la ya varias veces mencionada jerarquía de plantillas de WordPress, para obtener una plantilla que realice esa tarea, basta con denominarla taxonomy-{taxonomy}.php, y añadirle el código necesario. Dado que el tema Twenty Ten no cuenta con ningún fichero que pueda aprovecharse como base (aunque se podrían utilizar tanto el archive.php como el category.php), he seguido de cerca el artículo How To Build A Media Site On WordPress (Part 2), en el que se explica detalladamente su proceso de elaboración.

Los elementos esenciales de estos tres ficheros son los siguientes:

• Se define una consulta personalizada para obtener los datos necesarios (los términos de la taxonomía).
• Se añaden los campos del nombre del término y su descripción.
• Finalmente, se hace una lista de los artículos del tipo de contenido “libros” relacionados con dicho término.

2.6. Fichero functions.php.

He dejado voluntariamente para el final de este artículo el fichero clave de mi proyecto de sitio web especializado, en el cual se incluye el código que permite lograr muchas de sus características más destacadas. Me apresuro a señalar que ninguna de las funciones ha sido programada ex novo, pues todas ellas son adaptaciones basadas en códigos propuestos por los artículos que he encontrado en la Red, a la caza y captura de aquellos trucos y técnicas que me permitieran alcanzar los objetivos deseados. La lista completa de los recursos que he utilizado puede verse en la página Elementos utilizados para crear este sitio, de la web Comentarios y reseñas de libros,

A continuación figura una relación exhaustiva de todas esas funciones. Dada la naturaleza de esta información, de nuevo animo a mis lectores y lectoras a que descarguen el ZIP que aparece al final del artículo y comprueben por sí mismos el código, en cuyos comentarios se describe el propósito de cada función y se cita la procedencia de las fuentes.

a) Función “icono_para_libros”, que permite utilizar en el menú del tipo de contenido personalizado “libros” un par de iconos identificativos (figura 1). Algunos de entre los plugins para declarar tipos de contenido personalizados que mencioné en el artículo del pasado 22 de noviembre permiten definir el icono, pero no así el que yo he utilizado (recuerdo que se trata del Custom Post Type UI), y de aquí la necesidad de acudir a una función específica.

Figura 1 - Interfaz de gestión del tipo de contenido "Libros", con taxonomías y campos personalizados

b) Función “miniatura_a_partir_de_la_primera_imagen”, para extraer una miniatura de 100×100 píxels y presentarla en el resumen de cada uno de los artículos del tipo “libros” que aparecen en la página Comentarios de libros.

c) Funciones “registrar_columnas_tipo_personalizado_libros”, “gestionar_columnas_tipo_personalizado_libros”, “ordenar_columnas_tipo_personalizado_libros” y “autores_clauses_eduardo”, que sirven para crear un interfaz personalizado para la gestión de los artículos del tipo “libros” en el backend de WordPress (figura 1). Estas funciones permiten filtrar los artículos del tipo “libros” por cualquiera de las etiquetas correspondientes a una taxonomía personalizada (figura 2), y también hacen posible la ordenación alfabética de los artículos de acuerdo con las etiquetas de la taxonomía “autores” (figura 3).

Figura 2 - Filtrado de artículos por etiquetas de taxonomías personalizadas

Figura 3 - Ordenación de artículos por la taxonomía personalizada "Autores"

d) Función “incluir_libros_en_fuenterss”, para incorporar el contenido del tipo de contenido “libros” a la fuente RSS del sitio web.

e) Funciones “eliminar_menus_para_no_administradores” y “desactivar_widgets_por_defecto_escritorio”, para crear un interfaz de edición más limpio y sencillo, apto para su uso por parte de usuarios poco o nada acostumbrados a lidiar con el backend de WordPress. Los interesados en comprobar el aspecto visual de dicho interfaz pueden comprobarlo en las dos primeras capturas de pantalla que ilustran el artículo Sitios educativos fechos al taxonómico modo 1.

Antes de terminar este artículo, aquí va el ZIP tantas veces prometido:

Tema Twenty Ten taxonómico

En la próxima entrega de esta serie, que espero sea la última, me ocuparé de los retoques finales a la presentación del sitio (menús, instrucciones, plugins adicionales) y de sus condiciones de uso en entornos educativos. Permanezcan atentos a sus pantallas.

Addenda del 3 de diciembre de 2011

A partir de la versión 3.0.2 del plugin Advanced Custom Fields, publicada el 28 de noviembre, se puede exportar el contenido de los campos personalizados a un fichero en formato XML, que posteriormente se puede importar desde otro blog. Para comprobar la nueva funcionalidad, he exportado la configuración de los campos personalizados del sitio Comentarios y reseñas de libros y he añadido el correspondiente fichero XML al ZIP que aparece sobre estas líneas. De este modo, cualquier persona interesada en reproducir dicho sitio web podrá hacerlo con un trabajo mínimo.

Entradas relacionadas

1. Sitios educativos fechos al taxonómico modo 2
2. Sitios educativos fechos al taxonómico modo 1
3. Sitios educativos fechos al taxonómico modo 4
4. Sitios educativos fechos al taxonómico modo 5
5. Las taxonomías personalizadas de WordPress y sus posibilidades educativas, 2

Gestión de campos personalizados con el plugin Advanced Custom Fields

Para crear las taxonomías, los tipos de contenido y los campos personalizados que necesita un sitio como el de Comentarios y reseñas de libros, sobre el que escribí el pasado jueves en la anterior entrega de esta serie, existen dos procedimientos diferentes. El primero consiste en declarar dichos elementos dentro del fichero functions.php del tema activo; es el más elegante y preciso, pero también el más difícil de poner en práctica. El segundo implica el uso de uno o varios plugins de WordPress, lo cual supone ciertas restricciones y peajes, dado que no todos los plugins pueden lograr todo lo que el diseñador de un sitio se proponga, pero a cambio es una alternativa mucho más accesible para la inmensa mayoría de los usuarios.

A diferencia de lo que en su día hice con el proyecto de antología textual, para el sitio Comentarios y reseñas de libros he optado por la segunda opción, pues me interesaba recorrer la misma senda que deberían emprender los docentes interesados en la experiencia, y encarar las mismas dificultades a las que ellos habrían de enfrentarse. Así pues, tras muchas consultas y pruebas, opté por utilizar los plugins que describo a continuación.

1. Custom Post Type UI.

Este plugin permite declarar y configurar tanto las taxonomías como los tipos de contenido personalizados, mediante un interfaz gráfico muy fácil de utilizar (siempre, claro está, que se tenga un conocimiento mínimo de ambos conceptos y de la lengua inglesa). Como puede observarse en las figuras 1 y 2, correspondientes a la configuración del tipo “libros” y la taxonomía “autores”, el plugin permite definir en la lengua del usuario todas las etiquetas que posteriormente aparecerán en los menús de creación y gestión de los artículos correspondientes al tipo de contenido personalizado y los términos o etiquetas relacionados con las taxonomías personalizadas.

Figura 1 - Edición del tipo de contenido personalizado "Libros"

Figura 2 - Edición de la taxonomía personalizada "Autores"

Además, el plugin hace posible establecer las necesarias relaciones entre el tipo de contenido y la taxonomía, y definir con precisión qué elementos del interfaz de edición del tipo de contenido personalizado se mostrarán a los usuarios, lo cual resulta de gran utilidad para adecuar el editor del sitio web a las características de las personas que vayan a hacer uso de él. En la mayoría de los casos, los usuarios pueden desentenderse de los parámetros más técnicos y difíciles de entender (como “Public”, “show UI”, “Has Archive”, “Query Var”, etc.), pues el plugin utiliza por defecto aquellos que mejor se ajustan a las situaciones más habituales.

Conviene señalar que el plugin Custom Post Type UI no es el único que sirve para la creación y gestión de taxonomías y tipos de contenido personalizados, pues hay bastantes que pueden competir ventajosamente con él. Sin ánimo de agotar el inmenso catálogo de posibilidades que ahora mismo brinda WordPress (véanse los listados que en su día publiqué en Taxonomías, tipos de contenido y paneles personalizados en WordPress. El turno de los plugins, Más sobre taxonomías y tipos de contenido personalizados: plugins para taxonomías y Más sobre taxonomías y tipos de contenido personalizados: plugins para los tipos de contenido), a los lectores de este artículo quizás les interese saber que pueden elegir entre un amplio abanico de extensiones: CMS Press, Custom Content Type Manager, Custom Content Types, CustomPress (de pago), Custom Press, Easy Content Types (también de pago, y quizás el más completo de todos), GD Custom Posts And Taxonomies Tools (con versiones gratuita y de pago), More Taxonomies, More Types, Pods CMS Framework, Simple Custom Post Types, Simple Taxonomy, Taxonomy Manager, Ultimate Post Type Manager, Ultimate Taxonomies Manager, WP Easy Post Types y WP Post Type UI.

Si he seleccionado de entre todos ellos el Custom Post Type UI ha sido por varias razones: es gratuito, no es difícil de utilizar (aunque exige dedicarle una cuidadosa atención), carece de fallos graves que dificulten su uso y, sobre todo, es capaz de generar el código PHP necesario para declarar las taxonomías y los tipos de contenido (figura 3), con lo cual una configuración dada es fácilmente exportable a otro sitio web elaborado con WordPress, para lo cual basta con copiar el código en el fichero functions.php del tema del nuevo sitio. De hecho, tengo intención de publicar en próximas entregas de esta serie un fichero ZIP que, entre otros elementos, incluirá el código necesario para reproducir el tipo “libros” y las taxonomías “autores”, “géneros literarios” y “literaturas nacionales” en otros sitios web.

Figura 3 - Exportación del tipo de contenido "Libros"

2. Advanced Custom Fields.

La creación y gestión de campos personalizados asociados a las taxonomías y los tipos de contenido personalizados y su integración en el interfaz de edición de WordPress son tareas significativamente más difíciles de llevar a cabo que las que hemos descrito en el punto anterior. Es cierto que en WordPress se puede conseguir casi cualquier objetivo mediante la manipulación del código o el uso de extraordinarias librerías como Custom Meta Boxes, pero también lo es que tales desarrollos solo quedan al alcance de expertos que tengan una amplia experiencia en la programación en PHP.

La mayoría de los usuarios tendrán, pues, que conformarse con un plugin que haga por ellos el trabajo pesado. Afortunadamente, existen abundantes recursos, como los plugins Advanced Custom Fields, Custom Field Suite, Custom Field Template, Custom Fields, Custom Metadata Manager, Easy Custom Fields, Just Custom Fields, Magic Fields y Magic Fields 2, More Fields, Simple Fields, Verve Meta Boxes. Ahora bien, debemos advertir que las extensiones más potentes de la lista son difíciles de utilizar, o adolecen de diversos bugs que las hacen poco aconsejables. Tras numerosas pruebas, yo me decidí en primera instancia por el plugin More Fields, aunque con el sitio web ya construido tuve que descartarlo porque al editar los campos personalizados perdí, de forma inexplicable, las configuraciones que tanto me había costado desarrollar.

En busca de un recambio, y tras una nueva serie de experimentos, opté por el plugin Advanced Custom Fields, que tiene dos versiones, una gratuita y otra de pago, esta última con funcionalidades adicionales. Los motivos que me llevaron a utilizar la versión gratuita (más que suficiente para la mayoría de las necesidades) son, en primer lugar, que el plugin se integra perfectamente con los tipos de contenido personalizados y con el editor de WordPress (véanse las opciones que aparecen en la parte inferior de la figura 4, correspondientes al grupo de campos personalizados que asocié al tipo de contenido “libros”); en segundo lugar, que la extensión permite definir una gran variedad de campos (texto, área de texto, texto WYSIWYG, imagen, subida de archivos, selección única o múltiple, campos lógicos, enlaces, selector de colores, etc.); por último, el plugin está muy bien documentado y ofrece un espléndido sistema de soporte. No está enteramente libre de bugs (por ejemplo, éste), pero la comunidad de usuarios los tiene identificados y, lo que es mejor, contribuye positivamente a solucionarlos.

Figura 4 - Gestión de campos personalizados con el plugin Advanced Custom Fields

En mi sitio de comentarios y reseñas de libros, he definido los siguientes campos:

• Campos “Resumen del argumento”, “Ficha editorial” e “Información complementaria”. Los tres corresponden al tipo “Wysiwyg Editor”, lo cual supone en la práctica otras tres instancias adicionales del editor visual de WordPress. El plugin Advanced Custom Field tiene la ventaja de que cuando se utiliza este tipo de campo, es posible conmutar en cualquier momento entre el editor visual y el editor HTML. Además, permite decidir si se utiliza o no la barra de iconos completa del editor y si se quieren mostrar los botones de subida de ficheros. En mi caso, la primera opción está definida en “Full” y la segunda en “No”, pues no me interesa que los alumnos que van a rellenar los campos adicionales suban ficheros desde las correspondientes instancias del editor. También es posible añadir a cada campo un completo juego de instrucciones. Todas estas funcionalidades pueden advertirse en la figura 5.
• Un campo de texto denominado “Catalogación del libro”, que admite el formato HTML, y que está destinado al código de catalogación de la Clasificación Decimal Universal (figura 6). Advierto que este campo es, en la práctica, redundante con respecto a la taxonomía “Literaturas nacionales”, pero lo he añadido para experimentar con los tipos de campos.
• Un campo de menú desplegable de opciones o “select”, denominado “Ubicación”. Este tipo de campos es muy útil cuando una sección del contenido debe rellenarse con arreglo a un juego limitado de opciones, como es el caso que puede observarse en la figura 7, que ilustra la situación de un libro de un centro educativo, que puede localizarse en cuatro ubicaciones diferentes: la Biblioteca, la Sala de Profesores, el Departamento de Lengua y una cuarta opción, que a falta de otra denominación mejor he etiquetado como “Propiedad personal”, para aquellos libros que no están inventariados en el centro, sino que son propiedad de los alumnos o sus profesores.

Figura 5 - Edición de un campo personalizado de tipo Wysiwyg Editor

Figura 6- Edición de un campo personalizado de tipo Texto

Figura 7 - Edición de un campo personalizado de tipo Select

El resultado de la combinación que he puesto en práctica con el tipo de contenido “libros”, sus tres taxonomías asociadas y los cinco campos personalizados es un editor simplificado y adaptado a la particular naturaleza del propósito que orienta la elaboración del sitio web. Dicho editor cuenta con las instrucciones necesarias para ser utilizado por usuarios que tengan poca o nula experiencia previa con WordPress (véase la captura del editor incluida en la figura 2 del artículo Sitios educativos fechos al taxonómico modo 1). Basta pues, con los plugins Custom Post Types UI y Advanced Custom Fields para desarrollar un sitio web totalmente personalizado y para comenzar a escribir en él. Ahora bien, su presentación en sociedad requiere de un minucioso trabajo de retoque del tema y de los ficheros de plantilla, tema sobre el cual tratará la próxima entrega de esta serie. Permanezcan atentos a sus pantallas, por favor.

Addenda del 3 de diciembre de 2011

A partir de la versión 3.0.2 del plugin Advanced Custom Fields, publicada el 28 de noviembre, se puede exportar el contenido de los campos personalizados a un fichero en formato XML, que posteriormente se puede importar desde otro blog. Para efectuar la operación de exportación, basta con acudir al menú Herramientas > Exportar y selecionar la opción Advanced Custom Fields.

Addenda del 10 de diciembre de 2011

Acabo de enterarme de la muy reciente publicación (el día 6 de diciembre) de un plugin que parece llamado a revolucionar el trabajo con los tipos de contenido, las taxonomías y los campos personalizados. Se llama Types, es gratuito, y permite definir y gestionar conjuntamente estos tres elementos, mediante un interfaz de usuario que, a juzgar por lo que he podido ver en el sitio web dedicado a esta extensión (por cierto, con una excelente documentación), parece muy fácil de utilizar y de gran potencia. En todo caso, conviene tener en cuenta que el máximo aprovechamiento de Types se obtiene en combinación con otro plugin para la creación de plantillas y listados, denominado Views, que es de pago. Habrá que estar muy atento a esta pareja, que promete grandes satisfacciones.

Entradas relacionadas

1. Sitios educativos fechos al taxonómico modo 3
2. Sitios educativos fechos al taxonómico modo 4
3. Sitios educativos fechos al taxonómico modo 5
4. Sitios educativos fechos al taxonómico modo 1
5. Formulario para construir tipos de contenido personalizados

Interfaz de edición del tipo de contenido "Libros"

El título de esta entrada, con su deliberada imitación del que encabezaba la famosa obra del Marqués de Santillana tiene detrás una breve historia que merece la pena recordar. Hace algo así como año y medio me embarqué en un proyecto de antología textual, basada en taxonomías y tipos de contenido personalizados, que no pasó de una fase de esbozo, por dos motivos complementarios: las limitaciones que por aquel entonces tenía WordPress para la gestión de dichos elementos (en aquel momento la versión 2.9 no incorporaba muchas de las funciones que ahora están plenamente disponibles), y mis propias insuficiencias en ese y otros ámbitos.

Mucho ha avanzado WordPress desde mayo de 2010, especialmente a partir de la aparición de la versión 3.0 (yo también he dado unos cuantos pasitos hacia adelante y alguno hacia atrás, como puede verse en la relación de artículos que he escrito sobre las taxonomías y los tipos de contenido personalizados), lo cual me permite franquear con cierta garantías los límites que en su momento me frenaron. En consecuencia, me he empeñado en una aventura parecida a la anterior, aunque bastante más modesta, pues se limita a montar un sitio web para demostrar las posibilidades que las taxonomías y los tipos de contenidos personalizados tienen para la creación de sitios web especializados en el ámbito educativo. El objetivo final que me he marcado ha sido la creación de un entorno web de contenidos y propósitos específicos, con un interfaz de edición adaptado al trabajo de profesores y de alumnos, capaz por sí mismo de orientar a un usuario con poco o ningún conocimiento previo del funcionamiento de la aplicación con la que está elaborado.

El trabajo que he realizado durante las dos últimas semanas ha quedado plasmado en el sitio web Comentarios y reseñas de libros, cuyo núcleo consiste en un tipo de contenido personalizado denominado “libros”, que no es otra cosa que un contenedor para breves reseñas o comentarios de obras literarias. Este tipo de contenido se complementa con los siguientes elementos:

• Tres taxonomías personalizadas, es decir, tres criterios de clasificación mediante los cuales se pueden etiquetar los libros con respecto a su autor, y al género literario y literatura nacional a los que dichos libros pertenecen.
• Varios campos personalizados que complementan los comentarios de los los libros, a saber:
• Un breve resumen del argumento.
• Una ficha editorial.
• Informaciones adicionales, como enlaces a páginas web sobre la obra y el autor, referencias bibliográficas, etc.
• Información útil a efectos de catalogación, cómo el código de la CDU, la ubicación del libro, etc.

Esta estructura de contenido podría haber sido mucho más compleja y ambiciosa, pero he preferido reducirla a su mínima expresión, no solo para facilitarme a mí mismo el trabajo de elaboración del sitio, sino también para hacerla más inteligible. Por otro lado, mi propósito es que sirva de inspiración a aquellos profesores y profesoras que quieran montar sitios web especializados, con un interfaz de edición ad hoc, capaz de guiar a los alumnos cuando estos realicen las tareas que les hayan sido encomendadas.

En el esquema mental que he concebido para la utilización del sitio, las tareas que corresponden a cada uno de los usuarios son las siguientes:

1. Para el administrador del sitio, que normalmente debiera ser un profesor:

• Montar el sitio y gestionar temas y plugins, lo cual requiere conocimientos de instalación de un blog de WordPress. En próximas entregas de esta serie daré cuenta del material necesario.
• Crear, editar y organizar las entradas y páginas necesarias para proporcionar a los usuarios las instrucciones pertinentes.
• Crear los menús de navegación.

2. Para los usuarios-editores (los alumnos):

• Redactar los comentarios y reseñas de los libros que hayan leído.
• Redactar el resumen del argumento, la ficha bibliográfica y las informaciones complementarias.
• Subir la imagen de portada del libro.
• Etiquetar los comentarios mediante las taxonomías previstas.

También este esquema de reparto de tareas se puede hacer más complejo. Por ejemplo, podría haber un profesor-administrador y varios profesores-editores, y se podría asignar a los alumnos los roles de autores o colaboradores (según los casos), pero ello exigiría un trabajo minucioso de reasignación de capacidades que por su complejidad desborda el ámbito de la presente exposición.

Como una imagen vale más que mil palabras, incluyo a continuación una serie de capturas de pantalla que ilustran lo que se encontrará un usuario-editor de WordPress (por ejemplo, un alumno) al acceder al backend de este sitio (supongo que no hace falta decirlo, pero naturalmente el menú del administrador del sitio tiene muchas más opciones):

1. Un menú simplificado (figura 1), con un escritorio en el que solo están accesibles los siguientes elementos:

• El submenú correspondiente al tipo de contenido personalizado, para la creación y administración de los comentarios de libros.
• El submenú de acceso a las funciones del gestor de multimedia, ya que los usuarios-editores pueden tener necesidad de modificar las imágenes que suban al sitio (por ejemplo, las de las portadas de los libros).
• El submenú correspondiente al perfil del usuario.

Figura 1 - Menú general del sitio para un usuario editor

2. Un editor preparado para adecuarse a la naturaleza del contenido (figura 2). El editor solo muestra las cajas que corresponden al editor principal (el texto del comentario propiamente dicho), las que permiten introducir las etiquetas de las taxonomías personalizadas y las de los campos personalizados que se han creado al efecto: resumen del argumento, ficha editorial, información complementaria, código de catalogación y ubicación del libro. Como puede verse en la captura de pantalla, el interfaz de edición proporciona a los usuarios un juego de instrucciones que les permiten realizar con más eficacia las tareas asignadas.

Figura 2 - Interfaz de edición del tipo de contenido "Libros"

3. Un editor preparado para mejorar y hacer más fácil la edición de los términos o etiquetas correspondientes a las taxonomías personalizadas (figuras 3 y 4). Por defecto, WordPress no ofrece ninguna ayuda visual para añadir código HTML a la descripción de las etiquetas, con lo cual es necesario utilizar un plugin que haga accesible el editor visual. En las siguientes entregas de esta serie daré más detalles al respecto.

Figura 3 - Editor visual para la edición de etiquetas

Figura 4 - Edición visual de una etiqueta de la taxonomía "Géneros literarios"

Con la ayuda de los ficheros de plantilla previamente diseñados (de ellos hablaremos por extenso en próximos artículos), WordPress se encarga de presentar el contenido del sitio de una forma perfectamente organizada, como puede verse en estos enlaces, correspondientes a los cuatro ítems principales del menú del sitio:

• Menú de la página principal, en la que se hace una descripción del sitio web. A diferencia de lo que ocurre en un blog convencional, cuya información se dispone de forma cronológica, este sitio ha sido organizado para que muestre en su portada una página fija. De esta página depende otra página estática en la que se enumeran todos los materiales (temas, plugins, documentación) que se han utilizado para montar el sitio.
• Menú de instrucciones, que corresponde a una categoría de WordPress, formada a su vez por dos artículos que dan las explicaciones necesarias para que los usuarios-editores (los alumnos) aborden la escritura de los comentarios y el etiquetado de los artículos. Naturalmente, es posible que en un contexto educativo real estas instrucciones debieran ampliarse, modificarse, etc.
• Menú correspondiente al tipo de contenido libros. Es una página de archivo o índice de WordPress, de la que dependen los diez comentarios, cuyo contenido es puramente demostrativo (para los interesados, se ha creado mediante un generador automático de textos lorem ipsum). En cada uno de los comentarios, la disposición visual permite distinguir sus elementos constitutivos: el núcleo de la reseña (con fondo blanco), el resumen del argumento (fondo amarillo), la ficha editorial (fondo rojo), las informaciones complementarias (fondo azul) y las etiquetas descriptivas (fondo verde). A título de ejemplo, véanse los comentarios de El vigilante del fiordo y Los mares grises sueñan con mi muerte.
• Menú de páginas de archivo o índice de los distintos criterios de clasificación de las obras comentadas: autores, géneros literarios y literaturas nacionales. Cada una de las páginas correspondientes a un término de clasificación (véanse, por ejemplo, novela de ciencia ficción, literatura española y George R.R. Martin), están encabezadas por la descripción de la etiqueta, lo cual resulta muy útil a efectos educativos, pues permite crear algo así como un índice de conceptos literarios. El menú incluye una página final en la que se agrupan todos los términos o etiquetas de clasificación.

El sitio ofrece una estructura de navegación sistemática y coherente, que se puede crear con muy poco esfuerzo gracias a la gran flexibilidad que proporcionan los menús de WordPress. Para facilitar la navegación y reducir al mínimo las posibilidades de que un visitante se pierda entre sus páginas, el menú de navegación de la cabecera se repite en la barra lateral derecha de todas las páginas del sitio.

Dada la complejidad inherente a la clasificación de los libros, se ha añadido a la barra lateral un widget que permite realizar búsquedas sobre los criterios de clasificación. Las búsquedas pueden realizarse por un único criterio de clasificación, o por una combinación de dos o más criterios.

En próximas entregas de esta serie examinaremos el proceso seguido para crear las taxonomías y los tipos de contenido personalizados. También daremos cuenta de los plugins utilizados, y de las modificaciones efectuadas sobre los ficheros de plantilla. Permanezcan atentos a sus pantallas.

Entradas relacionadas

1. Sitios educativos fechos al taxonómico modo 4
2. Sitios educativos fechos al taxonómico modo 2
3. Sitios educativos fechos al taxonómico modo 5
4. Sitios educativos fechos al taxonómico modo 3
5. Algunas capturas antológicas

El plugin WP-Filebase, en un entorno multiusuario

En el artículo anterior de esta serie, glosé las posibilidades que el plugin WP-Filebase Download Manager ofrece como herramienta integral para subir archivos al blog y gestionar sus descargas. Pues bien, me interesa ahora profundizar en el análisis de las capacidades de esta extensión bajo dos circunstancias que hacen muy aconsejable su uso, esto es, en sitios web con múltiples usuarios, por una parte, y en entornos multisitio o multiblog, por otra. En este artículo analizaré cómo se comporta la extensión en una configuración de múltiples usuarios, y en una próxima entrega de la serie daré cuenta de su funcionamiento en una instalación multisitio de WordPress.

A diferencia de otros plugins de gestión de descargas (como por ejemplo el WordPress Download Monitor), WP-Filebase no define ninguna capacidad nueva, y por tanto asume como propia la estructura de roles y capacidades de WordPress, en virtud de la cual los usuarios administradores, editores y autores tienen la capacidad de subir ficheros (upload_files). Por tanto, su funcionamiento en entornos multiusuario sigue los patrones de dicha aplicación a la hora de definir qué usuarios tienen la capacidad de llevar a cabo las acciones que se detallan a continuación. Conviene aclarar que, aunque WordPress no distingue entre frontend y backend a la hora de establecer la mayor parte de sus capacidades, yo sí lo he hecho, con el único propósito de conseguir una mayor claridad expositiva:

1. Configurar el plugin desde el backend: solo los administradores pueden modificar las opciones de la extensión.
2. Subir ficheros desde el frontend o desde el backend: estas acciones pueden ser realizadas por los administradores, editores y autores.
3. Gestionar ficheros desde el backend: tienen capacidad para llevar a cabo esta tarea los administradores, editores y autores.
4. Crear categorías de ficheros desde el frontend: tanto los administradores como los editores y autores tienen tal capacidad.
5. Crear y gestionar categorías de ficheros desde el backend: es una tarea solo disponible para administradores y editores.
6. Insertar listados de fichero desde el backend, mediante el editor del blog: esta acción puede realizarla cualquier usuario registrado con derecho a crear contenido, esto es, los administradores, editores, autores y colaboradores.
7. Descargar ficheros desde el frontend: en la configuración por defecto del plugin, esta acción puede llevarla a cabo cualquier cualquier visitante del sitio. No obstante, es posible configurar las categorías de ficheros, y también los ficheros individuales, para restringir su acceso a un rol determinado. Desde la versión 0.2.9.4 también es posible definir los ficheros como privados, situación en la que solo puede acceder a un fichero el usuario que lo ha subido y el administrador del sitio.

Esta relación entre las tareas que se pueden llevar a cabo con el plugin WP-Filebase y los roles de usuario de WordPress es sin duda muy potente, y en general está bien estructurada, pero no carece de ciertos puntos discutibles, a saber:

• Que los administradores y editores puedan editar y borrar los ficheros subidos por otros usuarios es coherente con la organización general de WordPress. Ahora bien, el hecho de que los autores también dispongan de esta capacidad constituye una circunstancia que, si no ha sido advertida por el administrador, puede ser causa de un funcionamiento no deseado del sitio web, ya que un usuario (por ejemplo, un autor) puede borrar ficheros que hayan sido subidos por usuarios que tienen más capacidades (por ejemplo, editores o administradores).
• Que los autores disfruten de la capacidad de crear categorías de ficheros desde el frontend parece una innovación del plugin con respecto a la configuración por defecto de WordPress, que solo permite crear y gestionar categorías de entradas y enlaces (en esto consiste la capacidad manage_categories) a los administradores y los editores. No obstante, debe advertirse que, aunque un autor pueda crear categorías desde el frontend, carece de cualquier control para ajustar sus características y comportamiento desde el backend. En todo caso, creo que es una buena idea que un autor pueda crear categorías de ficheros desde el frontend, pues ello dota al sistema de mayor flexibilidad, siempre que dicha circunstancia sea bien conocida por el administrador del sitio web.
• El plugin dispone de la capacidad de restringir los ficheros y las categorías de ficheros a uno o varios roles de usuarios, lo cual es muy útil para prevenir que un usuario de bajo nivel puede borrar o modificar ficheros y categorías creadas por un usuario de nivel de usuario superior. La desventaja de esta función es que, si se configura una categoría o un fichero para que solo sea accesible por determinados roles de usuario, tal característica afecta tanto al backend como al frontend, lo cual impide que una categoría de ficheros, o un fichero concreto, sean visibles y descargables desde el sitio web por parte de usuarios con roles diferentes. Por otra, parte, esta capacidad puede volverse en contra de los usuarios; por ejemplo, se da la paradoja de que un autor puede acceder desde el backend a un fichero que no está restringido para ningún rol y modificarlo de forma que solo esté disponible para otros roles que el suyo, con lo que lo convierte en inaccesible para sí mismo.
• La posibilidad de convertir los ficheros en privados solo puede activarse para todo el sitio web; es decir, no cabe decidir a qué ficheros se aplica. No hace falta insistir en el hecho de que esta característica puede ser muy interesante en ciertas situaciones, pero también puede volverse en contra de los usuarios si no se maneja con sentido común.

El plugin WP-Filebase no proporciona por sí mismo ningún control sobre la forma en que se presentan a los usuarios las acciones que estos pueden ejecutar desde el frontend. Es decir, solo con el plugin WP-Filebase no se puede escoger que, por ejemplo, los widgets para subir ficheros, crear categorías y generar listados de ficheros y de categorías solo aparezcan en determinadas páginas, o para determinados usuarios y no para otros. No obstante, estas limitaciones se pueden subsanar con bastante facilidad mediante diversos plugins, a saber:

• Members, para limitar el acceso a la página solo a aquellos roles que el administrador haya decidido y proporcionar un mensaje de advertencia en caso de que no se dé tal circunstancia.
• Widget Logic, para obligar a que los widgets sean visibles solo en las condiciones deseadas.

He llevado a cabo buen número de pruebas con los tres plugins, y no he encontrado ninguna incompatibilidad o limitación que impida poner en práctica cualquier combinación concebible entre las funciones de las tres extensiones. Por ejemplo, en el blog al que corresponden las capturas de pantalla de este artículo, elaborado con el tema Graphene, he publicado los widgets de subida de ficheros y creación de categorías de ficheros bajo las siguientes condiciones: en primer lugar, ambos widgets solo deben aparecer en la página denominada “Subida de ficheros”; en segundo lugar, los dos widgets solo deben aparecer cuando el usuario que se conecta al blog sea un administrador o un editor. En caso de que no concurran ambas condiciones, aparecerá una advertencia de error.

Pues bien, para conseguir este efecto, he utilizado los plugins Widget Logic y Members, del siguiente modo:

• Mediante el plugin Members he restringido la visibilidad de la citada página a los administradores y editores. De este modo, solo los usuarios que tengan estos roles podrán subir ficheros y añadir categorías de ficheros, mientras que los demás usuarios y los visitantes del blog verán un mensaje de advertencia: "Esta página solo está disponible para usuarios administradores o editores". La configuración de las opciones del plugin Members para la página “Subida de ficheros” puede observarse en la figura 1.
• Con el plugin Widget Logic he conseguido que los widgets de subida de ficheros y creación de categorías de ficheros sean visibles en la citada página y solo para usuarios administradores y editores, para lo cual he utilizado las etiquetas condicionales is_page y current_user_can. La primera está asociada al identificador del artículo (el 1034); la segunda, a la capacidad edit_other_posts, que es exclusiva de los dos roles mencionados. Las dos condiciones están unidas mediante el operador lógico “&&”, lo cual significa que los dos widgets solo se mostrarán si se dan, a la vez, ambas condiciones (figura 2).


Figura 1 - Configuración del plugin Members para la página "Subida de ficheros"





Figura 2 - Condiciones para los widgets, declaradas mediante el plugin Widget Logic

Las figuras 3-5 muestran el efecto simultáneo de ambos plugins, en tres circunstancias diferentes:

• Cuando el usuario conectado es el administrador, tiene acceso a los widgets (figura 3).
• Cuando se trata de un autor, no lo tiene (figura 4).
• Cuando es un simple visitante del blog, tampoco se le concede dicha capacidad (figura 5).

Como puede verse en estas capturas de pantalla, los demás widgets del blog aparecen siempre, puesto que no se les ha aplicado ninguna restricción.

Figura 3 - La página de subida de ficheros, para el usuario administrador

Figura 4 - Página de subida de ficheros, para un usuario autor

Figura 5 - Página de subida de ficheros, para un visitante del sitio

Una última observación: la zona de widgets que puede advertirse en la figura 2, denominada “Graphene After Post Content”, es una característica muy interesante del tema Graphene, que permite activar áreas de widgets asociadas a determinados lugares del blog, mediante los denominados action hooks. Yo he utilizado el action hook denominado “graphene_after_post_content”, asociado al fichero loop.php del tema, con el cual es posible incluir widgets tras el contenido de un artículo, donde hay mucho más espacio que en la barra lateral.

Queda claro, pues, que con el plugin WP-Filebase, en combinación con un tema que sea suficientemente flexible, y aliado con otras extensiones que permitan una gestión más afinada de usuarios y permisos que la que WordPress proporciona por sí mismo, ofrece enormes posibilidades para la gestión de la subida y la descarga de ficheros. Animo a los lectores y lectoras de este blog a probarlo, y les brindo mi ayuda y colaboración, si la necesitan.

Entradas relacionadas

1. Gestores de descarga para WordPress 3: WP-Filebase, una solución integrada
2. Gestores de descargas para WordPress
3. Gestores de descargas para WordPress 2. Plugins de subida de ficheros
4. Más utilidades para exportar un blog de WordPress
5. Algo más sobre los plugins de edición para WordPress

Tigre en el Parque Nacional Kanha (fuente: www.flickr.com)

En La Bitácora del Tigre raramente utilizo fotografías que no haya tomado yo mismo. Por tanto, en la inmensa mayoría de las ocasiones no tengo la necesidad de citar la fuente. Sin embargo, en otros blogs en los que participo, la cita de la URL original y su autor constituye una obligación, casi siempre algo enojosa, porque WordPress no proporciona, de forma nativa, ninguna manera de incorporar dicha referencia, por ejemplo en el pie de la fotografía, que suele ser el lugar idóneo para hacerlo.

Echaba en falta esta funcionalidad hasta esta misma tarde, cuando me he encontrado con un artículo de WordPress Tavern (al que he llegado desde WordPress Planet y que luego he vuelto a ver citado por Ayuda WordPress), en el que se da cuenta de diversas técnicas para conseguir el objetivo de que en el pie de una imagen se pueda incluir, de forma rápida y fácilmente sistematizable, el enlace a su URL de publicación original.

De los recursos que ambos sitios proponen, he escogido el que WordPress Tavern considera el mejor, esto es, añadir al fichero functions.php del tema del blog el código propuesto por Konstruktors.com. Dicho y hecho: tras unos someros ajustes en mi tema-hijo basado en Hybrid (apenas he hecho otra cosa que traducir algunas cadenas de texto al español) y unas cuantas pruebas, la nueva función ya está incorporada a este blog. En fechas próximas la añadiré a los otros sitios donde suelo utilizar imágenes ajenas.

Nada mejor para demostrar esta nueva funcionalidad que traer hasta esta página, una vez más, el emblema del blog, a partir de una estupenda fotografía de Ashish Gautamm, que he encontrado en Flickr. Aprovecho la ocasión para recordar algunos de mis anteriores experimentos gráficos con el solemne y hermosísimo felino rayano: Fotos de Flickr con licencia CC, YubNub y tigres siberianos y Tigres con FlickrCC.

Tigre en el Parque Nacional Kanha (fuente: www.flickr.com)

Entradas relacionadas

1. Fotos de Flickr con licencia CC, YubNub y tigres siberianos
2. Sigo subiendo fotos a Flickr
3. Tigres con FlickrCC
4. Otro Slideshow de Flickr
5. WP Tiger Administration para el Tigre