Planeta WordPress

Desinstalar un multisite de WordPress: una tarea sencilla

Desinstalar un multisite de WordPress es muy sencillo si se siguen ordenadamente la serie de pasos que indico en esta entrada.

Imagen elaborada a partir de otra de ShutterStock

Qué debes saber antes de empezar

Lógicamente, debes conocer la estructura de tablas de la base de datos y los cambios que hay que realizar en el archivo wp-config.php y en la configuración del servidor para llevar a cabo una instalación multisite de WordPress. Las peculiaridades de una instalación multisite se explican en WordPress 3.0 multisite: cómo instalarlo (I) y WordPress 3.0 multisite: cómo instalarlo (y II).

Un caso especial es que hayas tenido que emplear el mapeo de dominios para conseguir que funcione un dominio del tipo sitio1.com, a pesar de que se trate de uno de los blogs de la red multisite; por ejemplo, sitio1.misitio.com. Pero eso solamente tenlo en cuenta en el punto 2 de las siguientes instrucciones.

Cómo desinstalar un multisite de WordPress: pasos a seguir

Sigue los pasos indicados a continuación para desinstalar un multisite de WordPress.

• 1. Asegúrate de que tu plugin de backup funciona en cada blog de tu red multisite y que posees una copia de respaldo satisfactoria.
• 2. Copia a otro servidor, o a otro dominio dentro del mismo servidor, cada blog del multisite excepto el principal. Para ello, sigue las instrucciones que doy en Cómo cambiar un blog de servidor en un WordPress multisite.
• 3. Elimina todos los blogs del multisite, excepto el principal, desde la administración de la red (“My sites” > “Network Admin” > “Sites”) y haciendo clic en “Delete” en el blog que se quiere borrar.
• 4. Quita la definición “ServerAlias *.|DOMAIN|” de Apache. Cada panel de administración es diferente, hay que buscar la opción de configuración Httpd. Así se lleva a cabo en CPanel: Wildcard *.domain.com.
• 5. Comprueba que en las definiciones DNS no existe ningún registro del tipo A con nombre “*” y la dirección IP del servidor. Este apartado se incluye en el punto 2 (mapeo de dominios) pero conviene chequearlo ahora.
• 6. Borra todas las definiciones referentes al multisite del archivo wp-config.php (ver WordPress 3.0 multisite: cómo instalarlo (y II)).
• 7. Borra las instrucciones del archivo .htaccess de la raiz del servidor. Puedes dejar vacio el archivo pero no lo elimines. Solamente debes dejar sentencias que no tengan que ver con WordPress.
• 8. Entra en phpMyAdmin y elimina las tablas siguientes: wp_blogs, wp_blog_versions, wp_registration_log, wp_signups, wp_site y wp_sitemeta.
• 9. Elimina, empleando también phpMyAdmin, los campos de la tabla wp_users denominados “spam” y “deleted”.
• 10. Comprueba que el archivo wp-config.php es semejante al de una instalación normal de WordPress (las últimas sentencias son diferentes y si no las eliminas la desinstalación no funciona).
• 11. Regenera los permalinks, desde el escritorio de WordPress: opción “Settings” > “Permalinks” (esto requiere permisos de escritura adecuados, 777, en el archivo .htaccess; si no se consigue desde WordPress hazlo manualmente insertando las instrucciones que se indican).
• 13. Optimiza la base de datos entrando de nuevo en phpMyAdmin.
• 13. Ajusta el plugin de backup para asegurar que se realiza correctamente la siguiente copia de respaldo del blog principal.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada Desinstalar un multisite de WordPress: una tarea sencilla fue publicada primero en Blogpocket

Cómo cambiar un blog de servidor en un WordPress multisite

En esta entrada te explico cómo cambiar un blog de servidor en una instalación multisite de WordPress, modificando también el dominio. La alternativa de configurar WordPress.org como un conjunto de blogs es muy interesante y útil. Sin embargo, es posible que necesites extraer uno de sus blogs para trasladarlo a otro servidor como sitio independiente. A continuación, te detallo todo el proceso.

Introducción

Suponiendo que el dominio principal de la red sea misitio.com, y esté compuesta de los subdominios sitio1.misitio.com, sitio2.misitio.com, etc., lo que vamos a hacer es ver cómo cambiar un blog de servidor, por ejemplo, sitio1.misitio.com a otra máquina bajo el dominio sitio1.com.

¿Qué necesito antes de empezar?

Es fundamental realizar un backup completo del blog que deseamos migrar. Te recomiendo que para ello emplees un plugin. Yo sigo utilizando DB Backup con el que se obtiene un archivo de las instrucciones sql necesarias para restaurar la Base de datos, incluyendo comentarios y configuración (plugins, widgets, etc.) y que, aunque ya no se actualiza, cumple su misión. Te recomiendo, no obstante, que leas el siguiente artículo de Ayuda WordPress acerca de cómo hacer backup de tu instalación: Backup WordPress, la guía definitiva.

