Media Upload de WordPress en Frontend

Utilizar el Media Upload de WordPress fuera de su ambiente común es simple y puede ser muy útil si queremos por ejemplo, agregar un editor en el frontEnd, para que los usuarios agreguen artículos con todas las opciones de media que nos da WordPress.

Código de php:


add_action( "wp_enqueue_scripts", "enqueue_media_uploader")
function enqueue_media_uploader() {
  //esta función pone en cola todos scripts que se necesitan para que funcione el media uploader.
  wp_enqueue_media();
  wp_register_script( 'my-script', plugins_url( 'my-scripts.js', __FILE__ ), array( 'jquery' ), '', true );
  wp_enqueue_script( 'my-script' );
}

en el archivo ‘my-scripts.js’


jQuery( document ).ready(function($){
  $('.boton_add_media').on('click', function(e){
    e.preventDefault();
    wp.media.editor.send.attachment;
    wp.media.editor.open();
    return false;
  });
});

Cabe aclarar que el editor debe haber sido creado con la función wp_editor() para que pueda encontrarlo.

WordPress Plugin Boilerplate

Estoy utilizando WordPress-Plugin-Boilerplate para desarrollar plugins, y puedo decir que es una herramienta que sirve mucho para trabajar ordenadamente el código, obtener plugins más prolijos, todos orientados a objetos y fáciles de mantener.

Este es el repositorio en github: https://github.com/DevinVinson/WordPress-Plugin-Boilerplate

Y como no tiene mucha documentación recomiendo accudir a los issues como fuente y area de consultas.

Para arrancar a utilizarlo hay que reemplazar todas las ocurrencias de ‘plugin-name’, ‘Plugin_Name’, con el correspondiente nombre de tu plugin, dentro de los archivos y en los nombres de los archivos.

También como necesitaba usar shorcodes, modifique la clase loader según este comentario del autor.

La idea es separar los archivos en admin y public, que son llamados en la clase genérica dentro del include, que agrupa los hooks, filters y shortcodes en mi caso.

Conectar Jetpack

Tuve problemas con mi instalación para conectar jetpack y lo resolví, primero chequeando en el debug de Jetpack, que me mostraba un problema para acceder al xmlrcp.

Como yo tengo WordPress en otro directorio, intenté haciendo una redirección 301 en el .htaccess.

Redirect 301 /xmlrpc.php http/tusitio.com/directorio_de_wordpress/xmlrcp.php

Desconecté, rehice la conexión y funcionó!

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.

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.