A otras cosas …

Prefiero no recordar (ni hablar) de como termino mi infernal 2014 y empezó 2015, tanto a nivel profesional como personal. Afortunadamente desde hace unos meses estoy en un trabajo nuevo, rodeado de gente de talento y en una empresa con voluntad (y muy importante: mentalidad) de crear producto.

Aprovecho este tirón y cambio de rumbo, y dejo esto aquí solo como testigo temporal de un “antes y un después”.

Fundido a negro … y reset.

Pon a Vagrant en tu vida, no esperes más

vagrant-icoLlevaba ya un tiempo con ganas de ponerme a usar de una vez Vagrant. Aun teniendo claro las ventajas que ofrece y todo lo que soluciona, el tema de probarlo, aprender un flujo de trabajo con el, establecer la configuración optima, etc … se hacia imposible dentro del asfixiante día a día en que he estado sometido estos últimos meses.

Pero hoy ha llegado el momento. Realmente instalar y tener en marcha un entorno con Vagrant es sumamente fácil y por lo tanto rápido, en pocos minutos he tenido una VM linux dando servicio Web con PHP 5, MySQL, Node, Composer y algunos “habituales” más, montado en mi portátil Windows.

Hay mucha documentación y libros al respecto, ahora también tocara ponerse con algunos de ellos y profundizar, pero para empezar yo he encontrado útiles estos dos recursos:

Como desarrollador empezar a usar una herramienta como Vagrant no solo mejora la “calidad de vida” sino que ademas es un gustazo.

Unos par de comentarios sobre tutorial

El tutorial se desarrolla sobre un entorno MacOSX pero yo lo he realizado en un Windows 8 sin problemas, esos si, usando como consola Git Bash, que es el shell que se instala junto con Git para Windows. Esta consola (shell) incorpora los comandos más habituales de un entorno Unix, entre ellos el ssh.

Otro cosa a tener en cuenta es que en el punto 5 del tutorial se indica que debes hacer un:

$ vagrant reload --provisioning

Pero esto no es correcto, la orden correcta es:

$ vagrant reload --provision

Por lo demas, todo perfecto.

Y unos comentarios sobre el Vagrant provision script que he usado

De scripts de estos se pueden encontrar varios en Internet, este es el que me ha parecido más practico para mi caso en estos momentos, puede que para otras situaciones no lo sea. Si lo usas ten en cuenta que:

  • Debes recordar configurar el nombre de la BBDD, usuario y password en las variables del principio del script
  • Usando este script, el directorio de documentos que deja configurado en Apache es: /vagrant/public y no el /vagrant a solas como queda configurado en el ejemplo del tutorial

Consumiendo servicios SOAP y REST en WordPress

Recientemente he trabajado en un proyecto web en WordPress en que la web tenia que dar acceso a fuentes de información “externas”, en concreto:

  • Acceder a consultar contenidos en otro servidor. Contenidos que se recibian a traves de un API Rest modelados en JSON.
  • Registrar usuarios en un servicio de newsletter propio del cliente, usando un API SOAP

Implementar esto con WordPress no es muy complicado porque detrás no hay más que PHP, pero quiero dejar anotadas algunas cosas.

Para empezar el consumo de estos dos servicios lo desarrolle como plugins de WordPress, de manera que quedaban independientes de los ficheros propios del theme, esta es una practica recomendable, ya que Wordpress no contempla el patrón MVC, pero eso no quita que separemos las cosas de una manera razonable para facilitar mantenimiento y escabilidad y en eso los plugins son parte vital.

Por otra parte cada uno de estos casos tenia un tratamiento diferente para WordPress, mientras que en el caso del API REST podemos usar directamente la función wp_remote_request() del API de WordPress ya que vamos a realizar una llamada GET. Para el caso de una conexión SOAP se implementa todo con la típica SoapClient de PHP.

Conectar a una API REST

