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.

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

Dominios Personalizados en Heroku

Hacer funcionar un dominio personalizado en Heroku con wordpress, no tan simple como lo plantea acá, por lo menos me costo un rato darme cuenta que fallaba. En mi caso el dominio esta registrado en nic.ar, asi que opte por usar Zerigo como módulo de heroku, siguiendo este instructivo, que básicamente plantea que con dos lineas de comando se hace la magia y que no necesitás más nada.

heroku addons:add zerigo_dns:basic
heroku domains:add mydomain.com

Pero no, parece que por el tipo de instalación utilizada no permite utilizar el router como viene, aunque me queda la duda si es eso o es que el modulo de zerigo esta utilizando una forma obsoleta de heroku de direccionar el dominio.

Después de varios intentos de hacer funcionar mi dominio lo conseguí de la siguiente forma:

Primero delegue en nic.ar a los servidores de dns de zerigo:

a.ns.zerigo.net
b.ns.zerigo.net
c.ns.zerigo.net
d.ns.zerigo.net
e.ns.zerigo.net

En zerigo cambie eliminé las delegaciones que me creo por defecto y cree un CNAME que direcciona el subdominio www a lauramelos.herokuapp.com y una URL redireccionando el raiz a www.lauramelos.com.ar cambiamos las url de wordpress a ese dominino y voila! acá estamos!

Instalar WordPress en Heroku

Usé este instructivo:

http://blog.themeskult.com/2013/03/04/wordpress-on-heroku/

Lista de comandos:

wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh
heroku login
wget http://wordpress.org/latest.zip
unzip latest.zip
mv wordpress lauramelos
cd lauramelos/
git init
git remote add origin git@github.com:lauramelos/lauramelos.git
git add ./
git commit -m "wordpress"
git push -u origin master
sudo gem install heroku
heroku create --stack cedar
heroku rename lauramelos
heroku addons:add cleardb:ignite
mv wp-config-sample.php wp-config.php
vim wp-config.php

Agregamos esto:

if (isset($_SERVER["CLEARDB_DATABASE_URL"])) {
$db = parse_url($_SERVER["CLEARDB_DATABASE_URL"]);
define("DB_NAME", trim($db["path"],"/"));
define("DB_USER", $db["user"]);
define("DB_PASSWORD", $db["pass"]);
define("DB_HOST", $db["host"]);
}
else {
die("Your heroku DATABASE_URL does not appear to be correctly specified.");
}

lo subimos a Heroku:

git commit -a -m "config db"
git push heroku master

cd wp-content/plugins
wget http://downloads.wordpress.org/plugin/tantan-s3-cloudfront.0.4.1.1.zip
unzip tantan-s3-cloudfront.0.4.1.1.zip
git add tantan-s3-cloudfront
git commit -m "tantan s3 cloudfront plugin"
git push heroku
heroku open

Use Amazon para las imágenes.