viernes, 30 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

Tras actualizar no puedo publicar, solo enviar a revisión

Posted: 29 May 2014 11:00 PM PDT

wtf-dog

Hace unos días un buen amigo se encontró que, tras actualizar WordPress, había perdido permisos en su cuenta de administrador. No podía crear usuarios y algunas cosas más, pero sobre todo ni siquiera podía publicar nada en su sitio, el único botón disponible era el de enviar a revisión.

enviar para revision wordpress

Investigando un poco encontré algunas posible soluciones a este embarazoso problema:

  1. Si puedes crear usuarios crea un nuevo usuario administrador, sales de la cuenta actual y accedes con la nuevas credenciales de administrador , comprueba que este nuevo usuario tiene todas las capacidades intactas y a continuación borra el usuario anterior, asignando sus entradas y enlaces al nuevo en el proceso.
  2. Desactivar todos los plugins por FTP renombrando la carpeta ‘plugins‘ por si alguno estuviese provocando el problema, vaciar la cache del navegador, acceder a WordPress y volver a intentarlo.
  3. Desactivar el tema actual para que se active el tema por defecto, vaciar la cache del navegador, acceder a WordPress y volver a intentarlo.
  4. Subir una versión limpia de WordPress por FTP (menos wp-content claro), vaciar la cache del navegador, acceder a WordPress y volver a intentarlo.
  5. Sustituir las cookies de sesión en el archivo de configuración wp-config.php, vaciar la cache del navegador, acceder a WordPress y volver a intentarlo.
  6. Comprobar que la carpeta wp-content tiene los permisos 755 y si no es así cambiarlos, vaciar la cache del navegador, acceder a WordPress y volver a intentarlo.
  7. Acceder al panel del alojamiento y comprobar la base de datos desde PHPMyAdmin, si alguna tabla está corrupta seleccionarla y repararla desde el desplegable de la parte inferior de la pantalla.
  8. Acceder al panel del alojamiento y acceder a PHPMyAdmin, revisa el id de tu usuario en wp_usermeta y localiza la meta_key wp_capabilities (si wp_ es el prefijo de tu tabla, sino el que tengas). Cambia esa meta_keya:1:{s:13:"administrator";s:1:"1";}. A continuación también revisa la tabla wp_options y comprueba que en wp_user_roles está presente la opción s:13:"administrator" al principio de esa cadena. Por supuesto, guarda los cambios.

En cualquiera de estos pasos deberías poder volver a publicar y acceder al resto de ajustes en tu web, sino pasa al siguiente y así sucesivamente.

jueves, 29 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

Cookies inseguras permiten hackear las cuentas de WordPress.com

Posted: 28 May 2014 11:00 PM PDT

cookies zomby

Aviso a navegantes: si te conectas a tu web desde una WiFi abierta, aunque lo hagas mediante la identificación en dos pasos, cualquier hacker novato puede secuestrar tu sitio alojado en WordPress.com.

Esto es posible debido a que los servidores de WordPress.com envían al navegador la cookie de las contraseñas en texto plano, sin encriptar, como sería deseable.

La cookie, denominada como “wordpress_logged_in“, se define cuando un usuario introduce un nombre y contraseña válidos en WordPress.com, y es un pase permanente a tu sitio ya que cualquiera que capture la cookie podrá acceder a tu cuenta de WordPress.com y hacer de todo.

Yan Zhu, una experta en tecnología de la Electronic Frontier Foundation, capturó de una red abierta su propia cookie y la pegó en otro navegador, al acceder desde este navegador a WordPress.com descubrió que había accedido directamente, pudiendo gestionar la cuenta de WordPress.com sin restricción alguna, cambiando el correo electrónico y hasta la configuración de seguridad.

Lo que implica esto es que un hacker malintencionado podría fácilmente capturar una cookie y tomar control de la cuenta de WordPress.com de cualquier usuario, aunque esté usando la identificación en dos pasos.

Para empeorar aún las cosas resulta que la dichosa cookie dura nada menos que 3 años, ahí es nada.

El problema, claramente, es que una cookie de este estilo debería ser exclusiva para la combinación de usuario y navegador, y por supuesto no durar hasta 3 años.

Así que si utilizas WordPress.com tu cuenta es vulnerable hasta que no se solucione el problema con la fastidiosa cookie y, entretanto, deberás acceder siempre mediante HTTPS.

Por el contrario, si usas WordPress alojado en tu servidor, el auténtico, eres menos vulnerable pues la cookie es más segura y además puedes habilitar la navegación HTTPS fácilmente. En cualquier caso ya se ha tomado nota y en la próxima actualización se solucionará el problema.

miércoles, 28 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

¡WordPress cumple 11 años!

Posted: 27 May 2014 02:55 PM PDT

11 cumpleaños wordpress

Hace exactamente 11 años, un 27 de mayo de 2003 salió a la luz la primera versión preliminar de WordPress, la 0.71 Gold, y hoy, muchas versiones y satisfacciones después, WordPress se ha convertido en el más importante CMS del mundo.

Actualmente, el 22,3% de todas las Webs están creadas con WordPress, y es el elegido por el 60% de todas las webs que usan CMS, siendo utilizado por grandes empresas y medios de comunicación, creando empleos y ayudando cada día a que cualquier usuario de Internet pueda publicar de manera sencilla y con toda la potencia de cualquier sitio web profesional.

uso de cms historicamente

Quedan muchos retos que superar, errores que evitar y mejoras que incorporar, pero a día de hoy WordPress cumple 11 años y es motivo de celebración que cada día esté más vivo.

martes, 27 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

Cómo activar WordPress Multisitio

Posted: 27 May 2014 12:25 PM PDT

imagen de red wordpress multisitio

Seguramente ya sabrás que WordPress, sí, el mismo que tienes instalado, puede convertirse en un entorno multisitio o red de sitios, y así ofrecer la creación de sitios a otros, igual que servicios como Edublogs o el mismo WordPress.com.

Lo mejor de todo es que es muy sencillo activar la red o el multisitio en WordPress

Antes de empezar asegúrate de lo siguiente:

  1. Desactiva todos los plugins antes de empezar.
  2. Comprueba que no utilizas los enlaces permanentes por defecto.

Una vez comprobado lo anterior ya estás listo para activar tu red multisitio en WordPress y el primer paso es añadir la siguiente línea al fichero de configuración de WordPress wp-config.php:

>/* Multisitio */  define( 'WP_ALLOW_MULTISITE', true );

Una vez guardes los cambios vuelve al escritorio de WordPress y verás un nuevo menú en “Herramientas -> Configuración de la red“, donde simplemente le pones nombre y un correo electrónico de administración y haces clic en “Instalar“.

crear red multisitio wordpress

A continuación, en esa misma pantalla, veremos una serie de códigos que debemos añadir manualmente a los archivos wp-config.php y .htaccess para terminar la activación de la red multisitio en WordPress, estos:

wp-config.php:

define('MULTISITE', true);  define('SUBDOMAIN_INSTALL', false);  define('DOMAIN_CURRENT_SITE', 'librowp.es');  define('PATH_CURRENT_SITE', '/');  define('SITE_ID_CURRENT_SITE', 1);  define('BLOG_ID_CURRENT_SITE', 1);

.htaccess:

RewriteEngine On  RewriteBase /  RewriteRule ^index\.php$ - [L]    # add a trailing slash to /wp-admin  RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]    RewriteCond %{REQUEST_FILENAME} -f [OR]  RewriteCond %{REQUEST_FILENAME} -d  RewriteRule ^ - [L]  RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]  RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]  RewriteRule . index.php [L]

codigos activar wordpress multisitio

Cuando hayas añadido los códigos anteriores y guardado los cambios ya puedes acceder al escritorio de tu nueva red de sitios WordPress, donde encontrarás el nuevo escritorio de Administrador de la Red y sus páginas de ajustes específicas, desde donde crear nuevos sitios, usuarios o instalar plugins y temas para que estén disponibles para los sitios de la red.

Cuando accedas de nuevo a la administración de tu nueva red WordPress descubrirás que hay varios cambios:

  • Nuevo submenú en “Inicio -> Mis sitios” en los que estará la lista de sitios creados, en principio solo el principal. Desde esta pantalla puedes acceder a visitar cada sitio y su escritorio.
  • Nuevo menú en la barra de administración denominado Mis sitios desde el que acceder a las herramientas del Administrador de la red:
    • Escritorio de la red.
    • Sitios de la red, donde puede administrarlos, o sea, crearlos o incluso borrarlos.
    • Usuarios de la red, de todos los sitios.
    • Temas disponibles para la red, que puedes activar o desactivar para que estén disponibles en todos los sitios de la red.
    • Plugins disponibles para la red, que puedes activar o desactivar para toda la red.
  • Ahora hay un nuevo tipo de usuario, el Super administrador o Administrador de la red. Puedes asignar a cualquier usuario la capacidad de administrar la red mediante una nueva casilla que aparece cuando lo editas.
  • En los “Ajustes -> Generales” hay un nuevo ajuste donde establecer el idioma por defecto para la red, que debes cambiar nada más terminar la instalación a Spanish;Castilian pues nada más activar la red queda por defecto en Inglés.

Lo único que te quedará por hacer es anunciar la buena nueva al mundo y ofrecer una página desde donde los usuarios puedan crear su nuevo sitio en tu dominio, para lo que debes ofrecer un enlace a la ruta tusitio.es/wp-signup.php desde donde se crean los nuevos sitios de la red.

crear blog gratis

El proceso para aquél que quiera crearse un sitio es totalmente transparente e inmediato.

5. Acceder 4. Activar sitiio 3. Confirmación 2. Crear sitio 1. Crear usuario

Y el resultado perfecto …

nuevo sitio red wordpress multisitio

Para terminar una simple reflexión … 

Crear una red multisitio WordPress es muy sencillo, con un par de cambios en los archivos de configuración la tienes montada sin problemas, ahora bien, no es una opción para todos y, sobre todo, no debe ofrecerse a la ligera.

Ten en cuenta que ofrecer sitios gratuitos conlleva una serie de responsabilidades y gastos pues debes administrar los sitios, controlar los sploggers (instala obligatoriamente WangGuard), y por encima de todo disponer de un buen servidor bien cargado de memoria, recursos y disco duro, para ofrecer una experiencia decente a tus futuros usuarios.

Pero si estás decidido es una posibilidad muy interesante para entornos educativos, comunidades de usuarios con intereses comunes e incluso webs corporativas que quieran ofrecer un plus a sus clientes.

viernes, 23 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

WordPress 4.0 permitirá elegir idioma desde la instalación

Posted: 22 May 2014 11:00 PM PDT

wordpress multilenguaje

Si recuerdas cuando hace 15 días hacía la lista de novedades y deseos para WordPress 4.0, entre mis peticiones estaba que WordPress fuese multilenguaje desde la instalación. Pues bien, así será.

Ayer mismo ha puesto en marcha esta iniciativa Andrew Nacin, con gran éxito entre la comunidad de desarrollo y traducción, todo hay que decirlo, porque el hecho de poder elegir el idioma desde la instalación, y otras mejoras de internacionalización, llevarán WordPress a otro nivel.

El trabajo está aún por hacer, pero la expectativas son buenas y los beneficios que ofrecerá serán enormes. Si todo sigue el guión, cuando salga a la luz WordPress 4.0 el 27 de agosto de 2014 será una distribución internacional.

wordpress 4.0

¿Cuáles son los objetivos?

  • El primer  paso de la instalación de WordPress debería ser elegir un idioma. El resto del proceso de la instalación ya será en ese idioma. Igual que cuando instalas el sistema operativo Mac OSX.
  • Debería ser posible elegir o cambiar de idioma desde la pantalla de ajustes generales, momento en el que se descargarán el paquete de idioma elegido.
  • Debería ser posible buscar desde el escritorio plugins y temas disponibles en tu idioma.
  • Todos los paquetes de idioma deberían poderse crear automáticamente y estar disponibles de manera inmediata como parte del proceso de lanzamiento de versiones.
  • Los paquetes traducidos solo se utilizarían para descargas iniciales desde WordPress.org. Para las actualizaciones se usarían los paquetes de idioma.

