Kentico es un popular CMS (Content Management System) basado en .Net con el que estoy trabajando desde hace algunos meses en ClearPeople. Como todo CMS, el contenido de la web depende del trabajo de los editores, y en muchas ocasiones, la optimización del contenido no es la mejor posible. Uno de los principales problemas de rendimiento que puede sufrir nuestra web está en las imágenes que los editores suben a nuestra web. Por norma general, el editor no se va a preocupar de subir imágenes optimizadas, lo que supone que el peso de las páginas se verá incrementado en unos cuantos KBs de más, con lo que ello supone en cuanto a rendimiento y transferencia de datos.

Plugin para Kentico

Para evitar este problema, en nuestro último proyecto desarrollé un plugin para Kentico que se encarga automáticamente de optimizar las imágenes que los editores suban a la Media Library, de manera transparente. El código fuente lo puedes encontrar en https://github.com/sgisbert/Dianoga-for-Kentico y se distribuye a través de Nuget. Este plugin es un fork de la librería original de Kamsar para Sitecore, que hemos adaptado para Kentico. Está disponible en dos versiones, tanto para Kentico 8.x (.Net 4), como para Kentico 9 (.Net 4.6). Además, ha sido aceptado en el marketplace de Kentico: https://devnet.kentico.com/marketplace/utilities/dianoga-image-optimizer.

Instalación

La instalación es muy sencilla y transparente, y se realiza a través del administrador de paquetes de Nuget. Si lo realizamos a través del GUI, buscaremos “dianoga” en nuget.org e instalamos la versión correspondiente a la versión de Kentico que tengamos instalada: 8 o 9. 2016-02-21_1223 O bien a través de la consola de Nuget: Kentico 8.x:

Kentico 9:

Una vez instalado el paquete adecuado, funciona sin necesidad de ninguna configuración adicional, y se producen los siguientes cambios en nuestra aplicación: Web.Config: Se añaden las siguientes entradas al web.config:

Solución Se incluye una nueva carpeta en la solución, “/Dianoga Tools”, que contiene las librerías que realizan la optimización, y que debemos desplegar junto con el resto del proyecto.

Cómo funciona

Dianoga se encarga de optimizar automáticamente las imágenes que se suban a la Media Library. Para comprobar su funcionamiento, subiremos una imagen y comprobaremos su tamaño. Pongamos como ejemplo la imagen anterior de este mismo artículo: 2016-02-21_1607 Si la subimos a la Media Library, observamos la reducción de tamaño: 2016-02-21_1609 En el visor de eventos se registra la optimización que ha sufrido cada imagen subida: 2016-02-21_1611 Donde podemos ver los detalles: 2016-02-21_1611_001

Conclusión

Esta pequeña librería es un fijo en nuestros proyectos de Kentico. Si te ha servido de utilidad, ¡coméntalo! Y si crees que puedes aportar alguna mejora, no dudes en colaborar en el repositorio de GitHub.

A raíz de una consulta que me llega de Jesús González a través de Google+, parece que instalar WordPress en una carpeta de Azure Websites no es tan común como pensaba, o, al menos, no está demasiado documentada. La idea es que http://www.miwebsite.com/blog pueda alojar una instancia de WordPress, mientras que en el raíz se mantenga una aplicación .Net. Este mismo escenario es el que tengo yo aquí mismo, en este blog.

Para ello, la primera opción sería seguir uno de los tutoriales que existen para ello, como este: http://blogs.msdn.com/b/kaushal/archive/2014/04/19/microsoft-azure-web-sites-deploying-wordpress-to-a-virtual-directory-within-the-azure-web-site.aspx. Este tutorial aborda una instalación desde cero de WordPress, realizando una instalación en local a través de la galería de aplicaciones de WebMatrix, y realizando la publicación a posteriori sobre el website.

Sin embargo, se puede dar el caso de que ya dispongamos de un WordPress funcionando y no queremos que WebMatrix le meta mano a nuestro código. Para ello necesitaremos realizar un par de pequeñas modificaciones manuales.

En este post anterior, en el que desglosaba un poco los detalles técnicos que he utilizado para implementar esta web, ya indicaba la problemática de compartir WordPress con MVC en Azure, y cómo lo había solucionado, pero parece que el tema tiene entidad suficiente como para dedicarle este pequeño post.

Configurando el Website

El problema principal de intentar hacer convivir una aplicación basada en .Net con otra basada en PHP, como es el caso, es saber discernir cuándo las peticiones que recibe el website las tiene que manejar un framework y cuándo el otro. En este caso, todo lo que se reciba a la url “/blog” y por debajo de ésta, lo tiene que renderizar el motor de PHP, y, en concreto, WordPress. Todas las demás, dejaremos que las maneje .Net.

