Ha salido un nuevo sitio sobre plugins para WordPress. Entre sus caracterÃsticas tenemos que se pueden votar, nos muestra estadÃsticas sobre el número de veces que se ha descargado, versión, web del plugin, web del autor, tags, descripción, screenshots y comentarios por los usuarios.
Otro sitio más de plugins para WordPress que merece la pena echar un vistazo. WP Plugins
VÃa / dzone
Interesante hack que permite darle más velocidad al plugin de WP-Cache, para lo cual enviará más datos en la cabecera para que el caché sea más rápido: Content-Length y Cache-Control.
Es curioso que para el primero lo que hace el hack es descomentar líneas del código original que por lo visto estaban comentadas porque daban error con algunas instalaciones de PHP. Hack WP-Cache for Huge Speed Increase
La gente de WordPress ha lanzado la versión 2.0.5, la cual es recomendable su descarga para actualizar la versión que disponamos ya que incluye varias correcciones de seguridad. El total de correcciónes está disponible aquÃ, mientras que un resumen de las actualizaciones se puede leer aquÃ.
Existe para la descarga la versión completa y la posibilidad de actualización de la versión 2.0.4 a la versión 2.0.5.
Como dato curioso, hasta ahora no habÃa caÃdo, el sistema de control de errores que usan es Trac, del cual hablábamos gracias a la colaboración de Albert. WordPress 2.0.5
Cuando estamos desarrollando un plugin para WordPress y queremos que la administración del plugin tenga estilos y scripts propios, ya sea para darle cierta interactividad o diseño, o bien podremos incluir los estilos o librerías a pelo en la página del plugin, o bien podremos hacer que WordPress añada lo estilos y los scripts en el head del HTML. Para realizar esto, deberemos utilizar las acciones admin_print_styles y admin_print_scripts:
add_action('admin_print_styles', 'incluir_css');
add_action('admin_print_scripts', 'incluir_script');
function incluir_css() {
echo '';
}
function incluir_script() {
echo '';
}
Una de las opciones que trae WordPress 3.8 es que permite que cada usuario elija una gama de colores para el admin de WordPress. Esto puede ser bastante útil si somos una empresa y queremos que los colores propios se vean reflejados en el administrador de WordPress, por ejemplo para el blog de un cliente.
Para ello deberemos crearnos un CSS (tomando por referencia los que hay en wp-admin/css/colors) y meterlo en nuestro theme y luego añadir lo siguiente a nuestro functions.php:
add_action('admin_init', 'colores_admin');
function colores_admin() {
wp_admin_css_color( 'id', 'Titulo', // poned el id que querais, si id = fresh modificara el diseño por defecto
get_template_directory_uri(). "/css/admin.css" ,
array( '#f00', '#0f0', '#00f', '#ff0' ), // los cuatro colores que muestran y que deberan corresponder a los del css que hemos creado
array( 'base' => '#0ff', 'focus' => '#f0f', 'current' => '#fff' ) // los textos
);
}
Recordad que WordPress ya no usa iconos, sino font icons, por lo que si queréis añadir o modificar iconos, deberéis crearos una web font con ellos (podéis usar Fontastic).
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' );
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: