Blog GAVAB

El objetivo final de este punto, era imitar el comportamiento de la gestión de archivos que tiene WordPress.  En este CMS esta integrado la gestión de archivos, con la edición de contenido, y esta orientado a utilizar esos archivos, que generalmente serán multimedia, en la creación de contenido.

Como en Drupal esto por defecto no existe, hay que buscar módulos que puedan añadir esa funcionalidad. En primer lugar, el módulo update, que viene por defecto en el core de Drupal y el cual hay que activar, nos sirve como primer paso para subir archivos. Pero nosotros aspiramos a algo más que a la mera subida de archivos al servidor.

Para ello he utilizado el módulo WebFM ( Web File Manager )  el cual está pensado como un gestor de archivos, donde se pueden subir, descargar, y modificar archivos. Bastante completo y bastante configurable. Pero no es perfecto, de momento lo que hecho en falta es la relación entre los archivos que se pueden adjuntar a un contenido, y la gestion de nuestro WebFM, ya que son independientes. Los archivos que se suban cuando se crea el contenido, sólo son accesibles desde la página que muestra el contenido. Por otro lado, desde la pantalla de “Exploración web” que gracias al nuevo módulo tiene nuestro CMS, se visualiza mediante FLASH, el árbol de ficheros que hemos especificado en la configuración. Y en esta misma pantalla se pueden subir, descargar, borrar, etc archivos.

Este árbol de ficheros que muestra nuestro Explorador web, tiene que ser una carpeta incluida dentro de la ruta donde Drupal almacena los archivos que se han adjuntado. Por lo tanto, nunca van a ser visibles los archivos adjuntados a nuestro Explorador web.

Este defecto puede empañar todas las demás ventajas que tiene nuestro nuevo módulo, que son muchas. Habrá que consultarlo y decidirlo. De momento, doy la tarea como zanjada.

Después de 2 semanas dedicandome en exclusiva a las dos asignaturas que me quedaban, vuelvo a retomar el proyecto. Espero tener la fuerza de voluntad y el tiempo para terminarlo. Lo primero que he hecho para subirme la moral ha sido una tonteria. He cambiado el favicon.ico. Para ello, he realizado lo siguiente.

- En esta web he creado un favicon. Como debe tener unas medidas y un tamaño adecuado, es mucho más rápido que fabricartelo tu. http://tools.dynamicdrive.com/favicon/

- Después he ido a la página de configuración de mi Theme. Construcción del sitio -> Temas ->Configuración. Dentro hay un apartado para el favicon.ico. Donde puedes habilitar el que tiene por defecto, indicarle una ruta donde se encuentra la imagen que quieres utilizar, o subir tu una imagen para utilizarla.

- Y ya está. Me imagino que si se quiere utilizar la misma imagen para varios sitios, habrá que mantener activa la casilla de utilización  del favicon.ico por defecto, y sustituir el .ico dentro de nuestra instalación drupal, por el nuevo que queramos.

Tras hacer varias pruebas ayer, con los módulos necesarios para tener un sistema en drupal de gestión de archivos, me acojoné bastante ya uno de los módulos hizo que el sitio Drupal se quedará inutil, y saliera un error cada vez que se queria realizar una acción. Al quitar el módulo a pelo, salian warning hasta en la página principal.

Asi que hoy me he metido un poco con las copias de seguridad. Hacer una copia de seguridad en WordPress es bastante fácil, el propio Core de WordPress te da las herramientas necesarias para exportar/importar  dentro de su menú. “Herramientas”.

Drupal no tiene esta utilidad en su Core, así que hay que añadirsela mediante un módulo. El módulo que recomienda más gente es Backup and Migrate. El módulo es bastante sencillo de utilizar y muy configurable, además funciona bién. Lo que no he probado ha sido restaurar mi sitio desde una copia de seguridad, lo tendré que probar en un sitio de pruebas, no me atrevo con este.

