Traduce tu plugin para Gutenberg

Traducir los plugins desde WordPress es bastante fácil, tan solo tienes que ejecutar este comando para generar los ficheros .pot.

wp i18n make-pot .

Una vez generados los ficheros de traducción, yo uso PoEdit, el siguiente paso es generar los ficheros JSON, ya que Gutenberg es lo que usa.

Para ello utilizaremos la herramienta po2json, que podrás instalar ejecutando:

npm i -g po2json

Cuando se haya instalado tendremos que generar el fichero json ejecutando desde el directorio donde están los ficheros de traducción:

po2json mi-plugin-es_ES.po mi-plugin-es_ES-mi-plugin-handler.json -f jed

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' );

Snippets Block en WordPress.org

Snippets Block en WordPress.org

El otro día comentaba que estaba haciendo un plugin para WordPress que permitiera añadir snippets como bloques en Gutenber.

Por fin el otro día aprobaron el plugin en el directorio de WordPress.org, así que ya sabéis, si os viene bien, podéis instalarlo en vuestras webs.

Por cierto, echad un ojo al script que venía incluído dentro del boilerplate que usé. Está genial para poder subir al SVN de WordPress.org los cambios realizados en GitHub. Etiqueta versiones, sube a WP.org, …

Snippets Blocks en WordPress.org

Gutenberg Snippet block

Últimamente estoy trabajando bastante con Gutenberg, tiene sus cosas buenas y malas. Sea como sea, es el futuro de WordPress, así que toca aprender.

Lo más interesante de todo es poder usar lo que sabía de webpack, React, HMR, … Y para practicar he hecho un plugin que permite añadir snippets de código en los posts usando los bloques de Gutenberg

Para ello uso la librería highlight.js que permite destacar código de forma sencilla. Aquí un ejemplo

//  Import CSS.
import './scss/style.scss';
import './scss/editor.scss';
import icon from './icon';
import edit from './edit';
import save from './save';
import attributes from './attributes';

import { __ } from '@wordpress/i18n'; // Import __() from wp.i18n

export const name = 'sentidoweb/snippet';

export const settings = {
	// Block name. Block names must be string that contains a namespace prefix. Example: my-plugin/my-custom-block.
	title: __( 'Snippets editor', 'sw-snippet' ), // Block title.
	icon: icon,
	category: 'common', // Block category — Group blocks together based on common traits E.g. common, formatting, layout widgets, embed.
	keywords: [
		__( 'code', 'sw-snippet' ),
		__( 'format', 'sw-snippet' ),
		__( 'snippet', 'sw-snippet' ),
	],

	attributes,
	edit,
	save,
};

Snippet Block en Github

Testear un plugin de WordPress con PHPUnit

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' );
|

Búsquedas geolocalizadas en WordPress

Este es un ejemplo raro de uso de WordPress, pero el otro día una persona lo preguntaba en el foro de soporte de WordPress. El usuario tenía los posts geolocalizados (latitud/longitud), supongo con postmetas correspondientes.

Para poder realizar este tipo de búsquedas es necesario usar MySQL procedures, claro que no todos los hosting lo permiten:

CREATE PROCEDURE geodist (IN mylat decimal(18,12), IN mylon decimal(18,12), IN dist float)
BEGIN
declare lon1 float;
declare lon2 float;
declare lat1 float;
declare lat2 float;
set lon1 = mylon-dist/abs(cos(radians(mylat))*69);
set lon2 = mylon+dist/abs(cos(radians(mylat))*69);
set lat1 = mylat-(dist/69);
set lat2 = mylat+(dist/69);
SELECT p.*, 3956 * 2 * ASIN(SQRT( POWER(SIN((mylat -lat.meta_value) * pi()/180 / 2), 2) +COS(mylat * pi()/180) * COS(lat.meta_value * pi()/180) *POWER(SIN((mylon - lon.meta_value) * pi()/180 / 2), 2) )) as distance FROM wp_posts as p, wp_postmeta lat, wp_postmeta lon WHERE p.ID = lat.post_id and lat.meta_key = 'latitude' and p.ID = lon.post_id and lon.meta_key = 'longitude' and lon.meta_value between lon1 and lon2 and lat.meta_value between lat1 and lat2
and post_status = 'publish'
having distance < dist ORDER BY Distance;
END

Una vez creado el procedure deberemos llamarlo para obtener los resultados:

global $wpdb;
$posts = $wpdb->query($wpdb->prepare('call geodist(?, ?, ?)', $lat, $lon, $dis));

Acceder al código en Gist

Editores visuales para WordPress

Cada vez que tengo que usar un theme y me encuentro con el Visual Composer me dan los siete males. De todas formas, entiendo que si vas a crear contenido con diferentes módulos en cada página, los editores visuales pueden ser una buena solución.

El problema es que el Visual Composer cuesta unos 30$, y sinceramente, si puede ser gratis, mejor que mejor. Aquí paso un listado de los que he encontrado y que más me han gustando:

Esto realmente es un listado para que tenerlo apuntado en algún sitio y luego tirar de él cuando lo necesite.

Revolution Slider y W3 Total Cache