Para ello, añadiremos la siguiente configuración al archivo web.config que se encuentra en el raíz del sitio web:

De esta manera, utilizamos el módulo url_rewrite para enviar al motor de WordPress todas las peticiones que se reciban en la carpeta “/blog”

En segundo lugar, crearemos un segundo archivo web.config y lo alojaremos dentro de la carpeta “/blog”, con el mismo contenido:

Finalmente, también sería recomendable configurar el Website para indicarle que hay una aplicación virtual en la carpeta “/blog”, tal y como se indica en el enlace que he dejado al inicio.

Dependiendo del tipo de aplicación .Net que tengamos instalada, tendremos que decirle a su vez que ignore todas las peticiones a “/blog”. En mi caso,que utilizo MVC, esto se consigue añadiendo la siguiente configuración de enrutamiento:

En general, el concepto es el mismo para hacer convivir cualquier aplicación .NET y PHP:

  • Redirigir las peticiones desde la aplicación raíz a la carpeta de la otra aplicación
  • Configurar la aplicación raíz para que ignore las peticiones a la aplicación anidada.

¡Espero que os sea de utilidad!

Hace unos meses que empecé una nueva andadura profesional, que me ha tenido bastante ocupado, por lo que no he tenido tiempo de actualizar el blog con nuevo contenido, hasta ahora.

Últimamente, dedico mi tiempo profesional a trabajar con Sitecore, que es un CMS desarrollado en .Net, enfocado a grandes webs corporativas con grandes volúmenes de contenido y requisitos de personalización. Este CMS, a pesar de su complejidad, tiene un rendimiento notable, gracias a varios niveles de caché incorporados, que funcionan bastante bien.

Sin embargo, Sitecore permite añadir nuestro propio código, y, en este caso, obtener el mejor rendimiento nos corresponde a nosotros. Para ayudarnos en esta tarea, estoy utilizando MiniProfiler, que es un plugin para monitorizar aplicaciones web desarrolladas en .NET, muy útil para analizar el rendimiento de nuestras páginas en “tiempo real”, sin la necesidad de indagar a posteriori en el log de Sitecore, o utilizar las herramientas de profiling que también nos ofrece. Además, está disponible como código abierto en GitHub: https://github.com/MiniProfiler

Lo que a priori parecía una tarea sencilla, “Instalar MiniProfiler en Sitecore”, terminó necesitando cierto tiempo de investigación (aún me queda mucho Sitecore que aprender…), por lo que reproduzco a continuación los pasos necesarios para activar MiniProfiler en una instancia de Sitecore, en mi caso, la versión 6.6, aunque entiendo que será muy similar para cualquier versión posterior.

Instalar MiniProfiler en Sitecore

El primer paso, obvio, consiste en instalar MiniProfiler en nuestro proyecto. Para ello, la manera más sencilla es utilizar NuGet.

  1. Abrir la ventana de comandos de NuGet.
  2. Seleccionar en el desplegable de “Proyecto por defecto” el proyecto que contiene la aplicación web
  3. Ejecutar el comando: PM> Install-Package MiniProfiler

En este caso, estamos instalando la versión básica de MiniProfiler, suficiente para trabajar con ASP.NET WebForms. Podéis consultar en la web de MiniProfiler otras extensiones para MVC, EF, etc.

Configuración de MiniProfiler

A partir del proyecto de ejemplo para WebForms, podemos configurar fácilmente nuestra aplicación web.

Global.asax.cs:

  1. Añadir la configuración al archivo Global.asax.cs, que copiaremos de https://github.com/MiniProfiler/dotnet/blob/master/Sample.WebForms/Global.asax.cs
  2. En el método, recomiendo añadir las siguientes entradas a la lista de extensiones ignoradas por MiniProfiler, de manera que no apaezcan archivos estáticos ni las propias páginas de Sitecore:

Web.Config:

  1. Comprobar que la sección <Modules> tiene el atributo runAllManagedModulesForAllRequests=”true”.
  2. Añadir a la lista de URLs ignoradas por Sitecore la siguiente: /mini-profiler-resources, sin eliminar las de Sitecore.
  3. Por último, nos queda añadir a nuestro(s) layout(s) el código que incluye los archivos JS necesarios para mostrar los resultados en pantalla, justo antes de la etiqueta </body>:

A partir de este momento, publicamos los cambios en el site y ya debe de aparecernos la capa de timing que nos aporta MiniProfiler en la parte superior izquierda de nuestra web.