Usando wp_remote_request() primero definimos los parametros de conexión. Se trata de un API REST que espera autentificar la conexión mediante un API KEY que nos habran asignado y (en este caso particular) una URL de referencia. Si alguno de estos parametros no es correcto no tendremos acceso.

Esto lo hacemos asi:

$args_api = array('headers' => array('X-API-KEY' => $_EL_API_KEY_ASIGNADO,
 'URL_BASE' => $_SERVER["HTTP_HOST"]) );

Luego a la URL que tenemos asignada para conectarnos a la API le añadimos los parámetros deseados de la conexión tipo GET que realizamos, esto es lo que hacemos aquí, evidentemente en este caso es solo un ejemplo:

$url_api.='/publicaciones_descargas/limit/1';

Con la URL de conexión a la API y los parametros para autentificarnos, lanzamos la conexión:

$losdatos = wp_remote_request($url_api,$args_api);

La función wp_remote_request() nos devuelve un array con el resultado de la conexión, en el item ‘body’ de ese array (en este caso) esta todo el resultado recibido desde la API. Solo nos queda tratarlo como necesitemos, en este ejemplo paso los datos recibidos en formato JSON a un array $info para su posterior uso en el WordPress:

$info = json_decode($losdatos['body'],true);

 Conectar a una API SOAP

Aquí la cosa es diferente y usamos la class SoapClient. Primero instanciamos el objeto y la conexión:

$Soap_Object = new SoapClient("URL DE ACCESO SOAP A LA API -aqui va el tuyo-",
 array('trace' => true)
 );

Luego con el objeto creado, en este ejemplo $Soap_Object, accedemos a las funciones propias que implemente esa API, como métodos del objeto que hemos instanciado, por ejemplo:

$objResponse = $Soap_Object->existeContacto(array('email' => 'un email de ejemplo'));

Donde el metodo existeContacto() estará definido para esa API SOAP en concreto, que estemos usando. Las llamadas a los métodos siempre (si se han hecho las cosas bien) devuelven una respuesta que podemos poner en una variable y mostrar o evaluar para saber si todo has salido ok. En este ejemplo esto ocurre en $objResponse, que luego puede, por ejemplo, usarse así:

if( $objResponse->return->codigo == 4 )

Donde la propiedad “código” también es en este caso una propiedad definida por la API SOAP usada, pero que en otra sera diferente.

Por otra parte la class SoapClient tiene otros métodos y propiedades que nos pueden ser de ayuda en fase de desarrollo o debug, por ejemplo si una vez establecida la conexión ejecutamos un:

$objResponse = $Soap_Object->__getFunctions();
print_r($objResponse);

Obtendremos un array con todas los métodos que tiene definida la API SOAP con la que estamos conectando, esto nos ayuda a ver que acciones podemos realizar. En la API SOAP del proyecto que comento, esta llamada producía un array así:

Array
 (
 [0] => borrarContactoResponse borrarContacto(borrarContacto $parameters)
 [1] => altaContactoResponse altaContacto(altaContacto $parameters)
 [2] => actualizarCorreoResponse actualizarCorreo(actualizarCorreo $parameters)
 [3] => existeContactoResponse existeContacto(existeContacto $parameters)
 [4] => borrarContactoResponse borrarContacto(borrarContacto $parameters)
 [5] => altaContactoResponse altaContacto(altaContacto $parameters)
 [6] => actualizarCorreoResponse actualizarCorreo(actualizarCorreo $parameters)
 [7] => existeContactoResponse existeContacto(existeContacto $parameters)
 )

Aunque esta claro que no debemos esperar a realizar esto para conocer que nos ofrece la API, ya que se supone que el cliente nos ha facilitado la documentación necesaria, pero es un ejemplo de las posibilidades que nos ofrece SoapClient.

Nuestro amigo el Proxy

Todo esto funciona sin más problemas, pero si la web donde se realiza esta funcionando detrás de un proxy, las conexiones deben contemplarlo y  deben añadir la configuración de paso de tal proxy.

En el caso de la conexión a la API SOAP debemos sustituir:

