La gran experiencia de la WordCamp Irun 2018

No hace ni media hora que estaba despidiéndome entre abrazos de los que ya considero amigos y la “tribu” de personas apasionadas de WordPress. Hace dos semanas estaba en Bilbao, y este fin de semana ha tocado Irún.

Tenía muchas expectativas con esta WordCamp, expectativas que se han cumplido con creces, y me atrevo a afirmar que ha sido la mejor WordCamp en lo que a organización se refiere. Sin duda un grandísimo de Pablo Moratinos y todo el equipo de organización y voluntarios. Un 11, perfecto, nada que objetar.

Y por el resto, todo genial. El viaje comenzó movido, ya que Vueling canceló el vuelo (posteriormente me dijeron que había muchísima niebla) pero finalmente pude llegar el viernes por la tarde. Dejar las cosas en el hotel y nada más salir encontrarme con Ibon Azkoitia, con el que me fui de PintxoPote donde nos cruzamos con el equipo de Cádiz.

La cena fue simplemente espectacular. En la Sidrería Ola simplemente disfrutamos. Algunos ya decíamos que se podría acabar la WordCamp en ese momento.

Allí tuve la oportunidad junto a Tomás de conocer a Ryan, responsable de WPScan, la herramienta en la que se basa WPdanger, por lo que fue un placer poner cara a una muy buena persona que aporta tanto a la seguridad de WordPress.

El sábado comenzaron las ponencias… el programa de dos tracks y mi asistencia a algunas de ellas que fui “retransmitiendo” vía Twitter.

Primero vino la charla de Piccia que habló de los colores…

Luego vino la charla de Monty sobre AMP.

Luego vino mi charla… Hablé de WP-CLI, aunque eso ya lo he contado… muy contento por poder tratar temas técnicos desde una visión muy práctica y con una finalidad, en este caso: el mantenimiento de WordPress.

El siguiente punto fue la charla de Fernando sobre CMB2, muy interesante como elemento algo más técnico que ACF.

Previo a la comida estaba la charla de comunidad de Jonatan.

Después nos juntamos Ana, Fernando, Jaime y yo en el podcast de Club WordPress donde contamos muchas batallitas y en el que nos divertimos muchísmimo.

Cuando acabamos me fui rápidamente a la charla de Ana Cirujano, a la que llegué tarde por estar acabando de grabar el podcast, pero sin duda será el vídeo que recomiendo ver en WordPress.TV, porque su charla fue genial. Como siempre aprendiendo sobre tipografía y porqué usar una u otra letra según el momento adecuado o lo que quieras transmitir. Una fuente de conocimiento -y mejor persona- interminables.

Tras la charla de Ana me fui a otro podcast, en este caso el de Juanma de WP para Novatos

El siguiente paso fue la charla de Tomás. Recuerdo hace unos meses que hablando con él coincidimos casi casi a la par él en presentar la charla de Irún y yo lanzar la herramienta de Google Dorks en WPdanger.

Después de aquello, desconexión por mi lado, un rato de hotel y de camino a la cena / after-party. Allí muchas risas explicando batallitas de viejos de Internet, hablando de cómo era la web en los 90’s. Por supuesto rodeados de kalimotxos, cerveza, refrescos y comida. Por cierto, ¡qué ricas estaban las txistorras!

Y hoy ha sido el Contributor Day. Una vez más, en la sala/mesa de la Comunidad, tomando nota en todos los sentidos de cara a la WordCamp de Barcelona. Es muy probable que de Irún salgan dos meetup y una WordCamp, aunque aún es pronto para saberlo.

Y aquí ando, en el aeropuerto, recién llegado de la Universidad de Mondragón donde se ha celebrado el evento, con ganas de que anuncien Sevilla, Valencia, Pontevedra, llegue Barcelona y finalmente acabemos en Granada, con la posibilidad de una extra.

Gracias a todos los que os habéis acercado a saludar, a preguntar, los que me habéis hecho reír, los que habéis pedido fotos y sobre todo, gracias a la comunidad de Irún, porque ¡sois los p**os amos!.

#WCIrun 2018: WP-CLI para hacer mantenimiento semanal de tu sitio

En estos momentos se está llevando a cabo la WordCamp Irun, y una vez más, como ponente, quiero dejaros una pequeña presentación que se centra en comando de WP-CLI. El objetivo es sencillo: hay que hacer mantenimientos de WordPress de forma simple y a la vez con mucha información.

Si te atreves a usar la consola, quizá te interese usar WP-CLI, un pequeño gran proyecto de WordPress que te ayuda a ejecutar comandos sin necesidad de entrar e el panel de administración. Mucho más rápido y que no requiere de API ni servidor web.

Como decía, estos comandos que planteo están focalizados en hacer mantenimiento de WordPress con WP-CLI. Así que si estás harto de que al actualizar se te quede colgado el navegador, tengas problemas con JavaScript o cualquier otro impedimento, este es tu sistema.

Activar 2FA (Two Factor Authentication) en WordPress

WordPress es seguro, sí, y aunque se pueden hacer muchas mejoras a todos los niveles, el eslabón más débil siempre es el usuario, básicamente porque elije contraseñas muy débiles. Y sí, hay muchas maneras de aumentar la seguridad en WordPress pero hay una muy sencilla, que es el 2FA (Two Factor Authentication).

Seguro que en alguna película de esas de Las vegas donde salen casinos has visto que para entrar en la sala de seguridad hay un teclado en el que has de poner tus huellas dactilares y luego un código que aparece en una maquina y que el número va cambiando cada N tiempo. Pues básicamente esa es la idea que vamos a aplicar con nuestros usuarios.

Un segundo factor de autenticación es básicamente decir que has de poner dos contraseñas. La primera de ellas es fija y no tiene que cambiar en el tiempo (aunque cada usuario la puede cambiar cuando quiera). La segunda contraseña es una que ni tú mismo sabes. En este caso es un número de 6 cifras que se auto genera cada 30 segundos, habitualmente por una App que llevas en tu dispositivo móvil.

Como App, para usar algo libre y que no dependa de nadie podemos usar FreeOTP que dispone de App para iOS (en la tienda de iTunes) y para Android (en la tienda de Google Play).

Así que lo primero es descargarse la App e instalarla en tu dispositivo móvil. Cuando la tengas, pasaremos al propio WordPress donde tendremos que instalar un sistema que genere ese sistema de acceso doble. Hay muchas posibilidades de App, que básicamente hacen lo mismo, así que puedes elegir por ejemplo entre estas:

Al instalar el plugin básicamente te pedirá que escanees un código QR. Así que hay que irse a la App, abrirla e ir a donde está el lector de QR y escanear el código por pantalla. Tras eso, ya te comenzará a aparecer la serie de números en la pantalla del móvil, y tendrás que ponerlo en tu WordPress. Una vez quede activado, cada vez que accedas al panel de administración tendrás que poner tu usuario y contraseña, y posteriormente el código que te aparece por pantalla.

Con este sencillo sistema ya te proteges mucho más de lo que lo hacías antes. Y recuerda que estos sistemas de 2FA no solo están disponibles para WordPress, sino también para tu cuenta de Google, Dropbox, Linkedin, Twitter y otras plataformas conocidas (y no tan conocidas).

Organizar una Meetup de WordPress en España

Este fin de semana se ha celebrado la WordCamp Bilbao y aunque reconozco que mis expectativas no eran muy altas, me he quedado muy contento de cómo ha funcionado y muy probablemente volveré a la próxima que se haga.

En el Contributor Day he estado en la mesa de Comunidad. He decidido quedarme en esta ya que quería estar al día de varios temas que llevan candentes en los últimos meses, además de por ser uno de los responsables de la WordCamp Barcelona. Como sabéis he sido bastante crítico con el nivel “bajo” que ha habido últimamente en las WordCamp y quería saber cara a cara qué opinaban algunos pesos pesados de los asistentes y de la Comunidad en sí misma. Pero este tema lo voy a dejar aparcado hasta que pase la Wordcamp Irun que es lo que internamente me prometí.

Uno de los temas que han salido es el de la organización de las Meetup en España. Aunque oficialmente hay unas 45 (no sé la cifra exacta ahora) en WPCalendario tengo detectadas unas 55, por lo que surgen algunos temas importantes a la hora de organizar y crear Meetup de WordPress. En estas próximas líneas, y con licencia CC0, dejo mis ideas y sugerencias de conclusiones que saco como co-organizador de 2 Meetup (WPBarcelona y WPGramenet).


Creo que en mi zona hace falta una Comunidad WordPress

Lo primero que hay que plantearse es si realmente es una necesidad o no lo de la comunidad local. ¿Existen comunidades cercanas? ¿Crees que hay gente interesada? Si existen comunidades cercanas habla con ellos, ve a ellas, mira y aprende y a partir de ahí decide si crees que vas a poder conseguir crear tu comunidad local. Hay que tener presente que no ha de ser una comunidad WordPress genérica, sino que puede ser una comunidad específica de algún producto o temática, como las hay de WooCommerce, o solo de tecnología / desarrollo).

Vale, he decidido que sí

Pues si has decidido que quieres crear tu comunidad WordPress local, entra en el Slack de la comunidad española (puedes usar tu usuario de WordPress.org con la cuenta de correo nombredeusuario@chat.wordpress.org) que tienes un canal sobre las #meetup. Allí dentro puedes preguntar y consultar con otras personas que están en la organización y asisten a las Meetup. Pregunta e intenta que alguien te ayude y te haga de mentor (y si no lo encuentras, pregúntame a mi directamente que yo te ayudaré o encontraré a alguien que lo haga).

¿Qué necesito para comenzar?

Ganas… y unas cuantas cosas más. Para empezar lo más recomendable es que no estés tú solo en la lucha por la creación de la comunidad. Búscate a otra persona que te acompañe en el camino. ¡Somos una comunidad, así que al menos que dos tiren del carro!

Una vez tengas al equipo organizador, plantéate qué tipo de Meetup vas a querer: eventos en modo charla/ponencia, quedar con unos cuantos en el bar y charlar de los temas de actualidad y resolver dudas… no hay problema. Una Meetup puede ser tan formal e informal como quieras, por lo que puedes hacerlas en un Palacio de Congresos o en un bar cerca de tu casa. Incluso hay algunas Meetup que hacen un modelo mixto: cada 2 semanas quedan en el bar, y dos semanas después se reúnen de forma más “seria”.

Si has decidido hacer el modelo más formal, con ponencias, charlas y demás, has de plantearte los siguientes temas: lugar, temáticas y ponentes. Personalmente para mi el principal es el lugar; el resto ya saldrá solo.

El lugar

Si vas a hacer los eventos en un bar, piensa en cuánta gente puede caber, y habla con el dueño para que sepa qué vas a quedar con un grupo de gente. Si vas a hacer el evento con un modelo más formal busca un lugar donde quepan al menos 25 personas (mínimo). Para ello lo ideal es buscar lugares públicos, tipo bibliotecas. En general en las bibliotecas o algunas salas de los ayuntamientos, hay proyectos y sillas como para poder dar una charla y que quede bien. Cuando vayas a explicarles que eres parte de la comunidad WordPress, les puedes explicar que es WordPress en sí, pero sobre todo haz hincapié en que es una comunidad de código abierto, libre, que aboga por democratizar los contenidos en Internet y que el planteamiento es que sea inclusiva con un foco en enseñar a las personas a trabajar con el conocimiento y su privacidad. Además, cuando te pregunten quién será el responsable de las charlas, puedes decir que no existe una asociación como tal en España, pero que si necesitan un representante legal tienes a tu disposición la Fundación WordPress. Si aún así siguen poniendo pegas, entra en el canal del Slack de #meetups y coméntalo. Y si quieres ir un poco más arriba, puedes contactar con la Fundación y explicarles la situación.

