Estas son mis razones.

Anteriormente había hablado de W3 Total Cache. De como me estaba ayudando mucho mejorando el sitio web.

Debo de admitir que este plugin era prácticamente mi favorito para realizar la tarea de caching. Algo importante si realmente quieres tener un sitio web rápido, además de que me ahorraba tiempo de procesador.

Sin embargo, recientemente comencé a notar problemas. Mismos que me hicieron mirar a WP Super Cache de nueva cuenta.

Errores en todas partes con W3 Total Cache

Una de las cosas que más me agradaban de este plugin de WordPress, es que podía configurarse de acuerdo a mis necesidades. El gran número de opciones abría grandes posibilidades de optimizaciones. De mejoras puntuales de acuerdo a mis necesidades.

Sin embargo, siempre hay cosas que salen mal. Y eso es en verdad cierto con software complejo.

El primer síntoma estuvo en las entradas programadas. Comencé a notar que estas arrojaban el error missed schedule con frecuencia. Molesto, pero nada más que eso… e incluso errores esporádicos que parecían no tener sentido.

Todas las soluciones en la web indicaban que debía de instalar algún plugin.

No. No lo iba a hacer. No tenia sentido que algo así sucediera, ya que el servidor no tenia razón de estar comportándose de forma errática.

Tras investigar un poco, resultó que el Object Cache estaba causando problemas en mi back-end. Tras desactivar esa característica, los problemas cesaron… al menos temporalmente.

Las cosas se complican todavía más

El segundo gran problema sucedió con admin-ajax.php. Comencé a notar un número inusual de errores 403 sin una explicación clara.

Me arrojaba el error a mi, a visitantes al azar, e incluso a los bots de google. Esto último imperdonable.

Debido a que las instalaciones que manejo contienen más o menos los mismos plugins… detectar al culpable seria relativamente sencillo. Tras un análisis, solo se limitaba a W3 Total Cache o a uno de seguridad.

Para agravar más la situación, el problema de missed schedule había regresado.

Fue entonces que la opción de WP Super Cache se volvió mucho más viable.

Ya tenia experiencia con él y sabia que podía hacer el trabajo sin contratiempos.

WP Super Cache entra al relevo

A diferencia de W3 Total Cache, WP Super Cache tiene opciones muy minimalistas. No eres capaz de configurar absolutamente todo. Aunque no falla en su trabajo: Mejora el rendimiento del sitio web. Sin complicaciones.

Pero para tener una solución completa con WP Super Cache, se requiere de un aplicativo que haga minificación. Ahí es en donde entra Autoptimize. Esto para comprimir las hojas de estilo y los scripts de javascript.

Esto lo debemos de hacer si queremos mejorar aún más el rendimiento y experiencia del usuario.

Aunque si contamos con un servidor rápido, la ganancia puede ser marginal. Pero menos consultas por visita siempre es bueno. En especial si sumamos muchas visitas al día.

El modo experto de WP Super Cache

Si bien cuenta con muchas menos opciones, hay algunas cosas que si se pueden hacer. En especial en lo que respecta a activar el uso de reglas en el .htaccess. Esto permite que se pueda saltar parcialmente la ejecución de PHP en algunos casos.

Mientras menos veces se tenga que invocar a PHP, mejor.

Activando el modo experto, y asegurándose de activar los casilleros deseados, da un rendimiento que hace que no extrañe W3 Total Cache. Aunque lo único que no hace WP Super Cache es el asignar las cabeceras cache de Apache para los recursos estáticos.

Pero agregar ese tipo de cosas es trivial. Igualmente se puede agregar rápidamente las reglas que trae W3 Por defecto, dependiendo de las configuraciones.

Conclusiones sobre el regreso a WP Super Cache

Si bien soy fanático de tener una herramienta con cientos de opciones, es una pena que encontré que ella causaba más problemas que beneficios. Problemas que no parecían tener soluciones fáciles, o que hacían que no valiera la pena la solución.

Por lo cual el contar con una alternativa más sencilla fue la mejor idea.

Hay algunas cosas que todavía tengo que apuntalar, en especial del lado del servidor. Como son las cabeceras… aunque Cloudflare se encarga por mi de eso.

Pero establecerlas manualmente siempre será mejor para proporcionar una experiencia más uniforme.

Esperemos que no suceda nada inusual esta vez.

The post Adiós W3 Total Cache, Hola WP Super Cache appeared first on Endless Manifesto.