Lo que tampoco he conseguido con un simple módulo, es automatizar el proceso. El módulo no realiza la copia de respaldo automáticamente, ni siquiera creo que se pueda incluir en las tareas del cron. Para realizar esto, una solución es realizar un script en tu servidor: (Como este)

############################
### Backup base de datos ###
############################
# /bin/bash
date=`date -I`
mysqldump --opt -u user --password="secret" --add-drop-table bd_blog > /Escritorio/backup_web/bkpDrupal_xxx_`date +%Y-%m-%d_%H-%M`.sql
#

Y añadir la ejecución de este script en el crontab de nuestro servidor. Todo esto suponiendo que este script funciona.

Lo primero que he hecho tras documentarme, es ampliar la memoria reservada de nuestro PHP para subir archivos. Originalmente es de 2M, pero modificando el archivo:

/etc/php5/apache2/php.ini

Hay una linea dedicada a definir el tamaño máximo de los archivos que se suben:

upload_max_size = 8M

Asi que de momento he intentado aumentadar la capacidad a 8M, supongo que hará falta que se reinicie el servidor, así que todavía no se si ha dado resultado.

Lo siguiente, será investigar el módulo Upload, que es un módulo opcional del core de Drupal, y que está destinado a subir archivos para adjuntarlos a los contenidos. En principio no sería suficiente, ya que lo que entiendo que necesitamos, es más bién un sistema de gestión de archivos, es decir, que se puedan subir, pero que permanezcan visibles y accesibles para poder utilizarlos.

El problema de que no aparecen todos los tipos de edición en el resultado final, se debe a que no tenía marcada la opción “Full HTML” que aparece en el menú siempre que queires insertar un contenido.

Para afinar un poco más el aspecto, me he instalado el módulo WYSIWYG, este módulo funciona a modo de pasarela, entre Drupal y los demás pseudoeditores. Crea un intergaz más amigable a la hora de editar, y permite tener instalado varios pseudoeditores.

Hay que instalar el módulo WYSIGWYG, después el mismo te va dano instrucciones sobre lo que tienes que hacer para instalar el editor. Te aparece una lista con todos los editores que soporta, la página web donde descargarlo, y la ruta dentro de drupal donde guardar los archivos.

En mi caso, me he bajado el ckeditor y el TinyMCE. Ambos los he guardado en la ruta

sites/all/libraries/xxxxxxx

Una vez tienes instalado algun editor, puedes seleccionar que editor utilizar para los direntes modos escritura (Filtered, Full, o text plain) .

En mi caso, he utilizado el TinyMCE, ya que las opciones de configuración me han parecido las más sencillas, y son igual de potentes que el de CKeditor. En estás opciones de configuración, puedes indicar uno por uno, los elementos que quieres que se muestren en el editor.

Lo que no he visto desde que he instalado el módulo WYSIWYG, es una opción para personalizar el editor, dependiendo del rol del usuario. De momento doy por zanjado el tema del editor.

Uno de los requisitos de nuestro Drupal es que tuviera un editor de texto y html amigable, tal como viene por defecto en wordpress y en joomla, del tipo WYSIWYG.

Asi que después de repasar los foros y ver la documentación, me he decidido por CKEditor. Su instalación comprende dos pasos.

