Crear un plugin para WordPress con su propia tabla

ByLuis

Interesante artículo en el que nos explican cómo crear un plugin de wordpress usando su propia tabla, algo que no suele necesitarse porque para almacenar datos propios se usan las “options”, pero en algún momento podemos necesitarlo.

Nos explica paso a paso qué hay que hacer:

  • Declarar la función y las variables globales que se necesitan
  • Darle un nombre a nuestra tabla y usar el prefijo de WP
  • Comprobar que la tabla no existe y si no, crearla
  • Añadir la funcionalidad a WordPress
  • Añadir datos a la nueva tabla

Create a Plugin With Its Own Custom Database Table

Similar Posts

Testear un plugin de WordPress con PHPUnit

ByLuis

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

ByLuis

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

Traduce tu plugin para Gutenberg

ByLuis

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