Cambiar de servicio de hospedaje, para mi, era muy importante. Como parte de crecer y de aprendizaje. En especial por que tenia muy en claro lo que necesitaba. Además de que necesitaba mayor poder de procesamiento.

Es por ello que un VPS (Virtual Private Server) era la solución correcta. Pero es implicaba el ensuciarse las manos un poco. ¿Por qué? Porque en la mayoría de los casos, solo se nos entrega el esqueleto sobre el cual trabajaremos.

El resto de software corre por nuestra cuenta. Igual la seguridad. Es por ello que administrar un Servidor Privado no es para cualquiera. Tienes que saber exactamente lo que estás haciendo.

¿32bits o 64bits para Virtualmin?

Antes que nada, quiero decir que primero probé Virtualmin con Ubuntu 16.04 a 64bits en una VPS con 2GB. No lo hagan. En especial si van a instalar la suite completa.

¿Por qué? Bien, un sistema de 64bits solo se necesita si van a tener un servidor con 4GB de ram o más.

Si tienen uno de 3GB o menos, con una distribución de 32bits tienen más que suficiente. En especial en lo que respecta al uso de memoria.

Las aplicaciones de 64bits usan mucha más memoria. En mi caso, llegue a observar que tanto MySQL y Virtualmin competían por los recursos después de algunas horas. Esto causaba que se necesitara reiniciar el servidor cada que sucedía.

Esto a pesar de tratar de reducir la memoria al mínimo. De todas las aplicaciones.

De entrada, en un sistema 64bits, MySQL usa cerca de 1GB de ram (con el caché incluido). Claro, esto con varios programas y sitios instalados. Contra los 508MB con la misma configuración en un sistema 32bits.

Vaya que hay una diferencia notable. Incluso en los procesos de apache y php.

Igualmente, en el sitio oficial recomiendan 32bits para cuando hay memoria limitada. Cuando es 3GB o menos. Hay que hacer caso.

Instalación de Virtualmin y configuración

El panel lo puedes instalar tan fácilmente como ejecutar esto en la consola de un servidor nuevo:

# wget http://software.virtualmin.com/gpl/scripts/install.sh
# sudo /bin/sh install.sh

Por supuesto, nosotros podemos seleccionar entre otras opciones como instalar una configuración LEMP (nginx) en vez de LAMP (apache). O un servidor con características mínimas.

Pero el LAMP es mejor, en especial si necesitamos correr aplicaciones como WordPress. Aunque todavía, quizá en un futuro, pueda tener un proxy inverso con nginx y apache.

Pero ya veremos.

Regresando a la instalación. La misma es prácticamente automática. Como lo es la de VestaCP. Otro panel que pude probar. Pero a diferencia de Vesta, prácticamente todas las funcionalidades funcionaban out-of-the-box. Lo cual ahorra mucho más tiempo.

En cuanto a la configuración, hay poco que hacerle. Pero quizá lo más importante es el cambiar el modo por defecto de la ejecución delos scripts PHP por apache.

Por ejemplo, la configuración por defecto usa FCGId como modo de ejecución para PHP-FPM. Pero si instalas los paquetes necesarios, puedes usar el modo FPM. Aunque después de estar realizando muchas pruebas… tal parece que el modo por defecto, el FCGId, funciona sin comerse tanta memoria. Lo cual es una buena ventaja en servidores con poca memoria.

Se pueden hacer ajustes finos. Como los que se mencionan en esta página de Linode. Aunque no los he probado, hasta el momento el servidor que he montado ha soportado la carga.

Al menos ya no me muestra la multitud de errores 525, 503 y 520 de antes. Eso ya es ganancia. Junto con la velocidad general adquirida.

Conclusiones sobre Virtualmin y Digital Ocean

Si bien apenas llevo poco tiempo usando Virtualmin, este ha sido un panel que es realmente maravilloso para administrar un servidor. Te permite instalar servidor de correo con un cliente. Servidor LAMP, firewall, administrador de archivos, administrador de base de datos, entre otras cosas.

Esta muy completo.

Esto si, la curva de aprendizaje esta muy empinada. Uno puede tardarse mucho tiempo en conocer todo lo que puede hacer el panel.

No es muy amigable con el usuario. Pero eso no quita que sea muy poderosa.

Otra de las desventajas es que no cuenta con todas las opciones posibles en el frontend. Por lo cual muchas veces necesitarás editar los archivos directamente en el servidor desde la consola.

No es una queja, pero cuando te acostumbras… suele ser más rápido editar las configuraciones directamente en al consola. En vez de estarla buscando entre un mar de opciones.

Pero eso no quita el hecho de que sigo más que satisfecho y recomiendo este panel.

The post Virtualmin en Digital Ocean: Experiencias appeared first on Endless Manifesto.

Además, ofrece un importante número de opciones que se pueden configurar. Dependiendo de tus necesidades u objetivos. En mi caso, era el obtener un mejor rendimiento absoluto en varios frentes. Después de que los resultados en el PageSpeed Insights habían salido terriblemente mal.

Bueno, exagero un poco en ello. Pero al estar en un hospedaje compartido, es natural que ciertas cosas no corran de lo mejor. Yo espero poder migrar a un mejor ambiente en un momento cercano. Pero en lo que sucede, hay que trabajar con lo que se tiene.

Y un plugin de caché era la opción más natural para lograr los objetivos inmediatos.

¿Por que usar un plugin como W3 Total Cache?

La razón más sencilla es por que ya hay buenas alternativas que ya están correctamente escritas. De lo contrario, tendrías que reinventar la rueda. Dichos plugins ya toman en cuenta los problemas más comunes y los solucionan rápidamente.

Igualmente han tratado de seguir los lineamientos de Google, y otras plataformas similares, para realizar las mejoras. Esto buscando que los webmasters no tengan que estar instalando otras herramientas.

Por supuesto, esto no implica que sea la solución a todos los problemas. Hay casos en los cuales requerirás escribir tus propias soluciones, pero ese es un tema para otro día.

En mi caso, esta era la forma más viable de hacer las cosas.

Preámbulo a la optimización

Ten en cuenta que estas configuraciones funcionan en mi entorno de trabajo (Apache, PHP7, MariaDB). No necesariamente funcionaran en el tuyo. Hay muchas variables que están en juego, por lo cual al final lo que te funcione a ti pudiera ser diferente.

Ante de empezar, coloque el siguiente código en el footer de mi instalación. Con este, podría ver que tan mal estaba.

View the code on Gist.

Ya con ese código, pude ver resultados similares a este:

View the code on Gist.

Ouch, ¿De donde salían tantas consultas? ¿Como era posible que se consumiera tanto tiempo? Esos números indicaban que había un problema el cual tenia que ser solucionado.

Por supuesto, el primer lugar en donde tenia que mirar es en mi servidor e instalación. Eliminar los plugins innecesarios es algo que se tiene que hacer. Posterior, tuve que cambiar de PHP5 a PHP7. Esto debido a que PHP7 es mucho más rápido que PHP5, además de más seguro.

Por fortuna para mí, esto no generó problemas de compatibilidad. Pero es posible que tengas problemas si antes contabas con mensajes de «funciones obsoletas», ya que muchas de ellas fueron eventualmente eliminadas. Puedes solucionar ese tipo de problemas si no te importa ensuciarte un poco las manos con el código fuente.

Una vez limpiada mi instalación, ganando como 0.2 ms, solo quedaba optimizar lo que quedaba. Los plugins que quedaron eran los que consideré que eran de utilidad y necesarios.

Configuración de W3 Total Cache

Trataré de ser breve, ya que el compartir una configuración completa de W3 Total Cache puede ser extensivo. Aunque es bueno el tener una idea de todo lo que puedes lograr con dicho plugin. Aún para la versión gratuita.

Pero si haré incapie en aquellas características en las cuales logre observar una mejora.

Si vas a usar W3 Total Cache en una instalación multisite, lo primero que te recomiendo es activar el mismo para toda la red. Una vez que hayas configurado las opciones más comunes, como el Page Cache, Object Cache y Browser Cache; deberás encontrar la siguiente opción bajo Performance > General Settings y desmarcarla:

Esta es la opción que debe estar o mantenerse desmarcada

Una vez hecho hayas desmarcado «Use single network configuration file for all sites», podrás efectuar cambios «a medida» para cada sitio de tu red. Para ello, deberás de ir a «General Settings» dentro del Escritorio de cada sitio y buscar a la derecha el botón «Use Specific settings». Deberás de hacer clic sobre el mismo para poder editar las características a medida para ese segmento en cada sitio.

Por ejemplo, en mi caso, mi mayor problema fue con las opciones de Minify. Si bien estoy detrás de CloudFlare, el hacer uso de Minify era importante ya que las hojas de estilo CSS y JavaScript no se estaban combinando. Hacerlo eventualmente iba a ayudar mucho.

