la solucion esta en ser libres

espacio producto

Cómo añadir campos personalizados a las revisiones en WordPress

Por David Muñoz
Developer en OpenSistemas

Antes de empezar el artículo quiero aclarar que esta es una solución que he aplicado personalmente, después de investigar creo que es la correcta, pero no lo puedo confirmar. Por ello, invito a quien conozca una manera mejor de realizarlo que lo indique y entre todos consigamos estandarizar esta funcionalidad, que a priori parece poco documentada.

Para empezar, vamos a hablar de las revisiones y de su funcionamiento por defecto en WordPress. Para el que no conozca WordPress, recuerdo que, por defecto, tiene implementado un sistema de revisiones que permite un control de versiones de los post. Dicho sistema ofrece un historial de cada cambio y la posibilidad de volver a una versión anterior del artículo, post o publicación.

Por defecto, estas revisiones están activadas y no tienen límite. Además, existe una opción de autoguardado que añade una foto a este conjunto de revisiones.

Si queremos controlar estos parámetros podemos modificar las constantes AUTOSAVE_INTERVAL y WP_POST_REVISIONS, con las cuales podemos controlar el intervalo de tiempo del autosave y el número máximo de revisiones por post o si las queremos tener activas.

Y, ¿cuándo se guardan las revisiones? Podríamos pensar que existe un check para indicar que, cuando le demos a actualizar o a publicar el post, la foto actual se va a guardar como una revisión del post. No obstante, esto no ocurre, ya que WordPress maneja las revisiones de tal forma que si guardamos como borrador o publicamos un post, si alguno de sus “campos por defecto” ha sido modificado, automáticamente, y solo si las tenemos activadas, crea una nueva revisión y la añade a nuestro listado de revisiones.

Lo que guarda de esta manera es útil, aunque limitado, pero lo que me parece más limitado y aquí es donde quería llegar cuando hablaba de campos por defecto, es que solo esté observando el title, el content y el excerpt para tener en cuenta modificaciones. Y a partir de aquí, mi problema y el motivo de este post: ¿qué pasa con los post meta y las taxonomías asociadas a un post? ¿Qué hacer si las quieres versionar?

Pues tranquilo, WordPress nos facilita herramientas para poder indicarle qué post meta te gustaría versionar y añadir al seguimiento.

A modo de receta, para esta pequeña implementación vamos a necesitar los siguientes hook: edit_post, save_post, wp_restore_post_revision, _wp_post_revision_fields, _wp_post_revision_field_{nuestro_meta}.

- edit post es un action que se ejecutará cuando se edite un post que ya está creado.
- save_post es un action que se ejecutará cuando creemos o acualicemos un post.
- wp_restore_post_revision es un action que se ejecutará cuando revirtamos a una versión anterior de nuestro post.
- _wp_post_revision_fields es un filtro en el que le indicamos al sistema qué “campos” o “post meta” queremos que tenga en cuenta para comparar entre la nueva versión y la antigua del post.
- _wp_post_revision_field_{nuestro_meta} es un filtro que nos permitirá darle formato a nuestro meta para que sea legible por la clase wp_diff.

Es necesario formatear todos los campos que no sean texto, ya que esta clase solo compara textos y, si no lo hacemos, en la pantalla de revisión nos mostrará el siguiente mensaje: “Sorry, something went wrong. The requested comparison could not be loaded.” También puede darse el caso de que no se pinte ninguna de las columnas de comparación.

Bien, dichos los ingredientes, antes de empezar a meter código de ejemplo es bueno saber el flujo de lo que sucede cuando damos al botón Publicar.

En primer lugar, se ejecuta el action edit_post, después la comparación de campos del post con los de la última revisión. Si encuentra algún campo diferente, crea una nueva revisión y, por último, se ejecuta el action save_post.

Y, ¿por qué cuento esto? Porque si nosotros estamos ‘seteando’ nuestros campos en el save_post, cuando hace la comparación en el paso 2, el valor con el que compara la revisión actual es nulo, es decir, compara nulo con lo que hubiera en la última. Lo peor de todo es que se crea una revisión con valores erróneos.

Además, es importante marcar -y lo difícil de comprender, pero la clave- que en action edit_post, si preguntamos por la última revisión, se trata de la anterior a guardar el post. Si en el save_post se ha detectado cambio en algún campo, la última revisión es la creada con nuestros nuevos valores, es decir, almacena los cambios o las diferencias que hemos añadido nuevas con respecto al estado anterior.