También puedes llevar a cabo el backup con la función export de PHPmyAdmin pero, de esa forma, solo se consigue un respaldo de posts y páginas, no de la configuración.

Para realizar todos los cambios debemos poseer acceso a los paneles de administración de ambos servidores (origen y destino). El blog origen puede funcionar en paralelo con el de destino pero conviene que no actualices aquél hasta que el traslado no concluya satisfactoriamente.

Aunque el proceso no es complicado, requiere de ciertos conocimientos de gestión de bases de datos MySQL, cuestión que se simplifica mucho con el gestor PHPmyAdmin, facilitado por la mayoría de los proveedores de alojamiento Web.

Existe un plugin para llevar a cabo backups y migraciones de este estilo pero yo prefiero hacer este tipo de cambios manualmente. Dicho plugin es WordPress move.

Cómo cambiar un blog de servidor de una instalación WordPress multisite

Sigue los pasos detallados a continuación para cambiar un blog de servidor (el blog sitio1.misitio.com, dentro de una red WordPress multisite, a sitio1.com).

• Si ya existe una redirección a sitio1.com, en el servidor de origen, implementada con el método explicado en
  WordPress 3.0: mapeo de dominios, deshaz los puntos 4 y 3 en ese orden.
• Crea el dominio en el servidor destino y dirige sus DNS al servidor destino.
• Averigua el ID del blog sitio1.misitio.com accediendo a “My sites” > “Network Admin” > “Sites”. La URL del enlace para editar el sitio es del tipo: http://misitio.com/wp-admin/network/site-info.php?id=X y la X del final es la ID del blog.
• Copia a un directorio temporal las siguientes carpetas del servidor de origen: wp-content/themes, wp-content/plugins, wp-content/languages y wp-content/blogs.dir/X/files, donde X es la ID del blog.
• Copia también a un directorio temporal los siguientes archivos del directorio raiz del servidor origen: favicon.ico, .htaccess y robots.txt.
• Instala WordPress en el servidor destino. Realmente, con este paso solo comprobaremos que existe una conexión satisfactoria con la base de datos ya que, en un paso posterior, eliminaremos las tablas creadas y las restauraremos con el backup. Asumo que sabes instalar WordPress en un servidor. En caso contrario, lee el siguiente artículo: Cómo instalar WordPress 3.5 (y versiones superiores)
• Añade, en el servidor destino, lo siguiente al archivo wp-config.php: define(‘WPLANG’, ‘es_ES’); para traducir al español la instalación y $table_prefix = ‘wp_X_’; donde X es la ID del blog. Las tablas de un multisite poseen como prefijo “wp_X” (X la ID del blog) por lo que asignaremos también ese prefijo al blog en el nuevo servidor. Por seguridad también conviene hacer que dicho prefijo sea diferente de “wp_”.
• Copia las carpetas guardadas en un directorio temporal, en un paso anterior, al servidor destino: wp-content/themes, wp-content/plugins, wp-content/languages.
• Copia el contenido de la carpeta wp-content/blogs.dir/X/files guardada en un directorio temporal, en un paso anterior, a wp-content/uploads del servidor destino.
• Copia el archivo favicon.ico al directorio raiz del servidor destino.
• Elimina, en el servidor destino, con phpMyAdmin todas las tablas de la base de datos.
• Importa, en el servidor destino, con phpMyAdmin el archivo sql con el backup.
• Modifica, en el servidor destino, con phpMyAdmin el prefijo de las tablas que no sea “wp_X” (X es el ID del blog). Generalmente, esas tablas serán wp_usermeta y wp_users.
• Modifica, en el servidor destino, con phpMyAdmin los valores de site-url (sitio1.com), home (sitio1.com) y upload-path (wp-content/uploads) en la tabla wp-options.
• Comprueba, en el servidor destino, que tienes acceso al panel wp-admin en el nuevo dominio
• Reconstruye, en el servidor destino, los permalinks (“Settings” > “Permalinks”). Comprueba que el archivo .htaccess tiene permisos para poder escribir en él.
• Modifica, en el servidor destino, las URLs en la tabla wp-content. Para ello, ejecuta las siguientes consultas en phpMyAdmin: update wp_posts set post_content = replace( post_content, ‘http://sitio1.misitio.com/files/’, ‘http://sitio1.com/wp-content/uploads/’ ) y update wp_posts set post_content = replace( post_content, ‘http://sitio1.misitio.com’, ‘http://sitio1.com’)
• Modifica, en el servidor destino, las direcciones GUID en la tabla wp-content. Para ello, ejecuta las siguientes consultas en phpMyAdmin: update wp_posts set guid = replace( guid, ‘http://sitio1.misitio.com/files/’, ‘http://sitio1.com/wp-content/uploads/’ ) y update wp_posts set guid = replace( guid, ‘http://sitio1.misitio.com’, ‘http://sitio1.com’)
• Comprueba, en el servidor destino, que las URLs de las imágenes direccionan al servidor destino.
• Comprueba, en el servidor destino, que puedes subir una imagen desde el escritorio de WordPress y que se aloja en la carpeta wp-content/uploads
• Revisa, en el servidor destino, todos tus widgets y opcioines del theme (incluidos los menús). Cambia manualmente las URLs en todo lugar que sea necesario.
• Revisa, en el servidor destino, todos los plugins y verifica que se encuentran también activados en el servidor destino. Algunos suelen desactivarse con este tipo de operaciones como, por ejemplo, Akismet.
• Revisa, en el servidor destino, la configuración correcta de los plugins en el servidor destino. Por ejemplo, en el plugin de Backup ya no será necesario realizar copia de algunas tablas.
• Si posees un plugin para generar el archivo robots.txt, verifica que la URL es la del dominio destino. Si no lo generas con un plugin, copia el contenido del archivo robots.txt que guardaste al principio.
• Añade cualquier regla específica del archivo .htaccess que guardaste al principio. En principio, solo serán necesarias las añadidas por WordPress relacionadas con los permalinks. No añadas ninguna otra si no estás seguro de su significado.
• Añade sitio1.com a Google Webmaster Tools, verifica el sitio y envia un sitemap. Si utilizabas un plugin para generar el sitemap, verifica que la configuración para el nuevo sitio es correcta. Si no tenías plugin o ni siquiera usabas sitemap, lee el siguiente artículo: Cómo enviar el sitemap a los principales buscadores

Espero que este artículo te ayude a cambiar un blog de servidor, desde una instalación WordPress multisite.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada Cómo cambiar un blog de servidor en un WordPress multisite fue publicada primero en Blogpocket

Los comentarios regresan a Blogpocket con Google+

¿Por qué quitamos los comentarios en Blogpocket?

Históricamente, el sistema nativo de comentarios de Blogpocket (el que viene de serie con WordPress) no tiene apenas comentarios o, mejor dicho, la inmensa mayoría de ellos son spam. Así como en otros blogs los comentarios son esenciales, en Blogpocket no sucede así.

En doce años hemos probado todo tipo de servicios, pasando por Disqus y Facebook que pueden considerarse paradigmáticos. Disqus es el tipo de sistema externo que proporciona seguridad y optimiza el consumo de recursos pero que carece de las características sociales de Facebook. Por el contrario, Facebook posee esa socialización pero todos sabemos para qué utilizan esa red social muchos usuarios. Cuando probé Facebook como sistema de comentarios tuve mucho más spam que sin él.

Nos guste o no, la conversación está en las redes sociales y en Twitter. En estos tres meses en los que Blogpocket ha vivido sin comentarios, sorprendentemente, ha crecido mi interacción con mis seguidores, incluyendo en éstos a los lectores del blog. Ciertamente, sin comentarios en el blog se pierde el log de la conversación y no se puede hilar. Pero esa es una característica de la conversación en redes sociales. Hoy me quedaba con la frase que citaba Enrique Dans en Mercados que caen… por un tweet: “It’s not a bug, it’s a feature”.

No poder seguir ordenadamente el histórico de una conversación en Twitter o redes sociales, tal como se hace en el sistema de comentarios de un blog, también es una “feature” no un error.

¿Por qué regresan los comentarios a Blogpocket?

Sigo experimentando y buscando las mejoras que beneficien tanto a los lectores como a mi, como gestor del blog. Muy lejos de cometer un sacrilegio, como se dijo, deseo encontrar la mejor forma de interactuar con los lectores.

El blog es una herramienta nada más. El formato ha ido evolucionando y quién sabe lo que nos deparará en un futuro. Los blogs nacieron sin comentarios y Twitter ha influido mucho en el formato.

Google acaba de proporcionar el mecanismo para integrar los comentarios de Google+ en cualquier blog y vamos a probarlo con la intención de que nos sea útil a todos. A priori, las ventajas de este sistema son muchas. Por ejemplo, se puede comentar solo dentro del ámbito de tus círculos.

¿Còmo se implementa el sistema de comentarios de Google+ en WordPress?

Introduce el siguiente código en el sitio donde quieras añadir los comentarios, dentro del archivo single.php.

<script src="https://apis.google.com/js/plusone.js">
</script>
<div class="g-comments"
    data-href="<?php the_permalink(); ?>"
    data-width="642"
    data-first_party_property="BLOGGER"
    data-view_type="FILTERED_POSTMOD">
</div>

Si tu blog es de Blogger, simplemente sustituye “<?php the_permalink(); ?>” por “[URL]“.

Ya existe un plugin disponible, aunque todavía es un desarrollo provisional y no se encuentra en el directorio oficial de WordPress. A mi no me ha funcionado y, por eso, te recomiendo de momento que incluyas simplemente el código citado anteriormente.

En los próximos días saldrán a la luz más plugins y recursos relacionados con este asunto. Pero, de momento, vuelven los comentarios a Blogpocket. Úsalos para enriquecer Blogpocket.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada Los comentarios regresan a Blogpocket con Google+ fue publicada primero en Blogpocket

10 consejos para optimizar el rendimiento de tu blog

El otro día reflexionábamos aquí acerca del uso de un plugin como W3 Total Cache para optimizar el rendimiento de un blog. En ¿Quién tiene la culpa del incremento de carga de un blog? me inclinaba por no cargar la instalación de WordPress con todo tipo de plugins y dirigir los esfuerzos en simplificar la presentación, eliminando elementos que, al fin y al cabo, sirven para muy poco. Por ejemplo, vimos que los botones para compartir en medios sociales usan scripts (que hay que cargar en la página) que, como en el caso de Facebook, pueden incrementar el tiempo de carga en más de 1 segundo.

Con ello, no digo que haya que quitar los botones para compartir. Pero se ilustra a la perfección lo que quiero decir.

También he recibido algunos mensajes preguntándome acerca de la configuración en el servidor. Es decir, si todo no pasaría por acelerar el servidor con algún software del estilo de Varnish. En efecto, eso es una variable muy importante y que puede ser determinante para mejorar el rendimiento. Varnish es un proxy caché, acelerador web y balanceador de servidores Web que funciona sobre sistemas operativos como Linux y Mac, entre otros. Pero su instalación y configuración requiere conocimientos técnicos que no poseen la mayoría de los bloggers. Si tu servidor de hosting es compartido, seguramente veas mermado el rendimiento pero si gozas de uno dedicado lo más probable es que la configuración ya esté optimizada lo suficiente.

Así que la pregunta es ¿qué puede hacer la mayoría de la gente para acelerar la carga de las páginas de su blog?. Si utilizas alguna de las plataformas autoalojadas (Tumblr, Blogger, WordPress.com, etc.), no tienes que hacer nada. En el caso de WordPress.org, te recomiendo los siguientes consejos y verás acelerado tu blog.

• 1. Limpieza de plugins. Decididamente soy “anti-plugins” y no cabe duda de que los plugins son, muchas veces, fuente de quebraderos de cabeza. Pero también hay que reconocer que esa característica de WordPress es lo que hace a la plataforma verdaderamente interesante. Simplemente, plantéate llevar a cabo una limpieza de plugins. Puedes usar P3 (Plugin Performance Profile) para detectar aquellos plugins que frenan el rendimiento de tu blog.
• 2. Optimizar las imágenes. Junto a los scripts de JavaScript y los archivos CSS, las imágenes son los elementos que más influyen en la lentitud de un blog. Lo ideal sería un blog sin imágenes pero si las vas a usar, tienes que optimizarlas; es decir, que no ocupen muchos K’s. Lo malo es que una imagen con pocos K’s seguramente tendrá poca calidad y se verá mal (pixelada o borrosa). Te recomiendo el uso de algún plugin para optimizar las imágenes en el momento de subirlas al servidor. Prueba Smush.it que reduce el tamaño de las imágenes de forma óptima.
• 3. Servir las imágenes desde un CDN. Lo mejor sería alojar las imágenes en un CDN (Content Delivery Network) configurado para servir óptimamente las imágenes. El Cloud Front de Amazon (S3) tiene un precio muy asequible y entre otras ventajas es posible asociarlo a W3 Total Cache para que automáticamente se cree una copia de las imágenes que subas desde tu escritorio de WP.
  Otra solución, más sencilla y seguramente más adaptada a la mayoría de los usuarios, es Photon, una de las opciones que posee el súper plugin JetPack. Photon emplea los servidores de WordPress.com y la copia también es automatica una vez instalado. Para utilizar JetPack es obligatorio poseer una cuenta de WordPress.com.
• 4. Compresion GZIP. Esta es una forma de que nuestro blog acelere la carga de los archivos: comprimiéndolos con GZIP. Ayer mismo en Ayuda WordPress publicaban un estupendo artículo explicando cómo habilitar la compresión GZIP sin utilizar plugins.
  Para averiguar si tu sitio tiene activada la compresión GZIP puedes usar esta herramienta de GID Network: A simple online web page compression / deflate / gzip test tool.
• 5. Caching. El sistema de cache es, sin lugar a dudas, la mejor solución para optimizar el rendimiento de un blog. WP tiene que generar las páginas del blog cada vez que alguien lo solicita lo que significa múltiples accesos a la base de datos y muchas operaciones que disminuyen el rendimiento del servidor. Sin embargo, si se sirven páginas estáticas siempre que se pueda, se reduce mucho el tiempo de carga de las mismas.
  Como dije anteriormente, W3 Total Cache es el plugin por excelencia para este tipo de caching, con numerosas funcionalidades, incluida la de integrarse también con diversos CDNs, como el Cloud Front de Amazon.
  Sin embargo, ese plugin consume por sí mismo demasiados recursos y se han detectado diversos problemas de incompatibilidad con otros plugins y funciones. Pasa al punto 6 para ver otras alternativas.
• 6. Uso de un CDN. Emplear un CDN no solo puede ser útil para alojar las imágenes y que puedan servirse más rápidamente, sino que se pueden aprovechar todas sus funciones para acelerar la carga de tu blog. Por ejemplo, Cloud Flare nos ofrece un plan gratuito, con características suficientes para un blog normal. La configuración es muy sencilla y para resolver el problema de las IPS (al ser un proxy inverso, las IP de conexión ahora pertenecen al rango que emplea CloudFlare) existe el plugin WP CloudFlare. Mira esta lista de plugins gratuitos (puedes emplear incluso DropBox): Lista de CDN gratuitos.
  En cualquier caso, yo te recomiendo que pruebes PageSpeed Service de Google. Para mi, es mejor solución que W3 Total Cache y como puedes ver en la imagen feature de este post, se pueden conseguir reducciones de tiempo considerables.
  Para utilizar PageSpeed hay que enviar una solicitud a Google (es un servicio Beta) pero la configuración no requiere modificar los DNS del dominio (como en CloudFlare) sino realizar un par de ajustes en los registros A y CNAME y esperar a que se propaguen los cambios. Comprueba ésto último con Whatsmydns.net.
• 7. Minimizar y unificar CSS y JS. Para acelerar la carga de las páginas de tu blog, también es necesario reducir el tamaño de los archivos CSS y de los scripts JavaScript. Existen plugins que lo hacen como Better WordPress Minify. Pero si usas un CDN, como el de Google (ver punto 6), tendrás esas funciones aseguradas.
• 8. Eliminar widgets innecesarios. Este apartado tiene que ver con el hecho de que muchos elementos externos que se añaden habitualmente a un blog emplean scripts muy pesados. En la mayoría de los casos, el problema es también la conexión a los servidores desde donde se realiza la descarga que es muy lenta. Los ejemplos más claros son las conexiones al servicio de Google Adsense y los botones para compartir de Facebook.
  Te aconsejo una limpieza, en general, de widgets y elementos externos.
• 9. Usar un theme optimizado. El código PHP de un theme, si no está bien desarrollado, también puede afectar a la velocidad de carga. Con un theme Premium (de pago) te aseguras, además del soporte técnico y actualizaciones, un desarrollo de calidad. No siempre eso es así, pero si eliges un theme gratuito te arriesgas a errores que pueden llevar a penalizar el rendimiento de tu blog.
• 10. Plantearte no usar WordPress. ¿Y si todo lo anterior falla? Entonces, quizás sea el momento de plantearte abandonar WordPress y migrar el blog a una de las plataformas que vienen con mucha fuerza: Kirby, Jekyll o Anchor. De esos tres nuevos CMS, el que más se oye como sustituto de WP quizás sea Anchor, como hablábamos el otro día en Blogpocket.

Te recuerdo, que con Pingdom puedes medir la velocidad de carga de tu blog. No es exacta al 100% pero dispone de un análisis muy exhaustivo del grado de rendimiento.

Respecto a los nuevos CMS, Guillermo Carvajal está actualizando constantemente su artículo El retorno de los blogs estáticos. Te recomiendo encarecidamente su lectura.

De todo esto se desprende que no hay ni varita mágica ni soluciones universales para optimizar el rendimiento de tu blog. Deberás aplicar uno o varios de los apartados que hemos citado en esta entrada y comprobar con cuál o cuáles se reduce más el tiempo de carga de tu blog. En algunas no se requiere nada más que conocimientos de WP y en otras necesitarás saber algo (muy poco) de servidores.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada 10 consejos para optimizar el rendimiento de tu blog fue publicada primero en Blogpocket

¿Quién tiene la culpa del incremento del tiempo de carga de un blog?

Me refiero al tiempo que tarda en cargar cualquiera de las páginas de un blog. Es algo que podemos medir, sinir más lejos, con Pingdom. Observa la imagen siguiente que corresponde al tiempo que tarda en cargar el post más reciente de Minid.net, un ejemplo extraordinario y un modelo a tratar de imitar: 307 ms. Veloz como el rayo.

Pinchar en la imagen para agrandarla

Para llegar a esos niveles de optimización hay que conjugar una serie de técnicas que no son tan difíciles de aplicar. En Minid se utilizan seguramente todas ellas pero si accedes al blog con tu navegador te llamará la atención un diseño muy simple. No hay imágenes ni ningún aditamento superficial. Sin embargo, la página es muy agradable para leer que, al fin y al cabo, es lo que a los lectores de ese blog les gusta. Minid ha prescindido de todo lo superfluo y ahí radica, principalmente, la razón de su velocidad.

Cuando instalé P3 (Plugin Performance Profiler) para averiguar qué plugins recargaban más la instalación de mi WordPress, me di cuenta sorprendentemente de que W3 Total Cache era un de ellos. Por eso lo eliminé. No me extrañó que el tiempo de carga de las páginas de Blogpocket se redujera drásticamente. No solo lo reflejaba Pingdom sino que era palpable a simple vista tan solo manejando el panel de administración.

En teoría, un plugin de caching es recomendable para optimizar el tiempo de carga de las páginas pero, en la práctica, un plugin como W3 Total Cache consume tantos recursos que se come todo el tiempo que podría ahorrarse, o más. Hay soluciones alternativas como CloudFlare, pero no me fío de su plan gratuito que, pretendidamente, te ofrece optimización absoluta. Ya que CloudFlare actúa como un proxy inverso, las IP de conexión ahora pertenecen al rango que emplea CloudFlare. Eso puede suponer un problema y existe el plugin WP CloudFlare para asegurar el ver la IP original. Otro plugin añadido cuyo peso a la hora de cargar las páginas habría que medir.

¿Qué es lo que merece la pena entonces? Utilizar CDNs con sus correspondientes (y pesados) plugins o reducir todo lo posible los elementos innecesarios y conseguir una optimización orgánica. Apuesto por lo segundo.

Por otra parte, ¿qué es lo que más pesa en la carga de una página? Indudablemente, las imágenes, los archivos CSS, JS, etc.,… y todos aquellos scripts externos que instalemos. Respecto a imágenes, hay que tratar de subir las menos posibles u optimizarlas con plugins (¡Oh!) como jQuery lazy load plugin y WP Smush.it.

Para los archivos CSS y JS, se pueden comprimir o minimizar con una de las muchísimas herramientas existentes.

Pero, ahora te propongo que te fijes en la imagen que viene a continuación. Se trata de la carga de uno de mis posts más recientes (2,54 s. en total) y en ella se observa un excesivo tiempo de carga para un script de Facebook (más de 1 segundo). Se trata de uno de los scripts que se cargan para el botón de compartir en esa red social. Me llamó la atención y buscando información encontré este post revelador: Facebook Optimization It’s time for Social Media to Follow suit.

Pinchar en la imagen para agrandarla

Eliminando el botón de Facebook del pie de ese post, el tiempo total se redujo a 1,63 s., como puedes ver en la imagen siguiente.

Pinchar en la imagen para agrandarla

Con todo esto quiero reflexionar sobre el camino correcto que hay que adoptar para optimizar el tiempo de carga de un blog. No estoy seguro de que ese camino sean plugins de caching ni CDNs. Me inclino más por la opción de la simplificación, eliminando todo aquello que no necesitamos realmente. Y centrándonos todo lo posible en el contenido.

Y cuidado con los scripts que instalan las redes sociales para acceder a sus servicios (tales como botones para compartir). Puedes ahorrar mucho tiempo simplemente eliminándolos.

Ni más ni menos.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada ¿Quién tiene la culpa del incremento del tiempo de carga de un blog? fue publicada primero en Blogpocket

Eliminando el monstruo W3 Total Cache

W3 Total Cache no es un plugin, es un monstruo horrible que nunca debí instalar. Lo siento Clara, mi instalación cada vez se hacía más pesada y tras actualizar a la última versión, el monstruo dio la cara: Blogpocket Multisite simplemente se fue al carajo. Clara Avila me solicitó mi lista de plugins favoritos para confeccionar su post ¿Me puedes recomendar un plugin de WordPress?, y yo le recomendé W3TC en el capítulo de rendimiento. Lo siento, W3TC ayuda pero a destruir un blog .

Sin embargo, desactivar y eliminar W3TC no es tan fácil. Los monstruos es lo que tienen. A continuación, te indico los pasos a seguir para deshacerte totalmente de W3TC pero no te garantizo que quede algún rastro oculto por ahí.

• 1. Tener instalada la última versión del plugin W3 Total Cache.
• 2. Asignar permisos 644 al archivo “.htaccess”.
• 3. Asignar permisos 644 al archivo “wp-config.php”.
• 4. Acceder al panel de “General Settings” (Performance>General Settings) y desactivar todas las opciones de caching (quitar el check a todas las casillas “enable”).
• 5. Ir a la sección “Miscellaneous”, al final de la página de “General Settings”, y desactivar todas las opciones.
• 6. Hacer clic en “Save All Settings”.
• 7. Arriba de la pantalla, aparecerá el mensaje en rojo “The plugin is currently disabled”.
• 8. Ir a Plugins>Installed Plugins y desactivar el plugin W3 Total Cache.
• 9. Borrar el plugin W3 Total Cache. Si tienes un multisite es posible que no te aparezca la opción de borrado del plugin. En ese caso, elimina la carpeta del plugin y todos los archivos que contenga, mediante FTP.
• 10. Con FTP eliminar los siguientes archivos que se encuentran en la carpeta wp-content: w3-total-cache-config.php, db.php, advanced-cache.php y object-cache.php.
• 11. Dentro del directorio wp-content eliminar todas las carpetas que empiecen por “w3tc” y todos los archivos que contengan.
• 12. Comprobar que en el fichero .htaccess no existen reglas “re-write” relacionadas con W3TC. Si así fuese, bórralas
• 13. Dentro del archivo wp-config.php, sustituir la instrucción define(‘WP_CACHE’, true); por define(‘WP_CACHE’, false);. Si instalas otro plugin de caching, tendrás que volver a cambiar a “true”.

Una de las supuestas ventajas de W3TC era que se puede activar el CDN de Amazon para optimizar el tiempo de carga de las páginas. Aquí en Blogpocket se publicó cómo configur W3 Total Cache para el CDN de Amazon. Realmente, con el CDN de Amazon se redujo un poco la carga de las páginas pero, aunque el coste mensual en euros era muy bajo, esa optimización se puede conseguir subiendo imágenes de poco peso. No creo que merezca la pena tanto esfuerzo, incluso económico, para tan poco beneficio.

¿Sustituto para W3TC? Se habla de combinar Super Cache WP y WP Minify. Pero realmente dudo de que este tipo de plugins sean eficientes.

De momento, voy a darle descanso a la base de datos. Y a mí mismo: exorcizar monstruos deja exhausto.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

La entrada Eliminando el monstruo W3 Total Cache fue publicada primero en Blogpocket

Con la caída de Google Reader se ha prendido la mecha del renacimiento de los blogs. Quizás eso sea un poco exagerado pero algo esperanzador se respira ya en al aire, un poco contaminado, de la Blogosfera.

Llevábamos mucho tiempo dormidos, un poco narcotizados por el boom de Twitter y las redes sociales. Y, de repente, llega Google con su desprecio a los usuarios y se produce la catarsis.

Los síntomas de que algo está cambiando positivamente son claros: empresas que se ponen a desarrollar nuevos agregadores de feeds o a impulsar aplicaciones que se encontraban en stand by, movimientos dentro de la Blogosfera que reabren debates olvidados (cierre de comentarios, el diseño mimimalista, la vuelta al blog como corazón de tus actividades online, etc.), … Y ello solo es la punta del iceberg.

También hay un interesante movimiento en el área de los sistemas de publicación de blogs open source. Principalmente desarrollados en PHP (igual que WordPress), existe una creciente aparición de nuevos CMS que incorporan características innovadoras (por ejemplo, uso de Markdown o ausencia de base de datos como en el caso de Kirby). Aunque eliminar la base de datos no sea realmente algo innovador (yo mismo programé mi propio CMS en 2001 con PHP y ficheros planos) sino posiblemente una necesidad ante el excesivo consumo de recursos de plataformas como WordPress.

Pero hoy venía a hablar de Anchor, un CMS del que muchos bloggers empiezan a postular como el futuro sustituto de WordPress.

Como dicen en WP Daily, ¿y qué es lo que nos encontramos tan sorprendente al abrir la caja de Anchor? En primer lugar, el tamaño del paquete del software. Tan solo 184 KB contra los 5,4 MB de WordPress. Eso es algo de lo que quienes estamos acostumbrados a lidiar con WP agradecemos como agua de mayo. Eso y la simplicidad: amamos lo sencillo pero, a la vez, aquello que nos proporciona funciones potentes y escalables. Anchor promete eso y mucho más.

Anchor es un gestor de contenidos gratuito, bajo licencia WTFPL, escrito en PHP5 y diseñado especialmente para blogs en los que prime el diseño minimalista y atractivo: bonito y limpio. Un ejemplo de sitio implementado con Anchor: Zleek. O estos otros: Dribbble.

Kirby me parece demasiado rudo y primitivo, por decirlo de alguna forma. Además, no quiero volver a perder el tiempo desarrollándome mi propio CMS. Sin embargo, al abrir la caja de Anchor me he encontrado un bonito paquete de software, que pesa poco, listo para usar y con posibilidad de extender con plugins y themes bonitos y limpios. Lo que debería ser WordPress, al fin y al cabo.

Buscar el theme perfecto para tu blog es una tarea muy difícil. Yo soy de los que piensa que el aspecto visual de tu blog no es lo más importante pero reconozco que, de todos los pasos que hay que dar para ponerlo en marcha, la elección de la plantilla es el más complicado. En los 12 años de Blogpocket, he desarrollado mis propios themes, he descargado plantillas gratuitas y también las he comprado.

Si vas a emplear WordPress como plataforma (y, sobre todo, en su versión instalable) existen muchas empresas que se dedican a desarrollar y vender themes. La cuestión sería si es preferible adquirir uno o utilizar uno gratuito. Themes gratuitos también los hay para todos los gustos y es fácil encontrarlos (aunque sí es verdad que cada vez menos). La diferencia suele estar en que los de pago poseen más funcionalidades y se ofrece soporte y actualizaciones gratuitas. En ese sentido, uno de los mejores sitios para comprar themes es Theme Forest.

Si buscas un theme, con unas características determinadas, puedes echar un vistazo en uno de los numerosos directorios que encontrarás en la Red. También son habituales las recopilaciones de plantillas que se publican todos los días en la Blogosfera, como por ejemplo en WPlift, donde se acaba de publicar esta interesante lista de 21 Themes minimalistas y responsives gratuitos o esta otra con 30 modernos themes “lifestyle”.

Sin embargo, algo que echaba en falta es un sitio dedicado expresamente a mantenerte al día sobre los themes existentes, dividido por categorías, y con un listado de las empresas dedicadas a comercializarlos. Y acabo de descubrir There is a theme for that, una Web que ha puesto en funcionamiento Matt Hall, alguien que lleva tiempo desarrollando themes para WordPress y quien explicaba en Find the Perfect Theme with “There is a Theme for That” los motivos para lanzar un sitio de ese estilo.

“There is a theme for that” es (y será) un recurso muy útil, sobre todo si, como prometen, se mantiene actualizado, el verdadero caballo de batalla de este tipo de sitios.

Origen de la imagen: ryancboren via photopin cc

Con la versión 3.5 se ha introducido un pequeño cambio en el proceso de traducción de tu instalación de WordPress.

En el artículo que publiqué en Weblog Magazine, Cómo traducir WordPress, en agosto de 2012, puedes seguir el método para traducir el panel de administración. Sin embargo, ahora es necesario llevar al directorio “languages” más archivos, y no solo el “es_ES.mo”. A continuación, el proceso actualizado:

• 1. Descarga la versión es español desde el sitio es.wordpress.org.
• 2. Sube a la instalación de WordPress en tu servidor los archivos “admin-es_ES”, “admin-network-es_ES”, “continents-cities-es_ES” y “es_ES.mo”. El directorio de destino debe ser “wp-content/languages”. Si dicho directorio no existe debes crearlo previamente.
• 3. Añade la instruccion “define (‘WPLANG’, ‘es_ES’);” al archivo “wp-config.php” que se encuentra en la raiz de tu instalación.

Si lo que quieres es traducir una plantilla, deberás traducir los mensajes de salida de cada uno de los archivos que la componen. Como decíamos en Cómo traducir los themes de Genesis, el framework para WordPress, esa es la ventaja de emplear un “framework” como Genesis o Thesis: que se proporciona la herramienta para automatizar su traducción.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.

WordPress es la mejor plataforma para publicar un blog. Siempre y cuando dispongas de una máquina (propia o contratada) para alojarlo, un dominio y un poco de conocimientos de PHP, MySQL e instalación de aplicaciones en servidores.

Pero hay algunas cuestiones fundamentales que, por experiencia, te recomiendo no olvides nunca. Y ellas son:

• No instales más plugins que los necesarios. Hazme caso, la mayoría de los plugins no son necesarios y no hacen más que comer recursos, lo que redunda en menor rendimiento. Muchas veces son fuente de problemas por incompatibilidad entre ellos. En Blogpocket hemos escrito mucho acerca de este asunto, pero te recomiendo el siguiente link: WordPress Most Popular Plugins (Infographic), una interesante infografía con los 30 plugins más populares.
• El SEO y las plantillas (themes) son importantes pero no lo más importante. Puedes perder mucho de tu preciado tiempo probando themes o preparando tu blog para gustar a Google. Pero lo que realmente se traducirá en visitas es la calidad de tus contenidos y la interacción social. Lo mejor es que automatices las labores de SEO. Existen muchos plugins (el más conocido es All in One SEO Pack) pero no dejes de echar un vistazo a los que se incluyen en el siguiente link: Effective SEO Plugins for WordPress.
• No pierdas tu blog por culpa de no haber hecho backup. No serías ni el primero ni el último que echa a perder su trabajo por no realizar copias de respaldo. Un blog no es la excepción. Es recomendable que también automatices esa tarea con algún plugin. El más utilizado es WordPress Database Backup pero existen servicios muy interesantes (y económicos) como Vaultpress que al ser propiedad de Automattic (la empresa que desarrolla WordPress) ofrecen backup online con integración absoluta con tu blog.

AVISO IMPORTANTE: Cambia la configuracion de tu suscripcion a Blogpocket en tu agregador poniendo el feed nativo http://www.blogpocket.com/feed, ya que el de FeedBurner lo usaremos, como maximo, hasta el proximo 1 de Julio de 2013.

Suscribete tambien a Blogpocket.com por e-mail.