$Soap_Object = new SoapClient("URL DE ACCESO SOAP A LA API -aqui va el tuyo-",
 array('trace' => true)
 );

Por:

$Soap_Object = new SoapClient("URL DE ACCESO SOAP A LA API -aqui va el tuyo-",
 array('trace' => true, 'proxy_host' => '192.0.0.0', 'proxy_port' => '8080' )
 );

Donde 192.0.0.0 es evidentement una IP de ejemplo, en definitiva en ‘proxy_host’ añadimos la IP del proxy y en ‘proxy_port’ el puerto

Para el caso de la API REST y como la llamada es mediante wp_remote_request() bastara con tener en el wp-config.php de WordPress la configuración para paso por el proxy.

Estos solo son dos ejemplos consumiendo servicios web en un WordPress. Para ambos casos (REST y SOAP) aun hay más posibilidades como tambien la de ser servidor de estos servicios, pero ese ya es otro tema.

Para tener una visión general de ellos, bajo PHP, recomiendo la lectura del libro PHP Web Services

De Codeigniter a Symfony

En Junio Codeigniter se actualizo a la versión 2.2.0 para implementar algunos ajustes y revisiones básicamente en temas de seguridad (más detalles en su changelog), mientras el desarrollo de la versión 3.0 sigue en GitHub. Lento pero avanzando Codeigniter sigue “vivo y coleando”, y eso es una buena noticia. Llevo usando este framework desde su rama 1.0, no tiene de serie las “vitaminas” de otros pero si una estructura y enfoque practico para determinados desarrollos.

Pero llega un momento en que uno tiene ganas de refrescarse y probar cosas diferentes, por eso para mi ahora es el turno de Symfony, otro enfoque, otra “madurez”.

No voy a meterme a detallar el porque de elegir Symfony y no otro, este post no va de esto, llevo ya un tiempo dándole vueltas a usar otro framework y Symfony es el que se adapta más a mis objetivos y preferencias actuales, por lo que este post es más un tema personal de dejar “huella temporal” de un cambio importante en mis herramientas de desarrollo.

Por otra parte el problema, como siempre, sera encontrar el tiempo necesario para trabajar con Symfony ya que actualmente mi día a día es desarrollo sobre WordPress o evolucionando aplicaciones creadas (para un cliente) en CodeIginiter.

Lo ideal seria encontrar nuevos clientes/proyectos en los que empezar ya con Symfony, pero mientras eso no llega voy a usarlo en un proyecto personal mio, con el único inconveniente de los proyectos personales: que deben hacerse “fuera de horas de trabajo” y toda progresión es más lenta, pero vamos a ello 🙂

Listar los plugins de WordPress

Esto puede parecer absurdo porque en el admin de WordPress ya tenemos una página con el listado de los plugins instalados, activos, etc.

Es un listado muy bonito y con un montón de información de cada plugin pero poco practico en (las escasas) situaciones en las que necesitas tener una lista de los plugins para, por ejemplo, enviarla por e-mail.

Como hacer un copiar/pegar de esta página de plugins de WordPress, con el formato que tiene, no es fácil. La segunda vez que me he encontrado con esta necesidad lo he resuelto creando un plugin que, como podéis ver en la imagen siguiente, nos lista de una manera más básica, los plugins instalados y los activos.

Programando un poco: Un listado fácil de los plugins en WordPress - Daniel Ribes

Y si, ya existe algún otro plugin que hace también esto, pero ¿y lo divertido que es hacerse uno mismo estas cosas?

El codigo del plugin, al que en un golpe de creatividad he llamado “Plugins Inventory” esta disponible en bitbucket.org

¿Cuáles son los sidebars registrados en un WordPress?

Un simple truco (y a falta de una función oficial)  para obtener los datos de todos los sidebars que estan registrados en un theme de WordPress, usar la variable $wp_registered_sidebars.

