Hay muchos consejos para agilizar tus scripts de PHP, pero en este caso se concentran en el uso de funciones y sus funciones alias. Por lógica la llamada a una función será más rápida que la llamada a una función alias, salvo en un caso que la verdad me sorprende.
Los porcentajes que se muestran son reales, pero quizás no sean perceptibles, ya que el uso de estas funciones puede ser mÃnimo en un desarrollo, pero bueno, si algo de tiempo obtenemos, mejor que mejor.
Las funciones son las siguientes:
sizeof y count: count es un 12% más rápida.
is_int y is_integer: is_int es un 9% más rápida.
chop y rtrim: rtrim es un 7% más rápida.
doubleval y floatval: floatval es un 4% más rápida.
fwrite y fputs: fputs es un 23% más rápida, esta es la comparativa que me sorprende, porque fputs es alias de fwrite. Que alguien me lo explique, ¿una diferencia del 23%? o no son alias o el ejemplo está mal medido.
implode y join: implode es un 5% más rápida.
ini_alter y ini_set: ini_set es un 19% más rápida.
En SitePoint siempre sacan algún tutorial útil y que nos puede facilitar mucho nuestros desarrollos. En este caso se trata de listas de correos, quizás con el tema de las feeds, ya no se usen mucho, pero conozco a unos cuantos que aún tiran de ellas.
A grandes rasgos se trata de lo siguiente:
Un HTML dentro de un PHP que recibe las direcciones de correo de los usuarios.
Un Javascript que leerá cada cierto tiempo el formulario y realizará una llamada AJAX al servidor con la dirección de correo introducida.
Un script PHP que recibe la dirección, comprueba si es correcta, la almacena en la base de datos y manda un mensaje de que todo ha ido bien o de que ha habido error a la página web para que la muestre al usuario.
Creo que para ciertos blogs es muy útil ofrecer la opción de añadir OpenSearch para que la gente puede realizar búsquedas en nuestro blog. Algo también bastante útil es que nos ofrezca sugerencias de búsquedas (tal y como hace Google). Para ello tan sólo hay que añadir una opción al XML de OpenSearch y modificar nuestro functions.php.
En el fichero XML deberemos añadir la siguiente etiqueta:
Y añadir xmlns:suggestions="http://www.opensearch.org/specifications/opensearch/extensions/suggestions/1.1" a la etiqueta inicial OpenSearchDescription
Yo en este caso he preferido usar una URL amigable, sobre todo para practicar con el wp_rewrite, pero se podría hacer perfectamente con una variable con parámetros.
Una vez cambiado el opensearch.xml deberemos modificar el functions.php, para lo cual tendremos que coger el término que se quiere sugerir y buscar entre las categorías y tags y entre los títulos de los posts para así mostrar una unión de ambos. Las categorías se ordenarán por el número de veces que aparece y los posts por fecha descendente.
add_filter('init','suggestion_init');
add_filter('query_vars','suggestion_insertMyRewriteQueryVars');
add_filter('rewrite_rules_array','suggestion_rewrite');
// Acciones iniciales
function suggestion_init(){
// Reescribe las reglas
global $wp_rewrite;
$wp_rewrite->rewrite_rules();
// Obtiene el termino a buscar
$req = explode('/', substr($_SERVER['REQUEST_URI'], 1), 2);
if ($req[0] == 'suggestion') {
$result = wp_cache_get( 'suggestion_'.$req[1] );
if ( false == $result ) {
global $wpdb;
$list = array();
// Recupera las 4 categorias/tags que coincidan
$res = $wpdb->get_results("select name from $wpdb->terms t, $wpdb->term_taxonomy tx where name like '%".$req[1]."%' and t.term_id = tx.term_id group by name order by count desc limit 4");
foreach ($res as $item) $list[] = $item->name;
// Recupera las 4 anotaciones que coincidan
$res = $wpdb->get_results("select post_title from $wpdb->posts where post_title like '%".$req[1]."%' order by ID desc limit 4");
foreach ($res as $item) $list[] = $item->post_title;
// Devuelve en formato JSON
$result = json_encode(array($req[1], $list));
wp_cache_set( 'suggestion_'.$req[1], $result );
}
echo $result;
exit();
}
}
// Permite que WP acepte un nueva parametro en la query de la URL
function suggestion_insertMyRewriteQueryVars($vars) {
array_push($vars, 'suggestion');
return $vars;
}
// Reescribe la regla
function suggestion_rewrite($rules)
{
$newrules = array();
$newrules['suggestion/([^/]+)/(.*)$'] = 'index.php?suggestion=$matches[1]';
return $newrules + $rules;
}
En el código he añadido caché, porque es altamente recomendable, puediendo usar el plugin WP File Cache. También debo decir que me encontré con el problema del timeout que tiene Firefox para esperar la respuesta para la sugerencia, muy pequeño para mi servidor, por lo que si quieres modificarlo, busca el fichero nsSearchSuggestions.js y modifica el valor de _suggestionTimeout.
Marjory es un webservice que nos ayuda a indexar y buscar documentos realizado en PHP. Utiliza la búsqueda fulltext aunque también está disponible la búsqueda mediante Lucene (en un futuro pretenden sacar más).
No utiliza protocolos XML-RPC o SOAP, usa una interfaz REST para comunicarse con las otras aplicaciones. Aunque no estaría mal respuestas en JSON.
Está realizado con Zend Framework y usa la librería para Lucene como motor de búsqueda por defecto. Marjory
Algo que casi nunca hago, pero que debería ser obligatorio, es realizar pruebas unitarias de los plugins que realizo en WordPress. Si normalmente casi no tengo tiempo de realizarlos con detalle, imagínate hacer pruebas unitarias.
Para realizar esas pruebas voy a hacer uso de PHPUnit, el cual no voy a explicar cómo usarlo, pero sí voy a poner el bootstrap.php que uso:
// Cargar WP, la ruta supuestamente está en el directorio wp-content/plugins
define('WP_PATH', dirname(__FILE__).'/../../..');
include(WP_PATH.'/wp-load.php');
/**
* Loads/activates a plugin
*/
function run_activate_plugin( $plugin ) {
$current = get_option( 'active_plugins' );
$plugin = plugin_basename( trim( $plugin ) );
if ( !in_array( $plugin, $current ) ) {
$current[] = $plugin;
sort( $current );
do_action( 'activate_plugin', trim( $plugin ) );
update_option( 'active_plugins', $current );
do_action( 'activate_' . trim( $plugin ) );
do_action( 'activated_plugin', trim( $plugin) );
}
return null;
}
// Activa el plugin si no lo está, que no debería al estar en testing...
run_activate_plugin( 'wordpress-nonce-object/class-wp-nonce.php' );
Para mí, uno de los mayores fracasos de Twitter es su API, una limitación de su uso increíble para algo que le podría dar mucho juego a la aplicación. Ahora mismo no sé en cuánto está el límite, pero la posibilidad de realizar una aplicación basada en Twitter es una pesadilla.
Para aquellos que no quieran sufrir lo que hemos sufrido con TwitterPoster (los espacios en blanco es porque la gente actualiza su imagen y no podemos recuperar la de todos los usuarios por el límite en el API de Twitter), les recomiendo usar Twitter mediante CURL.
Os paso un script sencillito que he realizado:
<?php
// Primer hacemos login
$url ="https://twitter.com/sessions";
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
// Por si tienen limitación por navegador
curl_setopt($ch, curlOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)");
// Poned una ruta para las cookies
curl_setopt ($ch, CURLOPT_COOKIEJAR, '/temp/');
curl_setopt ($ch, CURLOPT_COOKIEFILE, '/temp/');
curl_setopt ($ch, CURLOPT_POSTFIELDS, "username_or_email=[usuario]&password=[contraseña]");
// Para que funcione el https
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, curlOPT_SSL_VERIFYHOST, 2);
curl_exec ($ch);
// Cargamos el home, porque Twitter añade dos campos ocultos para poder publicar por web
$url ="http://twitter.com/home";
curl_setopt($ch, CURLOPT_URL, $url);
$result = curl_exec ($ch);
// Recuperamos los campos ocultos
preg_match('//', $result, $match);
$authenticity_token = $match[1];
preg_match('//', $result, $match);
$siv = $match[1];
// Insertamos el texto
$res = $url ="http://twitter.com/status/update";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_POSTFIELDS, 'siv='.$siv.'&authenticity_token='.$auth.'&status=[texto]');
curl_exec ($ch);
curl_close ($ch);
unset($ch);
?>
¿Qué fallo tiene este script? pues que si cambian el HTML (campos de formulario, …) o las URLs deja de funcionar, pero al menos no tenemos limitaciones. Eso sí, es más costoso para sus servidores y para los nuestros, porque en vez de hacer una llamada, hacemos 3, y en nuestro caso, a parte parseamos una página para obtener dos campos ocultos.