aNieto2K Desarrollo web, Wordpress, y alguna cosilla más

Miguel(adSeok) nos muestra una forma evitar que Google SideWiki, la nueva aplicación de Google para intentar dispersar el contenido, permita que los usuarios dejen un comentario mediante esta herramienta.

(Ver Imagen)

Esta nueva aplicación, permite que los usuarios que la tenga instalada, puedan generar contenidos (que únicamente serán vistos por otros usuarios que tengan la aplicación) en forma de comentarios sobre una página web, simplemente mediante un click en un nuevo menú lateral.

 RewriteEngine On
 RewriteCond %{HTTP_USER_AGENT} GTB [NC]
 RewriteRule .* notoolbar.php [L]

Con este pequeño código que vemos arriba ubicado en nuestro .htaccess, nuestra página no permitirá acceder que esta aplicación deje comentar nuestras páginas.
Ojo, que el script no permitirá que los usuarios que tengan el plugin instalado puedan acceder a la página redireccionando a notoolbar.php

Si la iniciativa NOIE6Day no te convence, puedes optar por hacer que tu WordPress muestre el theme por defecto (kubrick) a tus usuarios con Internet Explorer 6. Para ello, únicamente tendremos que añadir esto al fichero functions.php de nuestro theme.

add_filter('template', 'serve_default_to_iesix');
add_filter('option_template', 'serve_default_to_iesix');
add_filter('option_stylesheet', 'serve_default_to_iesix');
function serve_default_to_iesix($theme) {
 if(strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 6') !== false)
    $theme = 'default';
 return $theme;
}

Desde este momento, tus usuario tendrán el theme por defecto activo cuando visiten tu blog.

Hace ya más de 3 años vimos una función para recoger parámetros pasados por GET mediante Javascript. Esta implementación pasaba por parsear la URL actual y obtener de ahí los parámetros. Pues en codeNothing? han implementado una versión para los amantes de php.

;(function(window){
var
 $_GET = window.$_GET = {},
 $_VAN = window.$_VAN = {},
 location = window.location,
 search = location.search,
 href = location.href, 

 index = search.indexOf('?') != -1 ? search.indexOf('?') + 1 : 0,
 get = search.substr(index).split('&'),
 vanity = href.replace(/^https?:\/\/(.*?)\//i, '').replace(/\?.*$/i, '').split('/'); 

 for (var i in get){
 var split = get[i].split('=');
 $_GET[split[0]] = split[1]||null;
 }
 for (var i in vanity)
 $_VAN[i] = vanity[i]||null;
})(window);
// Modo de uso

var param = $_GET["param"];
alert("Parámetro: " + param);

Como podemos ver, esta función  nos permite añadir al objeto window la variable $_GET y usarla exactamente igual que en PHP.

Hace un par de días hablabamos de una forma de mejorar el consumo de memoria de tu WordPress. La solución, usar eAccelerator junto a Zend Optimizer permitía mejorar hasta un 90% el consumo de memoria consumida.

Aprovechando que MAMP tiene un sistema fácil y cómodo de probar estas combinaciones he hecho una prueba con un blog limpio recien instalado con diferentes combinación, los resultados son realmente interesantes.

Test

Partimos de que estoy en un iMac con 2GB de RAM, bajo Leopard. La versión de MAMP disponde de :

• Apache 2.0.59
• MySQL 5.0.41
• PHP 4.4.7 & 5.2.3
• WordPress 2.8.4 (recien instalado)
• Plugin TPC! Memory usage

Las pruebas las he realizado sobre la versión PHP5 (osea la 5.2.3) con 32 MB de límite de memoria. Y los componentes que he testeado son:

• APC 3.0.14
• eAccelerator 0.9.5.1
• XCache 1.2.0
• Zend Optimizer 3.2.8

Mediante un simple panel de la propia aplicación hacer los cambios es tan sencillo como seleccionar la combinación y pulsar aceptar.

(Ver Imagen)

Continua —>

En WebJawns.com publicaron hace unas semanas una forma fácil de reducir el consumo de memoria de WordPress. Al parecer inicialmente usando únicamente eAccelerator obtenía unos resultados de aproximadamente un 57% menos de consumo de memoria, osea de 14MB lograba reducir el consumo a 8M.

(Ver Imagen)

Trás unas pruebas más, y midiendo los datos con el plugin TPC! Memory Usage nos muestra una mejoría del 90% en cuanto a consumo de memoria de WordPress.

La solución pasó por unir la mejoría de eAccelerator a la potencia de Zend Optimizer, ¿Alguien ha probado algo similar?

WP-Engineer, muestra un interesante código que nos permite comprobar si un plugin está activo o no. Ideal para reusar código de otros plugins desde los nuestros.

// Cargamos todos los plugins activos
$plugins = get_option('active_plugins');

// Plugin que deseamos comprobar
$required_plugin = 'debug_queries/debug_queries.php';

// booleano que activamos si el plugin está activo
$debug_queries_on = FALSE;

// Comprobamos que el plugin está entre los activos.
if ( in_array( $required_plugin , $plugins ) ) {

 // Activamos el booleano en caso de estar activo.
 $debug_queries_on = TRUE;
}

Muy interesante y práctico.

Hace unas semanas tuve que implementar una Class para cachear elementos de mi PHP en ficheros estáticos. Inicialmente usé un sistema similar al que había usado siempre basado en la función filemtime() que me devolvía la fecha de modificación del archivo estático y la contrastaba con la actual, si el resultado era mayor a un número de segundos especificado volvía a generar el fichero estático.

Código filemtime()

class Cache {
 function fileName($key){
 return 'cache/'.md5($key);
 }

 function put($key, $datos){
 $f = fopen($this->fileName($key), 'w');
 if (!$f) die('No se puede leer el fichero de caché');

 $data = serialize($data);

 if (fwrite($f,$data)===false) {
 die('No se puede escribir el fichero de caché');
 }
 fclose($f);
 }

 function get($key){
 $filename = $this->fileName($key);
 if (!file_exists($filename) || !is_readable($filename)) return false;
 if ((filemtime($filename) + 3600) < time()) {
 return file_get_contents($filename);
 }
 return false;
 }
}

Esta versión, me permite cachear en fichero cualquier contenido que yo le indique mediante put(). Veamos un ejemplo.

$cache = new Cache();
if (!$data = $cache->get('misdatos')) {
 ....
 $cache->put('misdatos', $misdatos);
}

Problemas

Tras unas horas usándolo me encontré con un problema, la poca flexibilidad de este sistema. Necesitaba que ciertos datos, se cachearan una hora y otros lo hicieran 24. De esta forma me era dificil montar un sistema basado en filemtime() que me permitiera indicar una caché para tiempos diferentes.

Las soluciones pasaba por comprobar el tipo de contenido y dependiendo de que fuera tomar un tiempo u otro, o crear métodos específicos para cachear por tiempos (put60(), put24(),…). Ninguna solución me parecía elegante.

Serialize()

Entonce recordé un artículo de hace ya unos años en los que mediante el uso de serialize() permitía hacer lo que estaba buscando.

serialize() es una función de PHP que permite convertir un objeto que puede ser fácilmente almacenable. Algo que me venía ideal para hacer que mi caché de ficheros estática fuera más flexible.

Código serialize()

>class Cache {
 var $cacheDir;

 function __construct($cacheDir = './'){
 $this->cacheDir = $cacheDir;
 }

 // Indicamos el directorio donde queremos alojar los ficheros de caché
 function put( $key , $data ,$time = 600) {

 $h = fopen( $this->getFileName( $key ) , 'w' );
 if (!$h) throw new Error('No se puede leer el fichero de caché');

 $data = serialize( array( time() + $time , $data ) );

 if ( fwrite( $h , $data ) === false ) {
 throw new Error('No se puede escribir el fichero de caché');
 }
 fclose($h);

 }

 // Obtenemos el nombre del fichero codificado
 private function getFileName($key) {
 return  $this->cacheDir.md5($key);
 }

 // Recuperamos de caché
 function get($key) {

 $filename = $this->getFileName($key);
 if (!file_exists($filename) || !is_readable($filename)) return false;

 $data = file_get_contents($filename);

 $data = @unserialize($data);
 if (!$data) {
 unlink($filename);
 return false;
 }
 if (time() > $data[0]) {
 unlink($filename);
 return false;
 }
 return $data[1];
 }
}

Esta clase ya me permite especificiar de una forma cómoda el tiempo que quiero que se cachee un contenido determinado.

$cache = new Cache('cache/');
if (!$data = $cache->get('misdatos')) {
 ....
 $cache->put('misdatos', $misdatos, 60); // 60 seg
}

Rendimiento

Este sistema es muy cómodo, pero hay que ser conscientes de los problemas de rendimiento que presenta. Hemos de pensar que cada comprobación pasa por leer el contenido del fichero, convertir el objeto serializado y comprobar la fecha de este último.

Esto, frente a la simple consulta de la última fecha de modificación hace que este método sea considerablemente más lento. Pero por contra es bastante más flexible.

Mejoras

Bueno, despues de todo el rollo os propongo un juego. ¿Como lo podemos mejorar?

Mi opción

La opción que estaba barajando era la de generar un fichero con la fecha de caducidad del fichero y el nombre del fichero. De esta forma, únicamente tendría que hacer una lectura de fichero para cargar la fecha de caducidad asociada al fichero y despues mediante filemtime() comprobar si esta es superior a la especificada.

Ejemplo

<?php
...

// Leer
$content = file_get_content($file);
$times = unserialize($content);

 if (filemtime($cache_file) > $times[$cache_file]) {
 ....
 // Generamos de nuevo la caché
 $times[$cache_file] = time() + 60; // 60 seg.
 }

// Grabar
serialize(array(
 md5("tmp".time()).".cache" => '123456789'
 ....
));

...
?>

¿Alguna idea más?

En PlanetOzh hacen un interesante tutorial de como lanzar peticiones HTTP mediante la API de WordPress. Desde la versión 2.7, disponemos de un interfaz muy sencillo para lanzar peticiones HTTP a servicios externos.

Peticiones HTTP

El fichero http.php que podemos encontrar en wp-includes/ nos permite hacer llamadas tan sencillas como estas:

$request = new WP_Http;
$result = $request->request( 'http://some.url.you-need.to-fetch' );

Como podemos ver, hacer las llamadas es realmente sencillo. Pero aquí no se queda la cosa:

Peticiones GET

Tambien podemos lanzar peticiones GET informando los parámetros como parte de la URL.

$url = 'http://search.twitter.com/search.json?q=rabbits';
$request = new WP_Http;
$result = $request->request( $url );
$json = $result['body'];

Peticiones POST

Si por lo contrario queremos enviar parámetros por POST, simplemente tendremos que cambiar la forma de enviarlos:

$body = array(
 'nick' => 'ozh',
 'mood' => 'happy'
);
$url = 'http://your.api.url/';
$request = new WP_Http;
$result = $request->request( $url, array( 'method' => 'POST', 'body' => $body) );

Respuesta

Una vez lanzada la petición, obtendremos una serie de parámetros con información sobre la respuesta del servidor externo.

• headers': Un array con las cabeceras de la respuesta
• 'body': La respuesta del servidor.
• 'response': Un array con los códigos  HTTP  de respuesta generalmente array('code'=>200, 'message'=>'OK')
• 'cookies': Un array con información de la cookie.

Ejemplo práctico

// Datos de Twitter
$username = 'joe'; // Twitter login
$password = '123456'; // Twitter password
$message = "Publicando desde la API";
// Lanzamos la petición HTTP
$api_url = 'http://twitter.com/statuses/update.xml';
$body = array( 'status' => $message );
$headers = array( 'Authorization' => 'Basic '.base64_encode("$username:$password") );
$request = new WP_Http;
$result = $request->request( $api_url , array( 'method' => 'POST', 'body' => $body, 'headers' => $headers ) );

Estas pocas líneas, nos permiten enviar a Twitter un actualización directamente desde nuestro WordPress, simplemente tendremos que informar los datos del usuario y lanzar la petición a la URL que obtenemos en la API de Twitter.