Hoy en AyudaWordPress.com

Posted: 20 May 2014 03:05 PM PDT

Acaba de salir la versión 3.0 del megaplugin JetPack, con interesantes novedades más allá de los cambios estéticos y de gestión de módulos.

La lista de las novedades de JetPack 3.0 es digna de mención:

Nueva interfaz de usuario de gestión de módulos y ajustes, ahora todo integrado, selección de módulos por categoría, preferidos y más, al estilo del navegador de temas.
Herramienta de verificación del sitio, un nuevo módulo desde el que verificar tu sitio en las herramientas de Webmaster de Google, Bing y Pinterest, realmente útil.
Nuevo aspecto del módulo de Compartir.
Varias mejoras en el modo en que se gestionan las Twitter cards.
Nueva opción para ocultar el banner de autoría de Google+ sin dejar de reconocer la autoría de los contenidos
Muchas mejoras en el scroll infinito, especialmente en rendimiento
JSON API mejorada
Nuevo filtro para asignar una imagen por defecto a las tags de Open Graph
Nuevo código corto para poder insertar manualmente las entradas relacionadas en vez de usar el lugar por defecto
El código corto de YouTube ahora permite reproducción en HD
Mejoras en el código corto de Google Maps
Mejoras en las galerías de mosaicos
… mucho más

¿Impresiones?

Pues no me ha gustado nada el rediseño. Para empezar la nueva interfaz consume muchos más recursos que la anterior y, para terminar de empeorar la cosa, resulta que es cualquier cosa menos intuitivo adivinar donde se activan o desactivan los módulos. A este respecto es un atraso completo.

Si antes en cada módulo, sin cambiar de pantalla, ya podías activar, desactivar o configurar, ahora esa pantalla de inicio es puro marketing, irrelevante del todo, innecesaria, vamos, que sobra. Ahora todo lo haces en la pestaña de configuración (no muy visible dicho sea de paso).

Han querido hacer una cosa chula, que los módulos se activen y desactiven por lotes (lo que no es mala idea) pero se han dejado por el camino la simplicidad y la experiencia de usuario.

Vamos, una cagada monumental en cuanto a usabilidad.

En cuanto a las funcionalidades, la herramienta de verificación del sitio es un básico, totalmente imprescindible, y las mejoras en las Twitter Cards y Open Graph eran una necesidad. La nueva interfaz de Compartir no aporta nada, solo quita colorines a los botones y poco más.

En resumen, muy bien por la incorporación de la verificación del sitio en Google, Bing, Pinterest y por las mejoras en Twitter Cards y Open Graph, necesaria la mejora en el códigos corto de YouTube, y fallida la actualización de la interfaz.

No sé qué pensarás tú.

wp-config.php para WordPress multientorno

Posted: 19 May 2014 11:00 PM PDT

desarrollo wordpress

Cuando desarrollas un sitio web siempre vas a tener diferentes entornos para el mismo, el número de entornos que necesites dependerá del tamaño del proyecto y de cuánta gente esté involucrada en el proyecto.

Los principales entornos que encontrarás en cualquier proyecto web son:

Servidor de desarrollo – La máquina local de los desarrolladores que crean la web.
Servidor de pruebas – Una vez se haya terminado el desarrollo este será el lugar donde se harán todas las pruebas.
Servidor de pruebas del cliente final – Donde el cliente revisará los cambios de la web.
Servidor de producción – La web definitiva.

Los dos entornos que siempre has de tener son el entorno de desarrollo y el de producción. Lo normal es que solo necesites estos dos entornos si el cliente no necesita ver la web antes de ponerla en marcha. Esto implica que una vez que el desarrollador haya terminado de trabajar en la web solo le queda ponerla en el servidor de producción.

Esto suele ser así para los proyectos básicos, esos en los que el desarrollador hace las pruebas en su servidor de desarrollo local antes de hacer visible la web.

Si tienes un cliente que necesita revisar tu desarrollo antes de poner la web a la vista entonces tendrás que disponer de un servidor de pruebas del cliente final, este entorno debería parecerse lo más posible al servidor de producción. Cuando el desarrollador haya terminado de hacer las pruebas locales podrá subir la web al servidor de pruebas del cliente final para que lo revise. Una vez que el cliente acepte los cambios hechos por el desarrollador se podrá ya mover la web al sitio de producción.

En proyectos con varios desarrolladores será imprescindible que tengas un servidor de pruebas adicional además del de desarrollo y del de pruebas para el cliente final. Necesitas este servidor ya que cuando el desarrollador esté creando la web y probando el código lo estará probando solo en su propio entorno, y este entorno con seguridad no se adaptará a los entornos del resto de desarrolladores.

