Últimamente no ando muy sobrado de tiempo, por lo que no posteo tanto como me gustaría, además, hay pocos temas que considere interesantes como para hacer un post, pero si son lo suficientemente interesantes para realizar un post rapidillo, a ser posible automático.
Es por ello que me he creado un plugin para WordPress, que cuando tenga tiempo lo puliré y publicaré, que me permite postear directamente desde Google Reader usando lo de “Enviar a”, vamos que con una llamada a una URL tipo http://sentidoweb.com/[path_seguridad]/[token]/${title}%20${source} publicaré directamente en mi blog, así podré pasaros posts que considere interesantes.
Muchos diseñadores suelen mostrar los menús en una línea separados entre ellos por una línea salvo el último elemento. El problema está en cómo diferenciar el último elemento para que no tenga ese estilo. Para ello tendremos que meter este código en el functions.php
add_filter( 'wp_nav_menu_objects', 'add_last', 10, 2);
function add_last($sorted_menu_items, $args) {
$c = 0;
foreach($sorted_menu_items as $i=>$item) {
$c++;
if ($c == count($sorted_menu_items)) {
$sorted_menu_items[$i]->classes[] = 'last';
}
}
return $sorted_menu_items;
}
La verdad es que se podria hacer con los selectores de CSS, pero aunque parezca mentira, no son compatibles con IE7, y algunos clientes aún usan el dichoso navegador.
No es la primera vez que me toca buscar malware en algún WordPress, y la verdad, suele ser un dolor de cabeza. Básicamente usan dos funciones: eval y base64_decode. Con eval nos meterán el código malicioso, que estará codificado en base64 para evitar que lo encontremos fácilmente.
Si tenéis acceso al SSH del servidor, una llamada a find . -name '*.php' -exec grep -l 'base64' {} \; suele bastar para encontrar este tipo de llamadas, o buscar eval en vez de base64.
Desgraciadamente esto no siempre funciona, ya que la función eval puede estar codificada de la siguiente forma:
Otro punto a tener en cuenta es la posibilidad de que hayan modificado el código de nuestro WordPress, lo cual se puede solucionar reinstalando el WP desde el admin. Aunque también pueden haber modificado el wp-config.php e incluir un fichero php que aparenta ser de WP (normalmente metindo en la carpeta wp-includes) pero que no lo es. Por lo cual es recomendado comprobar el wp-config.php con cualquier versión en local.
A parte de todo esto, es importante el tema de los permisos de los ficheros, etc…
Actualización 29/05/2015: también es aconsejable buscar esta cadena \142\x61\163\145\66\x34\x5f\144\x65\143\x6f\144\145, ya que al hacer un echo nos devuelve la función base64_decode.
Actualización 02/07/2015: buscar también la cadena \x65\x76\x61\x6c, ya que devuelve la función eval.
Soy desarrollador web y actualmente trabajo como responsable de proyectos web en Grupo Trevenque Kaplan. Llevo haciendo webs con más o menos acierto desde el año 1997 desarrollando tareas como maquetador y programador web durante todo este tiempo…
Si por un casual necesitas que tu WordPress realice las búsquedas por el título del post y que ignore el contenido, tan sólo hay que añadir un filtro a tu functions.php, lo cual también sirve para editar las condiciones de búsquedas y añadirle o quitarle condiciones:
add_filter('posts_search', 'mi_search_title');
function mi_search_title($search) {
preg_match('/%([^%]+)%/', $search, $m);
if (isset($m[1])) {
// Original
// " AND (((wp_posts.post_title LIKE '%termino%') OR (wp_posts.post_content LIKE '%termino%'))) AND (wp_posts.post_password = '') "
return " AND wp_posts.post_title LIKE '%$m[1]%' AND (wp_posts.post_password = '') ";
} else {
return $search;
}
}
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' );
Ahora viene la parte más complicada, y digo complicada porque sinceramente he tenido que mirar el código porque algo me fallaba cuando seguía lo que decía la documentación.
El nombre del fichero JSON tiene el siguiente formato [dominio de traducción]-[idioma]-[handler del fichero].json, total nada.
Dominio será el que usemos para traducir, en el ejemplo sería mi-plugin:
__( 'Hola que tal', 'mi-plugin' );
Idioma es el código del idioma, en este caso es_ES
Y por último el handler del fichero es el primer parámetro que usamos en wp_enqueue_script
Lo podemos ver todo en un ejemplo final:
wp_enqueue_script(
'mi-plugin-handler', // El handler mencionado anteriormente
$blocks_script, // Nuestro path
[
'wp-i18n', // De referenciar al menos a wp-i18n
],
);
wp_set_script_translations( 'mi-plugin-handler, 'mi-plugin', plugin_dir_path( __FILE__ ) . 'languages' );