Cambiar tamaño de las imágenes en una tarea

Desde opencms podemos crear una tarea con la clase org.opencms.scheduler.jobs.CmsCreateImageSizeJob podemos cambiar el tamaño de las imágenes que han subido los usuarios.
La tarea la va a reescalar respetando las proporciones de la imagen, por lo que es muy bueno para evitar imagenes muy grandes subidas por los usuarios.

Antes debemos configurar en WEB-IF/config/opencms-vfs.xml

<loader class="org.opencms.loader.CmsImageLoader">
<param name="image.scaling.enabled">true</param>
<param name="image.scaling.downscale">w:800,h:600,q:97,c:transparent</param>
></loader>

 

El parámetro image.scaling.downscale tiene:

  • w: El ancho de la imagen
  • h: la altura de la imagen
  • q:la callidad de la imagen en porcentaje
  • t: grado de transparencia de la imagen
  • c: color de fondo en hexadecial como c0c0c0

Otros parámetros que podemos configurar son

  • image.folder
  • image.scaling.maxblursize
  • image.scaling.maxsize

La tarea la creamos como el resto:
tareaopencms-cmscreateimagesizejob

Detectar en opencms cuando en un containerpage estoy cargando un detail

La situación que se describe a continuación está probada para las versiones 8 y 9 del opencms.

Recientemente hemos tenido un problema que consistía en extraer propiedades de un CmsResource a partir de la uri, para ello se puede insertar  sin problema en el template un pequeño script el cual partiendo de la uri desde la que es invocado obtenga un objeto CmsResource y a partir de este su CmsUUID etc… esto puede conseguirse de forma sencilla como sigue:

Leer más

Cachear un 302 con Squid

Aunque sea un poco saltarse el estándar por la torera, os vamos a plantear una solución para que el Squid guarde en su caché los 302. En el caso de OpenCms con sitios exportados, con un squid+Apache+Tomcat, la redirección 302 del sitio por ejemplo de www.uva.es a www.uva.es/export/sites/uva/index.html supone un a carga extra al tomcat ya que llega al Squid (que no o cachea por defecto), llega al apache y finalmente llega al Tomcat. Con un número muy grande de accesos esto supone ua carga extra al Tomcat que podemos evitar.

Lo primero, documentarnos. En la página http://wiki.squid-cache.org/SquidFaq/InnerWorkings, en la sección «How come some objects do not get cached?» podemos leer dos cosas interesantes. que por defecto no cachea los 30x y que para cachear el 302 «A 302 Moved Temporarily response is cachable ONLY if the response also includes an Expires header.», es decir, tenemos que tener una respuesta del servidor del 302 con el dato «Expires» en la cabecera, y aunque no lo dice, debe ser una fecha futura, ya que si ponemos una fecha pasada no lo va a cachear tampoco.

Pues vamos a ponernos a trastear ya. ¿Donde? Tenemos tres opciones, tocar el código de OpenCms, tocar el Tomcat o tocar el apache. En nuestro caso la más sencilla es el apache con su documentación, pero para el Tomcat también en muy sencilla y viene en la documentación buscando «Expires» , y la que no hemos mirado es el código de OpenCms.

En el caso de apache, podemos añadir un htaccess o directamente en la definición del virtualhost añadir estas líneas para que todos los contenidos digan que expiran en 5 minutos.
[code]
ExpiresActive On
ExpiresDefault «access plus 5 minutes»
[/code]

A partir de ese momento los 302 empezarán a ser cacheados por el Squid

[code]

1434098144.302      0 188.85.71.120 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098144.541      0 157.88.20.208 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098160.693      0 157.88.240.224 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098163.364      0 157.88.150.22 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain

[/code]

y desde los navegadores veremos también que el Squid nos devuelve el X-Cache: HIT como podéis ver en la imagen

Squid cacheando 302

 

A continuación podemos afinar más el dato Expires diferenciando por tipo por ejemplo, pero tened en cuenta que ya está el Squid de intermediario, y no afecta mucho al cliente:

[code]

ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 year"
[/code]

y podemos meter condiciones para que sólo lo haga los 302, pero no lo vemos necesario.

Como siempre, esperamos que os ayude!!

Número 1 en accesibilidad [actualización]

Captura de pantalla 2014-05-26 a la(s) 12.24.02

Según un estudio de accesibilidad de todas las webs universitarias realizado por la Universidad de Granada, la web de la Universidad de Valladolid es la número uno en accesibilidad con una puntuación global de 0,949 seguida por la web de la Universidad de Almeria con 0,915.

Desde aquí seguimos trabajando para mejorar nuestra web dotandola de nuevos servicios y mejorando, no solo la capacidad, sino tambien desarrollando nuevas herramientas que ayuden al entorno universitario.

Damos las gracias a todos los que nos han ayudado y apoyado en su realización.

Link: UGR