Por supuesto, hay muchos detalles aún que, no ya pulir, sino definir, pero la idea no es buena, es cojonuda, y seguro que va a llevar a WordPress a un nivel superior.

Lo que si está claro es que este cambio va a ser tremendamente relevante, y no va a afectar solamente a la instalación de WordPress sino que implicará que, por ejemplo …

  • Los desarrolladores de temas y plugins se tomen en serio ofrecer versiones internacionales de sus desarrollos, preparando para traducción temas y plugins.
  • Se modifique la estructura de los archivos readme de temas y plugins de manera que muestren información en los idiomas disponibles.
  • Incluso la web WordPress.org deberá rediseñarse para mostrar la información de plugins y temas en el idioma elegido, búsquedas, etc.

Puede ser una completa revolución, que requeriría del trabajo colaborativo de toda la comunidad, así que nos esperan meses muy interesantes, con el objetivo final de tener un WordPress mucho mejor y más internacional.

 

jueves, 22 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

¡Acabemos con los temas WordPress hinchados!

Posted: 21 May 2014 11:00 PM PDT

wp bloat ayudawp

Si estás harto de que los temas WordPress sean cada vez más complejos, convirtiéndose en enormes montones de código, shortcodes, plugins incorporados, y todo tipo de bloques, entonces ya es hora de empezar la revolución contra el WordPress theme bloat.

Y el sitio donde empezar a quejarte, y de paso obtener tu etiqueta con la que protestar por esta manía de engordar los temas WordPress, es WP Bloat.

Vale que en cualquier mercado de temas encuentras verdaderas maravillas, llenas de elementos que hacen que el tema sea realmente vistoso pero ¿realmente es necesario tanto código? ¿no te das cuenta de que si usas un tema hinchado estás atado a el de por vida?

WordPress nació para la simplicidad, para hacer fácil la creación web y la gestión de contenidos. Entonces ¿qué sentido tiene usar un tema que ocupa y consume más que el propio CMS? ¿no te parece una locura depender de shortcodes y características que provocan que el hecho sencillo de cambiar de tema se convierta en un infierno?

Si quieres usar shortcodes es mejor que hagas tu propio plugin, si quieres funcionalidades extra instala un plugin, si quieres modificar el aspecto de un tema edita el CSS.

Hoy en día hay temas donde no se deja nada al azar. En el momento en que los instalas desaparece tu contenido, tienes que configurar cada aspecto del diseño e incluso WordPress desde, cómo no, su enorme panel de ajustes.

Y lo que es peor, las actualizaciones de WordPress no volverán a ser lo mismo, pues al utilizar funciones no estándar deberás comprobar exhaustivamente que funciona todo con la nueva versión, y esperar a una nueva versión del tema, si es que esto existe, algo con lo que me he encontrado en multitud de ocasiones en sitios de clientes.

Esto implica que si el día de mañana quieres cambiar de tema tendrás que volver a empezar de cero, o peor, tendrás que eliminar shortcodes, reorganizar tus contenidos, a veces incluso tu estructura de etiquetas y categorías.

En serio, es una auténtica locura.

Así que comprométete y, tanto si eres desarrollador o usuario, no apoyes los temas hinchados, promociona, apuesta, instala y crea temas que usen funciones estándar, con lo necesario para el usuario final, que no aten al usuario de WordPress a un tema concreto.

Si aún tienes dudas te invito a volver a ver la charla WordPress vs Frameworks, donde se habló extensamente de este asunto.

martes, 20 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

JetPack 3.0 – Cambio radical

Posted: 20 May 2014 03:05 PM PDT

jetpack 3.0

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.

configuracion jetpack 3.0

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.

verificacion sitio jetpack 3.0

compartir jetpack 3.0

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

lunes, 19 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

October CMS, de regreso a los básicos

Posted: 18 May 2014 11:00 PM PDT

octobercms logo

El pasado viernes salió a la luz un nuevo sistema de gestión de contenidos que promete devolver la creación web y publicación a los básicos: October CMS.

Según la filosofía de October CMS, creado por Alexey Bobkov y Samuel Georges, los actuales sistemas se han hecho complicados, y nos ofrece una plataforma sencilla, por la que, por ejemplo, podemos crear fácilmente una plantilla en el tema y aplicarle directamente la URL, algo que se haría así:

title = "Acerca de nosotros"  url = "/acerca"  ==  <h1>Acerca de October</h1>  ...

October CMS está basado en PHP y el framework Laravel, y sus características principales son las siguientes:

:: Instalación con asistente ::

Los requisitos para instalar October CMS son los siguientes:

  • PHP 5.4 o superior con safe_mode desactivado.
  • PDO PHP.
  • cURL PHP.
  • MCrypt PHP.
  • ZipArchive PHP.
  • GD PHP.
  • PHP JSON

Aunque le lista parezca larga la mayoría de los servidores actuales lo ofrecen ya, pero siempre debes consultar antes.

Si tu servidor cumple los requisitos, solo tienes que descargar el instalador o bajarte una copia desde el repositorio.

Si optas por el instalador, la mejor opción, el procedimiento es el siguiente:

  1. Prepara un directorio vacío en tu servidor. Puede ser un sub-directorio, la carpeta raíz o un subdominio.
  2. Descarga el archivo del instalador.
  3. Descomprime el archivo del instalador en el directorio de tu servidor donde quieras instalar October CMS.
  4. Da permisos de escritura al directorio de instalación y a todos sus subdirectorios y archivos.
  5. Navega hasta el script install.php desde tu navegador web.
  6. Sigue las instrucciones del instalador.

:: Componentes de página ::

Los componentes son bloques de construcción de páginas. Simplemente se añade un componente a la página y este añade nuevas funcionalidades y luego lo configuras con el Inspector, una herramienta visual con la que gestionar las propiedades de los componentes, todo sin tener que programar.

octobercms components

:: Plataforma extensible: plugins ::

Al igual que con cualquier otro CMS puedes extender las características de October CMS con plugins. Las clases que usan los plugins son muy sencillas, simplemente describe el plugin y registra las funcionalidades que quieras que tenga.

Hay una página disponible con unos cuantos fundamentales, de los que no puedes prescindir.

octobercms plugins

:: Framework Ajax ::

El framewordk AJAX framework permite realizar fácilmente una petición de formularios o botones. Estas peticiones las gestionan los componentes de tu propio código de la página o diseño.

octobercms ajax-framework

:: Administración sencilla ::

Aunque no es lo que esperas en WordPress si que dispone de una interfaz de administración con buenas virtudes. Lo mejor es que usa muy poco código PHP y los archivos de configuración son sencillos, casi humanos.

octobercms administracion

:: Plantillas basadas en archivos de texto ::

Las páginas, diseños y parciales son solo archivos, uno por plantilla. Gracias a esto los temas son fácilmente manejables mediante sistemas de revisión de versiones como Git o SVN.

octobercms sistema archivos

La estructura de los temas es bastante simple:

  • Páginas – entradas y páginas del sitio web.
  • Parciales – trozos de marcado HTML reutilizables. Esto es una de las mejores características de October CMS.
  • Diseños – los archivos que definen el aspecto de la web.
  • Archivos de contenido – bloques de texto, HTML o Markdown que pueden editarse independientemente de la página o el diseño.
  • Archivos de recursos – archivos de recurso como imágenes, y ficheros CSS y JavaScript.

Una estructura tipo de un tema de October CMS sería así:

themes/
web/ <== El tema empieza aquí
pages/ <== Directorio de páginas
home.htm
layouts/ <== Directorio de diseños
default.htm
partials/ <== Directorio de parciales
sidebar.htm
content/ <== Directorio de contenido
intro.htm
assets/ <== Directorio de recursos
css/
my-styles.css
js/
images/

Tienes la documentación completa sobre temas de October CMS en esta página.

¿Quieres saber más?, pues echa un vistazo a este vídeo, se explica solo y es un buen repaso.

Yo lo estoy probando en mi máquina local y, aunque cambia el método de trabajo al que estoy acostumbrado tengo que decir que es muy sencillo de usar y modificar, tiene conceptos muy interesantes.