Pero aquí no había una solución que funcionase en todos los escenarios.

Peleándose con Minify en W3 Total Cache

La posibilidad de «minificar» las hojas de estilo CSS y JavaScript es algo muy importante. Pero, el problema de dicha utilidad es que muchas cosas pueden salir terriblemente mal.

Por ejemplo, compactar el HTML me es útil en este sitio web, pero no en otro. Esto debido a que puede romper el tema y sus características.

Algunas de las opciones activadas para minificar HTML

En el caso de Javascript, «defer» para compactar destruye las páginas hechas en Page Origin, mientras que la opción «async» destruye a Slider Revolution. ¿Que lio verdad? Dejarlos a todos con su gusto con una sola configuración es imposible. La tarea de optimizar se vuelve una de «prueba y error» en el mejor de los casos.

Las opciones de JavaScript pueden causar algunos problemas

En el caso de las hojas de estilo, el problema no es tan prominente. En la mayoría de los casos… las cosas simplemente funcionaron bien y se pudo optimizar sin mayor problema.

El único inconveniente de tener este tipo de configuraciones, es que deberás de «limpiar el cache» siempre que haya cambios. Eso puede ser un poco molesto cuando estás haciendo muchos cambios pequeños, pero se soluciona desactivando la opción de compactar o desactivando este plugin.

Activando Object Cache

Esta alternativa en W3 Total Cache es quizá la que mejor me ha resultado, después de la minificación.

Con los cambios antes mencionados y esta, logre tener entonces un tiempo re respuesta similar a este:

View the code on Gist.

Pasar de 101 consultas a 24 es muy bueno. Es decir que ahora se están realizando solo un cuarto de las consultas que se hacían antes. Eso le quite estrés al servidor de base de datos y se accede más rápido.

Para entenderlo mejor, el Object Cache almacena en disco las «consultas más comunes». Algo similar a lo que hace «Page Cache». Esto permite que ciertos valores sean accedidos de una forma mucho más rápida y ágil.

Mientras menos consultas sean realizadas, mejor. Eso siempre ayudará a que el sitio web sea más eficiente a la hora de tener mayor carga. Pero ten en cuenta que, al almacenar el cache en disco, es posible que esto genere muchos archivos adicionales. Eso hay que tenerlo en cuenta en especial si tienes el espacio o los inodes limitados.

Conclusión

Si la configuración de W3 Total Cache se hace bien, se pueden tener buenos resultados. En mi caso, pase de tener una respuesta promedio de +2 segundos a ~0.6 mili-segundos. Una mejora sustancial tomando en cuenta que todavía estoy algo limitado en este entorno.

También en este caso, es importante indicar que solo apuntale una parte del problema. El otro es del lado del servidor. Si se tiene acceso a un procesador más poderoso en el hosting, el tiempo de respuesta podrá verse mejorado.

Algunos incluso dirían que tener un VPS es casi una necesidad. Pero yo opino que todo depende de las propias necesidades y objetivos de cada persona. Un VPS es bueno para quien tiene el tiempo y recursos para administrar un servidor. Esa es una bestia completamente diferente. Y más si ponemos en la mezcla un servidor Varnish.

Encontrar el hosting adecuado resuelve una parte del problema. Con suficientes recursos se puede rentar un buen servidor, pero sin alguien que sepa como optimizar los programas que corren… pues, serán recursos desperdiciados.

Hay que tener un buen balance entre ambos, pero por ahora W3 Total Cache me ha sacado del apuro.

The post Mejorar WordPress con W3 Total Cache appeared first on Endless Manifesto.

And all of that because I wanted to run WordPress locally. This, because I would need more computing power than I could get from a regular hosting account.

The Origin of the Problem

I have been using EasyPHP since earlier this decade. Found it to be quite easy to install, move and play with. I just copied over the whole «install» folder to an USB pen drive and I had a portable server.

Easy so far there.

Even deployed it into a very special project made for Quintana Roo’s state government, that has given some interesting results.

I trusted it because it could resist all sort of problems and because messing with it was very easy. At least for self-developed solutions.

Before giving it a new shot into windows, I installed a LAMP stack into my Kubuntu install. Loaded WordPress into it, and gave it a go.

Eventually, I found some problems like that I needed to change users for the folders (like setting «www-data» as the owner) and other issues.

Everything worked as it should. Even preventing me from doing silly unsafe things, but that meant also that I would need to spend extra time I did not have.