[Actualización]: Aquí tenéis un enlace al Dossier de Prensa del Gabinete de Comunicación de la UVa en donde se hace un reflejo de los articulos de periódicos donde se nos hace referencia.

Opencms: replicación de índices de Solr

Nosotros tenemos una configuración de un maestro donde la gente edita y dos esclavos para servir las webs de OpenCms. El problema que nos encontramos es que en el disco compartido donde tienen los índices de Solr varias instancias de OpenCms (1 del maestro y 2 de los esclavos) intentaban manipular el mismo índice, y esto daba problemas de bloqueo para hacer los updates y commits. Además si un maestro hace las modificaciones, los esclavos no se enteran de las modificaciones. También había un problema con el cacheado de los esclavos, que no se enteran de los cambios en los contenidos del maestro y no actualizan las caches, por que cachean aunque la tengas desactivado y a tamaño cero.

La solución ha sido complicada pero efectiva.Ehmos replicado el índice Solr Online del maestro en los esclavos, y definiendo un servlet para que los esclavos se enteren de las actualizaciones en el maestro. Todo está basado en la configuración de las realizaciones de Apache Solr (http://wiki.apache.org/solr/SolrReplication) y la clase de OpenCms OpenCmsSolrHandler.

Paso a detallar la configuración del maestro:

– Instalamos un módulo con unas pequeñas modificaciones de CmsSolrIndex.java y una nueva clase OpenCmsHandleSolrReplicationHandler.java creada por nosotros (si alguien tiene interés que contacte con nosotros)

– Configuramos la replicación en WEB-INF/solr/conf/solrconfig.xml dentro de OpenCms con la información de la wiki:

[code]

<requestHandler name=»/replication» class=»solr.ReplicationHandler»>

<lst name=»master»>

<str name=»replicationAfter»>commit</str>

<str name=»replicationAfter»>startup</str>

</lst>

[/code]

– configuramos WEB-INF/web.xml un servlet con nuestra clase OpenCmsSolrReplicationServlet .

 

La configuración de los esclavos es más sencilla.

– Configuracmos el índice en  WEB-INF/config/opencms-search.xml

[code]

<directory>index_esclavoID</directory>

[/code]

– Configuramos la replicación en WEB-INF/solr/conf/solrconfig.xml

[code]

<requestHandler name=»/replication» class=»sold.ReplicationHandler»>

<lst name=»slave»>

<str name=»masterURL»>http://IP:PUERTO/replication</str>

<str name=»pollInterval»>00:00:20</str>

</lst>

</requestHandler>

[/code]

Con esto hemos logrado que los índices se actualicen sin bloqueos ni problemas.

Generar el war de opencms desde código fuente

Para generar el opencms.war desde el código fuente que OpenCms pone a nuestra disposición en GitHub aunque en la documentación pone que haya que hacer un «ant war» esto os generará un war sin los módulos, con lo cual el opencms se queda tan limpio que no se puede usar. Si bien podemos instalarlos desde el CmsShell mi recomendación es realizar antes del «ant war», hacer un «ant bindist» que generará los ficheros de los módulos y los incluirá en el war.

OpenCms. Compilar versión 9

Si nos costó compilar la MS 9.4.1, también cuesta la versión 9 del Github del día 28 de Enero. Aquí os dejamos una guía paso a paso.

Lo primero, bajar el eclipse para Java EE, aunque con el clásico valdría.

Lo segundo, como usa Gradle, debemos instalar el plugin para eclipse. Esta nueva versión trae en el menú->Help el Marketplace que nos permite instalar el plugin de una manera sencilla.

Después nos bajamos de github la última versión del acacia-editor, un zip que tras descomprimir debemos importar en nuestro workplace como proyecto Gradle.

Seguimos pulsando el botón derecho sobre el proyecto de acacia editor, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies». Esto nos descargará las librerías necesarias para su compilación.

A continuación, os recomiendo activar la vista «Gradle Task», en el menú->Window->Show view->other …y en Gradle la tenemos. Así podemos lanzar fácilmente las compilaciones. Lanzamos la tarea «clean» y luego la tarea «install». Todo debería ir bien aunque aparezca algún mensaje de error.

A continuación bajamos el minestrone 9.4.1 de opencms, descomprimimos el zip y lo importamos en nuestro workplace como proyecto Gradle.

Debemos hacer un pequeño cambio en el fichero dependencias.gradle ya que no le gusta la librería gwt-dev.  Debemos pulsando con el botón derecho en el proyecto importado de opencms, en «Java Build Path», en «Libraries» añadimos la librería buscándola en la carpeta lib, y luego compile.

Ya casi terminando, con el botón derecho sobre el proyecto de opencms, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies»

Con todos estos pasos, ya podríamos ejecutar en la ventana de «Gradle Task» la tarea «bindist» y no debería darnos problemas en generar en la carpeta «BuildCms/distributions» un opencms.war perfecto.

Espero que os sirva y muchas gracias a Montse por la ayuda, que esto debería estar contándolo ella ^_^