Una vez que el desarrollador haya probado su código debería subirlo al servidor de pruebas. Será ahí donde todos los desarrolladores harán los cambios para probarlos con los demás cambios del resto de desarrolladores. Una vez que este servidor sea estable y haya pasado las pruebas entones ya podrás subir esos cambios al servidor de pruebas del cliente final, donde este podrá revisar los cambios y, si los acepta, entonces se subirá todo al servidor de producción.

Multi entorno en WordPress

desarrollador wordpress

Si tienes un proyecto WordPress querrás que sea fácil cambiar entre distintos entornos, y el modo más fácil es que puedas subir todo lo que haya que hacer en el proyecto al mismo servidor. Esto implica que se subirán todos los cambios que hagas, no solo los cambios en los plugins o temas.

Pero si subes todo también cargarás el archivo wp-config.php, y este archivo le dice a WordPress cómo conectarse con la base de datos.

El archivo wp-config.php no es más que un fichero PHP que puedes cambiar, dependiendo del servidor desde el que se esté utilizando, usando la variable global $_SERVER para distinguir entre entornos.

Las variables que tienes que cambiar dependiendo del entorno son:

DB_NAME - Nombre de la base de datos.
DB_USER - Usuario para conectarse a la base de datos.
DB_PASSWORD - Contraseña para conectarse a la base de datos.
DB_HOST - Nombre del servidor donde está alojado la base de datos.
WP_HOME - URL de la ubicación de la página principal donde está instalado WordPress.
WP_SITEURL - URL de la ubicación del sitio WordPress, la mayoría de las veces la misma que en WP_HOME, pero puede cambiar si, por ejemplo, WordPress está instalado en un subdirectorio.
WP_DEBUG - Mostrará cualquier error o aviso PHP.
WP_CACHE - Cacheará WordPress.

Teniendo en cuenta todo lo anterior, un fichero wp-config.php para un WordPress multientorno sería así:

<?php    if( stristr( $_SERVER['SERVER_NAME'], "desarrollo" ) ) {      	// Entorno de desarrollo  	define( 'DB_NAME', 'project_dev' );  	define( 'DB_USER', 'project_dev_user' );  	define( 'DB_PASSWORD', 'contraseña' );  	define( 'DB_HOST', 'localhost' );  	  	define( 'WP_HOME', 'http://proyecto.dev');  	define( 'WP_SITEURL', WP_HOME);  	  	// Para el desarrollo siempre querrás que el debug esté activo y la cache inactiva  	define( 'WP_DEBUG', true );  	define( 'WP_CACHE', false );  	   } elseif( stristr( $_SERVER['SERVER_NAME'], "pruebas" ) ) {     	// Entorno de pruebas  	define( 'DB_NAME', 'project_test' );  	define( 'DB_USER', 'project_test_user' );  	define( 'DB_PASSWORD', 'contraseña' );  	define( 'DB_HOST', 'localhost' );  	  	define( 'WP_HOME', 'http://proyecto.pruebas');   	define( 'WP_SITEURL', WP_HOME);  	  	// Para las pruebas siempre querrás que el debug esté activo y la cache inactiva  	define( 'WP_DEBUG', true);  	define( 'WP_CACHE', false);  	  } elseif( stristr( $_SERVER['SERVER_NAME'], "cliente" ) ) {     	// Entorno de pruebas del cliente final  	define( 'DB_NAME', 'project_uat' );  	define( 'DB_USER', 'project_uat_user' );  	define( 'DB_PASSWORD', 'contraseña' );  	define( 'DB_HOST', 'localhost' );  	  	define( 'WP_HOME', 'http://proyecto.cliente');   	define( 'WP_SITEURL', WP_HOME);  	  	// El entorno de pruebas del cliente final siempre será el mismo que el de producción así que desactivamos el debug y activamos la cache  	define( 'WP_DEBUG', false );  	define( 'WP_CACHE', true );	  	   } else {     	// Entorno de producción  	define( 'DB_NAME', 'project_live' );  	define( 'DB_USER', 'project_live_user' );  	define( 'DB_PASSWORD', 'contraseña' );  	define( 'DB_HOST', 'localhost' );  	  	define( 'WP_HOME', 'http://proyecto.es');   	define( 'WP_SITEURL', WP_HOME);   	  	// El entorno visible siempre será el mismo que el de producción así que desactivamos el debug y activamos la cache  	define( 'WP_DEBUG', false );  	define( 'WP_CACHE', true );  		  }     define('DB_CHARSET', 'utf8');  define('DB_COLLATE', '');  ?>

Con lo anterior, con un solo fichero wp-config.php puedes tener todos los entornos en un mismo alojamiento sin problemas, cada uno funcionando independientemente pero usando la misma base, algo que a la hora del desarrollo y las pruebas es fundamental.

Por supuesto, debes utilizar las URLs y la información de conexión a las bases de datos tuyas, no las del ejemplo.

Fuente: Paulund

AYUDA WORDPRESS

martes, 20 de mayo de 2014