Esta variable es un array de uso interno del WP, con la información de cada sidebar registrado por el theme en curso, con lo que tenemos una manera rápida de saber que está registrado y su ID, por ejempo. Para usarlo basta con algo asi:

global $wp_registered_sidebars;
print_r($wp_registered_sidebars);

Obtener todos los shortcode del content en WordPress

Esta es una de esas cosas que usas poco y que cuando la necesitas no la recuerdas, por lo tanto dejo constancia de ella aquí. La función en si es muy simple, devuelve un array con todos los shortcode que encuentra en el content de un post o una pagina.

Usando el hook wp_head de WordPress

Entre los hooks que expone la API de WordPress uno de los más usados es el wp_head, que permite añadir contenido en la sección HEAD del HTML que genera WordPress.

Para usarlo basta usar una llamada del tipo:

add_action('wp_head', 'nombre_de_nuestra_funcion');

Y luego definir una función, con el nombre que hemos indicado en ‘nombre_de_nuestra_funcion’, que sera la encargada de generar el contenido que queremos añadir al HEAD.

Esto lo podemos añadir en el functions.php del theme, o mucho mejor, definirlo como un plugin y de esta manera queda independiente de los ficheros usados en el theme.

El contenido que añadamos al HEAD usando esta tecnica, ya queda bajo nuestra responsabilidad, WordPress aqui no realiza ningun tipo de filtraje.

Por otra parte todo esto funcionara si en el fichero correspondiente del theme (generalmente el head.php) se usa la función wp_head() antes de cerrar el HEAD, ya que precisamente esta función es la encargada de dar el control al WordPress para escribir en el HEAD de un documento.

Un ejemplo más concreto. Cuando compartimos una URL en Facebook, este busca imagenes dentro del documento referenciado para usar una como miniatura del enlace que compartimos. Usando el protocolo OpenGraph podemos indicar a Facebook que imagen concreta queremos que muestre.

Para hacer esto basta con que en el HEAD añadamos este META:

meta property="og:image" content="LA_URL_DE_NUESTRA_IMAGEN"

Teniendo esto en cuenta podemos hacer que Facebook use como miniatura la imagen destacada de nuestro post.

El siguiente código realiza precisamente esto y se implementa como un plugin que una vez activado, y solo para las paginas tipo post que tengan una imagen destacada, añade el meta og:image indicando a Facebook que esta es la imagen que preferimos usar.

WordPress 3.9

Ya lo tenemos aquí, las novedades más destacadas, de cara al usuario, son básicamente en edición de contenidos:

  • Mejoras en el editor, destacando la posibilidad de pegar directamente de
    Word y que se haga “limpieza automática”
  • Mejoras en la subida y edición de imágenes que se añaden a una entrada,
    facilitando recortar y escalar imágenes
  • La galerias ahora se previsualizan dentro la edición de una entrada, hasta ahora
    solo se mostraba un rectángulo gris
  • Mejoras en el selector de temas y ne la vista previa de personalización de widgets
  • Mejoras en la inclusión de audio y vídeo, con listas de reproducción

Como es habitual, en los próximos días, Internet se llenara de análisis detallados y probablemente tendremos la típica actualización a 3.9.1

MySQL y su socket en un MacOSX 10.6.8

Configurando un antiguo MacOSX 10.6.8 para ejecutar PHP y MYSQL, lo típico, el PHP se activa editando el archivo de configuración del Apache que viene de serie con el MacOSX.

MySQL se descarga e instala, pero luego necesita arrancar el socket que usara PHP para trabajar con el y resulta que (al menos en el 10.6.8) el fichero esta en un sitio, y en la configuración del PHP.INI apunta a otra parte. Bueno, la solución fácil es buscar donde esta el socket con un:

sudo find / -name "mysql.sock"

Y una vez localizada su ruta, una de dos o creamos un link simbólico con ln -s entre la ruta esperada y la real, o editamos el PHP.INI y le ponemos su ruta real. He preferido crear el simbólico.

© 2016 Daniel Ribes

Tema por Anders NorénSubir ↑