- Descargar el módulo desde el repositorio de Drupal. (http://drupal.org/project/ckeditor)

- Descargar el contendio desde la página web del autor. ( http://ckeditor.com/download )

El contenido de la página del autor, se guarda en una carpeta llamada “ckeditor” dentro de la carpeta del módulo, y se sigue el proceso normal de instalación de cualquier módulo en drupal.

La instalación ha sido facil, el funcionamiento del editor me genera dudas, parece que tiene todas las funcionalidades normales, pero me parece que es un poco cutre. Un fallo es que al desplegar los tipos predefinidos de fuente (Encabezado, titulo, etc…)  no aparece scroll para moverte por ellos, es necesario moverte con el cursor para poder verlos todos.

Las opciones de configuración no son sencilla. Se puede configurar diferentes tipos de escritorios para diferentes tipos de usuarios, pero la forma de quitar/poner elementos es compleja.

El siguiente paso es automatizar de alguna forma el proceso de la creación de etiquetas. Queremos un mecanismo dependiendo del texto del contenido, le asocie unas etiquetas determinadas.

El módulo autotager nos puede servir. Para ello, primero tenemos que tener activados otros tres módulos (Taxonomy, JQuery UI y Lowername). La instalación de JQuery es un poco más compleja que la de un módulo normal, ya que consta de dos pasos. Primero te descargas el módulo del repositorio de la página de Drupal, y se guarda en la carpeta módules del sitio. Además, necesita otro contenido, que se descarga de la página del fabricante, y que se tiene que guardar dentro del módulo, en una nueva carpeta llamada  “jquery.ui”.

En la documentación de auto tagger se pueden leer los siguientes requisitos para que el módulo cumpla su función:

• El vocabularió fué creado por el módulo taxonomy
• El vocabulario tiene habilitado “Multiple select”
• El vocabulario no está marcado como “Requiered”
• El vocabulario está asociado con el tipo de contenido que estás editando
• Autotagger no ha sido deshabilitado para ese voabulario.

Una vez instalado se puede configurar dos casillas en autotagger

-No user input required before auto tagging. (If checked, no user input will be required to automatically tag a node)

-Tag nodes with only terms at the very tip of a taxonomy (i.e. Terms which are not the parent of any other term)

De las tres instrucciones posibles, me he decantado por:

si veo que funciona, aumentaré los intervalos de actualización.

PD. Veo que no funciona, en cuanto vaya al laboratorio hago más pruebas.

Para una correcta actualización de los hilos sindicados, es necesario una configuración automática del cron. Drupal te redirecciona a  http://drupal.org/cron, para que aprendas como.

En este amplio artículo te explican como ejecutar las tareas del cron, que en el fondo es ejecutar el archivo cron.php alojado en tu sitio. Si eres el propietario del servidor, ejecutando la instrucción:

crontab -e

y después añadiendo una de estas lineas:

Una vez conseguido crear el vocabulario, al crear contenido se puede introducir tags. Si hay varios vocabularios asociados a un tipo de contenido, aparecerán dos apartados para introducir los tags correspondientes a cada uno de ellos.

Lo siguiente es configurar el módulo Tagadelic. Este módulo realiza la recopilación de los tags y  se pueden definir los siguientes parámetros:

• Determina el orden de las etiquetas en la página de etiquetado libre. (por peso, por título, aleatorio)
• La cantidad de tag en una página (Cuando se muestren en un bloque, habrá que especificarlo dentro de la configuración de bloque)
• Número de niveles. (Diferenciando según la popularidad del término)

Con el Tagadelic configurado, se puede mostrar en un bloque (Admistrar->Construcción del sitio->Bloques) una  nube de tags estática.

Además, si se instala el módulo Cumulus, basandose en Tagadelic, se  podrá construir una nube en 3D basada en Flash. La configuración de la nube de tags se realiza desde la configuración del bloque.

• Título del bloque
• ID de los vocabularios incluidos ( Con esto hay que tener cuidado, ya que no sabemos a priori cual es el ID de un vocabulario, los ID se van asinando automáticamente y de forma creciente desde 1). Se pueden ingresar varios vocabularios.
• La cantidad de tamaños que se pueden utilizar.
• La cantidad de tags que se van a mostrar.
• Altura y anchura de la nube.
• Color de fondo.
• Transparencia del fondo.
• Color de la fuente de los tags (2 colores, para los más importantes y para los demás).
• Velocidad de rotación.
• Distribución uniforme de los tags.
• El tamaño de la fuente
• La diferencia de tamaño entre os más importantes y los demás.