Otro detalle importante del lugar es que es muy recomendable que haya WiFi, además de una pantalla o proyector. En caso de ser posible, ten disponible siempre cable o un portátil para que el ponente pueda emitir sin problema en caso de que su portátil no consiga funcionar.

Ponencias y Ponentes

En caso de querer quedar en plan informal, no habrá ni ponencias ni ponentes, simplemente una reunión de colegas en las que os ayudaréis unos a otros. Unas veces unos aportarán más que otros, seguramente depende de los temas que vayan surgiendo. Habrá diseñadores, desarrolladores, gente de negocio, marketing o contenidos, por lo que cada uno podrá aportar según sus conocimientos.

Pero si el planteamiento es más forma, con sus presentaciones, lo más recomendable es comenzar con al menos 2-3 temas y con 2-3 ponentes. Habitualmente os tocará a los organizadores hacer las 2-3 primeras charlas. Normalmente la primera suele ser de presentación de la Comunidad, explicando que simplemente por el hecho de asistir ya son parte de ella, hablando de WordPress.org, de los foros, del Slack, de las Meetup, de las WordCamp, etcétera. Además puedes enseñar un WordPress y explicar a los asistentes que con herramientas como poopy.life o pilvia.com pueden crear WordPress para hacer pruebas rápidas.

Si necesitas temas o ideas, lo más recomendable es darle una ojeada a las Meetup que se hacen en el resto de España o del Mundo. Seguro que los otros te darán ideas sin parar, además de tendencias en algunos temas (por ejemplo, en 2018 los temas más candentes fueron Gutenberg y el RGPD).

Las fechas

Aunque no hay un calendario perfecto, mi recomendación es la de que hagas eventos una vez al mes para comenzar, intentando además que tenga alguna lócica en cuanto a día de la semana (por ejemplo: todos los primeros martes del mes, o todos los últimos sábados de cada mes). las meetup de WordPress suelen hacerse durante la semana sobre las 1900-2100, aunque puedes encontrar muchas variaciones. Seguramente dependa mucho de lo que el lugar deje o no hacer. Muchas meetup, tras las charlas, quedan para tomar algún refrigerio y charlar de la vida en general, mucho más personal y para crear amigos y comunidad.

Meetup.com

Cuando tengas ya planteada una primera Meetup, date de alta en meetup.com y crea tu comunidad. Meetup es un proyecto de pago, por lo que tienes dos opciones: crear la Comunidad y pagar 1-2 meses la cuota, y estar seguro de que la cosa funciona, o directamente solicitar a la Fundación que te de de alta la comunidad. En cualquier caso el objetivo es que el usuario [wordpress] de Meetup se haga cargo como organizador de la Meetup, siendo tú y tus colegas los co-organizadores. No te preocupes, tendrás control absoluto de todo lo que se puede utilizar en la plataforma.

Una recomnedación es que una vez crees la comunidad, antes de promocionarla, le cambies el nombre a la URL y le pongas algo más molón, como puede ser WPDondeSea. Así tu web será [meetup.com/WPDondeSea].

Logo, web, Twitter…