The solution? Go back to windows and use a solution I had there.

Updated EasyPHP and got it running as usual. Installed WordPress and when come to download the first plugins… oh problems.

Long history short: WordPress did not saw any transport. Activating cURL or SSH did not help. Neither FTP. Neither some voodoo magic I had at hand.

Aim for a solution

Spend a fair time of weekend searching for another solution to my problem. As I had spent already a lot on it.

Giving up was not an option at this point.

After some reading, apparently, I also needed an FTP server to be running in Windows to make stuff work.

In Linux, I just had used the FS_METHOD «direct» to make it work with no issues at sight. In windows, it just did not work. WordPress complained that there was no «transport available».

That is why then I needed to search for an alternative. There are plenty there.

XAMPP is found

After a couple of searches just came across XAMPP. And I almost did jump aboard when seeing what it does come bundled with.

Like any stack, it comes with Apache, MySQL/MariaSQL and PHP… and Perl and FTP! This last one is what made me jump on as it was bundled.

I am not going to bother explaining the steps on how to get yourself rolling into a local WordPress install, as there are plenty examples out there already. And because I installed it almost on automatic.

The control panel, with some of its options

Of course, I do not recommend to get the bitnami WordPress add-on. While installing WordPress is easy and is tempting to run another installer to do the work for you… the results are not always… nice.

Closing it

Being able to do certain things locally will always be nice. And much faster than reliying in a remote server to process our requests.

It is a great way to rush development, try new things and of course… have the whole potential of your computer in case you need extra power while testing.

I have done one of the first steps needed… now, let’s see how far I can start to go when things start to fall on its place.

The post Give XAMPP a try… if using WordPress appeared first on Endless Manifesto.

So far, WordPress has been quite easy to manipulate. Extend and even update without any major issues. Something that I did not experienced with Drupal 6, back in the day.

That is why the more I mess with WordPress, the more I like it.

Keep building with WordPress

Rebuilding has been a pleasure so far. And that I have not yet got into code and extend some functionality myself. This using PHP or JavaScript. But I totally plan to do so.

Maybe this one will fit on what I do need. For now, a simple blogging platform that I can mess with at will. Not caring much of a dissaster happens.

But one thing is true, I need to wipe out properly some old installations and domains. Or probably give them a proper set up for its own.

One of the things that I have seen is that you can do Multisite installs. And that really sounds amazing. I had something like that when I was on Drupal.

But on Drupal it was like an administration nightmare. I hope it is much more easy with this CMS. With what I have been quite happy, and been seeing that some rumors I did read back in the day where not totally true. At least for now.

I mean, back in the day, I did not went the WordPress route because it was regarded as heavy and bloated. Maybe that was right back in 2010 or earlier, when I got this space.

But for today standards, almost any hosting space can deal with its needs quite easily. Despite that, there is a lot of work to do. A lot of optimizations that need to be done.

So, its time to move on.

The post WordPress: Setting up some websites appeared first on Endless Manifesto.

Back at the day when I was much more active web-wisely, having SSL or HTTPs was… painful at best, if not really expensive.

Today, while I was lurking and figuring out how to implement a nice online poll for something that is going on… I stumbled upon that.

Making a really long history short, I basically was messing up with a service called » Let’s Encrypt™» that comes embedded with cPanel. It was interesting that I could now offer secure content quite easily and without having to spend a bunch of extra bucks… what is good.

Of course, this only means that the communications between this server and you are secure… but is a nice step forward. Eventually, maybe I’ll have my hands over a private key or something, but that is a tale for another day.

Sadly for me, not all was that easy to set up in what seemed easy: Just change http to https.

Given the setup I have set here (Internet -> Cloudflare -> Private Server), WordPress started to fall into an «infinite redirection loop», and I pretty much clueless about it.

If I visited the website, without changing WP to use https instead of http, I saw half the stuff… but if I told WP to use https… it did fall into an infinite loop.

Of course, I was looking into websites like this one for answers… somewhere «promising», but at the end, only one thing or another worked out.

I was almost to give up when I finally found some light at the official WP codex, and I was surprised how much little I needed to add to fix such thing.

For the looks of it… apparently, my WP install got confused when I changed the settings and saw CloudFlare and kept trying to fix the issue, just making it worst…

But now things are much better, and kind of force SSL one way or another. What I have implemented in the other project I was messing with… and as long I do not have some kind of weird «warning», I will be a happy skonk (yeah, guess that one why).

The post SSL appeared first on Endless Manifesto.