Si te animas nos cuentas qué te parece.

viernes, 16 de mayo de 2014

Hoy en AyudaWordPress.com

Hoy en AyudaWordPress.com

Link to Ayuda WordPress

Los widgets inactivos de WordPress

Posted: 15 May 2014 11:00 PM PDT

personalizar widgets wordpress

Hoy te voy a hablar un poco sobre los widgets inactivos que tenemos en WordPress.

¿No sabes lo que son?

Venga anda, vete al admin de tu WordPressAparienciaWidgets y mira abajo del todo.

O a lo mejor si sabes que eso estaba ahí, pero nunca lo has usado.

No te preocupes que te voy a explicar un poco para lo que te puede servir.

Vale.

Realmente no es que tenga unos usos super importantes, pero si creo que debemos usarlo.

Lo más importantes es que cualquier widget que tu metas dentro, guarda la configuración que le tengas puesta.

Si metes un widget de texto, te lo almacena.

Si metes uno que tenga varias cosas a configurar, te guarda esa configuración.

 

Widgets inactivos WordPress

Guardar un widget

Me pongo en tu lugar.

Estás haciendo unos cambios a tu WordPress y claro.

Para hacer una modificación estructural y no tener que crear los widgets de nuevo, éste sitio donde guardarlos te viene muy bien.

Yo no se tú, pero yo que diseño webs, con lo cuál tengo bastante trillados algunos temas de diseño, aún me cuesta trabajo tener que hacer algo de nuevo.

Imagina tener que entrar de nuevo a Facebook para crear botones de compartir, el widget de Twitter, la insignia de Google+ u otra cosa.

La verdad es que es un coñazo y una perdida de tiempo.

Pos nada.

Lo quitas de su sitio.

Lo metes en los widgets inactivos y ahí no molesta.

Cuando te haga falta de nuevo, no tienes más que cogerlo y meterlo donde se necesite.

O también puede que tengas el mismo widget, pero con 2 configuraciones diferentes.

Por decirte algo.

Que tengas 2 widgets de texto con Adsense. Uno con un anuncio de un tamaño fijo y otro responsive y quieras ir probando el cambio a ver cuál te da el mejor resultado.

Las posibilidades son infinitas y los límites los pones tú.

Creando un widget

Imagina que estás creando un widget para hacer lo que sea.

Por ejemplo:

Estás preparando uno para insertar un formulario de captura de correos electrónicos.

Todo lo que tu quieres insertar en tu web, tienes que configurarlo antes.

No puedes meter un widget en el sidebar e ir guardando a ver como va quedando.

O por lo menos yo no te recomiendo hacerlo.

Otra cosa es que una vez que está listo y funcionando, quieras cambiar algo.

Hay widgets que necesitan bastante configuración.

Si tienes una web con bastantes visitas y agregas un widget a medias, puede que tus visitantes quieran interactuar con él y no esté listo para ponerlo en producción.

Por eso debemos usar los widgets inactivos.

Metes ahí el widget, lo vas configurando, lo repasas antes, y después lo metes donde lo necesites.

Creando una web

¿Crees que se puede hacer una web a base de widgets?

Te respondo yo. Si.

Hay plantillas de WordPress que tienen un creador de páginas desde la home a cualquier otra y se hace mediante widgets.

Tu creas varios widgets para hacer varias cosas como un widget para clientes, otro donde muestro un producto, otro para un formulario de contacto, etc.

Y después en cada página hay un sistema con el que vas colocando las piezas del puzzle.

Ésto a la derecha, lo otro a la izquierda. Ésto lo pongo más ancho y arriba, etc.

Aquí el tener unos widgets inactivos creados nos facilita mucho la cosa.

Simplemente los vas cogiendo e insertando donde necesitas.

¿Ahora los ves más útiles verdad?

Desde mi punto de vista es una función muy interesante y que yo no usaba antes.

Y eso que lleva disponible desde la versión 2.8.

Así que mi consejo es que lo uses si lo ves conveniente, aunque desde mi punto de vista, totalmente recomendable.

Si te ha gustado ésto, te invito a aprender más en mi web Ragose.

 

Seguidores

Archivo del blog