PHP_CodeSniffer para WordPress

Este post solo tiene la finalidad de registrar el proceso de instalación de PHP_CodeSniffer y configurarlo para los requerimientos de WordPress, en MAC OS El Capitan.

Primero instalamos PEAR: Install PEAR and PECL on Mac OS X

curl -O http://pear.php.net/go-pear.phar
sudo php -d detect_unicode=0 go-pear.phar

Podemos Configurarlo en la instalación o bien como en mi caso, luego:

sudo pear config-set php_bin /usr/bin/php
sudo pear config-set bin_dir /usr/local/bin

luego instalamos PHP_CodeSniffer

sudo pear install PHP_CodeSniffer

Y voilà:

phpsc --version

Debería funcionar, pero no, da algunos errores:

Warning: include_once(PHP/CodeSniffer/CLI.php): failed to open stream: No such file or directory in /usr/local/bin/phpcs on line 21
Warning: include_once(): Failed opening 'PHP/CodeSniffer/CLI.php' for inclusion (include_path='.:') in /usr/local/bin/phpcs on line 21
Fatal error: Class 'PHP_CodeSniffer_CLI' not found in /usr/local/bin/phpcs on line 24

Necesitamos hacer una configuración más: http://viastudio.com/configure-php-codesniffer-for-mac-os-x/

sudo mkdir -p /Library/Server/Web/Config/php
sudo touch /Library/Server/Web/Config/php/local.ini
echo 'include_path = ".:'`pear config-get php_dir`'"' | sudo tee -a /Library/Server/Web/Config/php/local.ini

y con eso corregimos los errores de include_path y tenemos nuestro comamndo phpsc funcionando en la consola.

Ahora vamos a integrar el WordPress Coding Standards for PHP_CodeSniffer, para ajustarnos a sus parametros.

git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wpcs
sudo phpcs --config-set installed_paths /path/to/wpcs

ahora probamos la herramienta

phpcs --standard=WordPress path/to/file.php

o

phpcs --standard=WordPress path/to/fdir

y este es un posible resultado:

----------------------------------------------------------------------
FOUND 6 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------
16 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found
16 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found
16 | ERROR | [ ] Expected next thing to be an escaping function
| | (like esc_html_e() or esc_attr_e()), not '_e'
19 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found
19 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found
19 | ERROR | [ ] Expected next thing to be an escaping function
| | (like esc_html_e() or esc_attr_e()), not '_e'
----------------------------------------------------------------------
PHPCBF CAN FIX THE 4 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------
Time: 117ms; Memory: 11Mb

y tal como lo indica ahi, con:

phcbf --standard=WordPress path/to/file.php

resolvemos automáticamente alguno de los errores.

Javascript en JSConfUY

Este fin de semana tuve la suerte de poder asistir a la JSConfUy y volví muy impresionada de la gran calidad de la mayoría de las presentaciones y con un montón de información nueva en mi cabeza para procesar.

Ya habia tenido acercamientos a nodejs, hice mis primero pinitos (muy minimos) hace un tiempo influenciada por mi pareja que trabaja con la tecnología hace bastante tiempo. Sin embargo pude darme cuenta que es la tecnología de este momento y que de alguna manera la web va a volcarse a nodejs mas ponto que tarde. Sobretodo por su potencialidad y por lo amigable que es con el desarrollador. Tuve la oportunidad de participar de un workshop que me ayudo a refrescar algunas cosas y me dejo pensando en cual será el camino a seguir para poder aplicar esas tecnologías en mi actividad actual.

Algunas herramientas ya las utilizo, (como jade, stylus, components, etc.) todavía en el medio del camino, desde wordpress (php) y el desarrollo de themes y plugins customizados, pero voy viendo que no es tan lejana la posibilidad de dejar de compilar en consola para compilar en el cliente.

Otro tema en el que vi luz, es Web Components, según la presentación que dio Zeno Rocha. Tiene un potencial enorme, y voy a intentar escribir particularmente mi experiencia en un post cuando empiece a tratar el tema. Espero pronto tambien suban el video de la charla por que puede ser de mucha ayuda.

Como conclusión personal, ya me voy anotando a la proxima JSConf en Argentina, no me la pierdo.

Mudanza

Finalmente mudé el blog a mi hosting, para seguir publicando regularmente y tener más control en mi sitio. La versión free de heroku no deja de ser un host de desarrollo, con sus limitaciones.

Es mi propósito de este año publicar regularmente en este blog para documentar la experiencia que acumulo en los últimos años que tengo trabajando en esto que me da tantas satisfacciones.

Ser freelancer es mi forma de trabajo ideal, trabajar en lo que me gusta, en mi casa, con mis horarios. Qué más puedo pedir?

GIT – Eliminar submódulos del proyecto

Que pasa cuando querés eliminar un submódulo de tu proyecto? no alcanza con git rm SUBMODULO, por que quedan todas las referencias dando vueltas en los archivos de git. Buscando un poco en Stackoverflow varias respuestas mencionaban git submodule deinit un herramienta que presenta la versiones posteriores a 1.8.3 de Git.
git --version
y resulta que tengo instalada una versión anterior de git. Entonces me bajo la última versión:
https://code.google.com/p/git-osx-installer/downloads/list
La instalo sin problemas. Terminado el proceso, volvemos a chequear la versión y sigue mostrado la misma! algo salió mal.

which git me dice que está instalada en /usr/bin/git y la nueva versión parece que se instala en /usr/local/git/bin/git. Bueno, el post no venia de como actualizar git, pero me costó bastante lograr que me tomara la nueva versión, por ejemplo ninguna de las dos opciones presentadas en este artículo me funcionó, asi que finalmente movimos el binario que estaba en /usr/bin/git y tomo la nueva versión.

