Aunque en varios artÃculos hemos hablado de cómo manipular imágenes mediante PHP y GD. No está nada mal, tener un tutorial que nos ayude con esta librerÃa. En el siguiente tutorial podremos encontrar:
El spam se ha convertido en uno de los mayores problemas con los que nos podemos enfrentar a la hora de desarrollar una aplicación web. Si estás en el proceso de creación de una aplicación, te va a venir bastante bien la lectura de los artÃculos que os pasamos a continuación y de los que hacemos un pequeño resumen.
Reescribir: Tan sencillo como cambiar antispam@example.com por antispam [ARROBA] example [PUNTO] com.
Uso de imágenes: sustituir la dirección de correo electrónico por una imagen que muestre el mismo texto, ya sea mediante una imagen estática o una dinámica creada mediante PHP.
Uso de formularios: aunque no te evita del todo el spam, si no muestras tu email y usas un formulario en su lugar, conseguirás que te llegue menos spam.
Moderadores: se trata de que personas aprueben el contenido de los mensajes antes de que sean publicados.
Filtros: tener filtros de palabras no permitidas, asà como direcciones IP o números de enlaces posibles que identifiquen los mensajes como posibles spam.
Validación de email: se envia un email con una url que valida y finaliza el proceso de inscripción.
Aunque parezca mentira cada vez es más frecuente la necesidad de usar geoposicionamiento en nuestras aplicaciones web, sobre todo si queremos darle este toque web2.0 tan de moda.
En el tutorial que hacemos referencia nos guía paso a paso por todo lo que necesitamos saber para usar Google Maps en nuestras aplicaciones.
Desde una pequeña introducción a lo que es el geocoding, pasando por el uso de Google Maps: obtener key, realizar llamadas al API de Google, explicación de la respuesta devuelta por el API; hasta la obtención de datos mediante PHP y la creación de una clase para tratar con el API. Geocoding with PHP and the Google Maps API
Vía / PHPDeveloper.org
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' );