Ahora que ya tienes creada la comunidad en Meetup, puedes plantearte montar un WordPress en un sitio del estilo a [www.wpdondesea.com]. El alojamiento y dominio corren de tu parte, pero si realmente te interesa y no te lo puedes permitir, hay personas en la comunidad que estarán dispuestos a ayudarte. Una vez más, si tienes alguna duda, contáctame e intentaré ayudarte con este asunto. De la misma manera es muy recomendable disponer de una cuenta en Twitter para comunicar. Lo más recomendable es disponer de una cuenta estilo [@WPDondeSea] y usar el hashtag [#WPDondeSea]. Cuando lo tengas todo, dímelo que lo añadiré a WPCalendario y así se irá promocionando entre aquellos que lo siguen tanto en la web como en Twitter. Muchos de los podcast que hay en España utilizan esta web cada semana para anunciar las Meetup que hay por todo el país, así que es una forma sencilla de conseguir promoción y de que asistentes que tal vez no epan de tu comunidad, la descubran.

Ahora que ya lo tengo todo, ¿qué más he de hacer?

Pues el objetivo es poco y mucho a la vez: por un lado consigue que te promocionen (coméntalo a tu radio local, a medios locales, periódicos y similares) sobre todo al principio, dilo por la comunidad, en Slack y otros lugares para que gente de sitios que tal vez no querían organizar el evento pero sí asistir, lo hagan… y por otro lado piensa en temas, preparar presentaciones, busca posibles ponentes de otras meetup cercanas que puedan estar dispuestos a viaja, como es mi caso en el que más d euna vez me he desplazado 100 kilómetros a la redonda para ir a dar alguna charla de un tema que me motiva y que me cuadraba por fechas.

¿Cómo sé que esto que me explicas es la forma de hacerlo?

Esta es una de tantas formas de hacerlo… cada comunidad es distinta, ya que tiene su propio sistema. Normalmente las diferencias entre las ciudades más grandes (Madrid, Barcelona…) y las del resto son significativas. Como decía al principio yo ahora mismo estoy gestionando la de Barcelona y la de Santa Coloma de Gramenet, una tiene 3.000 apuntados en Meetup y la otra tiene 30. Las expectativas son distintas, pero al final el trabajo y esfuerzo suele ser el mismo. Lo importante es que tú te sientas bien con cómo lo haces, y si no es así, mejorar la siguiente ocasión. Y para que veais formas distintas de cómo se organizan eventos WordPress, tenéis a vuestra disposición una charla de Pablo Moratinos: Cómo conseguir 25 asistentes a tu primera WordPress Meetup (y mantenerlos).



Y hasta aquí es una primera idea de cómo hacer paso a paso. Como digo, es un primer paso, es mi propia idea… Pero seguro que te sirve.

#WCBilbao 2018: Hola Dorothea

Cuando instalamos un WordPress nuevo siempre nos encontramos con varios elementos que vienen de serie: una entrada del estilo al ¡Hola Mundo!, un comentario, una página, una plantilla (twentynosequé) y un plugin. Ese plugin que siempre está es el Hello Dolly.

Todos estos elementos vienne de serie como ejemplo para aprender a usar WordPress. Y el plugin, es uno más. Este plugin tan sencillo que en el panel de administrador va publicando frases de la canción Hello Dolly, llevó en la WordCamp Santander 2017 a que unos cuantos de nosotros nos pusiéramos a investigar el TRAC y nos diesemos cuenta de algunos detalles interesantes sobre el plugin. Todo ello entre risas de ¿en realidad se habla de la oveja Dolly?

Y esto es lo que quiero transmitir con la presentación en la WordCamp Bilbao 2018, cómo un plugin de ejemplo ha evolucionado para adaptarse a lo largo de los 15 años de WordPress, y de cada uno de los cambios aplicados sacar algunas conclusiones.

Y tú ¿eres de churras o de merinas?

WPtest: test visuales para WordPress

Seguro que más de una vez te has planteado probar una plantilla pero a lo mejor no tienes contenidos para probar, o no sabes dónde o cómo hacerlo, y sobre todo: ¿cómo van a quedar las cosas que no están controladas?

Si este es tu caso, te explico que existe una herramienta muy sencilla para hacer estas pruebas visuales, y su nombre es WPtest, y su funcionamiento también es muy simple. Y para hacerlo aún más, te lo voy a explicar paso a paso.

Lo primero que vamos a hacer será descargarse el fichero de wptest y descomprimir el ZIP en vuestro dispositivo (mejor en un ordenador de escritorio PC/Mac). Esto lo tendremos ahí porque será nuestro sistema de pruebas.

Lo segundo que necesitamos es un WordPress de pruebas. Para no ensuciar una instalación, lo que haremos es crear uno en algún sitio gratuito, por ejemplo poopy.life. Al cabo de unos pocos segundos tendréis un panel de administración de WordPress a vuestra disposición durante unas cuantas horas.

Una vez lo tengáis controlado hay que acceder al WordPress, y en la sección de Tools (Herramientas) vais a la sección de Import (Importar) e instaláis la opción de WordPress. Esto instala un plugin que permite importar contenidos.

Una vez instalado os aparecerá un texto de Run Importer (Ejecutar Importación) donde seleccionareis el fichero [wptest.xml] de vuestro ordenador (del ZIP que antes habéis descargado).

Ahora hacéis un Upload file and import (Subir fichero e importar) y en la siguiente pantalla tendréis que marcar la opción Download and import file attachments (Descargar e importar los ficheros adjuntos). El resto no hace falta cambiarlo.

Ahora sí, hacéis un Submit (Enviar) y se crearán automñaticamente varios usuarios, varios post (entradas) y varias pages (páginas) además de los ficheros multimedia correspondientes.

Y finalmente eso genera una página tal que así (ejemplo con Twenty Sixteen)


Por favor, pulsa en la imagen para ver la página completa

Como puedes comprobar, hay contenidos con muchas categorías, con muchas etiquetas, con galerías, con títulos largos y raros, listas, entradas fijas, tweets, cabeceras, tablas, alineaciones varias, contenidos con contraseña, comentarios, distintos tipos de entrada… en fin, que si te dedicas a desarrollar plantillas, es un campo de pruebas perfecto para verificar que cualquier destrozo que un usuario / cliente quiera hacer, funciona.

WordPress 4.9.6, privacidad y GDPR

WordPress también se está adaptando a la GDPR y es por eso que será imprescindible actualizar todos los WordPress que tengas para que cubran un par de funcionalidades que el software debe disponer.

Para empezar, ahora mismo solo está disponible una beta de WordPress 4.9.6, pero que incluye ya casi por completo las funcionalidades de Privacidad que tendremos.

Hay dos grandes bloques diferenciados en el nuevo sistema. El primero de ellos hace referencia a la exportación y eliminación de datos personales. De esta forma los usuarios que estén en la plataforma podrán solicitar que se les haga una exportación de sus datos. Esto genera un ZIP con sus contenidos. Está en la zona de Herramientas y allí en Exportar Datos Personales.

Otra de las herramientas es la de eliminar los datos. El procedimiento es prácticamente el mismo… el usuario podrá acceder y solicitar la eliminación de los datos, entrando en Herramientas y allí en Eliminar Datos Personales.

El segundo conjunto de herramientas en realidad hace referencia a la página de privacidad, obligatoria a partir de ahora. Si ya la tienes creada de antes, solo has de decirle cuál de todas es y ya está.

Pero si no tienes ninguna, puedes seleccionar la opción de crear una nueva que te mandará a un generador que te ayudará a rellenar los datos mínimos necesarios.

Este sistema parece que va a ser la base con la que se trabajará también en otros sistemas como WooCommerce. En este caso concreto, han hecho algunos cambios en la sección “Cuentas” pasándose a llamar Cuentas y Privacidad en la que se permite configurar qué hacer en el caso que hace referencia a los puntos anteriores (integración propia de WordPress) además de contener los mensajes de check de registro y compra. Para acabar, han añadido los tiempos de retención de datos de algunos elementos (cuentas inactivas, compras pendientes…) elementos que en realidad no afectan a los datos fiscales que sí que han de retenerse.

Así que tanto si utilizas un WordPress sin plugins como si tienes una tienda con WooCommerce u otros, recuerda estar atento a las actualizaciones de privacidad que van a ir apareciendo, y si necesitas ayuda con todo este mantenimiento, no dudes en ponerte en contacto conmigo por si puedo ayudar.

Seguridad en WordPress y la RGPD (GDPR)

Estos días se está hablando mucho sobre la RGPD (Reglamento General de Protección de Datos) que se va a aplicar a todos los países de la Unión Europea, pero de aplicación a cualquier usuario que realice una acción sobre un sitio europeo. La cuestión es que si bien es cierto que muchos sitios con WordPress están mejorando sus plugins y creando páginas con información personalizada, hay un elemento del que se habla poco: la seguridad.

Todo el mundo está dedicado a mirar que en todos los formularios hay que añadir un “checkbox” más pidiendo permiso, que en los boletines también, que si una página de términos y condiciones, pero, además de todo eso que es más formal hay una serie de reglas básicas que son la base de toda esta regulación, como la privacidad y seguridad de serie en el proyecto.

Para comenzar, esta regulación no solo afecta a las empresas, sino también a las personas, por lo que el simple hecho de disponer de cualquier tipo de material en Internet has de cumplir. Un blog personal requiere el cumplimiento de la legislación.

Para comenzar ha de haber alguien responsable de “el fichero de datos”. Yo me atrevería a decir que tiene que haber dos personas responsables de los datos: uno de ellos ha de ser un responsable de la empresa o propietario de los contenidos y por otro lado ha de haber un responsable técnico de los mismos. Vamos, el que entra en el panel del WordPress y el que hace los mantenimientos, seguridad y tecnología. Es importante diferenciar ambos casos porque cada uno tiene responsabilidades distintas.

Artículo 20: Derecho a la portabilidad de los datos

Con respecto a la portabilidad de los datos, hay que recordar que el propio WordPress ya dispone de una herramienta para la parte básica que permite la exportación de datos de un usuario, y que aunque no es un formato estándar (cada software tendrá el suyo) sí que hay herramientas que permiten su legibilidad, por lo que en este punto, no hay que hacer grandes cambios.

Artículo 24: Responsabilidad del responsable del tratamiento

Cada empresa ha de tener una especie de código ético al que se han de sumar todos los responsables de los datos. No voy a decir que todos los informáticos / internautas lo tenemos, pero yo personalmente tengo un código ético personal por el que me rijo desde hace muchísimos años en los que, por ejemplo, si estoy trabajando y alguien me da un usuario, contraseña, tarjeta de crédito o similar, nunca queda apuntado, o s´olo durante el tiempo que es necesario, y una vez hecho su uso, lo destruyo o “lo olvido”. Esto quizá debería dejarse por escrito en el caso de las empresas. Además, este código ético ha de revisarse con frecuencia para añadir elementos o modificar los existentes según avance la tecnología.

Artículo 25: Protección de datos desde el diseño y por defecto

Este es quizá uno de los elementos más importantes desde el punto de vista de seguridad. Últimamente se ha puesto de moda esas instalaciones que “con un clic” te instalan un WordPress. Todos los WordPress que yo instalo lo hago directamente desde el servidor, con una lista de tareas que me he creado y que llevan, de serie, todos los elementos para que esa instalación tenga elementos de prevención y seguridad. Básicamente es lo que se explica en WPdanger Code. La instalación por defecto de WordPress es segura, pero no solo es WordPress lo que hay que tener presente y revisado, sino también el servidor. Si quieres saber más sobre esto, o te interesaría que le diera una ojeada a cómo tienes montada la seguridad de tu sitio, no dudes en contactarme.

Artículo 32: Seguridad del tratamiento

Este punto para mi tiene un elemento complejo que es el de la seudonimización de los datos, aunque no el del cifrado. En este caso hay que mirar de configurar los servidores exclusivamente para funcionar con conexiones cifradas, entre otros HTTPS (y no HTTP), SFTP (y no FTP) o SSH. Cualquier conexión que se haga entre usuario y servidor o entre propietario y servidor debería ser bajo un sistema seguro, nunca aceptando los mensajes de conexiones no seguras.

Por otro lado, el sistema de copias de seguridad. Son obligatorias y han de estar siempre accesibles. Así que si no tienes copias de seguridad de tu sitio a varios niveles (en el caso de WordPress es tan sencillo como instalar un plugin de backup). Hay que recordar que las copias de seguridad pueden estar en varios lugares, así que recomiendo siempre una copia local, pero otra en algún servicio externo (tipo Dropbox, OneDrive, GDrive o lo que sea) y si ya quieres, un servicio profesional de copias. Si necesitas ayuda con tus copias de seguridad, puedes contactarme y vemos cómo configurar el sistema.

Por último también es obligatorio el mantenimiento del software para hacer prevención. Creo que poco más a decir… si no tienes tus plugins, themes o core actualizado y no puedes demostrar que pro activamente lo haces (no, no sirven las actualizaciones automáticas de WordPress porque no cumplen con todo) seguramente estás cometiendo una infracción. Hay formas sencillas de mantener los sitios actualizados a un nivel muy barato y que te sirva como mínimo para demostrar que estás haciendo un poco de mantenimiento del sistema.

En este punto, añadiría también algo que no se suele comentar y que sirve para elementos posteriores, que es la instalación de un sistema de seguimiento y control de los cambios que se ejecutan en el propio WordPress. No solo hablo de tener o no activos los logs del servidor web (que no tienen porqué ser suficientes) sino un sistema de monitorización de qué hacen los usuarios cuando están en el panel de administración, o que haga un log de lo que hacen los usuarios cuando navegan por la web, no por saber quién hace qué (que también) sino por saber qué se hace y cómo.

Artículo 33: Notificación de una violación de la seguridad de los datos personales a la autoridad de control

Existe la obligación de informar de un hackeo a las pocas horas de conocerse. Puede que en ese momento aún no sepas cómo ha sido, pero has de investigarlo mínimamente, intentar saber cuál es su alcance, a quién afecta y comunicarlo. Gracias a lo que comentaba en el punto anterior, si tienes un registro de todos los cambios, y puedes demostrar que tienes todo al día, no tiene porqué ir a más. Entregas la documentación que ya tienen estos sistemas y a partir de ahí ya se verá.

Artículo 44: Principio general de las transferencias

Aunque existen ciertos tratados de transferencia de datos entre países, ten presente que si trabajas con un alojamiento web en la nube, físicamente las máquinas deben estar en territorio de la Unión Europea. Esto implica que si actualmente tienes tu sitio web alojado en algún sitio que no controlas o no sabes físicamente, deberías moverlo / migrarlo inmediatamente a un servidor que esté dentro de los países de la Unión Europea. Migrar un WordPress es una tarea en principio sencilla, pero recuerda que cuando lo hagas, el servidor nuevo ha de cumplir los requerimientos mínimos de seguridad. Si no quieres perder ningún tipo de dato y quieres que sea leve, recuerda que hay profesionales que podemos hacer migraciones con un tiempo mínimo de caída.

Como decía al principio, es probable que te estén diciendo que has de contactar con tus clientes para verificar sus datos y la cesión de los mismos, que has de poner páginas nuevas de información, que has de actualizar los términos y condiciones, unos checkbox más en los formularios… pero recuerda que el foco principal de la ley es la seguridad y privacidad, por lo que da igual que recojas bien los datos si luego están desprotegidos.

Eventos WordPress, una reflexión

Cuando volví de la WordCamp Santander me propuse que a lo largo de 2018 iba a ir a todas las WordCamp de España. Por ahora lo estoy cumpliendo. Además en estos últimos meses también se han comenzado las Meetup de Molins de Rei y de Santa Coloma de Gramenet (esta última en la que soy el cabecilla visible), además de seguir gestionando la Meetup de Barcelona con Joan Artés y la WordCamp Barcelona en la que también estoy de organizador. No quiero decir en ningún momento que sea un experto montando eventos, pero creo que en la parte de WordPress tengo una visión bastante clara de lo que hay y lo que me gustaría que hubiera.

En la WordCamp Madrid surgieron varias conversaciones de corrillo en las que se comentó sobre las charlas, sobre los que vamos de WordCamp en WordCamp, sobre las comunidades locales. Comencemos por lo más de abajo.

Las Meetup son básico para la comunidad WordPress, pero generan ya un par de grandes problemas. Por un lado las Meetup las suelen gestionar y dirigir gente que está metica ya en la comunidad y que su inquietud les lleva a crear o participar como organizadores de ellas. Las primeras se suelen hacer con gente potente de esa comunidad que quiere participar, pero al cabo de 2 o 3 sesiones, “los ponentes se acaban” porque al final nadie se atreve a dar una charla. Esto provoca dos cosas: o que se repitan los ponentes y acaben dando charlas siempre los mismos (y que los asistentes se acomoden) o que la comunidad acabe desapareciendo porque no hay gente que pueda hablar de distintos temas. También puede pasar que se organice el sistema exclusivamente “con charlas” y a veces no es tanto eso como simplemente quedar, que se traiga un tema (o no) destacado de actualidad, y a partir de ahí se genere conversación. Esto, en lugares o Meetup pequeñas de 10-20 personas es gestionable, pero en una de Barcelona, por ejemplo no lo es porque te vienen 50-100 personas por sesión y generar conversación es complejo.

Por otro lado, cada Meetup va a su bola, y no se comparten los materiales entre unas y otras. no hay un “repositorio de presentaciones” agrupadas por temas o similares (una especie de WordPress TV pero de powerpoints) en los que puedas entrar, buscar temas, niveles o ideas, y como debería ser, las charlas también son GPL, por lo que las presentaciones también deberían estar disponibles al público, y poder ser reutilizadas. gastamos mucha energía en dar charlas que ya se han hecho en otros lugares.

Y para acabar, el nivel de las charlas o reuniones. En el caso de Barcelona, en general una cuarta parte de los asistentes son fijos, otra cuarta parte son conocidos (vienen de tanto en tanto, normalmente según e tema) y la otra mitad suelen ser nuevos o despistados. En muchas ocasiones los que saben encuentran las charlas que son de bajo nivel, y viceversa. Está claro que nunca vas a acertar con una charla para todo el mundo pero ¿por qué no se separan las charlas por niveles? Básicamente porque parece que haya una directiva superior que dice que las charlas han de ser siempre para gente de nivel básico, gente que conoce poco WordPress… pero ¿entonces, qué pasa con los que ya saben de WordPress y tienen otras inquietudes que habitualmente solo pueden resolver otras personas de la comunidad?

Cuando las Meetup se hacen grandes, como está pasando en España, se plantea la opción de hacer una WordCamp. Estos eventos, de un par de días habitualmente, en el que uno es de sesiones / charlas (habitualmente en 2 tracks) y el otro es un Contributor Day, se plantean como el gran evento. Y aquí volvemos a la problemática anterior… se supone que las WordCamp están concebidos para ser charlas para todos los públicos, por lo que se parte de que han de ser charlas de nivel bajo o básico. Hay lugares del mundo que llevan 10 años haciendo WordCamp, en España hay algunos que también llevan muchos, y al final lo que te queda es que los que llevamos más tiempo en el mundillo (yo no me considero un experto en WordPress en lo general, pero sí conocedor en profundidad de la plataforma y de algunos elementos en concreto -por ejemplo a parte de seguridad-) vamos a ver qué se cuece, pillaremos alguna cosa nueva que no conozcamos de una temática que nos toque de rebote (por ejemplo, en mi caso, cosas de diseño o las plantillas, porque los plugins los tengo más a mano, y el core quizá aún más). ¿Se puede aprender en una WordCamp? Sí, pero de forma limitada. Si eres nuevo en WordPress aprenderás mucho, si llevas tiempo, te costará (es mi sensación, y seguro que es muy discutible con otras personas). Con esto no quiero decir que las charlas no sean interesantes o estén mal planteadas, pero sí que no queda claro el target del público asistente.

Cuando se piden los formularios para mandar una charla, además de las cosas genéricas, se suele pedir el tipo de público al que va dirigido (técnico, desarrollador, marketing, negocio…) pero no se pide el nivel de conocimiento de ese tema que se ha de tener (básico, intermedio, avanzado…), por lo que cuando llegas a la charla, tienes más o menos claro si es para ti o no en cuanto a la temática (muchas WordCamp separan los tracks en negocio / marketing y técnico / desarrollo), pro cuando llegas a la charla te llevas un chasco porque lo que se explica es de un nivel que ya conocías, o de un nivel que se te escapa. En mi caso, que suelo dar charlas técnicas, te das cuenta de que nunca llueve a gusto de todos, cuando no tendría porqué ser así.

Partiendo de la base de que se supone que las Meetup han de ser inclusivas y focalizadas a personas que tienen conocimientos bajos de WordPress, y que las WordCamp son la extensión de esto, y también han de ir principalmente focalizadas a asistentes de pocos conocimientos ¿dónde quedan los que podríamos llamar profesionales de WordPress?

Los que me conocen saben que soy bastante revolucionario o incendiario, y en algunas cenas y after-party he hablado con muchas personas (principalmente las que están más en el ajo) y siempre me queda la sensación de que sí, que los asistentes aprenden y conocen temas nuevos, pero que el resto estamos más por la socialización que por aprender… ya que “para eso” está en Slack, o directamente Google. Pues no, me niego a creer eso. ¿Por qué no podemos tener un evento en el que se puedan dar charlas de nivel alto donde realmente aprendas de un tema en profundidad?

En paralelo a esto encontramos el tema de si los eventos son locales o globales. En la mesa redonda de la #WCMadrid surgió el asunto de si tenemos muchas WordCamp en España. Es cierto que tenemos más de 40 Meetup (segundo país del mundo tras US, y primero en ratio de población) y que hasta hace un año o dos la cantidad de personas era muy reducida, y se concentraba todo en 3-4 ciudades grandes. Ahora las Meetup ya tienen buena aceptación, se suelen hacer cada mes, y el ejemplo está tan solo entrando en WPCalendario donde no dejan de aparecer eventos y más eventos. Acepto el asunto y es de agradecer. Ves que hay temas tendencia por épocas (últimamente la GDPR y Gutenberg), y por otro lado que se acaban sacando temas tangenciales a WordPress por no repetir o por no tener ponentes. Es normal si lo hacemos localizado. Las WordCamp también se suponen que son eventos locales. Está claro que vamos los 10 superusers a todas las que podemos, muchas veces por ver a colegas, por comer y por pasar el rato que por lo propio. Este año, como decía, me he propuesto ir a todas, pero cuando no soy ponente a veces me pregunto si en ese caso, iría. Me interesa estar al día de WordPress, tengo la posibilidad de ir a los eventos, pero ¿realmente voy a aprender algo? Es posible que yo no sea el público objetivo pero ¿qué pasa con gente como yo que somos público objetivo en algo?

Desde hace unos meses que llevo comentando con gente de la comunidad de Barcelona el montar un evento para profesionales WordPress, incluso tengo nombre y dominio… La cuestión es que, aunque por ahora todas las conversaciones son informales, ha quedado claro que “no puede ser una WordCamp”. En su día se hicieron WPDay (WordPress Days) o hace poco el Pasión Por WordPress, que no dejaba de ser una WordCamp sin serlo.

El planteamiento en sencillo, el WordPress for Professionals debería ser un evento de 1 o 2 días, en el que haya 6-8 charlas, una de cada tema (una de plugins, una de core, una de…) relacionado con cada uno de los equipos de trabajo que hay en WordPress.org y en el que se expliquen las últimas novedades o trucos y cosas en profundidad. Charlas de 40-45 minutos, con 10-15 de preguntas. Un track. Se podrían plantear dos eventos al año, uno más de desarrollo y otro más de marketing y negocio. Se podría plantear que haya un Contributor Day en el que te aseguras que los que van a estar no requieren de formación y pueden aportar sin tener que explicarle a otras personas nada. Un evento en el que para asistir tengas que “demostrar” que eres alguien del sector, aportando de alguna manera (ya sea como autónomo o como agencia, con plugins o temas en el repositorio, con algo relacionado con el mundo WordPress…). La cuestión, ¿este evento ha de ser “oficial / oficioso” o ha de ser privado (cuando digo privado es que lo monte la comunidad sin el apoyo de la Fundación)?

NOTA final: Antes de que me lancéis a los leones, quiero expresar mi enorme respeto a los voluntarios y organizadores de WordCamp que hacen un trabajo excelente y difícil (lo vivo en primera persona) y a los que gestionan las Meetup, que tienen la presión de “qué vamos a hacer en la próxima”… sin vosotros la comunidad y todo lo que se pretende no existiría y ni mucho menos pretendo que esta entrada sea algo concreto para nadie, sino una reflexión de que con el crecimiento de WordPress estamos gestionando bien la parte de formación, eventos y comunidad presencial.

#WCMadrid 2018: Codename Servehappy y Project Tide

WordPress y PHP siempre pueden ir en la misma frase, y es que PHP es el corazón del gestor de contenidos más importante de Internet. Es por eso que dos de los proyectos que se han gestado en estos últimos meses toman relevancia cuando se acerca la versión 5.0 de WordPress.

Ahora mismo hay 4 versiones / ramas de PHP activas… pero ¿las soporta WordPress?

  • 5.6.34: no soportada
  • 7.0.28: soportada, no recomendada
  • 7.1.15: soportada, no recomendada
  • 7.2.3: recomendada

Por esto se ha creado el proyecto Servehappy, con la idea de que tu instalación de WordPress detecte qué versión tienes y te ayude a actualizar. Incluso, en algunos casos le propio WordPress Danger es capaz de decirte si tus plugins y themes son compatibles.

Pero quizá lo más interesante es el proyecto Tide, un sistema que analiza la calidad de plugins y themes y que te dice, además de si es compatible con tu versión de PHP, si el desarrollo está bien hecho y cumple unos mínimos estándar.

Si quieres, solo has de descargarte la presentación, disponible bajo licencia EUPL 1.2.

La comunidad WordPress española en Meetup

Si quieres aprender sobre WordPress, además de lo que puedas encontrar por Internet, lo más recomendable es acercarte a alguna de las comunidades locales que hay alrededor de toda España (y si no la hay, ¿has pensado en crearla?). Esta es una recopilación de las distintas Meetup que hay.

Andalucía

Aragón

Asturias

Baleares

Canarias

Cantabria

Castilla La Mancha

Castilla y León

Cataluña

Extremadura

Galicia

Madrid

Murcia

Navarra

País Vasco

Valencia

Última actualización: 2018-02-05
¿Crees que falta alguna? No dudes en escribirme un correo [javier-arroba-casares.org] que la añadiré.

La comunidad WordPress española en Twitter

Me atrevería a decir que España tiene una de las comunidades WordPress más importantes del mundo, y así se refleja en muchas ocasiones por la cantidad de Meetups o de WordCamp que se realizan. Por eso me he parado a hacer una recopilación de cuentas de Twitter de las distintas comunidades que hay.

WordCamp

Andalucía

Canarias

Cataluña

Madrid

País Vasco

WordPress

Andalucía

Aragón

Asturias

Baleares

Canarias

Cantabria

Castilla y León

Cataluña

Extremadura

Galicia

Madrid

Murcia

Navarra

País Vasco

Valencia

WooCommerce

Madrid

Otros

Oficiales

Última actualización: 2018-02-05
¿Crees que falta alguna? No dudes en escribirme un correo [javier-arroba-casares.org] que la añadiré.

Continuando la evolución de WPdanger

Cuanto más tiempo le dedico a la seguridad de los WordPress, más me doy cuenta de la dejadez de muchos de sus usuarios. Y es que cuando comencé con WPdanger todo venía un poco del mal trago que tuve que pasar con un proyecto que me toca de cerca y que prácticamente se había dejado. Y eso que era un WooCommerce.

Según ha pasado el tiempo y he podido ver análisis de cientos de sitios, voy viendo que sí, que cada vez más usuarios mantienen al día sus sitios pero que, aún siendo la recomendación más dada -mantén al día tu WordPress, los plugins y plantillas- parece que no vemos que no es suficiente.

Esto que he ido viendo en algunas WordCamp como la de Santander o la de Zaragoza me ha hecho lanzar WPdanger Code, el sitio en el que publico algunos bloques de código y artículos con recomendaciones.

Pero, aún así, no es suficiente. Es cierto que estar al día es muy acertado pero ¿por qué dejar ver qué tiene tu sitio, qué plugins utilizas? Y ahí es donde me entran las dudas… no sé si es que los que usamos WordPress no tenemos claro que hay que proteger nuestro hosting (y algunas configuraciones propias de WordPress) o es que simplemente tenemos ya la idea en la cabeza de que “como WordPress es seguro, estar con todo actualizado es suficiente”.

La primera versión de WPdanger era bastante sencilla… simplemente hacía el análisis, te mostraba lo que tenías, y poco más. Poco después añadí ciertas funcionalidades extras como la integración básica del “Project Tide” de WordPress (para analizar la calidad del código de plugins y themes, y que creo que va a sacar las vergüenzas a muchos desarrolladores), el análisis de un antivirus, el sitio con documentación y códigos para aumentar la prevención… aún así, sigo viendo de forma recurrente algunos sitios que van haciendo análisis y no acabo de ver una evolución en cuanto a protección. Lo ideal es que WPdanger te dijera que “no sabe nada de tu sitio”.

Estos últimos días he dedicado bastante tiempo a montar un VPS sin nada, ponerle un WordPress con una decena de plantillas destacadas y una veintena de plugins habituales y hacer un primer análisis. En aquel momento (aunque estaba todo al día) me detectaba lo que no está escrito. Haciendo tunning del servidor, comenzando a ocultar algunos elementos desde el exterior (desde la configuración del nginx, y seguramente también se podría hacer desde los .htaccess) fui dejando de ver la lista de plugins, la lista de plantillas (exceptuando la que tenía puesta), y comencé solo a ver elementos “detectados de forma agresiva”. Eso es buena señal, si el sistema solo detecta elementos haciendo “ataques” contra el sitio y no de forma pasiva, quiere decir que alguien que use herramientas sencillas y necesite poco tiempo para detectar ataques, lo va a tener complejo porque tendrá que aplicar muchos más recursos.

Tras la presentación en la meetup de Barcelona y el taller de seguridad en Zaragoza he tomado la decisión de comenzar a ofrecer servicios de prevención para aquellos que usan WordPress, creo que a unos precios asumibles para alguien mediano o que ha sufrido algún tipo de ataque. Para bien o para mal, aunque tengo medio paquetizado todo, lo más probable es que tengan que ser servicios personalizados, ya que en general cada WordPress es un mundo… aún así, me he prometido intentar mantener el servicio lo más estándar posible.

Otra cosa que me he encontrado bastante últimamente es el asunto de los “plugins de seguridad”. Es curioso porque los plugins como Sucuri o Wordfence son de los plugins que tienen más incidencias y vulnerabilidades documentadas… lo que hace que un sitio en general seguro pueda convertirse en inseguro por poner en marcha estos plugins… ¿realmente es necesario tener un sistema como ese? Yo suelo ser partidario de eliminar puntos de fallida, y soy muy dado a tener un Firewall en modo WAF fuera del propio sistema, lo mismo que tener el correo en un sitio, las DNS en otro, el hosting en uno distinto…

Al final, y en resumen, la cuestión es… tienes un WordPress y ¿vas a dejar la seguridad de tu sitio en manos de la Comunidad o de tu Hosting, o vas a ser un poco proactivo en intentar promover sistemas de seguridad activa? Obviamente la comunidad aporta muchísimo, pero requiere que pongas de tu parte (no va a venir alguien que contribuye a actualizar tu sitio), y lo mismo tu hosting, que puede poner medidas de seguridad, pero va a tener que dejar el sistema lo más estándar posible y no va a poner medidas extremas que puedan hacer incompatible tu configuración de WordPress.

Al fin y al cabo, como en todo, si buscas seguridad, privacidad y todo lo demás, has de comenzar por ti mismo (o dejarte que te asesoren bien).

Seguridad WordPress

Cada vez más personas utilizan WordPress como gestor de contenidos, ya sea un blog, un sitio web corporativo, o directamente foros, o un e-commerce. Este hecho de que cada vez más personas decidan utilizar WordPress hace que se convierta en un punto de inicio de ataques contra usuarios y sistemas.

Si eres de los que utiliza WordPress, para empezar, tranquilo: WordPress es seguro (las personas no tanto).

Aquí te dejo la presentación de la meetup de WordPress Barcelona en la que hablo de seguridad, presento WPdanger, hablo del próximo Proyecto Tide de WordPress…

Descárgate la presentación en formato PDF (987 KB).

WP-CLI para mantenimiento y seguridad

Si utilizas WordPress y tienes la posibilidad de gestionar el acceso por Shell, sin duda has de tener disponible WP-CLI. Y si utilizas WP-CLI entonces ya sabes que existen una decena de comandos que te facilitan la vida.

En general tengo puesto en mi agenda hacer al menos una revisión semanal de todos los WordPress que tengo, y eso incluye cierto mantenimiento y, de paso, darle una ojeada a los distintos elementos para que, de un vistazo, no se haya colado nada que no tenga que estar…

Esta es una pequeña lista de comandos que uso en este orden para revisar, verificar y actualizar el sistema.

$ reviso la versión de la instalación de WP-CLI
wp cli version
$ compruebo si hay actualizaciones disponibles de WP-CLI
wp cli check-update
$ actualizo WP-CLI a su última versión
wp cli update

$ entro en la carpeta de la instalación que quiero analizar
cd /carpeta/de/instalacion/wordpress/

$ verifico que no haya nada "raro" instalado en el core
wp core verify-checksums
$ listo la configuración del wp-config
wp config get
$ listo la lista de usuarios
wp user list

$ reviso la versión del WordPress
wp core version
$ compruebo si hay una nueva versión del WordPress
wp core check-update
$ actualizo a la última versión del WordPress
wp core update --path="/carpeta/de/instalacion/wordpress/"
$ verifico que no haya nada "raro" instalado en el core
wp core verify-checksums

$ hago una lista de todos los plugins instalados
wp plugin list --path="/carpeta/de/instalacion/wordpress/"
$ listo todos los plugins que tienen actualizaciones
wp plugin update --dry-run --all --path="/carpeta/de/instalacion/wordpress/"
$ actualizo todos los plugins que tienen actualizaciones
wp plugin update --all --path="/carpeta/de/instalacion/wordpress/"

$ hago una lista de todas las plantillas instaladas
wp theme list --path="/carpeta/de/instalacion/wordpress/"
$ listo todas las plantillas que tienen actualizaciones
wp theme update --dry-run --all --path="/carpeta/de/instalacion/wordpress/"
$ actualizo todas las plantillas que tienen actualizaciones
wp theme update --all --path="/carpeta/de/instalacion/wordpress/"

$ hago una lista de todos los idiomas instalados
wp language core list --status=installed
$ listo todos los idiomas que tienen actualizaciones
wp language core update --dry-run --path="/carpeta/de/instalacion/wordpress/"
$ actualizo todos los idiomas que tienen actualizaciones
wp language core update --path="/carpeta/de/instalacion/wordpress/"

$ elimino todos los transients caducados
wp transient delete --expired
$ compruebo el prefijo del WordPress
wp db prefix
$ verifico el tamaño de la base de datos del WordPress
wp db size
$ optimizo la base de datos del WordPress
wp db optimize
$ verifico el tamaño de la base de datos del WordPress
wp db size

Obviamente este listado de comandos tiene algunos “inútiles” pero que son válidos para comprobar por enésima vez que todo es correcto y que nada se descuadra de lo que ha de ser. De la misma forma hay varios comandos que revisa y re compruebas elementos que no son necesarios comprobar. Pero aún así, con este listado, poco a poco, salen las cosas bien.

WordPress SEO: ¿Yoast o más sencillo?

En muchas ocasiones cuando instalamos un WordPress vamos con nuestra lista predefinida de plugins, y habitualmente incorporamos uno de SEO. Estos plugins de SEO en realidad hacen poco, ya que es cierto que WordPress no permite de serie gestionar cómo queremos los títulos, pero él es capaz de generar automáticamente el meta-description si se hace bien.

Es por esto que mucha gente utiliza Yoast como plugin de SEO, que además de llevar muchas herramientas que te dicen cómo escribir (algo que nunca he usado ni usaría), te corrigen (en cierta manera) el formato de título y snippet que se muestra en los resultados de búsqueda.

Hace poco me puse a buscar una solución que fuera extremadamente simple para el tema de eso: título, descripción y palabras clave. Estos tres viejos elementos son en el fondo lo único que necesitaba, el resto ya lo hace bien la plantilla. Y acabé encontrando un plugin que no está en el repositorio oficial pero que está gestionado como tal: WP SEO: A simple, straightforward SEO plugin for WordPress. Just the facts, Jack. Para aquellos que quieran, descarga la versión 0.13.0.

Este plugin lo que hace es añadir estos campos:

Y hace simplemente eso… aunque se pueden usar los distintos códigos de sustitución:

#archive_date#
#author#
#categories#
#date_modified#
#date_published#
#excerpt#
#post_type_plural_name#
#post_type_singular_name#
#search_term#
#site_description#
#site_name#
#tags#
#term_description#
#term_name#
#thumbnail_url#
#title#

Con estos códigos te puedes hacer la configuración personalizada para todos los tipos de página que tengas en tu sitio:

En la última opción, que te permite crear tus propios “metas”, podrías por ejemplo configurar uno para Google Search Console, de forma que el nombre sea google-site-verification y el content, el identificador que Google proporciona.

Lo siguiente es… si hasta ahora he estado utilizando Yoast ¿puedo migrar los datos de Yoast a este sistema? La respuesta es sí, se puede hacer, aunque no tengo ningún plugin ni nada parecido. Aún así, con 2 consultas SQL se hace muy rápido:

UPDATE wp_postmeta SET meta_key = '_meta_title' WHERE meta_key = '_yoast_wpseo_title';
UPDATE wp_postmeta SET meta_key = '_meta_description' WHERE meta_key = '_yoast_wpseo_metadesc';

Y si quieres hacer limpieza una vez desinstalado Yoast, puedes borrar “los restos”:

DELETE FROM wp_postmeta WHERE meta_key LIKE '_yoast%';

A partir de aquí tendrás una forma sencilla de añadir el título, descripción y keyworks que quieras sin necesidad de instalar un plugin pesado como son generalmente los de SEO.

Mejora la página de mantenimiento de WordPress

Cuando actualizamos el núcleo de WordPress, sus plantillas o los plugins, en ese fragmento de tiempo pequeño, suele aparecer un breve mensaje de texto en cualquier pantalla de navegación en la que nos encontramos. Esa pantalla suele ser una pantalla fría, blanca con el mensaje de texto Briefly unavailable for scheduled maintenance. Check back in a minute. Sin duda no es la pantalla más bonita que podemos mostrarle a nuestros usuarios, es útil, pero no tiene gracia.

El mantenimiento de WordPress se gestiona por la creación de un fichero en la carpeta raíz (donde está el index.php principal) llamado .maintenance. El hecho de que exista este fichero con un pequeño codigo hace que todo el sitio quede bloqueado hasta que acaben de actualizarse todos los complementos.

¿Te gustaría darle un formato un poco más elegante a la página? Se puede hacer, creando un fichero en PHP que haga lo mismo que hace el sistema por defecto, pero con cierto contenido. Para ello deberás incluir el fichero maintenance.php dentro de la carpeta /wp-content/.

Ese fichero ha de tener una cabecera que devuelva un código 503 (conforme la página no está accesible temporalmente) y el tiempo en el que se debe volver a revisar. Como habitualmente las actualizaciones de WordPress son rápidas, pondremos que el reintento se haga en 1 minuto.

<?php
wp_load_translations_early();
$protocol = wp_get_server_protocol();
header($protocol.' 503 Service Unavailable', true, 503);
header('Retry-After: 60');
header('Content-Type: text/html; charset=utf-8');
?>

Teniendo esto en cuenta, podemos crear diseños que tengan al menos alguna animación:

<?php
wp_load_translations_early();
$protocol = wp_get_server_protocol();
header($protocol.' 503 Service Unavailable', true, 503);
header('Retry-After: 60');
header('Content-Type: text/html; charset=utf-8');
?>
<!DOCTYPE html>
<html>
<head>
  <title><?php _e('Maintenance'); ?></title>
  <style>.container{width:200px;height:100px;padding-top:100px;margin:0 auto}.ball{width:10px;height:10px;margin:10px auto;border-radius:50px}.ball:nth-child(1){background:#ff005d;-webkit-animation:right 1s infinite ease-in-out;-moz-animation:right 1s infinite ease-in-out;animation:right 1s infinite ease-in-out}.ball:nth-child(2){background:#35ff99;-webkit-animation:left 1.1s infinite ease-in-out;-moz-animation:left 1.1s infinite ease-in-out;animation:left 1.1s infinite ease-in-out}.ball:nth-child(3){background:#008597;-webkit-animation:right 1.05s infinite ease-in-out;-moz-animation:right 1.05s infinite ease-in-out;animation:right 1.05s infinite ease-in-out}.ball:nth-child(4){background:#fc0;-webkit-animation:left 1.15s infinite ease-in-out;-moz-animation:left 1.15s infinite ease-in-out;animation:left 1.15s infinite ease-in-out}.ball:nth-child(5){background:#2d3443;-webkit-animation:right 1.1s infinite ease-in-out;-moz-animation:right 1.1s infinite ease-in-out;animation:right 1.1s infinite ease-in-out}.ball:nth-child(6){background:#ff7c35;-webkit-animation:left 1.05s infinite ease-in-out;-moz-animation:left 1.05s infinite ease-in-out;animation:left 1.05s infinite ease-in-out}.ball:nth-child(7){background:#4d407c;-webkit-animation:right 1s infinite ease-in-out;-moz-animation:right 1s infinite ease-in-out;animation:right 1s infinite ease-in-out}@-webkit-keyframes right{0%,100%{-webkit-transform:translate(-15px)}50%{-webkit-transform:translate(15px)}}@-webkit-keyframes left{0%,100%{-webkit-transform:translate(15px)}50%{-webkit-transform:translate(-15px)}}@-moz-keyframes right{0%,100%{-moz-transform:translate(-15px)}50%{-moz-transform:translate(15px)}}@-moz-keyframes left{0%,100%{-moz-transform:translate(15px)}50%{-moz-transform:translate(-15px)}}@keyframes right{0%,100%{transform:translate(-15px)}50%{transform:translate(15px)}}@keyframes left{0%,100%{transform:translate(15px)}50%{transform:translate(-15px)}}</style>
</head>
<body>
  <center><h1><?php _e('Maintenance'); ?></h1></center>
  <p align="center"><?php _e('Briefly unavailable for scheduled maintenance. Check back in a minute.'); ?></p>
  <div class="container"><div class="ball"></div><div class="ball"></div><div class="ball"></div><div class="ball"></div><div class="ball"></div><div class="ball"></div><div class="ball"></div></div>
  <script>var maintenance_check=function(){var n=new XMLHttpRequest;n.open("HEAD",window.location,!0),n.onload=function(){this.status>=200&&this.status<400?window.location.reload():setTimeout(maintenance_check,5000)},n.onerror=function(){setTimeout(maintenance_check,5000)},n.send()};maintenance_check();</script>
</body>
</html>

Aunque si ese, que es sencillo y con un poco de formato te ha gustado, este tampoco se queda atrás.

<?php
wp_load_translations_early();
$protocol = wp_get_server_protocol();
header($protocol.' 503 Service Unavailable', true, 503);
header('Retry-After: 60');
header('Content-Type: text/html; charset=utf-8');
?>
<!DOCTYPE html>
<html>
<head>
  <title><?php _e('Maintenance'); ?></title>
  <style>body{background-color:#012;background-image:url(https://cssanimation.rocks/demo/starwars/images/bg.jpg);background-size:33%;background-repeat:repeat;min-height:2025px;color:#fff}.system{position:relative;top:0;left:0;width:100%;height:100%;-webkit-transform:scale(.75);transform:scale(.75)}.sun{width:144px;height:144px;border-radius:72px;position:absolute;top:1066.67px;left:50%;margin:-72px;background-image:url(https://sdo.gsfc.nasa.gov/assets/img/latest/latest_256_HMIIF.jpg);background-size:144px;background-repeat:no-repeat}.mer,.mer-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-mer{from{-webkit-transform:rotate(0) translatey(-84px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-84px) rotate(-360deg)}}@-keyframes rot-mer{from{-webkit-transform:rotate(0) translatey(-84px) rotate(0);transform:rotate(0) translatey(-84px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-84px) rotate(-360deg);transform:rotate(360deg) translatey(-84px) rotate(-360deg)}}.mer{width:3.5px;height:3.5px;background-color:#888;margin:-1.75px;-webkit-animation:rot-mer .88s infinite linear;animation:rot-mer .88s infinite linear;z-index:200}.mer-path{width:168px;height:168px;z-index:100;margin:-84px;border:1px solid #444}.ven,.ven-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-ven{from{-webkit-transform:rotate(0) translatey(-90px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-90px) rotate(-360deg)}}@-keyframes rot-ven{from{-webkit-transform:rotate(0) translatey(-90px) rotate(0);transform:rotate(0) translatey(-90px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-90px) rotate(-360deg);transform:rotate(360deg) translatey(-90px) rotate(-360deg)}}.ven{width:5.5px;height:5.5px;background-color:#f5f9be;margin:-2.75px;-webkit-animation:rot-ven 2.25s infinite linear;animation:rot-ven 2.25s infinite linear;z-index:200}.ven-path{width:180px;height:180px;z-index:100;margin:-90px;border:1px solid #444}.ear,.ear-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-ear{from{-webkit-transform:rotate(0) translatey(-102px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-102px) rotate(-360deg)}}@-keyframes rot-ear{from{-webkit-transform:rotate(0) translatey(-102px) rotate(0);transform:rotate(0) translatey(-102px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-102px) rotate(-360deg);transform:rotate(360deg) translatey(-102px) rotate(-360deg)}}.ear{width:7px;height:7px;background-color:#4b94f9;margin:-3.5px;-webkit-animation:rot-ear 3.65s infinite linear;animation:rot-ear 3.65s infinite linear;z-index:200}.ear-path{width:204px;height:204px;z-index:100;margin:-102px;border:1px solid #444}.mar,.mar-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-mar{from{-webkit-transform:rotate(0) translatey(-118px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-118px) rotate(-360deg)}}@-keyframes rot-mar{from{-webkit-transform:rotate(0) translatey(-118px) rotate(0);transform:rotate(0) translatey(-118px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-118px) rotate(-360deg);transform:rotate(360deg) translatey(-118px) rotate(-360deg)}}.mar{width:6px;height:6px;background-color:#dd411a;margin:-3px;-webkit-animation:rot-mar 6.87s infinite linear;animation:rot-mar 6.87s infinite linear;z-index:200;background-image:-webkit-repeating-linear-gradient(top,#fff,#fff 1px,transparent 1px,transparent 5px);background-image:repeating-linear-gradient(to bottom,#fff,#fff 1px,transparent 1px,transparent 5px)}.mar-path{width:236px;height:236px;z-index:100;margin:-118px;border:1px solid #444}.jup,.jup-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-jup{from{-webkit-transform:rotate(0) translatey(-228px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-228px) rotate(-360deg)}}@-keyframes rot-jup{from{-webkit-transform:rotate(0) translatey(-228px) rotate(0);transform:rotate(0) translatey(-228px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-228px) rotate(-360deg);transform:rotate(360deg) translatey(-228px) rotate(-360deg)}}.jup{width:70px;height:70px;background-color:#eaad3b;margin:-35px;-webkit-animation:rot-jup 43.32s infinite linear;animation:rot-jup 43.32s infinite linear;z-index:200;background-image:-webkit-repeating-linear-gradient(84deg,#797663 22px,#e1dcde 16px,#c3a992 30px,#e9ece2 30px);background-image:repeating-linear-gradient(6deg,#797663 22px,#e1dcde 16px,#c3a992 30px,#e9ece2 30px)}.jup-path{width:456px;height:456px;z-index:100;margin:-228px;border:1px solid #444}.sat,.sat-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-sat{from{-webkit-transform:rotate(0) translatey(-362px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-362px) rotate(-360deg)}}@-keyframes rot-sat{from{-webkit-transform:rotate(0) translatey(-362px) rotate(0);transform:rotate(0) translatey(-362px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-362px) rotate(-360deg);transform:rotate(360deg) translatey(-362px) rotate(-360deg)}}.sat{width:58px;height:58px;background-color:#d6cd93;margin:-29px;-webkit-animation:rot-sat 107.59s infinite linear;animation:rot-sat 107.59s infinite linear;z-index:200}.sat-path{width:724px;height:724px;z-index:100;margin:-362px;border:1px solid #444}.ura,.ura-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-ura{from{-webkit-transform:rotate(0) translatey(-648px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-648px) rotate(-360deg)}}@-keyframes rot-ura{from{-webkit-transform:rotate(0) translatey(-648px) rotate(0);transform:rotate(0) translatey(-648px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-648px) rotate(-360deg);transform:rotate(360deg) translatey(-648px) rotate(-360deg)}}.ura{width:26px;height:26px;background-color:#bfeef2;margin:-13px;-webkit-animation:rot-ura 306.87s infinite linear;animation:rot-ura 306.87s infinite linear;z-index:200}.ura-path{width:1296px;height:1296px;z-index:100;margin:-648px;border:1px solid #444}.nep,.nep-path{border-radius:50%;position:absolute;top:1066.67px;left:50%}@-webkit-keyframes rot-nep{from{-webkit-transform:rotate(0) translatey(-972px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-972px) rotate(-360deg)}}@-keyframes rot-nep{from{-webkit-transform:rotate(0) translatey(-972px) rotate(0);transform:rotate(0) translatey(-972px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-972px) rotate(-360deg);transform:rotate(360deg) translatey(-972px) rotate(-360deg)}}.nep{width:24px;height:24px;background-color:#363ed7;margin:-12px;-webkit-animation:rot-nep 601.9s infinite linear;animation:rot-nep 601.9s infinite linear;z-index:200}.nep-path{width:1944px;height:1944px;z-index:100;margin:-972px;border:1px solid #444}.plu,.plu-path{border-radius:50%}@-webkit-keyframes rot-plu{from{-webkit-transform:rotate(0) translatey(-1246px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-1246px) rotate(-360deg)}}@-keyframes rot-plu{from{-webkit-transform:rotate(0) translatey(-1246px) rotate(0);transform:rotate(0) translatey(-1246px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-1246px) rotate(-360deg);transform:rotate(360deg) translatey(-1246px) rotate(-360deg)}}.plu{width:3px;height:3px;background-color:#963;position:absolute;left:50%;margin:-1.5px;-webkit-animation:rot-plu 904.65s infinite linear;animation:rot-plu 904.65s infinite linear;z-index:200}.dem,.jove,.lune,.pho{background-color:#fff;left:50%;position:absolute}.plu-path{width:2492px;height:2492px;z-index:100;position:absolute;left:50%;margin:-1246px;border:1px solid #444}@-webkit-keyframes rot-lune{from{-webkit-transform:rotate(0) translatey(-7px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-7px) rotate(-360deg)}}@-keyframes rot-lune{from{-webkit-transform:rotate(0) translatey(-7px) rotate(0);transform:rotate(0) translatey(-7px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-7px) rotate(-360deg);transform:rotate(360deg) translatey(-7px) rotate(-360deg)}}.lune{width:2px;height:2px;top:50%;margin:-1.5px;-webkit-animation:rot-lune .27s infinite linear;animation:rot-lune .27s infinite linear}.dem,.pho{margin:-1px}@-webkit-keyframes rot-pho{from{-webkit-transform:rotate(0) translatey(-7px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-7px) rotate(-360deg)}}@-keyframes rot-pho{from{-webkit-transform:rotate(0) translatey(-7px) rotate(0);transform:rotate(0) translatey(-7px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-7px) rotate(-360deg);transform:rotate(360deg) translatey(-7px) rotate(-360deg)}}@-webkit-keyframes rot-dem{from{-webkit-transform:rotate(0) translatey(-9px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-9px) rotate(-360deg)}}@-keyframes rot-dem{from{-webkit-transform:rotate(0) translatey(-9px) rotate(0);transform:rotate(0) translatey(-9px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-9px) rotate(-360deg);transform:rotate(360deg) translatey(-9px) rotate(-360deg)}}.dem,.pho{width:1px;height:1px;top:50%}.pho{-webkit-animation:rot-pho .15s infinite linear;animation:rot-pho .15s infinite linear}.dem{-webkit-animation:rot-dem .2s infinite linear;animation:rot-dem .2s infinite linear}.jove{width:2px;height:2px;top:35px}@-webkit-keyframes rot-io{from{-webkit-transform:rotate(0) translatey(-39px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-39px) rotate(-360deg)}}@-keyframes rot-io{from{-webkit-transform:rotate(0) translatey(-39px) rotate(0);transform:rotate(0) translatey(-39px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-39px) rotate(-360deg);transform:rotate(360deg) translatey(-39px) rotate(-360deg)}}@-webkit-keyframes rot-eur{from{-webkit-transform:rotate(0) translatey(-41px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-41px) rotate(-360deg)}}@-keyframes rot-eur{from{-webkit-transform:rotate(0) translatey(-41px) rotate(0);transform:rotate(0) translatey(-41px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-41px) rotate(-360deg);transform:rotate(360deg) translatey(-41px) rotate(-360deg)}}@-webkit-keyframes rot-gan{from{-webkit-transform:rotate(0) translatey(-45px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-45px) rotate(-360deg)}}@-keyframes rot-gan{from{-webkit-transform:rotate(0) translatey(-45px) rotate(0);transform:rotate(0) translatey(-45px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-45px) rotate(-360deg);transform:rotate(360deg) translatey(-45px) rotate(-360deg)}}@-webkit-keyframes rot-cal{from{-webkit-transform:rotate(0) translatey(-53px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-53px) rotate(-360deg)}}@-keyframes rot-cal{from{-webkit-transform:rotate(0) translatey(-53px) rotate(0);transform:rotate(0) translatey(-53px) rotate(0)}to{-webkit-transform:rotate(360deg) translatey(-53px) rotate(-360deg);transform:rotate(360deg) translatey(-53px) rotate(-360deg)}}.io{-webkit-animation:rot-io .2s infinite linear;animation:rot-io .2s infinite linear}.eur{-webkit-animation:rot-eur .35s infinite linear;animation:rot-eur .35s infinite linear}.gan{-webkit-animation:rot-gan .7s infinite linear;animation:rot-gan .7s infinite linear}.cal{-webkit-animation:rot-cal 1.65s infinite linear;animation:rot-cal 1.65s infinite linear}.spot{position:absolute;width:16px;height:12px;border-radius:8px/6px;top:45px;left:50%;background-color:#bc833b;box-shadow:0 0 5px #e1dcde;border:1px solid #e1dcde;box-sizing:border-box;-moz-box-sizing:border-box;-webkit-box-sizing:border-box;z-index:300}.nep .spot{background-color:#29319d;border:0;box-shadow:none;top:50%;left:45%;width:10px;height:6px;margin:-2px;border-radius:5px/3px;border-left:solid 1px #7ed6fe}div[class$="-ring"]{border-radius:50%;position:absolute;top:50%;left:50%;opacity:.7;-webkit-transform:rotatex(45deg);transform:rotatex(45deg)}.a-ring{border:5px solid #96866f;width:119px;height:119px;margin:-64.5px}.b-ring{border:10px solid #554c3c;width:104px;height:104px;margin:-62px}.c-ring{border:9px solid #574f4a;width:95px;height:95px;margin:-56.5px}.f-ring{border:2px solid #908e8d;width:133px;height:133px;margin:-68.5px}.e-ring{border:7px solid #908e8d;width:76px;height:76px;margin:-45px;-webkit-transform:rotatex(0) rotatey(89deg)!important;transform:rotatex(0) rotatey(89deg)!important}.plu,.plu-path{top:1354.07px}</style>
</head>
<body>
  <center><h1><?php _e('Maintenance'); ?></h1></center>
  <p align="center"><?php _e('Briefly unavailable for scheduled maintenance. Check back in a minute.'); ?></p>
  <div class="system"><div class="sun"></div><div class="mer-path"></div><div class="mer"></div><div class="ven-path"></div><div class="ven"></div><div class="ear-path"></div><div class="ear"><div class="lune"></div></div><div class="mar-path"></div><div class="mar"><div class="pho"></div><div class="dem"></div></div><div class="jup-path"></div><div class="jup"><div class="spot"></div><div class="jove io"></div><div class="jove eur"></div><div class="jove gan"></div><div class="jove cal"></div></div><div class="sat-path"></div><div class="sat"><div class="f-ring"></div><div class="a-ring"></div><div class="b-ring"></div><div class="c-ring"></div></div><div class="ura-path"></div><div class="ura"><div class="e-ring"></div></div><div class="nep-path"></div><div class="nep"><div class="spot"></div></div><div class="plu-path"></div><div class="plu"></div></div>
  <script>var maintenance_check=function(){var n=new XMLHttpRequest;n.open("HEAD",window.location,!0),n.onload=function(){this.status>=200&&this.status<400?window.location.reload():setTimeout(maintenance_check,5000)},n.onerror=function(){setTimeout(maintenance_check,5000)},n.send()};maintenance_check();</script>
</body>
</html>

Ahora ya tienes unas primeras plantillas para optimizar tu WordPress cuando esté en mantenimiento y tus usuarios no vean un feo texto.

WPdanger, análisis de seguridad para WordPress

Un clásico de los sitios web que usan un CMS de fondo es la falta de actualización de los mismos. Esto hace que si en un par de meses tu sitio está sin actualizar sea objetivo de cualquier ataque, ya que todos los problemas que puedan haber, estarán.

Si a esta preocupación personal le sumamos que en verano suelo hacer “cositas por entretenerme”, salen proyectos como WPdanger, un sitio web en el que pones la dirección de tu sitio en WordPress y te da algunas vulnerabilidades o te puede servir para encontrar problemas que puedas tener y que todos pueden verificar.

Al principio comencé usando WPscan para hacer algunas pruebas, pero aunque en particular funcionaba, a lo grande ya no era tan simple. Así que monté un primer sistema que mostraba los resultados por pantalla web, posteriormente comené a procesarlos y al final ha salido una web en la que analiza más de lo que hacía al principio (que era puramente reactivo) a algo un poco más decente y que da más datos, además de mostrar enlaces a todos aquellos problemas que pueden aparecer.

Pero esto era poco… si cualquiera tiene acceso a este tipo de herramientas ¿cómo evitar que los datos que aparecen sean útiles para prevenir ataques? Obviamente la primera fase era evitar enseñar lo que no se tiene que enseñar, es decir, que la herramienta crea que lo que realmente hay no esté. Así, si un hacker usa estas herramientas, y ve que aparentemente no hay mucho que hacer en el sitio, pase de él. Esto me ha llevado durante algunos días a hacer y hacer análisis hasta poder ir bloqueando aquellos elementos que bloqueasen ataques pero hiciesen que la web siguiera funcionando. Tras varias horas revisando y analizando y probando con mi sitio, llegué a varias conclusiones.

La primera de ellas es que WordPress funciona mejor con nginx que con Apache HTTPD. En principio debería dar igual, pero a la hora de configurar elementos ys eguridad, ya no tanto. Entre uno y otro, me quedo con nginx. Lo segundo es que hay que montar PHP 7, principalmente por temas de rendimiento. A partir de esta combinación, podemos comenzar a trabajar.

La segunda es que hay plugins (muy utilizados) que no piensan en la seguridad, no permiten desactivar determinados elementos y que ponen en riesgo todo t sitio. El principal que me he encontrado es el Yoast SEO. Me gusta, no me importa que tenga código que ponga que lo usas, pero por favor, no indiquemos la versión, o al menos que la versión sea un eleemnto que se pueda desactivar. Como digo, es el plugin más inseguro (desde ese punto de vista) que he encontrado.

La tercera es que el hecho de que WordPress sea tan estándar y tan sencillo, hace que se puedan detectar versiones de plugins y plantillas de forma extremadamente sencilla (y sobre todo, de forma automática). Obviamente hay que encontrar un mix entre funcionalidad y seguridad. Me ha costado, pero he acabado encontrándolo.

El cuarto es que las configuraciones de seguridad que hay por Internet sobre WordPress se quedan extremadamente cortos. Es obvio que hay que informar, siempre lo primero, en que tu WordPress esté actualizado, obvio ye s así, pero por ejemplo, en todos los manuales se habla del famoso “usuario admin” que desde hace muchísimas versiones ya no viene por defecto. Está bien decir que no se use, pero han pasado años de que sea el mayor problema de seguridad de los usuarios. Lo que más me molesta es que no se explique esto, que es un tema histórico y que una instalación nueva no debería preocuparse en exceso por este asunto.

El quinto es que me ha parecido extraño que los grandes proveedores de hosting especializados en WordPress no den soluciones de seguridad sencillas más avanzadas, sobre todo en la parte preventiva.

Obviamente, no hay sitios 100% seguros, ni pretendo que los haya, pero sí que la prevención de la que siempre se habla en seguridad, se aplique. No tiene sentido decir que tienes un Firewall si luego puedo saber la lista de plugins que tienes instalados, o qué plantillas usas, y mucho menos saber qué versiones son y si están al día o no, incluyendo al núcleo.

¿Qué he aprendido con todo esto? A mejorar la ocultaciónd e información de la manera más simple posible que he encontrado, y principalmente poner difícil a los demás saber qué uso o dejo de usar. Un ejemplo, ahora mismo, es que si lanzo un análisis contra mi sitio, hace unos días me decía qué versión de WordPress tenía (exactamente), toda la lista de plugins, con sus versiones y sabiendo sie staban actualizados o no, y lo mismo con las plantillas… Ahora me dice una versión casi exacta de la que tengo en realidad de WordPress, pero ya no me dice qué plugins o plantilla tengo.

Esto no significa que si te miras un poco el código no se pueda saber, pero el hecho de que “de forma automática nos e sepa” me hace sentir un poco mejor, porque mucha gente que quiera hacer maldades lo tendrá ligeramente más difícil o, como mínimo, tendrá que dedicarle tiempo humano (y no tiempo máquina) para hacer maldades (a alguien que, la verdad, dudo que le aporte o vaya a conseguir nada útil).

Para acabar, tengo escrito un ¿folleto? de 15 páginas sobre seguridad de WordPress en el que explico con pelos y señales cómo solventar prácticamente todos estos problemas. La cuestión es si debería publicarlo por completo o parcialmente y plantear como vía de negocio / modelo de vida (y más ahora que no estoy trabajando en ningún proyecto y he vuelto al autonomismo) y de esa forma, ofreciendo uns ervicio barato, ofrecer la posibilidad de montar WordPress de forma segura a quien no sepa qué hacer con su sitio web. Aún así, como siempre, si alguien necesita ayuda con algo, parcialmente como parte de la comunidad, parcialmente como modelo de vida, estoy aquí para ayudar.

Consejos básicos de seguridad para WordPress

WordPress es seguro. Esa es una máxima que normalmente los seres humanos rompemos y convertimos el software en algo menos seguro de lo que debería.

En la presentación que hice ayer tuve la oportunidad de presentar algunas cosas que todo el mundo explica sobre seguridad, otras que se dicen pero no se hacen y otras tantas que son más desconocidas o que deberían hacerse y no se hacen.

Además, como tema máximo, comenté sobre el uso del 2FA (segunda autenticación) que ayuda a bloquear intrusos aunque te roben tus claves.

Aquí os dejo la descarga del PDF de mi parte de la presentación (Consejos de Seguridad para WordPress), en la que hay bastantes códigos para el wp-config.php, además de algunos plugins que te pueden ayudar a proteger un poco más el sistema.

Instalar WordPress desde cero en Ubuntu 16 (para torpes como yo)

Uso WordPress desde 2005 y en todos estos años he pasado por todo tipo de alojamiento web: hosting compartidos, dedicados, VPS, gestionados, sin gestionar… Normalmente depende de la cantidad de sitios que he de gestionar para tomar una decisión u otra.

Ahora que estoy volviendo a hacer mis cosas a mi manera, me ha dado por volver a montarme yo mismo los WordPress, de una forma que sea escalable, o al menos que en un futuro me permita crecer. Y para eso he decidido pasar de un hosting compartidos a un VPS. Esto me ha llevado a algunos problemas a la hora de realizar las migraciones, pero al fin y al cabo, hay que empezar por algún sitio.

Este manual está creado y funcionando en un VPS de 5$/mes de DigitalOcean (los de 512MB de RAM). Obviamente está organizado para poder escalar si es necesario, aunque con una máquina de estas, para un blog “normalito” hay más que suficiente, y 60 dólares al año es un precio razonable para tener tu sitio con un control del 100%.

NOTA 1: En esta documentación las IP que usaré son rangos de IP privada (por supuesto hay que sustituirlas por la IP pública que os de vuestro alojamiento) y como dominio usaré siempre example.com (que por supuesto tenéis que cambiar por vuestro dominio).

NOTA 2: Seguro que hay mil formas de hacer esto que os voy a explicar yo. Esta es una de ellas, que a mi me funciona, mejorable, seguro (y si alguien quiere, que comente y lo mejoramos)

Lo primero que recomiendo hacer es tener la máquina creada, y pedir la IPv6. Puestos ya, configurémoslo todo al 100%. Esto implica que una vez tengamos la IPv4 y la IPv6 lo que hay que hacer es configurar las DNS con las entradas siguientes:

@    A      172.16.0.0
www  A      172.16.0.0
@    AAAA   fd12:3456:789a:1::1
www  AAAA   fd12:3456:789a:1::1

Si habéis elegido DigitalOcean como proveedor, lo primero es instalar su sistema interno de estadísticas (esto se puede obviar en cualquier otro hosting):

$ curl -sSL https://agent.digitalocean.com/install.sh | sh

Lo siguiente es poner en hora la máquina:

$ timedatectl set-timezone UTC
$ timedatectl set-ntp on

Y actualizar el sistema:

$ apt-get -y update
$ apt-get -y upgrade
$ apt-get -y dist-upgrade
$ apt-get -y autoremove

Comencemos instalando algo de software base:

$ apt-get -y install software-properties-common curl vim unzip

Lo primero que vamos a montar es la base de datos. Para ello usaremos MariaDB 10.2

$ apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://ams2.mirrors.digitalocean.com/mariadb/repo/10.2/ubuntu xenial main'
$ apt-get -y install mariadb-server
$ mysql_secure_installation

Lo primero que se hace es descargar e instalar, y posteriormente configurar. Es muy recomendable poner contraseña a la base de datos y eliminar todo aquello que no se vaya a utilizar.

Lo siguiente es la instalación del servidor web. Aunque he utilizado durante muchos años Apache HTTPD, en este caso propongo el uso de nginx.

$ apt-get -y install nginx

Y finalmente vamos a instalar PHP, en este caso la versión 7.

$ apt-get -y install php php-fpm
$ apt-get -y install php-common php-curl php-gd php-iconv php-json php-mbstring php-mcrypt php-mysqli php-xml php-xmlrpc

La instalación la hago en 2 pasos; primero la instalación base, del PHP-FPM y posteriormente algunas bibliotecas añadidas para que WordPress funcione sin problema.

Ahora que tenemos todo instalado, activamos los servicios

$ systemctl enable nginx.service
$ systemctl enable mysql.service
$ systemctl enable php7.0-fpm.service

En este punto podríamos tener un sitio web funcionando, pero hoy en día lo interesante es tener un sitio web segcurizado con certificados SSL/TLS, así que vamos a usar Let’s Encrypt para ello, y que actualice y haga todo sólo. Comenzamos generando una clave segura:

$ openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

E instalamos el software de gestión de los certificados

$ add-apt-repository ppa:certbot/certbot
$ apt-get -y update
$ apt-get -y install python-certbot-nginx

Aunque aún no tenemos ningún certificado, os recomiendo dejar ya el cron puesto para que se autorenueven 8se ejecuta una vez al día a las 0645 UTC; podéis cambiarlo, por supuesto):

$ crontab -e

Contenido a añadir:

45 6 * * * certbot renew --dry-run

Lo siguiente es activar los Firewall (por ahora abrimos el nginx 80/443 y el SSH 22):

$ ufw app list
$ ufw allow 'Nginx Full'
$ ufw allow 'OpenSSH'
$ ufw enable

Vamos a montar un servidor de correo que permita el envío de correo sólo interno, para los correos que se manden desde el propio WordPress. Este sistema estará cerrado a correos externos o cualquier otra cosa.

$ apt -y install mailutils
$ ufw allow 'Postfix'
$ ufw reload

Ahora que está instalado, vamos a configurarlo

$ vim /etc/postfix/main.cf

Contenido a modificar:

inet_interfaces = loopback-only
mydestination = $myhostname, localhost.$mydomain, $mydomain

Iniciaremos el servicio de correo

$ systemctl enable postfix

Ahora configuraremos el sistema para que tenga nuestra cuenta de correo como base:

$ vim /etc/aliases

Contenido a modificar/añadir:

postmaster:    root
root:          mi.correo@example.com

Y para aplicar la configuración, ejecutaremos:

$ newaliases

Para acabar la parte de configuración del servidor, lo que queda por hacer es limpiar la web por defecto:

$ rm /var/www/html/index.*

Y sustituirla por otra cosa que “no moleste mucho”:

$ vim /var/www/html/index.html

Contenido a crear:

<!DOCTYPE html>
<p>Hello World!</p>

En este momento, si visitas la web desde la IP, deberías ver un mensaje por pantalla que diga: Hello World!. A partir de aquí podríamos utilizar este sistema para todas las webs distintas que queramos.

Para comenzar lo que haremos es crear la base de datos:

$ mysql -u root -p

Accederemos con la contraseña que configuramos en su momento, y crearemos la base de datos:

CREATE DATABASE example CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

Porteriormente crearemos un usuario que tenga permisos para controlar la base de datos:

GRANT ALL ON example.* TO 'exampleuser'@'localhost' IDENTIFIED BY 'examplepassword';

Y antes de salir, lo que haremos es refrescar los permisos:

FLUSH PRIVILEGES;

Recuerda que para salir del servidor de base de datos puedes escribir “quit”.

El siguiente bloque es el de subir el propio WordPress, el software; el objetivo es crear el lugar donde subiremos el software y dejarlo de forma ordenada.

$ mkdir /var/www/example.com/
$ cd /var/www/example.com/
$ wget https://wordpress.org/latest.tar.gz
$ tar xzvf latest.tar.gz
$ rm latest.tar.gz
$ mv ./wordpress/* ./
$ rm -rf ./wordpress/

Y posteriormente configuraremos los permisos de los ficheros y de su sistema:

$ chown -R www-data:www-data ./
$ find /var/www/example.com/ -type d -exec chmod 755 {} \;
$ find /var/www/example.com/ -type f -exec chmod 644 {} \;

El primero de estos comandos lo que hace es dar permisos a los ficheros como el nginx genera; el segundo da permisos a las carpetas y el tercero a los ficheros. En principio con estos permisos se debería poder trabajar sin problema.

Comenzaremos a configurar el WordPress con su fichero de configuración. Aunque el software de instalación permite generarlo, he preferido crear una plantilla base con ciertas configuraciones:

$ cp wp-config-sample.php wp-config.php
$ vim wp-config.php

Contenido:

<?php
define('DB_NAME', 'example');
define('DB_USER', 'exampleuser');
define('DB_PASSWORD', 'examplepassword');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
// Crear esto con https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY', 'xxxxx');
define('SECURE_AUTH_KEY', 'xxxxx');
define('LOGGED_IN_KEY', 'xxxxx');
define('NONCE_KEY', 'xxxxx');
define('AUTH_SALT', 'xxxxx');
define('SECURE_AUTH_SALT', 'xxxxx');
define('LOGGED_IN_SALT', 'xxxxx');
define('NONCE_SALT', 'xxxxx');
//
$table_prefix = 'example_';
define('WPLANG', 'es_ES');
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);
define('WP_CACHE', true);
define('WP_SITEURL', 'https://www.example.com');
define('WP_HOME', 'https://www.example.com');
define('COOKIE_DOMAIN', 'www.example.com');
define('AUTOSAVE_INTERVAL', 30);
define('EMPTY_TRASH_DAYS', 7);
define('WP_POST_REVISIONS', false);
define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
define('WP_AUTO_UPDATE_CORE', true);
define('IMAGE_EDIT_OVERWRITE', true);
//
if(!defined('ABSPATH')) define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');
?>

He puesto como configuración de “CHARSET / COLLATE” la de “utf8mb4” que permitiría una gestión avanzada de idiomas “raros” (no occidentales, como el chino, japonés, cirílico, árabe…) sin problema. Obviamente aquí cada uno que configure los detalles como le parezca mejor. Esto es una plantilla que yo uso.

Ahora que tenemos el fichero, vamos a quitar permisos para que no pueda ser modificado o leído por terceros:

$ chown www-data:www-data wp-config.php
$ chmod 600 wp-config.php

El siguiente bloque es el que va a permitirnos tener sitios webs distintos. La primera vez hemos de reconfigurar el sitio web por defecto, que se supone que sólo será para cuando se acceda a las IP (o cuando haya algo configurado apuntando a esas IP pero no sea algo que tengamos en marcha).

$ cd /etc/nginx/sites-enabled/
$ rm default
$ cd /etc/nginx/sites-available/
$ rm default
$ vim default.conf

Contenido:

server {
  listen 80 default_server;
  #listen 443 ssl http2 default_server;
  server_name _;
  root /var/www/html;
  index index.html index.php;
  location = /favicon.ico {
    log_not_found off;
    access_log off;
  }
  location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
  }
  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
  }
  location ~ /.well-known {
    allow all;
  }
  location ~ /\.ht {
    deny all;
  }
}

Activaremos el sitio web, para que funcione y posteriormente comprobaremos que el nginx dice que está todo correcto:

$ ln -s /etc/nginx/sites-available/default.conf /etc/nginx/sites-enabled/
$ nginx -t

Lo que nos debería mostrar por pantalla un mensaje tal que:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si todo va correctamente, ahora sí que crearemos un sitio web para el WordPress; lo crearemos en dos fases. La primera simplemente haremos que responda el sitio y que se puedan generar los certificados de seguridad. Posteriormente los activaremos.

$ vim example.com.conf

Contenido:

server {
  listen 80;
    listen [::]:80;
  server_name untor.com www.untor.com;
    root /var/www/untor.com;
  location ~ /.well-known {
    allow all;
  }
}

Activaremos el sitio y comprobaremos que la configuración es correcta y reiniciaremos el servicio:

$ ln -s /etc/nginx/sites-available/untor.com.conf /etc/nginx/sites-enabled/
$ nginx -t
$ systemctl restart nginx.service

Ahora crearemos el certificado y los ficheros necesarios para que vaya el HTTPS:

$ certbot --nginx certonly

Elegiremos las opciones y los certificados que se requieran, y una vez que estén creados, los añadiremos al fichero de configuración. Sustituiremos el que acabamos de crear por uno mucho más detallado:

$ vim example.com.conf

Contenido:

server {
  listen 80;
  listen [::]:80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request_uri;
}
server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  #ssl on;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
  ssl_ecdh_curve secp384r1;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;
  ssl_session_timeout 1d;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
  resolver 208.67.222.222 valid=300s;
  resolver_timeout 5s;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;
  add_header Strict-Transport-Security max-age=15768000;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}
server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  #ssl on;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
  ssl_ecdh_curve secp384r1;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;
  ssl_session_timeout 1d;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
  resolver 208.67.222.222 valid=300s;
  resolver_timeout 5s;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;
  add_header Strict-Transport-Security max-age=15768000;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  server_name www.example.com;
  root /var/www/example.com;
  index index.php;
  location / {
    try_files $uri $uri/ /index.php?$args;
  }
  location = /favicon.ico {
    log_not_found off;
    access_log off;
  }
  location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
  }
  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
  }
  location ~* \.(bmp|bz2|cur|doc|docx|exe|gif|eot|gz|htc|ico|jpeg|jpg|mid|midi|mp3|mp4|ogg|ogv|otf|png|ppt|pptx|rar|rtf|svg|svgz|tar|tgz|ttf|wav|webm|woff|woff2|xls|xlsx|zip)$ {
    expires max;
    add_header Cache-Control "public";
    log_not_found off;
  }
  location ~* \.(atom|css|js|rss)$ {
    expires 1d;
    add_header Cache-Control "public";
  }
  location ~ /.well-known {
    allow all;
  }
  location ~ /\.ht {
    deny all;
  }
  location ~* wp-config.php {
    deny all;
  }
}

Si todo va bien, ahora deberíamos probar este fichero, y si nos da correcto, reiniciar el servidor web:

$ nginx -t
$ systemctl restart nginx.service

Ahora es el momento de irte a tu navegador web, y visitar https://www.example.com/ (el dominio que hayas configurado), y debería aparecerte el instalador de WordPress que te pedirá el nombre de tu sitio, tu usuario y contraseña, etcétera.

En principio el sistema ya está funcionando correctamente, y permitiría, usando estos últimos bloques, disponer de varios sitios web funcionando en paralelo. pero antes de acabar quiero hacer unos pequeños cambios a la configuración del PHP.

$ cd /etc/php/7.0/fpm/
$ vim php.ini

Sustituir:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

Por:

error_reporting = E_ALL

Este cambio no debe afectar en principio a nada, ya que el muestreo de errores seguirá apagado, pero si en un momento determinado se ha de activar, lo mejor es que muestre absolutamente todos los errores habidos y por haber.

Sustituir:

upload_max_filesize = 2M

Por:

upload_max_filesize = 32M

Este cambio es bastante útil para el WordPress, ya que permitirá que se puedan subir ficheros (imágenes, adjuntos, etc…) -los llamados Media- de ese tamaño que pongamos. Por norma general si sólo usas imágenes 2 Megas puede ser una cifra correcta, pero si realmente trabajas con imágenes de calidad, ficheros PDF o similares, seguro que se queda corto, por lo que puedes subirlo a 32 Megas, 128 Megas, e incluso si tienes vídeos y los quieres subir así, a 1 Giga (o más). Tampoco recomiendo pasarse.

Sustituir:

;date.timezone =

Por:

date.timezone = UTC

Y ya mi TOC me lleva a configurar algo que genera a veces problemas en muchos sistemas, que es la hora. Al principio pusimos la máquina en hora UTC, y ahora configuramos el PHP para que siga también esa regla. Finalmente lo único que queda es aplicar los cambios, reiniciando el propio PHP.

$ systemctl restart php7.0-fpm.service

Y hasta aquí el sistema que configura una máquina Ubuntu 16 para uno o más WordPress, con sus certificados HTTPS, con un sistema integrado de caché (activando además la propia de WordPress), con una base de datos de última generación, con un PHP a su última versión… Comod ecía, seguro que hay más trucos, configuraciones y demás, pero esto ha de servir de base para una instalación de uno o varios WordPress, y que funciona.