Ahora hacemos:
git submodule deinit submodulo
git rm --cached submodulo

Subimos los cambios y eso es todo.

Toda la información relativa a este comando esta en esta respuesta en Stackoverflow.

Usar la API de Mailchimp

En un caso en el que estoy trabajando me pidieron desactivar la doble confirmación que pide por defecto Mailchimp a la hora de hacer una suscripción. No hay forma de hacerlo usando los formularios que vienen por defecto, pero si podemos lograrlo usando la API.

Como hasta ahora, partimos de un instructivo existente: Creating a Single Opt-In Mailchimp form.

Este ejemplo usa la api anterior de mailchimp, como no tengo mucho tiempo de ponerme a ver como es la versión nueva baje de acá http://apidocs.mailchimp.com/api/downloads/#php el wrapper de php para la versión 1.3 de API.

Tal como dice el intructivo, usamos los siguientes archivos:

/inc/config.inc.php
/inc/MCAPI.class.php
mcapi_listSubscribe.php

En el config.inc.php cargamos el API Key en la variable $apikey de la cuenta y el ListID en la variable $listId de tu lista dentro de mailchimp y comentamos la linea que define $my_email y $boss_man_email.

En el archivo mcapi_listSubscribe.php cambiamos la variable $merge_vars por aquellas que tengamos en nuestro formulario y en $subscriberemailID pasamos el email a suscribir.
y modificamos los parámetros del llamado al método:
$retval = $api->listSubscribe( $listId, $subscriberemailID, $merge_vars, 'html', false, true, true, true );

Los últimos cuatro parámetros sirven para indicar el comportamiento de la suscripción:

listSubscribe(string apikey, string id, string email_address, array merge_vars, string email_type, bool double_optin, bool update_existing, bool replace_interests, bool send_welcome)

Plugins de WordPress como submodulos de git

Siguiendo la línea del post anterior y sin necesidad de agregar mucho más, podemos mantener actualizados los plugins con git, siempre que el autor mantenga su plugin en un repositorio de git público.

En mi caso, voy a instalar el plugin de YOAST WordPress SEO

Parados en la raíz del proyecto hacemos git submodule add https://github.com/Yoast/wordpress-seo.git wp-content/plugins/wordpress-seo.

Commiteamos el resultado git commit -am "add yoast wordpress seo plugin" y git push.

Para actualizar, podemos movernos al directorio del plugin y hacer git pull origin master o bien git submodule -q foreach git pull -q origin master en el directorio raíz, que nos va a actualizar todos los submódulos del proyecto.

Hay que tener en cuenta que esto instala la versión de desarrollo, siempre la última. Esto puede ser un poco peligroso en un sitio de producción, incluso con wordpress. Por esto es importante tener en cuentas las versiones y después de actualizar movernos al ultimo release:

En el caso del plugin:

  • Nos movemos al subrepositorio del plugin (cd wp-content/plugins/wordpress-seo) y hacemos:
    git fetch --tags
    git checkout 1.4.18

    Reemplazando 1.4.18 con el numero de versión correcto.
  • Volvemos al raíz y commiteamos la nueva versión.

WordPress como un submódulo de git

Siguiendo el siguiente instructivo “Install and manage wordpress with git”, que está clarísimo, cambié la instalación de WordPress, a la forma de submódulo de git. Esto me permite mantener actualizado a la versión de desarrollo con un simple comando. WordPress mantiene el repositorio sincronizado cada 15 minutos con SVN, básicamente es un espejo del repositorio de desarrollo.

En mi caso los pasos fueron los siguientes:

  1. Eliminar todos los archivos de la antigua instalación, salvo el wp-config.php, el .htaccess y todo el directorio wp-content/
  2. Agrego el repositorio de wordpress como un submódulo: git submodule add git://github.com/WordPress/WordPress.git wordpress. Esperamos un poco a que termine de bajar.
  3. Commiteamos lo hecho: git commit -m "Add WordPress subrepository."
  4. El siguiente paso del instructivo es para mantenerse en la versión estable, en mi caso lo obvie por que quiero probar las características nuevas de wordpress lo antes posible y dentro de mis posibilidades ayudar a debuggear un poco, en este blog que es mío.
  5. Copiamos el index.php al directorio raiz: cp wordpress/index.php .
    git add index.php
    git commit -m "Adding index.php"
  6. Ahora configuramos:
    • En index.php cambiamos la línea: require( dirname( __FILE__ ) . '/wp-blog-header.php' ) por require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' )
    • En wp-config.php agregamos estas dos lineas al inicio:

      define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/wordpress');
      define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME']);
      define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');
      define('WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/wp-content');

      Estas líneas permiten redefinir los directorios de instalación y el wp-content particularmente para que utilice el que tenemos en el directorio raíz y no el que viene en la instalación.
  7. Ahora commiteamos estos cambios: git commit -am "Update settings"

Eso es todo, ahora cuando queremos actualizar simplemente nos movemos al directorio de WordPress dentro de nuestro repositorio y hacemos: git pull origin master o bien en la raíz del repositorio hacemos: git submodule -q foreach git pull -q origin master para actualizar todos los submódulos que tengamos de un saque.

En el caso de un sitio de producción conviene trabajar con la versión estable de wordpress, eso seria así:

  • nos movemos al subrepositorio de wordpress (cd wordpress) y hacemos:
    git fetch --tags
    git checkout 3.3.2

    Reemplazando 3.3.2 con el numero de versión correcto.
  • Volvemos al raíz y commiteamos la nueva versión