Me he encontrado con un problema con RevSlider y W3 Total Cache, cuando actualizo un slider no se renueva la caché. La verdad es que no me gusta nada RevSlider, y para colmo no hay ningún action que permita añadir funciones extra, por lo que para poder borrar la caché cuando se actualiza un slider, tengo que meter mano a la acción ajax:

add_action( 'wp_ajax_revslider_ajax_action', 'purge_cache', 1);
function purge_cache() {
  // Me aseguro que sea cuando se actualiza el slider
  if (isset($_POST['client_action']) && $_POST['client_action'] == 'update_slide') {
    // Si está instalado el plugin
    if( class_exists('W3_Plugin_TotalCacheAdmin') ) {
        $plugin_totalcacheadmin = & w3_instance('W3_Plugin_TotalCacheAdmin');
        // Borro toda la caché, seguro que hay un método que borra la página específica
        $plugin_totalcacheadmin->flush_all();
    }
  }
}

Traducir Contact Form 7 en widgets usando WPML

O bien no me enteré, o bien la solución que plantean desde Contacto Form 7 para traducir formularios no me servía. Ellos proponen crear otro formulario en otro idioma y añadir cada formulario en la página correspondiente a su idioma. ¿Pero qué pasa cuando el formulario no está en una página sino en un widget dentro de un sidebar?, pues que necesitaremos traducir las cadenas de texto mediante WPML.

Para ello nos creamos un filtro que coge los values de la etiqueta, las registra en WPML y las traduce:

add_filter( 'wpcf7_form_tag', 'wpml_cf7_tags');
function wpml_cf7_tags($scanned_tag, $exec ) {
  foreach($scanned_tag['values'] as $i=>$v) {
    icl_register_string('Contact Form 7', $v, $v);
    $scanned_tag['values'][$i] = icl_t('Contact Form 7', $v, $v);
  }
  return $scanned_tag;
}

Ahora solo falta traducir las cadenas desde WPML.

Añadir notificación de actualizaciones en el menú del admin de WordPress

Si queremos indicar que hay novedades en algún elemento del menú del admin de WordPress, tendremos que añadir un simple filtro en nuestro functions.php. Esto puede ser necesario por ejemplo si tenemos un Custom Post Type y se actualiza mediante un cron, el usuario podría tener un vistazo rápido de como ha ido el cronjob si usamos ese tipo de notificaciones.

Clipboard01

Para añadir estas notificaciones tendremos que hacer uso del filtro add_menu_classes, que aunque no creo que esté pensado para esto, nos permite modificar el menú antes de ser dibujado. En el filtro tendremos que buscar la opción del menú por la acción que realiza (posición 2 del array) y añadir un pequeño HTML en el título (posición 0 del array). Buscamos por la acción y no por el título ya que si usamos multi-lenguaje nos puede dar problemas.

add_filter( 'add_menu_classes', 'admin_menu_updates');
function admin_menu_updates( $menu ) {
  foreach($menu as $i=>$item) {
    if ($item[2] == 'edit.php?post_type=miposttype') {
      $c = get_transient( 'contador_updates_miposttype' );
      if ($c) $menu[$i][0] .= ' '.$c.'';
    }
  }
  return $menu;
}

Yo en este caso el valor lo almaceno usando la API de Transients, pero vosotros lo podéis gestionar como os venga mejor.

Acceder a WordPress en localhost desde tu red WIFI

Uno de los problemas a los que nos enfrentamos al desarrollar en responsive es que en local es difícil acceder a nuestro localhost desde móviles y tablets. Aunque con unos sencillos pasos podremos acceder sin problemas.

Primero tendremos que modificar nuestro vhosts de Apache para que acepte peticiones desde la red, añadiendo lo siguiente:

<VirtualHost [IP de nuestro ordenador en la red]>
    ServerAdmin [IP de nuestro ordenador en la red]
    DocumentRoot "[path a nuestro WP]"
    ServerName [IP de nuestro ordenador en la red]
    LogLevel debug
    ErrorLog "logs/wordpress-error.log"
    CustomLog "logs/wordpress-access.log" combined
</VirtualHost>

A continuación tenemos que modificar el wp-config.php para decirle el WP_SITEURL y el WP_HOME que variará si se accede desde nuestro ordenador o desde un móvil o tablet.

// Hay que ver si la IP desde la que accedemos es del rango de nuestra red que normalmente suele ser 192.168.1.x
if(preg_match('#^192\.168\.1\.\d+#', $_SERVER['HTTP_HOST'])) {
  define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].'/');
  define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST'].'/');
}

Y ya por último nos creamos un plugin que sustituirá toda referencia a la URL de local por la correspondiente que se encuentre en el contenido de los posts y que activaremos cuando trabajemos en local, o bien lo metemos en el functions.php, pero esto sería guarrear el código:

if(preg_match('#^192\.168\.1\.\d+#', $_SERVER['REMOTE_ADDR'])) {
  function replace_domain($buffer) {
    // modify buffer here, and then return the updated code
    return str_replace('http://localhost/', 'http://'.$_SERVER['HTTP_HOST'].'/', $buffer);
  }
  
  function buffer_start() { ob_start("replace_domain"); }
  
  function buffer_end() { ob_end_flush(); }
  
  add_action('wp', 'buffer_start');
  add_action('wp_footer', 'buffer_end');
}

Tienes el plugin disponible en mi repositorio de GitHub