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:
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]
[/code]
y desde los navegadores veremos también que el Squid nos devuelve el X-Cache: HIT como podéis ver en la imagen
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!!
Los alojamientos que ofrecemos no dan la oportunidad de conectarse por FTP (o SFTP) debido a restricciones de seguridad. Por eso, cuando alguno de vosotros quiere instalar o actualizar algún elemento o el propio WordPress os toca conectaros al alojamiento y subir los ficheros a mano.
Esto esta bien si tienes capacidad de llegar al alojamiento, pero, puede que por emergencia no podáis hacer esto y os interese hacerlo desde el propio administrador del WordPress, descubriendo, que os pide los datos del FTP.
Para que no os lo pida y podáis hacerlo «directamente» añadid la siguiente linea tras el último define del fichero wp-config.php:
[code]define(«FS_METHOD», «direct»);[/code]
Recordad dar permisos de escritura al directorio wp-content ya que lo utilizara de temporales para dejar las cosas y, de disponer de hueco (espacio) suficiente en vuestro alojamiento.
No solo de JQuery vive el programador de Javascript. Google tiene una preciosa y extraña API que sirve como catalizador y centralizador de otras APIs de Google a modo de que no tengas que «preocuparte» en tener que meter muchas lineas o incluso en las versiones de las mismas.
Esta API nos puede servir, rapidamente, para desarrollar a traves del cliente, desde la lectura de un WebService hasta, por ejemplo, hacer un lector de feeds sencillo.
Vamos a describir los pasos para depurar un Tomcat con IntelliJ, por ejemplo para depurar nuestro OpenCms.
En primer lugar debemos arrancar el Tomcat en modo depuración. Una de las soluciones es modificar el script de arranque, startup.sh y añadir el parámetro jpda. Para ello en ese fichero donde pone
[code]
exec «$PRGDIR»/»$EXECUTABLE» start
[/code]
Debemos poner
[code]
exec «$PRGDIR»/»$EXECUTABLE» jpda start
[/code]
A continuación vamos a indicar al Tomcat el puerto y el modo de depuración. Un a de las opciones es añadir las variables siguientes al .bash_profile de nuestro usuario
[code]
JPDA_ADDRESS=9000
JPDA_TRANSPORT=dt_socket
export JPDA_ADDRESS
export JPDA_TRANSPORT
[/code]
Y tras rearrancar el Tomcat, desde IntelliJ, vamos «Run -> Edit configurations…» y pulsamos al «+», Tomcat Server-> Remote. Nos aparecerá una pantalla como la siguiente:
Podemos quitar en «Before Launch» el make ya que vamos a depurar directamente el código sin compilarlo, y en «Startup/Connection» debemos seleccionar el puerto que indicamos anteriormente, en este caso el 9000.
¡¡y ya podemos depurar el tomcat!!. A poner puntos de interrupción como cosacos… ^_^
Muchos de vosotros (bueno, realmente una persona), nos ha preguntado como hacer para mostrar las RSS de una categoría en concreto que tenéis en vuestro blog.
El caso es que, por si no lo sabéis, las RSS en WordPress es un servicio web ubicado en la siguiente direccion:
[code]http://www.vuestroblog.es/feed[/code]
Es decir, la URL de vuestro blog /feed o /?feed
Obviamente, como buen servicio WS se le pueden pasar parámetros. Como tiene bastantes parámetros, lo mejor es que reviséis la URL del propio WordPress donde os los indican para filtrar por categoría, tag, etc…
Por ejemplo, dentro de los blogs corporativos, si quereis, por ejemplo, mostrar solo los post de la categoría «noticias» no teneis mas que pasar la siguiente URL:
[code]http://vuestroblog.blogs.uva.es/feed?cat=noticias[/code]
Siempre y cuando vuestra categoría de noticias se llame, noticias.
Malditos y molestos ficheros ._ culpables de los fork de HFS que se crean para meter las «propiedades» de OSX. Malditos y culpables que cuando copias desde el Finder aparecen por todos los lados y, aunque no os lo creáis, en algunos sistemas os pueden dar problemas.
Menos mal que el terminal esta para ayudaros:
[code]find / -name ‘._*’ -delete[/code]
Ya sabéis, un find para buscar, el / para buscar en todo el equipo (podéis poner la ruta que mas os guste o que necesitéis, el ‘._*’ que es el string de conexión que significa que busque todos los ficheros que comienzan por ._ y el -delete para que les borre.
Al instalar esta librería en Mac con un port install php53-mysql o en Ubuntu con un apt-get install php5-mcrypt, y tras reiniciar el apache a veces no nos funciona, y lo vemos porque no sale en un phpinfo o simplemente porque nos da error al cargar la librería.
El problema es que en lugar de dejar la librería mcrypt.so en el sitio por defecto donde php (por ejemplo /opt/local/lib/php/extensions/no-debug-non-zts-20090626/) va a buscarlo deja las librerías en otro directorio, /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/
La solución pasa por modificar el php.ini para añadir un directorio de extensiones. Por ejemplo en Mac sería
[code]
extension_dir=»/opt/local/lib/php53/extensions/no-debug-non-zts-20090626/»
[/code]
Otra solución es crear enlaces simbólicos según las librerías instaladas en la carpeta por defecto. Para ello hacemos un ls de la carpeta y vamos haciendo los enlaces simbólicos.
[code]
ls /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/
ln -s /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/mcrypt.so /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mcrypt.so
[/code]
Y si no nos queremos complicar nada, pues copiamos de una carpeta a otra .
[code]
cp /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/* /opt/local/lib/php/extensions/no-debug-non-zts-20090626/
[/code]
Para comprobar si funciona desde un terminal hacemos
[code]
php -m | grep mcrypt
[/code]
Y ya sólo nos queda reiniciar el apache. Si nos siguiese dando problemas, deberíamos especificar las librerías en el fichero php.ini y en las extensiones añadir
[code]
mcrypt.so
[/code]
Como siempre, espero que os sirva
Hemos mejorado el buscador del directorio de la UVa, añadiendo la capacidad de buscar por la extensión. Es decir, ahora podéis no solo buscar por el nombre, apellidos y demás datos sino también por la extensión de la persona.
Ya tenemos durante los OpenCms Days 2014 la nueva versión de Opencms.