Dicho esto, lo primero que tenemos que hacer es guardar los datos de los post meta en el action edit_post.

function save_postdata($post_id, $post, $update = null) {
if (!current_user_can('edit_post', $post_id))
return $post_id;

$mymeta = sanitize_text_field($_POST['mymeta']);
update_post_meta($post_id, 'mymeta', $mymeta);
}
add_action("edit_post", 'save_postdata');

En el proceso interno del WordPress comparará los campos y ya los verá actualizados, por lo que al verlos diferentes creará una nueva revisión. En esta nueva revisión es donde setearemos los nuevos valores.

function os_revision_save_post( $post_id ) {
    if (!current_user_can('edit_post', $post_id))
        return $post_id;

    //Obtenemos la última revisión vigente
    if ( $revisions = wp_get_post_revisions( $post_id ) ) {
        // grab the last revision, but not an autosave
        foreach ( $revisions as $revision ) {
        if ( false !== strpos( $revision->post_name, "{$revision->post_parent}-revision" ) ) {
            $last_revision = $revision;
            break;
        }
    }
}

//Obtenemos el meta actual del post
$mymeta = get_post_meta($post_id, 'mymeta', true);
//Se lo seteamos a la última revisión
update_metadata( 'post', $revision->ID, 'mymeta', $mymeta );

}
add_action( 'save_post', 'os_revision_save_post');

Una vez añadidos los campos a la última revisión, es muy posible que en futuro queramos recuperar este tipo de valores, pues bien para ello le tenemos que indicar a WordPress cómo hacerlo:

//Reverting to the correct revision of the meta field when a post is reverted
function os_revision_restore_revision( $post_id, $revision_id ) {

$post     = get_post( $post_id );
$revision = get_post( $revision_id );

//Se obtiene el meta de la revisión elegida
$mymeta  = get_metadata( 'post', $revision->ID, 'mymeta', true );

//Se 'setea' el meta para el post
if ( false !== $mymeta )
update_post_meta( $post_id, 'mymeta', $mymeta );
else
delete_post_meta( $post_id, 'mymeta' );

}
add_action( 'wp_restore_post_revision', 'os_revision_restore_revision', 10, 2 );

¿Bueno, pero cómo se le dice a WordPress en qué campos tiene que mirar? Pues con el siguiente filtro:

//Displaying the meta field on the revisions screen
function os_revision_revision_fields( $fields ) {

//Filtro key=>value con el key del meta y el nombre a desplegar en la página de comparación.
$fields['mymeta'] = 'Title mymeta';

return $fields;

}
add_filter( '_wp_post_revision_fields', 'os_revision_revision_fields' );

Y, por último, ¿qué pasa si mi meta es un array y no es un texto? Me gustaría que también lo comparase. Pues, para ello, necesitamos hacer dos cosas: primero (y lo que menos me gusta), tocar el core, que no se debería hacer pero en este caso me he visto obligado para que los campos los convierta en un tipo serializado. De esta manera, podremos comparar arrays como string.

Para ello, vamos a wp-includes/revision.php sobre la línea 131 y cambiamos:

- if ( normalize_whitespace( $post->$field ) != normalize_whitespace( $last_revision->$field ) ) {

por

+ if ( normalize_whitespace( serialize($post->$field) ) != normalize_whitespace( serialize($last_revision->$field) ) ) {

Ya, por último, solo tenemos que dar formato a nuestro meta que nos llegará como un array y transformarlo en string para que sea comparable dentro de la clase wp-diff de WordPress. Esto se puede configurar al gusto de cada uno. En mi caso, al tener un array multidimensional que contiene el title, la url y el size de un fichero, lo filtro de esta manera:

function os_diff_custom_documento($compare) {
if(is_array($compare)) {
$output = '';
foreach ($compare as $document) {
$output .= 'Title:'.$document['title'].' Url:'.$document['url'].' Size:'.$document['size'].'
';
}
return $output;
}else {
return $compare;
}

}
add_filter( '_wp_post_revision_field_custom_documento' , 'os_diff_custom_documento' );

Una vez hecho esto, ya podemos hacer pruebas con nuestro post y jugar con los diferentes campos para ver si se están versionando correctamente.

Ahora bien, ¿qué pasa con las taxonomías? ¿Se pueden versionar? Pues a priori parece que no (que nos vamos a tener que buscar la vida), pero con un pequeño truco sí que es posible. Así que dejo pendiente para un próximo post explicar cómo se pueden versionar taxonomías de una publicación, aunque la idea es basarnos en un sistema similar de metas como el actual.

Espero que os sea de utilidad y si alguien tiene un sistema mejor, por favor, estoy abierto a opiniones y me encantaría escucharlas.

También querría hacer mención a John Blackbourn https://johnblackbourn.com/post-meta-revisions-wordpress del cual copie parte del código y me mostró un poco el camino hacia el sistema actual.

The post Cómo añadir campos personalizados a las revisiones en WordPress appeared first on Blog de Open Sistemas.

2015: Cambia el chip

Por Luis Flores
CEO en OpenSistemas

‘Cambia el chip’, de Chip y Dan Heath, dos reconocidos especialistas en comportamiento organizacional, también subtitulado ‘Cómo afrontar cambios que parecen imposibles’, es el libro con el que comienzo el año, tras haber leído en Navidad ‘El talento de los adolescentes’, escrito por el filósofo y pedagogo español José Antonio Marina.

‘Cambia el chip’ es una obra enormemente útil que recomiendo fervientemente a todos aquellos que quieran afrontar con éxito cambios en organizaciones o en su propia vida, alcance dentro del cual creo que cabemos todos.

Los autores hacen una analogía potente, pero a la vez gráfica y fácil de entender. Asemejan nuestro comportamiento al de un jinete sobre un elefante. El elefante simboliza nuestra parte emocional, mientras que el jinete lidera nuestra racionalidad. Encaramado sobre el elefante, el jinete sujeta las riendas y parece ser el líder. Pero el control del jinete es precario, porque es muy pequeño comparado con el elefante. El hombre vive inmerso en ese confrontamiento bipolar.

El ansia del elefante por la gratificación inmediata es lo opuesto a la fortaleza del jinete, que tiene capacidad para ver a largo plazo, planificar y pensar más allá del momento. Pero el elefante también tiene fortalezas enormes, y el jinete, debilidades muy serias. El territorio del primero son las emociones: el amor, la compasión, la simpatía y la lealtad o el instinto de proteger a sus hijos. Para progresar hacia un objetivo hay que contar con la energía y la determinación del elefante. El jinete, en cambio, no deja de darle vueltas a las cosas: tiende a analizar y pensar excesivamente en ellas.

Uno de los aspectos más interesantes del libro es la capacidad que tiene de hacernos ver lo importante que son las emociones en nuestro comportamiento, por mucho que hagamos gala de ser personas muy racionales tomamos de manera emocional muchas más decisiones de lo que podemos llegar a creer, de modo que sugiere que se use lo emocional como palanca para dar fuerza a nuestra racionalidad, obtener toda la fuerza que te da el elefante, siguiendo la analogía.

Otro aspecto en el que incide es en el manejo del contexto y de cómo muchos problemas desaparecen con una inteligente gestión del contexto. De este modo, a veces resulta más sencillo cambiar el contexto que intentar modificar el comportamiento de las personas, obteniéndose de manera más sencilla la resolución del problema.

Así, el secreto del cambio en las organizaciones, según los autores, radica en ofrecer instrucciones y siguientes pasos sencillos al jinete (algo en lo que también incide por citar otro ejemplo que nos es cercano, GTD como metodología), potenciarlos motivando y emocionando al elefante que somos, para así obtener toda la energía posible para impulsar el cambio y trabajar el contexto para facilitar todo el proceso.

Pero el libro no se queda en la simple idea y presentación de este sistema, sino que glosa el modelo aportando una enorme cantidad de ejemplos, casos y pequeñas recetas que nos serán de utilidad en este tipo de procesos.

En la época de la inteligencia emocional, de la asertividad o de la empatía, este tipo de libros actúan de potentes guías prácticas para desarrollar nuestro talento. Así es que ahí va mi recomendación para este inicio de año.

The post 2015: Cambia el chip appeared first on Blog de Open Sistemas.

Three.js 3D en nuestros navegadores web

Por José Manuel Cristóbal
Consultor Open Source en OpenSistemas

En octubre de 2014 el World Wide Web Consortium (W3C) publicó la versión definitiva de la quinta revisión del estándar de HTML. El CEO de la W3C Jeff Jaffe, dijo “Ahora estamos en un punto estable en el que cualquiera puede construir sobre el estándar y tener la certeza de que funcionará en todos los navegadores”.

Citando a Tim Berners-Lee, director del W3C y creador de la WWW, dijo “Hoy en día no damos importancia a ver vídeo y audio de forma nativa en el navegador, o de ejecutar un navegador en un teléfono”, “Esperamos poder compartir fotos, comprar, leer noticias y buscar información donde sea, en cualquier dispositivo. Aunque sigue siendo invisible para muchos usuarios, el HTML5 y la Open Web Platform están conduciendo estas expectativas crecientes de los usuarios”.

Lo cierto es que HTML5, incorpora nuevos elementos y atributos, unos más ocultos de cara al usuario, como la semántica de las etiquetas y otros más visuales como el audio, vídeo o canvas.

A canvas 2D, popularmente se le conoce como “el sustituto Flash Player”, pero canvas también es capaz de renderizar y crear 3D interactivos en los navegadores, sin necesidad de plugins de terceros.

Actualmente, los navegadores están desarrollando y mejorando el WebGL, que es la especificación estándar basada en OpenGL 2.0, para mostrar gráficos 3D acelerados por hardware GPU, (unidad de procesamiento gráfico). A fecha de hoy el navegador más aventajado para el renderizado 3D, es el navegador Google Chrome.

A la par, se están desarrollando nuevas librerías de JavaScript, que facilitan la programación de WebGL, entre ellas la más popular y la que tiene más seguidores es Three.js

Three.js fue creada por el español Ricardo Cabello en abril de 2010, en un principio fue desarrollado para flash action script y después fue trasladado a JavaScript, pudiendo renderizar en canvas y en SVG, posteriormente Paul Brunt añadió un módulo para renderizar en WebGL. En la actualidad hay más de 90 programadores que están manteniendo esta librería.

Las características principales son:

  • Renderizadores: Canvas, SVG y WebGL.
  • Efectos: Anaglyph, cross-eyed y parallax barrier.
  • Escenas: añadir y eliminar objetos en tiempo de ejecución; efecto niebla.
  • Cámaras: perspectiva y ortográfica; controladores: trackball, FPS, trayectoria y otras.
  • Animación: armaduras, cinemática directa, cinemática inversa, morphing y fotogramas clave.
  • Luces: ambiente, dirección, luz de puntos y espacios, sombras: emite y recibe.
  • Materiales: Lambert, Phong, sombreado suave, texturas y otras.
  • Shaders: el acceso a las capacidades del OpenGL Shading Language (GLSL): reflejos en la lente, pase profundo y una extensa biblioteca de post-procesamiento
  • Objetos: mallas, partículas, sprites, líneas, cintas, huesos y otros.
  • Geometría: plano, cubo, esfera, toroide, texto en 3D y otras; modificadores: torno, extrusión y tubo.
  • Cargadores de datos: binario, imagen, JSON y escena.
  • Utilidades: conjunto completo de funciones matemáticas en 3D, incluyendo tronco, matriz Quaternian, UVs y otras.
  • Exportación e importación: utilidades para crear archivos compatibles con JSON Three.js desde: Blender, openCTM, FBX, Max, y OBJ.
  • Soporte: La documentación de la API se encuentra en construcción, foro público y wiki.
  • Ejemplos: Más de 150 archivos de códigos de ejemplo más las fuentes, modelos, texturas, sonidos y otros archivos soportados.
  • Depuración: Stats.js, WebGL Inspector, Three.js Inspector.

En un futuro creo, que esta tecnología encierra un gran potencial por explorar, a simple vista podríamos pensar que sólo se hará un uso exclusivo en video juegos, pero también puede adaptarse a nuevas formas de representar la información, con interfaces interactivas en 3D, haciendo un uso adecuado de esta tecnología.

Una alternativa podría ser una interfaz para navegadores web, que sea capaz de hacer, una representación gráfica interactiva, de recogida de datos actualizados de votaciones, con animaciones de mapas en 3D, etc, el resto queda para nuestra imaginación.

El tiempo nos irá diciendo, cuáles son las soluciones que hoy parecen impensables, y que mañana se convertirán en hechos cotidianos, sin apenas darnos cuenta.

A mí particularmente me ha picado el gusanillo y he estado trasteando con Three.js. Añadiendo objetos, jugando con luces y movimientos, al final me ha quedado una especie de salva pantallas, con el cual aprovecho para desearos que tengáis un Próspero Año Nuevo.

Para visualizar esta demo, pinchar en este link. Es recomendable usar el navegador Google Chrome actualizado, en un ordenador con una potencia de mediana a alta.

En Three.js hay muchos más ejemplos interesantes, que muestran las posibilidades de los navegadores web actuales.

The post Three.js 3D en nuestros navegadores web appeared first on Blog de Open Sistemas.

OpenSistemas presenta en LibreCon 2014 uno de los talleres más novedosos en torno a Moodle y la nube de Microsoft

Éxito de participación, dinamización de negocios y máxima visibilidad de un sector en crecimiento que está ayudando a mejorar la competitividad de las organizaciones. Las tres ideas son un buen resumen de LibreCon 2014, el IV Congreso Nacional de Software Libre y Tecnologías Abiertas celebrado los pasados días 11 y 12 de noviembre en Bilbao y que ha contado con la asistencia de casi 1.500 personas y emprendedores procedentes de 600 empresas, administraciones públicas y otras organizaciones.

En este contexto de éxito por los resultados logrados, OpenSistemas ha protagonizado uno de los talleres más novedosos en tanto en cuanto ha sido la única compañía que ha presentado un despligue de entornos de elearning en la infraestructura cloud de Microsoft bajo el título Granja de Moodle de altas prestaciones en la nube.

Read the rest of this entry »

Una pequeña reflexión sobre la nueva forma de “ligar”

Por Juan Lotito
Soporte en OpenSistemas

Las nuevas marcas de desarrolladores no han estado exentas de esta búsqueda de felicidad, sobre todo, la nueva gama de aplicaciones móviles para encontrar pareja. Todos Conocemos Badoo, Meetic y demás, pero es en la nueva hornada en la que me gustaría detenerme. Un fenómeno que ya ha captado a más de 100.000 españoles de entre 20 y 35 años. Se trata de las aplicaciones Tinder y Happn.

No, nos confundamos… No son más que redes sociales, igual que Badoo, igual que Facebook, Twitter, etc. ¿Cuál es el factor diferencial? Primero, la fama que se ha creado, tú te registras en Tinder o Happn si buscas una cosa determinada. Uno entra en Facebook para buscar amigos, otro entra en Twitter para expresarse en 200 caracteres, pues entras en Tinder si buscas relaciones sexuales, no confundir con relaciones amorosas. El proceso de funcionamiento en ambas redes sociales es un poco diferente, pero igualmente atractivo y eficaz.

En Tinder el proceso de registro es como en cualquier red social, con la diferencia que tienes que añadir cuatro fotos que te definan, después de registrarte, el sistema te pide que indiques un radio de acción y un sexo que te gustaría encontrar (chicas o chicos). La idea es que el sistema te pondrá en contacto con las chicas/os que tu elijas dentro de tu radio de acción y que, a su vez, ellas/os te hayan elegido. Una vez hecho el contacto, se abre un chat privado para intimar más. Es importante dejar claro que el chat no está habilitado hasta que las dos personas se han gustado mutuamente, es decir, han hecho un match mutuo. Sobre todo, es muy relevante el apartado del radio de acción, sin duda, lo más innovador, ya que no solo te pone en contacto con la chica/o que quieras, sino que además te dice a qué distancia está de ti. Pero claro, levanta bastante la moral el saber que además de que gustas a alguien, está cerca de ti.

Este sería el proceso de registro, pero el uso general de los usuarios es todavía mas innovador. En vez de estar contestando tus WhatsApps, o viendo la ultima foto de tu ‘ex’ en Facebook, el usuario normal lanza la aplicación y en un momento se le llena la pantalla del móvil con aquellas/os chicas/os que se encuentran en el radio de acción. Para cada chica/o verás su info pública y la serie de cuatro fotos que realizó en el registro. Gracias a esas fotos, se decide si se quiere el match o no. Así que el funcionamiento no es más que ir pasando fotos, una tras otra hasta encontrar a la siguiente “víctima”.

Lo que sorprende de esto es la actuación de las personas una vez han hecho el match mutuo. Todos, hombres y mujeres han adoptado la realidad de que si se ha hecho match, hay posibilidades de tener relaciones sexuales, es decir, esta red social lo único que hace es calmar un sentimiento básico humano y ayuda a encontrar tu complemento para calmarlo. No busquéis al amor de vuestra vida, buscad al amor de esta noche.

La gran diferencia entre Tinder Y Hapn es que el segundo sustituye el radio de acción por encuentros casuales, es decir, si te cruzas por la calle con una chica/o que realmente te atrae, y si está dentro de la red social, te dirá su contacto y seguirás el mismo procedimiento que con Tinder. No es un radio de acción, es confiar en otro concepto: el flechazo ambulante.

The post Una pequeña reflexión sobre la nueva forma de “ligar” appeared first on Blog de Open Sistemas.