Tu sitio necesita ser público para utilizar Jetpack: site_inaccessible

Si tienes el error “Tu sitio necesita ser público para utilizar Jetpack: site_inaccessible” te muestro cómo resolverlo

Después de una mudanza no deseada del servidor que hospeda esta página (y otras como AndroidVenezuela.com) estaba obteniendo un error al tratar de configurar Jetpack, el archiconocido plugin de WordPress que hace de todo un poco.

jetpack-popular-wordpress-plugins

El error es el siguiente:

Tu sitio necesita ser público para utilizar Jetpack: site_inaccessible

Tu sitio necesita ser público para utilizar Jetpack: site_inaccessible
Detalles del error: The Jetpack server was unable to communicate with your site [HTTP 404]. Ask your web host if they allow connections from WordPress.com. If you need further assistance, contact Jetpack Support: http://jetpack.com/support/

Luego de barajar varias alternativas, la solución es simple cuando se conoce la causa. Este error viene del hecho que Jetpack no puede acceder al archivo xmlrpc.php de tu sitio, que por alguna razón está inaccesible. Puede ser por permisología (debe llevar permisos 644) o en mi caso era el .htaccess que tenía esta configuración:

Esto hace que el archivo xmlrpc.php fuese inaccesible, no solo para Jetpack sino para todo el mundo. Eliminadas las líneas del archivo .htacess y problema resuelto, ya Jetpack puede ser configurado correctamente.

Cloudflare y W3Caché no se la llevan bien

Si tienes un blog con bastantes visitas, como en mi caso con Android Venezuela, sabrás que es una sensación agridulce. Por un lado tu contenido gusta y atrae visitantes, por el otro, se puede volver una pesadilla entre caídas del servidor, aumento de costos de hospedaje y una búsqueda eterna por optimizar cada elemento del sitio de tal forma que cargue bien y rápido.

Con dicho blog hemos pasado por todas esas etapas, siendo esta última de la que deseo hablar un poco. En esa manía interminable de optimizar y optimizar y seguir optimizando, se me ocurrió la nada desdeñable idea de combinar dos servicios gratuitos para que la carga del servidor disminuyera y por otro lado brindar mejores tiempos de carga del sitio, especialmente en un país con las peores velocidades de conexión del mundo.

En ese proceso infinito de optimización combiné Cloudflare, un servicio de CDN (Content Delivery Network) que es gratuito y W3Caché, un plugin de WordPress (que es el CMS que usamos en Android Venezuela) que combina varias técnicas para mostrar un sitio cacheado a nivel del servidor, del navegador e incluso a nivel de bases de datos, para no tener que hacer tantas consultas al servidor MySQL cada vez que se produce una visita al sitio.

Inicialmente todo funcionó perfectamente, bajando la velocidad de carga a unos 2 segundos, algo realmente bueno considerando que a veces hemos llegado a estar por encima de los 10 segundos. Sin embargo, un día cualquiera, sin razón aparente, la página murió. No cargaba pero tampoco daba error, el servidor seguía “vivo” pero inaccesible.

Traté por varias vías junto con la gente de Red Radio y PC (la mejor compañía de hosting venezolano en la que he estado, se las recomiendo) de recuperar el sitio pero todos los intentos fueron infructuosos, nada parecía funcionar, ni siquiera reconfigurar el sitio. Como no podía entrar siquiera al Dashboard de WordPress, tampoco podía desactivar W3Cache y luego toqué el botón que no debí tocar: Intenté borrar el plugin a mano. Los que conocen WP saben que esto suele ser suficiente para desactivar el plugin cuando el panel de WP no es accesible, pero W3Cache realiza tantos cambios en el servidor para poder funcionar, que el remedio fue peor que la enfermedad. El sitio ahora no respondía y estaba roto por dentro, puesto que a nivel de bases de datos se seguía haciendo referencia a archivos y configuraciones que yo me había volado del servidor.

La única solución fue la que debí ejecutar desde el principio: Solicitar a nuestro hospedaje que restaurara uno de sus múltiples backups automáticos, de tal forma de volver a una versión funcional. El detalle: Hubo que hacerlo a una fecha 15 días atrás, antes de que yo empezara a trastear con W3Caché. Eso significó perder 15 días de noticias, las cuales estoy restaurando a mano, una por una, pero al menos el sitio está de nuevo arriba y totalmente funcional.

Moraleja:

Debí probar primero si Cloudflare y W3Caché funcionaban bien en otro sitio de pruebas, antes de aplicarlo a Android Venezuela en producción. Si tú tienes un blog, evita esta combinación mortal y usa sólo una de las 2 soluciones, o un CDN que alivie la carga o el cacheo con W3caché.

Existen otras soluciones que permiten combinar varias técnicas, las cuales no voy a ahondar en estos momentos. El objetivo de la publicación es advertir a otros bloggers que ésta combinación Cloudflare + W3Caché puede resultar peligrosa para su blog.

en Blog | 652 Palabras

The Field

In varius varius justo, eget ultrices mauris rhoncus non. Morbi tristique, mauris eu imperdiet bibendum, velit diam iaculis velit, in ornare massa enim at lorem. Etiam risus diam, porttitor vitae ultrices quis, dapibus id dolor. Morbi venenatis lacinia rhoncus. Continuar leyendo

Año nuevo, plantilla nueva

Durante el próximo mes las actualizaciones al blog -de por sí pocas- disminuirán, puesto que estoy diseñando desde cero una nueva plantilla. Deseo que sea un tanto minimalista pero con información relevante según el contexto, cosa que ya veremos como me queda. También actualizaré a WordPress 2.7 e instalaré nuevos plugins.

Por lo pronto, Feliz Año a todos los amigos que no he podido saludar a estas alturas y bueno, lamentablemente ya se acabaron las vacaciones, nos toca agarrar energías (de donde las haya) para poder comenzar nuestras labores educacionales con el máximo provecho.