Gracias a la web del Zend Framework, llego hasta este interesante proyecto de un lector de feeds al estilo Google Reader, realizado con el Framework de Zend y con un alto uso de AJAX (principalmente prototype).
Las capturas de pantalla y los videos tienen muy buena pinta y ya me he apuntado para ser de los primeros en probarlo.
Cuando parece que ya está hecho todo en un determinado tema, siempre hay gente capaz de innovar y mejorar lo existente. Y eso también saben verlo los inversores.
Desde hace tiempo, este blog está superando los 1000 visitantes diarios y las 2300 páginas vistas. Eso empieza a plantearme algunos problemas, sobre todo teniendo en cuenta la cantidad de recursos que consume el wordpress y que a mà me gusta mucho optimizar el rendimiento del servidor.
Es por eso que he estado buscando alguna forma de añadir cache de páginas al blog. Las opciones que he encontrado han sido:
Pero ninguno de los dos me ha convencido. Lo que yo busco es algo que sea muy eficiente pero a la vez muy simple. Ni siquiera necesito interfaz de administración.
Y es ahà cuando me he dado cuenta de lo evidente… Tanto tiempo usando el Zend Framework y su cache de páginas y no se me habÃa ocurrido aplicarlo al wordpress :P
La instalación es muy sencilla, simplemente he bajado el Zend Framework y he copiado la carpeta «library» a mi directorio raÃz de wordpress. Después he creado una carpeta donde irán las páginas cacheadas (en mi caso ha sido: wp-content/cache) que debe tener permiso de escritura (0777).
Y ahora viene lo importante. Hemos de modificar el index.php de wordpress para añadir el código que nos permite usar la cache. Este es ahora mi index.php:
<?php
set_include_path ('library' . PATH_SEPARATOR . get_include_path ());
require_once ‘Zend/Cache.php’;
$frontendOptions = array(
‘lifetime’ => 3600*6,
‘debug_header’ => false, // for debugging
‘default_options’ => array(
‘cache_with_session_variables’ => true,
‘cache_with_cookie_variables’ => true
),
‘regexps’ => array(
‘^/$’ => array(‘cache’ => false),
‘^/2007/’ => array(‘cache’ => true),
‘^/category/’ => array(‘cache’ => true),
‘^/2008/’ => array(‘cache’ => true)
)
);
$backendOptions = array(
/* cache_dir debe ser una ruta absoluta por temas del ob_start */
‘cache_dir’ => dirname($_SERVER[‘SCRIPT_FILENAME’]) . ‘/wp-content/cache/’
);
// getting a Zend_Cache_Frontend_Page object
$cache = Zend_Cache::factory(‘Page’, ‘File’, $frontendOptions, $backendOptions);
$cache->start();
/* Short and sweet */
define(‘WP_USE_THEMES’, true);
require(‘./wp-blog-header.php’);
?>
Podeis encontrar documentación sobre el sistema de cache del Zend Framework aquÃ. Pero básicamente lo que hago es cachear todos los posts y los listados de las categorÃas durante 6 horas (3600 segundos * 6). De esta forma, durante esas 6 horas, si se accede a alguno de los posts del blog o a alguna categorÃa, se tomará la copia de cache y se evitará el pasar por todo el codigo de wordpress, incluida la conexión a la base de datos.
Lo malo de esta solución es que cuando vuelva a actualizar wordpress, tendré que acordarme de no pisar el index.php.
Me ha vuelto a llegar de nuevo la pregunta de si es más interesante guardar las imágenes dentro de la base de datos o en el sistema de ficheros del Servidor.
Para todos aquellos que tengais dudas de cómo almacenar imagenes en MySQL, hace bastante tiempo escribà un artÃculo que os puede resultar interesante.
En general, mi experiencia sobre el tema me lleva a recomendar que se use el sistema de ficheros del servidor antes que guardar la imagen directamente dentro de la base de datos.
Algunos de los inconvenientes que me he encontrado:
Además, el tener disponibles las imágenes en carpetas del servidor os permitirá usar de forma sencilla herramientas de redimensionado y retoque como la biblioteca GD o las de imagemagick.
Por lo tanto, mi recomendación es – siempre que sea posible – evitar guardar las imágenes directamente en la base de datos.
Hoy me he encontrado con este interesante artÃculo en la Zend Developer Zone, donde se comenta la necesidad creciente de ser un poco «hÃbrido» a la hora de desarrollar en la web. Por una parte tener buenos conocimientos de programación y por la otra buen gusto y cuidado de la estética cara al usuario. Todo ello, aplicado a la metodologÃa de trabajo del Zend Framework. La única pega es que está en inglés.
HTML Purifier es una clase PHP que permite depurar el HTML (Standards Compliant) para:
Entre otras muchas cosas más…
Además, disponemos de versión para PHP 4 y para PHP 5.
Esta es una de esas cosas que encuentras y dices ¡si la hubiera conocido cuando hice aquel[..]!
Pues nada, a partir de ahora, a usarla.
Hace poco he estado desarrollando una utilidad para la edición de una newsletter HTML y me he encontrado con un problema interesante. Una vez que tenemos editado el formato, insertadas las imágenes, los links, etc. podemos proceder al envÃo de la newsletter. Pero el problema es que esas imágenes y algunos links tienen rutas relativas, por lo tanto, el programa de correo que reciba el html, no podrá encontrar esos elementos.
Gracias a PHP y la potencia de las expresiones regulares, aquà está la solución:
$str=preg_replace('#(href|src)="([^:"]*)("|(?:(?:%20|\s|\+)[^"]*"))#',
'$1="http://www.ingeniuz.com/$2$3',$str);
La función preg_replace, se encarga de realizar reemplazos en una cadena, siguiendo las instrucciones que se le dan en la expresión regular que toma como argumento.
De esta forma, todas las url contenidas dentro de los atributos src y href son cambiadas (si es necesario) por su forma absoluta.
Via: wintermute
¡Ya queda menos para la 1.0! Para todos lo que usamos a diario este framework estamos de enhorabuena, porque sin duda con cada release gana en calidad, estabilidad y rendimiento (se han corregido más de 90 problemas desde la 0.9.3).
Estas son algunas de las novedades en esta entrega:
¡Corre! ¡Descárgalo!