Ayer 22 de Mayo de 2017 se celebró la WordCamp de Madrid en el Google Campus, dos días frenéticos, el primero de charlas y el segundo de talleres al que por desgracia no pude asistir, pero estoy seguro que fue muy interesante para aquellos que hayan podido ir.

2 charlas en paralelo, dos escenarios y una duda permanente de saber si se ha acertado o no con la charla.

Voy a contaros a las charlas que más me gustaron, obviamente sólo pude estar en la mitad, pero en poco tiempo espero que estén en WordPress.tv.

GraphQL – Félix Zapata

Esta charla bajo mi punto de vista fue la más técnica y me gustó mucho la temática, pero no tanto para WordPress sino como tecnología en si, sinceramente creo que haría falta un taller entero para tratar este tema y no una charla en plan genérico.

¿Por qué ofrecer una web abierta?, 5 razones para mejorar nuestro futuro – Juan Hernando

Ciudadanob, ese es el nick de Juan Hernando dio una charla que estoy convencido fue una de las que más impacto causaron, supo gestionar perfectamente el humor con la seriedad para dar un menaje claro y cristalino sobre la neutralidad de la red, la propiedad de la información, etc…, la verdad es que fue la charla que más me gustó, así que no pude evitarlo y tuve que decírselo luego en un pasillo, cuando salga el vídeo os recomiendo verlo.

¿Tu web va a pedales? 10 mandamientos de WPO – Pablo López

Esta charla fue la típica charla de WPO sin sorpresas, estuvo bien tratada, pero no profundizó demasiado en nada que no fuera lo de siempre, el tema quizás tampoco da mucho más, pero me quedé un poco frío, seguramente porque Pablo López es una persona de la que siempre hay que aprender y siempre sorprende y es él mismo el que tiene un listón muy alto, pero ya digo, fue correcta y completa, aunque los puntos son los de siempre.

Migrando WordPress a HTTPS – Alejandro Gil Mialdea (Speed Talk)

Esta fue una charla express en la que Alejandro estaba tan nervioso que consiguió comprimirlo todo en 5 ó 6 minutos, una charla impecable, rápida y directa, nada que objetar y creo que una de las más útiles de la WordCamp, una pena que se le hubiera dedicado tan poco tiempo por parte de la organización porque este tema para mi es el estrella de este año y me cuesta entender cómo se le dedicó tan poco tiempo.

Me hubiera gustado que se profundizara más, pero al pobre Alejandro no se lo dio la orgnización, espero que para futuras se le den más tiempo a este tipo de charlas.

En ocasiones…hago migraciones – Jose Ramón Padrón

José Ramón es un profesional que con los años cada vez le veo moverse mejor en eventos, pero me esperaba una charla sobre migraciones tal y como decía el título, pero fue una charla sobre la empresa en la que trabaja que es uno de los patrocinadores, no obstante Moncho mantiene al público siempre encantado.

PLUGIN Really Simple SSL: https://es.wordpress.org/plugins/really-simple-ssl/

NEODIGIT: https://neodigit.net

Ya están disponibles en Neodigit los certificados Let’s Encrypt y en el capítulo de hoy os quiero comentar el procedimiento para pasar vuestro WordPress a SSL sin problemas y de forma fácil y sencilla.

Hola a todos, mi nombre es Eduardo y esto es RadioWordpress, un podcast disponible en eduardocollado.com dedicado a todos aquellos que de una manera u otra convivimos todos los días con WordPress.

Os comentaba al inicio del programa que en Neodigit ya están disponibles los certificados Let’s Encrypt y aunque ya estuvieran disponibles los de otras entidades como Comodo el tema coste parece que es fundamental y sólo el primer día por la tarde sin haber hecho ningún anuncio ni nada se dieron de alta ya 190 certificados, todo un éxito teniendo en cuenta que no sólo se avisó a unos pocos clientes para test.

Sea como fuere el éxito ha sido bestial y quería comentar en este podcast el procedimiento que realmente os sirve para cualquier certificado en cualquier hoster, no solo en Neodigit, aunque no os tratarán tan bien como en Neodigit.

Vamos a entrar en materia, lo primero crear el certificado Let’s Encrypt y si lo tenéis habilitado en vuestro servidor lo único que hay que hacer es ir al hospedaje en concreto donde lo queráis activar y pincháis en Certificados SSL.

Seleccionáis el subdominio o alias de apache donde queráis instalarlo y le dais a autorizar seleccionados y esperáis como mucho veinte minutos, que es el tiempo máximo que puede tardar en el peor de los casos en realizarse todo el proceso ya que el certificado se valida cada 15 minutos y 5 minutos después de validarse se instala.

Hace ya algún tiempo os conté en un capítulo qué había que hacer para tener un Wordpres con SSL, pues bien, ahora el proceso es muchísimo más fácil gracias a un plugin.

El plugin del que estamos hablando se llama Really Simple SSL, una maravilla, se instala, y luego se le indica que queremos instalar el SSL y ya está, no hay que hacer nada más, obviamente antes tendremos que tener funcionando el SSL en nuestro servidor

La versión de php afecta drásticamente al rendimiento de vuestro WordPress, quizás no seáis conscientes de cómo afecta la versión de php de vuestro servidor, pero creedme si os digo que es un factor crítico a tener en cuenta.

Me pasa mi compañero en Tecnocrática Adrian un enlace al blog de Mattias Geniar https://ma.ttias.be/wordpress-php-7-1/ en el que hacía unas pruebas para ver cual era impacto de la versión de php sobre nuestro WordPress y el resultado era aplastante, php 7.1 afectaba al rendimiento muchísimo.

En su entrada del blog Mattias Geniar hace unas pruebas de rendimiento, así que decidí reproducirlas en mi servidor de Neodigit, un servidor cloud con panel, exactamente igual que cualquier otro que haya.

En mi caso mi servidor cloud tiene 2 cores y 4 gigas de RAM, pero es un servidor con TCPanel normal, como el que cualquiera puede contratar, no os penséis que es diferente a lo que hay por defecto.

Aunque el servidor soporte las versiones 5.2, 5.3, 5.4, 5.5, 5.6, 7.0 y 7.1 para emular las pruebas de Mattias sólo voy a hacer las pruebas con las versiones de php mantenidas, es decir, la 5.6 que se encuentra en soporte extendido, es decir, solo actualizaciones de seguridad, la 7.0 y la 7.1 que están en mantenimiento actualmente.

Por supuesto para poder hacer las pruebas de php es necesario no hacer trampas, así que voy a desactivar las opciones de caché de los plugins de WordPress.

Antes de hacer las pruebas de todos modos he comprobado los problemas que puede dar el actualizar a php 7.1, como el Neodigit el cambio de versión de php se puede hacer al vuelo lo que he hecho ha sido simplemente poner versión 7.1 y no he notado ningún error ni visto nada en los logs de errores de apache, así que a priori parece que nada ha dejado de funcionar y que todo funciona correctamente.

Tener en cuenta que ya probé anteriormente actualizar a la 7.1 y tuve algún problema con jetpack, pero parece que ya quedó solucionado.

Bueno, ¿vamos a empezar con las pruebas?

Antes de nada y lo primero será desactivar cualquier plugin de caché, así que desactivando estos plugins. En mi caso estoy haciendo las pruebas con un subdominio de pruebas que no tiene nada instalado, ningún plugin, nada,es decir WordPress puro para que podamos ver mejor las diferencias.

Ahora vamos a cambiar en el panel de Neodigit la versión de php a php 5.6.

Ahora vamos a ejecutar el benchmark que nos sugiere Mattias con dos conexiones concurrentes y 300 peticiones, a ver qué datos nos da, ejecutaremos el comando ab -c 2 -n 3000 y la URL.

ab -c 2 -n 300 https://URL

Ya le hemos dado y esto va a tardar un ratito, así que vamos a hacer la mágia del podcast y vamos a parar el audio y seguimos ahora, en cuanto termine.

El resultado de las pruebas completas os las dejo en la transcripción del programa.

[email protected] ~ # ab -c 2 -n 300 http://subdominio/blog/2017/02/19/hola-mundo/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking subdominio (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: Apache Server Hostname: subdominio Server Port: 80 Document Path: /blog/2017/02/19/hola-mundo/ Document Length: 57598 bytes Concurrency Level: 2 Time taken for tests: 76.609 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 17379000 bytes HTML transferred: 17279400 bytes Requests per second: 3.92 [#/sec] (mean) Time per request: 510.727 [ms] (mean) Time per request: 255.363 [ms] (mean, across all concurrent requests) Transfer rate: 221.54 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 2 Processing: 430 510 139.1 466 1573 Waiting: 429 509 139.0 466 1573 Total: 430 510 139.1 466 1573 Percentage of the requests served within a certain time (ms) 50% 466 66% 485 75% 518 80% 538 90% 591 95% 643 98% 1030 99% 1365 100% 1573 (longest request)

Ahora vamos a hacer la prueba con PHP versión 7.0 a ver qué tal

[email protected] ~ # ab -c 2 -n 300 http://subdominio/blog/2017/02/19/hola-mundo/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking subdomino (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: Apache Server Hostname: subdominio Server Port: 80 Document Path: /blog/2017/02/19/hola-mundo/ Document Length: 57598 bytes Concurrency Level: 2 Time taken for tests: 50.236 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 17379000 bytes HTML transferred: 17279400 bytes Requests per second: 5.97 [#/sec] (mean) Time per request: 334.907 [ms] (mean) Time per request: 167.454 [ms] (mean, across all concurrent requests) Transfer rate: 337.84 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 2 Processing: 288 334 102.6 312 1371 Waiting: 288 334 102.6 312 1370 Total: 288 334 102.7 312 1373 Percentage of the requests served within a certain time (ms) 50% 312 66% 317 75% 320 80% 322 90% 346 95% 461 98% 761 99% 895 100% 1373 (longest request)

Y ahora vamos a hacer la misma prueba con PHP versión 7.1 y luego comentamos las diferencias

[email protected] ~ # ab -c 2 -n 300 http://subdominio/blog/2017/02/19/hola-mundo/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking subdominio (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: Apache Server Hostname: subdominio Server Port: 80 Document Path: /blog/2017/02/19/hola-mundo/ Document Length: 57598 bytes Concurrency Level: 2 Time taken for tests: 50.916 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 17379000 bytes HTML transferred: 17279400 bytes Requests per second: 5.89 [#/sec] (mean) Time per request: 339.439 [ms] (mean) Time per request: 169.720 [ms] (mean, across all concurrent requests) Transfer rate: 333.33 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 2 Processing: 290 339 119.9 317 1494 Waiting: 290 338 119.9 317 1494 Total: 291 339 119.9 318 1494 Percentage of the requests served within a certain time (ms) 50% 318 66% 323 75% 327 80% 329 90% 347 95% 430 98% 659 99% 1298 100% 1494 (longest request)

Una vez hechas las pruebas vamos a proceder a compararlas.

Lo primero será comparar el tiempo de ejecución total de las 300 peticiones hechas de 2 en 2 concurrentes:

En php 5.6 ha tardado 76.609 segundos, php 7.0 ha tardado 50.236 y php 7.1 ha tardado 50.916, es decir, en php 5.6 ha tardado aproximadamente un 50% extra del tiempo que php 7, entre las dos versiones de php la desviación es insignificante.

Con esta simple prueba ya vemos que el pasar a php 7 no es una opción sino una necesidad

Los Captchas han sido un invento fantástico que han evitado muchísimo spam y problemas de seguridad y ya tenemos el nuevo Invisible reCaptcha disponible para WordPress.

El objetivo de los captchas siempre ha sido el asegurarse que quien estaba delante de la pantalla era un humano. Al principio los captchas tenían unas palabras escaneadas que obligaban a ser humano para saber qué pasaba ahí, luego los OCRs, las biblioteca de captchas y demás hicieron que mediante sistemas automatizados esos captchas pudieran ser saltados.

Esa fue la primera generación de captchas, los cuales por cierto, eran muy incómodos pues incluso para seres humanos era difícil descifrar qué ponía ahí, pues para darle complejidad de tachaban las palabras, se ponían tipografías extrañas que no permitían diferenciar en mayúsculas y minúsculas o entre letras, etc.

De hecho los captchas de primera generación todavía se usan en muchos sitios aunque sean un atentado en toda regla contra la usabilidad.

Luego avanzamos y salió la segunda generación de captchas, donde el más famoso es el recaptcha de Google, el cual nos hacía marcar una casilla en la que ponía «No soy un robot» y luego no hacía preguntas en base a fotografías.

Las preguntas que recibíamos eran del estilo «Marca todas las fotografías que tengan agua» o «Marca todas las fotografías que contentan una señal de tráfico».

Por desgracia esto también hay gente, mucha menos, a la que le parece complicado, de hecho, a mi me ha pasado estar hablando con usuarios que tienen que logarse en un sistema y ellos preguntarme que qué hacen porque pone «No soy un robot».

Bien, los recaptchas han supuesto un gran avance y en WordPress han sido muy utilizados, sobre todo en los formularios de contacto, como en el caso de Contact Form 7, un plugin gratuito de formularios bastante resuelto.

En estos formularios antes de darle a Enviar había que marcar en «No soy un robot», pues bien, eso ya es historia.

Ahora tenemos algo mucho más fácil, donde el usuario no tiene ni que marcar el «No soy un robot», se trata del nuevo reCaptha Invisible que lo único que muestra es un pequeño cuadradito en el lugar donde queráis, o un cuadrado en el mismo sitio de antes, pero en el que no es necesario que el usuario haga nada.

Por supuesto el nuevo recaptcha invisible lo podemos tener en el login, en

Para poder disponer de Invisible reChaptcha en nuestro WordPress vamos a tener que instalar el plugin Invisible reCaptcha for WordPress, el cual nos va a permitir utilizar el reCaptcha invisible en las pantallas de:

1. Login
2. Registro
3. Comentarios
4. Recuperación de contraseña

Además también nos permitirá validar tanto en WooCommerce como en Contact Form 7.

Por supuesto el recaptcha tiene sus limitaciones y es que si el navegador no tiene javascript no va a funcionar, por ejemplo, si usamos links2, el navegador de consola de linux, uno de ellos, no podréis ni comentar, ni hacer nada.

Para poder utilizar reCaptcha Invisible en nuestro WordPress además de tener instalado el plugin necesitaremos disponer de tanto la clave del sitio como de la clave secreta.

Para obtener las dos claves iremos a https://www.google.com/recaptcha/intro/invisible.html y ahí tras logarnos y autorizar el dominio ya podremos generar las claves

Para incluir las claves en nuestro WordPress una vez instalado el plugin iremos a la barra de la izquierda a Invisible Recaptcha y una vez ahí Seleccionaremos Settings.

En Settings tenemos dos sitios para incluir nuestras llaves, seleccionar el idioma, la posición y tipo de nuestro badge, el botón de invisible recaptcha y luego si queremos modificar el CSS y guardar ese CSS en base de datos, nada recomendable por cierto.

Ya sólo nos va a quedar una pequeña modificación y va a ser en el plugin Contact Form 7, porque si lo único que hacemos es activar el Invisible reCaptcha en Contact Form 7 es posible que no nos funcione.

Es altamente probable que ya tuviéramos habilitado el reCaptcha antiguo, el de «No soy un robot» en Contact Form y que queramos sustituirlo por el nuevo.

Para sustituir en antigo recaptcha por el nuevo lo único que tenemos que hacer es eliminar la línea:

[recaptcha]

de nuestro formulario.

Otra cosa que tenéis que hacer es en Integración, en el menú integración de Contact Form 7, actualizar vuestras llaves, porque las llaves del nuevo recaptcha son diferentes a las del antiguo.

Con esto ya tendréis vuestro WordPress con la nueva versión de los recaptchas y al día haciendo la vida más fácil para vuestros usuarios ya que no tendrán que interactuar con el Captcha evitando frustraciones de determinados usuarios y además tendremos un sitio WordPress más seguro cada día.

Aquí os dejo también la presentación en vídeo de Google.

Más en: WPTavern

Últimamente se habla mucho en foros varios sobre stagin y temas de cacheen Wordress, y quería hablar un poco de eso, sobre todo de staging, porque nos lo están vendiendo como una especie de ciencia oculta cercana a la visión de una deidad y realmente todo eso al final son temas bastante accesibles y fácilmente implementables, incluso en vuestro propio PC, no necesitáis ningún servidor especial para eso.

Creo que la innovación en el sector de hosting está decayendo, y está mal que yo lo diga porque al final soy parte de ese circo, pero es que es verdad, últimamente estoy viendo cosas que no se cómo definir y se me queda cara de mapa

Yo soy de los que piensan que a los usuarios y desarrolladores hay que presuponerles una capacidad y un entendimiento del sector en el que desempeñan su actividad. Entiendo que si alguien se gana la vida en un entorno es porque lo conoce.

Todo esto lo comento porque hace poco llegó a mis oídos una oferta de hosting en la que ofrecían servidores especializados en WordPress, ojo, eso puede ser correcto si tienes desarrollado algo para atrapar los mensajes del wp-fail2ban o similar, pero en ese caso concreto hablaban de servidores con hardware especializado, vale, ahí se me quedé blanco, es como Apple que al principio vendía discos duros especiales para mac.

Yo tuve un Macbook de esos blancos del 2004 creo, que tenían unos discos Seagate que tenían una manzana pintada, eran los mismos discos que los demás, pero estos como tenían una pequeña manzana costaban muchísimo más caros, ni siquiera hacían como algún fabricante de cabinas que si no le gusta el firmware directamente lo desecha, en esos macs podías pinchar el disco que quisieras, en otras palabras, lo de los discos para mac era un cuento chino bastante ofensivo si sabías un poco.

Pues lo de los servidores con hardware especializado es básicamente lo mismo, un disco es un disco y no tiene nada que ver con un WordPress por mucho que nos lo vendan.

Bueno, después de ese hito, yo creo que insuperable, de la venta de humo pasamos a servidores que hacen caché o staging.

Entiendo que hablan de una capa de software por detrás que hace eso, perfectamente valido, pero no exclusivo.

Para el cache al final tenemos un montón de plugins que hacen exactamente eso mismo y para staging tenemos mil formas de hacerlo, desde copiar los ficheros a un directorio y duplicar la base datos a mano hasta unos plugins muy automáticos que hacen todo eso por nosotros.

Ayer publiqué en eduardocollado.com un screencast de la instalación del plugin WP Staging – DB & File Duplicator & Migration que hace justamente eso, hace un staging.

Pero a ver, estamos hablando de staging y a lo mejor no tenemos muy claro para qué sirve o qué aporta.

El Staging en si es muy interesante para desarrollo, para todos esos desarrollos que no son muy complicados y que se pueden hacer directamente en el servidor, por ejemplo retocar una plantilla o un plugin, algo que por desgracia no hace un usuario medio de WordPress, justo al que está enfocado el producto de staging que hemos hablado antes.

El staging lo que hace es duplicar la web y nos permite entrar en esa copia para trabajar sobre ella, y una vez vemos que los cambios son buenos los podemos trasladar directamente a la web principal sin miedo a que falle pues estamos haciendo los cambios en una copia exacta que está en el mismo servidor con la misma versión de php, mysql etc…, es decir, vamos a tiro hecho y nos aseguramos que los cambios van a funcionar.

Ojo, tenemos que tener en cuenta que staging no es un backup, un cosa es duplicar una web para hacer pruebas y otra cosa tener una copia de seguridad, para las copias de seguridad lo mejor es una copia de los ficheros por un lado y de la base de datos por otro lado.

Aunque hay muchos plugins que hacen muchas cosas a mi me sigue gustando más la forma tradicional.

Se nos va el tiempo y todavía no hemos hablado del plugin, del WP Staging – DB & File Duplicator & Migration, el cual instalaremos y crearemos el directorio logs, ya que el plugin por alguna razón que desconozco no lo crea por defecto.

Luego para ejecutarlo os recomiendo que subáis la prioridad de la creación del staging para ahorrar tiempo si es que vuestro hosting tiene la suficiente capacidad para que todo siga funcionando correctamente.

Luego en la sección de opciones os recomiendo dejar marcada la opción de que en caso de borrado del plugin borre todo lo que deja en el servidor que siempre va bien para no dejar residuos antiguos en el servidor.

Y ahora  esperar a que haga el staging, tardará un buen rato dependiendo del número de ficheros y tamaño de vuestro wordpress, pero os recomiendo que os veáis el screencast para aclarar cualquier duda sobre ese tema.

Enlaces

1. Podéis ver el screencast sobre este tema en: Screencast de WordPress Staging
2. Plugin WP Staging – DB & File Duplicator & Migration: https://es.wordpress.org/plugins/wp-staging/

 

Plugin Wp-Multi-network: https://es.wordpress.org/plugins/wp-multi-net

Hoy os traigo algo muy fuerte, sin paliativos, así que como cosa excepcional a la hora de escuchar un podcast os pido que os sentéis, porque siempre pensando en el impacto que podáis recibir por el audio de hoy creo que es más seguro estar sentados, bueno, vamos para allá.

Estoy seguro que muchos lo conoceréis, pero por alguna razón existe muchísima gente que todavía no conoce ni le suena el concepto de WordPress Multinetwork.

Tenemos WordPress donde configuramos un sitio, tenemos WordPress Multisite donde configuramos una red de sitios y tenemos WordPress Multinetwork donde configuramos una red de redes de sitios, ahí es nada. Así que vamos a hablar sobre el tema, a descubrir qué es un Worpdress Multinetwork y a hacer la configuración básica de un WordPress Multinetwork.

Antes de nada recomendaros que os escuchéis el capítulo 25 de RadioWordpress «Instalación de un WordPress Multisite» ya que vamos a partir desde ahí.

Lo primero va a ser instalar un WordPress Multisite ya que todo parte de ahí, ya sabéis para instalar un Worpdress Multisite partimos de un WordPress normal y para tener un WordPress Multinetwork partimos de un WordPress Multisite.

La instalación es trivial no, lo siguiente. Lo primero será instalar el plugin WP Multi Network que lo tenéis en el repositorio de plugins de WordPress, lo más curioso es que sólo tiene 700 instalaciones activas, realmente pocas para el volumen de instalaciones de WordPress en el Mundo.

Sólo hay una cosa que tendréis que hacer una vez instalado el plugin que es editar el wp-config.php y comentar, o eliminar la línea que contiene DOMAIN_CURRENT_SITE.

Luego tenéis que salir de la administración de vuestro WordPress Multisite y cuando volváis a entrar estaréis en la administración de un WordPress Multinetwork, así de fácil.

Aquí lo complicado sin embargo no es saber cómo se instala sino entender un poco el concepto y las diferencias con WordPress Multisite, así que vamos a ello.

Cuando en Wordpres Multisite creamos un sitio, si la red está configurada como subdominio tenemos que tener la entrada wildcard en el DNS, luego si queremos podremos modificar la URL del sitio para tener el dominio funcionando, obviamente tendremos que tener un alias de host en el apache del servidor web si es que es un apache.

En el caso de WordPress Multinetwork es exactamente igual, pero con la diferencia que podemos estar configurando un sitio o una red y con ver la URL no se va a saber si es un sitio o una red.

Por ejemplo si tenemos multisite.eduardocollado.com como sitio principal, y un sitio que sea 1.multisite.eduardocollado.com, bien, pues 2.multisite.eduardocollado.com podría ser una red que le hayamos puesto esa URL y por tanto 1.2.multisite.eduardocollado.com podría ser un sitio. A ver, esto es muy retorcido, pero podría llegar a usarse, lo normal será utilizar un dominio diferente para cada red y luego subdominios o directorios dentro de cada red.

En WordPress Multinetwork tenemos cosas muy chulas, como por ejemplo el poder crear un sitio en una red y luego moverlo a otra red diferente en caliente.

Para hacer eso lo primero que tenemos que tener claro es como nos movemos entre las redes en el WordPress Multinetwork . Si váis a Networks y luego a All Networks al pasar el ratón por cada una de las redes que componen vuestro WordPress Multinetwork tendréis un enlace llamado Dashboard, si pincháis ahí sería lo equivalente a entrar en el WordPress Multisite de esa red donde podréis instalar los temas y plugins para esa red, que ojo, pueden ser diferentes entre las redes, así que al mover un sitio entre redes hay que chequear eso.

Lo mejor con esta arquitectura es probarla y jugar con ella un poco, obviamente esta arquitectura requiere de soporte de vuestro hoster porque es necesario jugar con DNSs, con alias de hosts, etc… y no va a ser posible instalarlo en cualquier sitio por los requisitos que tiene.

Los requisitos básicos para que el usuario de WordPress pueda plantearse el montar un WordPress Multinetwork en el hosting serán:

1. Preferiblemente php de la versión 7.
2. Soporte de alias de hosts.
3. Soporte de DNS Wildcard.
4. Que el hoster conozca WordPress Multinetwork.

Y de estos cuatro requisitos pensar que hay una gran parte humana, de conocimiento humano que no tienen todos, un sitio donde llames a un call center te vale para un WordPress sencillito, pero para esto ya no, es necesario un soporte de gente preparada y no de un call center, sea del color que sea el call center. Lo que nos hace falta es que quien coja el teléfono en primera instancia conozca WordPress Multinetwork, pero sobre todo que sepa de sistemas y que no sea alguien que lea una plantilla.

Si os interesa este tema, o si os apetece charlar un rato sobre esto, pasaros por las oficinas de Tecnocrática y nos tomamos un café, la única pega es que para tomar un café tendrá que ser en Madrid, al lado del hospital Ramón y Cajal que es donde tenemos la oficina y el CPD, pero vamos, a mi me gustaría muchísimo, así que si os animáis ya sabéis.

Descripción de la base de datos de WordPress en Codex de WordPress: https://codex.wordpress.org/Database_Description

Mapa de la base de datos de WordPress (versión 4.7.2)

base de datos de WordPress

Hoy vamos a hablar de la base de datos de WordPress, de la base de datos y de las tablas que la componen en el momento de la instalación, las 12 tablas, porque son 12, aunque antiguamente eran 11.

De estas 12 tablas de todos modos sólo hay 11 que vayamos a usar, la tabla wp_links que por defecto si es una instalación nueva no se usa y se mantiene para mantener compatibilidad con versiones anteriores de WordPress.

La base de datos de WordPress tiene 6 partes principales: opciones, posts, taxonomía, usuarios, comentarios y enlaces, así que voy a utilizar esta organización lógica de las tablas para poder ir al tema.

Vamos a empezar con la parte de opciones generales de nuestro WordPress, esa es la tabla wp_options, en esta tabla tendremos el ID de la fila, el nombre de opción, el valor y luego un campo en el que indicamos si carga automáticamente o no.

Esta sería la estructura de la tabla wp_options, pero esta tabla es muy importante ya que va toda la información general del WordPress, todas esas cosas que se configuran en la sección de ajustes, pues bien toda esa información va aquí.

Además es muy normal que los plugins guarden información en esta tabla con lo que se enguarrina mucho la verdad, hay que cuidarla y limpiarla no es una tarea siempre obvia, así que con esta tabla hay que ir con especial cuidado.

Otra parte importante es la parte de posts, que está compuesta por las tablas wp_posts y por wp_postmeta.

La tabla wp_posts tiene este nombre por motivos históricos, de cuando WordPress sólo servía para publicar posts, pero no almacena sólo información sobre los posts, sino que almacena información sobre las páginas, los menús, los enlaces a los medios subidos y los propios posts así como las revisiones de todo.

Recordad que una revisión es un post en si mismo, es una fila dentro de la tabla, como un post o una página.

¿Información que haya en esta tabla y que sea importante?, pues toda la verdad, pero es aquí donde podemos ver si una entrada o página acepta comentarios o pings. También podemos ver si es un post, una página, un adjunto o cualquier otro tipo de post type, esto lo vemos en la columna post_type.

Así que si creáis un custom post_type que sepáis que donde va a ir a parar es aquí.

Otra cosa que podemos ver en esta tabla es si hay borradores, revisiones, etc… es una tabla muy completa en la que merece la pena perderse un buen rato.

Supongo que si estáis viendo la tabla mientras estoy hablando y si ya la habéis visto os estaréis dando cuenta que no está normalizada, sólo con ver que hay muchas columnas en las que se repiten constantemente los mismos datos canta bastante. Esto no es así por incompetencia del diseño de WordPress, sino por rendimiento, al premiar el rendimiento en el caso se funcionamiento de la web puede pasar que un simple update tarde un montón y se cargue el servidor, porque la base de datos de WordPress está pensada para generar contenido para servir y no para realizar otro tipo de acciones. Es decir, la estructura de las tablas está pensada para optimizar al máximo el rendimiento como motor web y no para seguir el funcionamiento estándar de bases de datos.

Bueno, después de este pequeño inciso podemos ver la tabla wp_postmeta que es la segunda tabla de la sección de posts.

En esta tabla lo único que se hace es proporcionar metas a cada uno de los posts, sean posts, entradas o cualquier cosa. Un meta en este caso no es otra cosa que un dato extra que se aplica como por ejemplo el contenido de los campos de un formulario, en fin, es un poco cajón de sastre esta tabla la verdad.

Ahora vamos a pasar a la tercera parte, las tablas de usuarios, que también son dos wp_users y wp_usermeta, seguro que con lo que hemos hablado de los posts ya os hacéis un poco la idea de qué hace cada una de las tablas pues es un caso muy similar.

En la tabla wp_users guardamos como muy bien dice su nombre los datos de los usuarios, esta tabla es quizás una de las más utilizadas en el momento el que se pierde una contraseña, pues es aquí donde podemos cambiar la contraseña de WordPress, para eso lo único que tenemos que hacer es venir aquí y en la columna user_pass escribir la contraseña que queramos, pero antes indicando que convierta a MD5 ese valor, en phpmyadmin sería desplegando la función y usando MD5 y escribiendo a la derecha la contraseña, así de fácil. Muchas veces es mucho más rápido hacer esto que hacer una recuperación con el email.

En la tabla wp_usermeta incluiremos datos como el color del interfaz y cosas así,

Vamos a por la parte de comentarios que son otra vez dos tablas wp_comments y wp_commentsmeta, aquí el mismo funcionamiento que antes.

En la tabla wp_comments tenéis información como la IP del que escribe el comentario, el correo electrónico, el comentario en si o incluso si es una contestación a otro comentario y en la tabla wp_commentsmeta la información complementaria a los comentarios.

Estas son quizás las dos tablas más sencillitas

Y llegamos a la sección de taxonomía, aquí son 4 tablas. Cuando hablamos de taxonomía hablamos de categorías, etiquetas o de cualquier otro tipo de taxonomía que nos queramos inventar, todo eso cae en este saco.

La primera tabla será la de wp_terms que lo que hace es guardar la taxonomía y el slug, que el slug recordad que no es más que cómo se va a mostar en la URL esa categoría, etiqueta o lo que sea.

La segunda tabla va a ser wp_term_relationships, la cual va a relacionar las entradas o páginas con las taxonomías, simplemente es una tabla intermedia que hace las relaciones, esta sí está perfectamente normalizada.

La tabla wp_term_taxonomy nos va a indicar qué es cada taxonomía, si es una etiqueta, una categoría o lo que sea, así se sencillo.

Y la última tabla que es wp_termmeta que sí, es lo que estáis pensando, esta tabla lo que tiene toda la información extra necesaria de las taxonomías, esta tabla suele estar vacia, así que si la tenéis vacía no os asustéis.

Es posible que ahora vosotros estéis viendo en vuestra base de datos de WordPress más tablas, es normal, pero no son las que instala WordPress. Es muy normal que los plugins instalen tablas para sus cosas, así que no os asustéis si veis tablas nuevas, pero es importante tener todas estas tablas controladas para que no crezcan hasta el infinito.

Otro día si queréis podemos hablar de cómo mantener un poco todo este follón de tablas para que el rendimiento de nuestro WordPress sea óptimo.

Sólo me queda despedirme y comentaros que si os interesa ver cómo funciona toda la parte de WordPress por debajo, los servidores, infraestructura y demás podéis contactar conmigo en Tecnocrática y podré enseñar un poco todo esto que a veces nos quedamos sólo con la idea de que Internet acaba en el WordPress y no no, hay muchísimo trabajo por debajo.

 

Hoy vamos a dar de alta juntos un nuevo sitio y vamos a escribir el primer post, hablaremos de las plantillas, de los temas y de lo que nos vayamos encontrando con una base de jazz, hoy vamos a hablar de WordPress Multisite.

Pero no quería empezar sin comentaros que ya tengo, al menos pagada la entrada para el WordCamp de Madrid del 22 y 23 de Abril entre el Viaducto y el Puente de Segovia, más en el centro de la ciudad imposible. Así que espero veros a muchos por ahí, así que si vais por favor decidmelo y como mínimo nos tamaremos un café.

Lo único que tener en cuenta que es en Sábado y Domingo, porque yo de ese pequeño detalle no me di cuenta hasta después de haber pagado las entradas, que por cierto, la organización no me ha enviado absolutamente nada, lo único que tengo es el resguardo de paypal, les he puesto un correo para ver si es normal o no, ya os contaré que me contestan.

Pero vamos a por algo interesante y vamos a ponernos con WordPress Multisite.

Hoy vamos a seguir los pasos para que creeis un sitio y podáis crear vuestra primera entrada, no es algo complicado, pero sí que tiene sus cosas y diferencias con WordPress tradicional, así que vamos a realizar el proceso juntos.

Lo primero va a ser crear el sitio nuevo, así que vamos a entrar en el admin de nuestro WordPress Mutisite y vamos a Sitios y a Añadir Nuevo, ahí ponéis la URL del nuevo sitio, el email del administrador, el título y el idoma del sitio, ya está, con eso crearéis el nuevo sitio, no hace falta hacer nada más.

Recordad que si usáis WordPress Multisite con subdominios si no tenéis la entrada de DNS Wildcard tendréis que crear una entrada por cada sitio nuevo que creéis.

Volviendo al tema, una vez creado el sitio, lo ideal es que le creéis un usuario y que no entréis con el administrador de la red en los sitios, pero eso va a gusto del consumidor porque podéis usar siempre el administrador de la red.

Para crear el usuario recordad que iréis a Sitios – Todos los Sitios, pasaréis el ratón sobre el nuevo sitio y os saldrá el menú editar, en el que pincharéis.

Ahora arriba tendréis Usuarios, lo suyo es agregar un usuario a ese sitio porque lo normal no es usar un Wordress multisite para un único usuario, es posible, perfectamente posible, pero no lo estándar.

Ya vimos como crear usuarios en el audio anteior, así que esa parte nos la saltamos. Ahora nos logaremos en el sitio nuevo, para ello irémos al sitio nuevo como si fuera un WordPress independiente, es decir sitio/wp-admin y nos logaremos y ahí tendremos un menú de WordPress de sitio normal, como un WordPress estándar.

Otra opción si queréis entrar con el Superadministrador de la red podéis pinchar arriba donde pone sitios, arriba a la izquierda y seleccionar el Sitio nuevo y luego Escritorio, así ya estaréis en el escritorio de ese sitio en concreto.

En este punto ya podéis ir a Entradas y Añadir Nueva, pero es probable que queráis personalizar este sitio un poco, añadir un tema, algún plugin, etc.. ese tipo de cosas y desde aquí no vais a poder hacerlas.

Sin embargo hay algo muy importante que sí vais a poder hacer desde aquí y es editar los enlaces permanentes, en Ajustes – Enlaces Permanentes, estos son los permalinks de toda la vida, pero en español ya sabéis, enlaces permanentes mucho mejor.

El otro día ya comentamos que en el panel de Administración de la red podíamos activar tanto temas como plugins, recordad que activar un tema para un sitio no significa que el tema esté activo en el tema sino que está disponible en el sitio, mientras que activar un plugin significa que ese plugin estará activo en el sitio sin posibilidad de ser desactivado o quitado.

Así que si queremos tener algunos temas en nuestros sitios tendremos que ir al administrador de la red y activarlos o para la red o ir sitio a sitio activándolo, como más os guste u os convenga.

Para los plugins sólo con tenerlos instalados ya serán visibles en el sitio, pero ya os digo, si no queréis que el usuario tenga la posibilidad de desactivarlo podéis forzarlos simplemente activándolos desde el administrador de la red.

Una vez hayáis tenido en cuenta todo esto ya podéis proceder a escribir vuestro primer artículo, página, crear las categorías, las etiquetas, etc… en definitiva podréis empezar a trabajar con el sitio nuevo del WordPress Multisite como si fuera un sitio normal, como cualquier otro sitio de un WordPress que no sea Multisite.

Y si necesitáis algún tema nuevo, o si necesitáis algún plugin extra lo que tenéis que hacer es solicitarselo al administrador de la red que será quien tenga que evaluar si es necesario o no para instalarlo si lo cree conveniente y si funciona correctamente en el WordPress Multisite. Por desgracia no todos los plugins están preparados para funcionar en WordPress Multisite, por eso hay gente que es bastante reacia a utilizar Worpdress Multisite y prefiern gestionar los WordPress por separado, pero dependiendo de la situación WordPress Multisite será la solución óptima y por supuesto la mejor para tener en cuenta.

El capítulo de hoy es bastante sencillito e incisivo en algún tema, pero tener en cuenta que esto que hemos recordado aquí son los fundamentos de WordPress Multisite

Un WordPress Multisite tiene un panel de administración bastante parecido al de un WordPress estándar, el que no es multisite, una de las diferencias principales, y la más obvia consiste en el menú de administración de la red, para llegar a él pincharemos en nuestro admin de wordpress en mis sitios y luego en administración de la red.

Mis sitios se encuentra arriba a la izquierda y ahí tendremos Escritorio, Sitios, Usuarios, Temas, Plugins y Ajustes, muy  muy similar al admin de un wordpress estándar.

En el Escritorio tenéis dos menús interesantes, Actualizaciones, que es donde os saldrán las actualizaciones de WordPress, y luego otra sección llamada «Actualiza la red», aquí es donde al darle actualizaremos todos los sitios de la red. Sólo así nos aseguraremos que todos nuestros sitios están correctamente actualizados.

En inicio simplemente tendremos dos enlaces, uno a crear nuevo sitio y otro a crear nuevo usuario, dos sitios que veremos ahora con un poco más de calma

En el menú de Sitios tendremos dos opciones, la primera en la que nos listará todos los sitios que están bajo nuestro WordPress Multisite y luego añadir nuevo, donde tendremos la forma de crear nuevos sitios, nuevos blogs, worpdress, o como queráis llamarlo.

Si en la configuración global de WordPress habéis indicado que queréis configurar con directorios tendréis el hueco para rellenar vuestro sitio al lado derecho del dominio, después de la barra, si hubieráis configurado subdominio lo tendréis a la izquierda, pero añadir el sitio sería igual.

Para añadir el sitio simplemente le indicamos la URL del sitio, el título del sitio, el idioma del sitio y el correo electrónico del administrador.

Aquí ha habido alguna pequeña modificación, pero bueno, en el momento de grabar este audio, estamos en la versión 4.7.2 de WordPress, os comento esto para que tengáis un punto de referencia. Y obviamente todo lo que estoy diciendo aplica a la versión 4.7.2.

El menú de sitios lo vamos a ir completando poco a poco, así que si veis algo más no os preocupéis.

Ahora vamos a añadir un usuario. Atentos a este punto porque quizás no es como lo esperáis, puede parecer un poco enrevesado, así que ya aviso.

Para crear un usuario vamos a Usuarios – Añadir nuevo.

Hasta aquí perfecto, es fácil, rellenamos nombre y correo electŕonico. Aquí lo único más que podremos decirle es si el usuario es un SuperAdministrador de la red, si no lo marcamos, será un usuario de blogs y será en los sitios donde definamos su rol, en cada uno de ellos.

Una vez creado vamos a Sitios, a Todos los sitios y en el sitio que queramos le damos a  Editar, y es ahí donde tendremos Usuarios y podremos añadir un usuario, lo añadiremos escribiendo su nombre e indicando su Rol en Perfil.

Si el usuario no existe podremos crearlo desde aquí, será como crearlo desde el menú de usuarios, pero con una diferencia, si lo creamos desde aquí no podremos crearlo como SuperAdministrador de la red y tendremos que ir luego a usuarios para modificar esto.

Como veis eso se puede liar un poco.

Ahora vamos a Temas, aquí es como en un Worpdress normal, con la única diferencia que podemos activar un tema para toda la red, pensar que dentro de un sitio no podremos instalar ni temas ni plugins, todo esto se tiene que hacer desde aquí.

Si quisieramos asignar un tema a un sitio específico podremos ir a Sitios – Todos los sitios y editar el sitio que queramos pasando el ratón por encima del nombre del sitio.

Ahí tendremos una pestaña que pone temas, justo al lado de la de usuarios y ahí podremos activar temas específicos para un sitio de la red.

Así que recordad si queréis activar un tema para toda la red lo hacéis desde temas, si sólo lo queréis activar para un sitio concreto lo hacéis desde la pestaña temas de Sitios – Todos los sitios y editáis el sitio concreto.

Una cosa que es importante, activar un tema significa que está disponible en ese blog, en ese sitio, es decir, si activamos 2 temas singnifica que en el admin de ese sitio concreto se podrá elegir, si no está activado no se va a ver desde el admin del sitio concreto. En temas activar significa que son visites en el admin del sitio, no que se activen

Ahora lo fácil sería que os dijera que los plugins van igual que los temas, pero no, sería demasiado fácil, así que no, los plugins van parecidos a los temas, pero no igual.

Los plugins se activan para la red o no se activan.

Y ¿qué significa activar en los plugins?, pues a diferencia de los temas si activamos un plugin para la red significa que el plugin está activo y que no puede ser desactivado en la red. Los plugins que no estén activos se verán en los sitios y podrán ser activados.

Así que recordad, plugin activo en la red es que está activo en todos los sitios de la red y no se podrá desactivar, sin embargo tema activo en la red significa que ese tema podrá ser visite, pero no está activado.

Esta es la razón por la que en el admin, en la edición de sitios no tengamos pestaña para plugins.

Es confuso, sí, lo se, bastente, pero está montado así aunque a mi personalmente me parezca bastante lioso la verdad.

Y luego tenemos la parte de ajustes que la vamos a dejar para el próximo día porque es bastante compleja la verdad.

 

 

Hoy tenemos WordPress Multisite, os comento las ventajas y como se instala. Como es un tema nuevo os he cambiado la música de fondo y ahora podréis disfrutar de jazz, ya me contaréis si os gusta.

Enlaces:

Instalación de WordPress Multisite – https://codex.wordpress.org/Create_A_Network

Código:

Código a instalar en nuestro wp-config.php

/* Multisite */ define( 'WP_ALLOW_MULTISITE', true );

Hoy os traigo el capítulo 25 y vamos a cambiar un poco de tercio, hoy vamos a empezar a hablar de WordPress Multisite.

Estoy seguro que muchos de vosotros ya habéis oído hablar de WordPress Multisite, incluso es posible que ya lo hayáis instalado o que ya lo estéis gestionando.

Todos sabemos qué es un WordPress, pues ahora imaginad que con una única instalación de WordPress pudieramos tener todos los WordPress que quisiéramos, gestionando y manteniendo sólo uno.

Realmente WordPress Multisite convierte nuestra instalación de WordPress en una red de WordPress gestionados desde un punto común, creo que esta podría ser la definición más precisa.

Esta forma de utilizar WordPress nos permitiría tener una instalación, un grupo de plantillas, un grupo de plugins y todo centralizado, realmente sólo gestionaríamos un WordPress, pero podríamos tener funcionando todos los WordPress que quisiéramos, lo cual es genial.

¿Donde nos puede venir bien este tipo de instalación?, realmente las posibilidades son enormes y podría ser por ejemplo un ayuntamiento que le de un blog a cada uno de sus ciudadanos, o una empresa que le de un blog a cada empleado, una escuela o facultad, incluso un periódico o revista online creado a base de secciones al estilo de cuartopoder.es.

En WordPress Multisite tendremos un WordPress principal y luego secundarios, en principio todos los que quisiéramos, pero por defecto no de cualquier manera, en principio tendremos que decidir si queremos que los nuevos blogs se instalen en directorios o en subdominios.

Por ejemplo tendremos que decidir si queremos que nuestro nuevo sitio se instale en eduardocollado.com/nuevositio o en nuevositio.eduardocollado.com

Estas son las dos opciones que nos facilita WordPress Multisite para trabajar por defecto, diferencias hay ya que el funcionamiento no es el mismo.

Si decidimos trabajar con directorios la complejidad se reduce enormemente ya que no tenemos que tocar DNSs, no tenemos que tocar la zona DNS mejor dicho, sin embargo si queremos trabajar con subdominios tendremos que tocar la zona DNS y dar de alta cada uno de los subdominios o bien crear una entrada wildcard en la zona de DNS para que todos los subdominios que creemos puedan apuntar al servidor donde esté instalado el WordPress Multisite.

Si usáramos directorios sería muchísimo más sencillo ya que no tendríamos que tocar la zona de DNS.

Bueno, vamos a instalar un WordPress Multisite, ya veréis lo sencillo que es. Lo primero va a ser instalar un Worpdress, un WordPress normal, el único cambio que vais a tener que hacer es escribir en el wp-config.php abajo del todo

/* Multisite */ define( 'WP_ALLOW_MULTISITE', true );

Y ya está ahora entramos en nuestro panel de administración y vamos a Herramientas -> Configuración de la red.

Es en este menú donde tenemos que empeza a configurar nuestra red, realmente lo que podemos configurar ahí es si queremos que nuestro Multisite funcione con subdominios o con directorios, si decidimos que funcione con directorios que será la opción más fácil la definimos ahí.

Si queremos que funcione con subdominios tendremos que ir al DNS y configurar una entrada * de tipo A que apunte a la IP del servidor donde tengamos el wordpress multisite, esto depende de nuestro proveedor, en Neodigit se pueden configurar sin problemas las entradas wildcard en la zona DNS, pero dependiendo de donde tengáis el hosting dependerá un poco, en caso de duda llamáis al soporte de vuestro hoster y que os resuelvan la duda que para eso están.

Una vez le hayamos dicho qué tipo de instalación queremos le daremos al botón de instalar y nos dará dos trozos de código, el primero para pegar en el wp-config.php y otro para pegar en el .htaccess

Muy importante que las líneas que vayan en el wp-config.php vayan encima de la línea que pone

 /* ¡Eso es todo, deja de editar! Feliz blogging */

porque si no no valdrá para nada.

Y el .htaccess sustituiremos todo lo que hay por defecto por las líneas que nos indica.

En este momento al volver a logarnos tendremos nuestro WordPress Multisite listo para empezar a trabajar con el.

Como habéis podido apreciar es bastante sencilla la instalación y no requiere gran cosa, lo único es el uso del FTP o del SSH para poder modificar los ficheros wp-config.php y .htaccess, pero el resto ya habéis podido ver que no es algo difícil.

En el próximo capítulo empezaremos a configurar nuestro wordpress multisite para poder empezar a trabajar y empezaremos a ver las diferencias con un wordpress estándar, aunque ya veis que a priori las diferencias deberían de ser mínimas.

 

Hola a todos, mi nombre es Eduardo y esto es RadioWordpress, un podcast dedicado a todos aquellos que de una manera o de otra convivimos con WordPress.

Hoy es Jueves 16 de Febrero y me gustaría recorrer con vosotros un WordPress para hacer una auditoria de seguridad básica, qué tenemos que mirar y donde. Esto no va a hacer que nuestro WordPress sea indestructible, pero sí que lo va a hacer menos vulnerable que el 99% de WordPress que hay por ahí.

La seguridad no es una cosa que hagamos un día y ya está, no, la seguridad es algo que tenemos que seguir todos los días, y en todos estos capítulos que llevamos hemos estado viendo diversas cosas que podemos hacer para mejorar la seguridad de nuestro WordPress, ya sea mediante mejores prácticas, modificaciones del fichero .htaccess, el uso de plugins o el uso del sentido común que es a día de hoy una de nuestras mejores armas.

La auditoría básica está pensada para hacer una evaluación rápida de aquellos WordPress que caen en nuestras manos, o que queremos revisar para poder emitir un juicio rápido, obviamente luego será necesario trabajar en profundidad con ese WordPress para poder emitir un juicio aceptable.

Lo primero que vamos a hacer es logarnos en el admin de WordPress y antes de entrar ya podemos evaluar si el usuario y la contraseña son aceptables, si vamos a entrar en un WordPress y las credenciales que nos facilitan son usuario admin y contraseña password, empezamos mal, realmente es difícil empezar peor, ahí tenemos que ver que el usuario no sea el usuario de WordPress y que la contraseña tenga una complejidad mínima.

Para ver la complejidad de la contraseña realmente no os hace falta ningún software y rápidamente podréis ver si se trata de un teléfono, una fecha, una palabra sencilla o una contraseña en condiciones, al menos veremos su apariencia y como evaluación primera, recordad que estamos haciendo una auditoría rápida, es más que suficiente.

Una vez nos hayamos logado miraremos que no hay actualizaciones y luego en el admin de WordPress iremos a Ajustes y luego a Generales, ahí buscaremos la opción «Cualquiera puede registrarse» y tenemos que ver que está deshabilitada. A veces por alguna razón llegamos a un WordPress y tienen esta opción habilitada lo cual no es una muy buena idea pues cualquiera podría llegar a entrar en nuestro admin después de logarse con algún tipo de permiso.

En cuanto a los comentarios también tendremos que ver que no todo el mundo pueda comentar alegremente. No es necesario tener que validar todos los comentarios, pero sí los comentarios de aquellos usuarios nuevos, así que os recomiendo en Ajustes – Comentarios dejar desmarcado «El comentario debe aprobarse manualmente», pero en cambio sí dejar marcado «El autor del comentario debe tener un comentario previamente aprobado» y justo debajo tener limitado el número de enlaces a otras webs que permitimos en los comentarios. Pensad que mucho spam viene indicado simplemente por el uso excesivo y desmesurado de los enlaces en los comentarios.

Luego obviamente podéis filtrar palabras que no os gusten.

Esto de los comentarios nos puede ayudar a controlar el poco spam que consiga saltarse a los plugins antispam y evitar que alguien pueda hacernos daño, por ejemplo un usuario con comentarios aprobados que diga cosas muy feas de nuestras competencia, eso no es elegante y hay que tener mucho cuidado con ese tipo de cosas.

Luego en Ajustes – Lectura, es muy interesante no tener marcada la opción «Disuade a los motores de búsqueda de indexar este sitio», pensar que a veces hay gente que gestiona WordPress y cuando tienen algún problema con el cliente marcan esta casilla para que el cliente desaparezca de Google, son malas prácticas, pero hay gente que las hacen, así que es un punto importante a mirar, obviamente también el htaccess no vaya a ser que ahí está indicado.

Llegados a este punto iremos a la sección de plugins. Ahí tendremos que comprobar que estén todos activos y actualizados, si no están activos es que no hacen falta y se pueden borrar. Luego iremos plugin por plugin viendo si son plugins que están al día o si llevan mucho sin actualizarse, por supuesto viendo si soportan nuestra versión de WordPress y demás, este punto es bastante laborioso y muchas veces no podremos hacerlo si tenemos muy poco tiempo para una vista rápida.

En los usuarios como hemos dicho antes miraremos que no exista el usuario admin y que los nombres de los usuarios no coincidan con el nombre de usuario de WordPress, esto realmente es más importante de lo que parece, porque si no se sabe nuestro usuario es más difícil que puedan conseguir la contraseña. Por supuesto el número de usuarios que sean adminsitradores del WordPress tienen que ser los mínimos imprescindibles.

En cuanto a los temas también tendremos que revisar las versiones, que estén actualizados, etc..

En este punto ya dejaremos de usar la web y pasaremos a revisar los ficheros de WordPress.

Empezaremos revisando el wp-config.php, comprobaremos que el prefijo no sea wp_, que el usuario y el nombre de la base de datos no sea el mismo y que la contraseña sea compleja, si es posible tendremos el acceso al mysql cerrado a todo aquel que no sea localhost.

Luego deshabilitaremos el error_display y la edición de ficheros desde nuestro admin, esto recordad que lo hemos hecho ya en capítulos anteriores, y es muy interesante protegernos con esto.

Y ahora pasaremos a nuestro amigo el .htaccess, ahí comprobaremos que al menos tengamos protegido el wp-config, que tengamos bloqueados los comentarios de spam no referidos, el hotlinking y comprobaremos que está bien definido el tiempo de cache, esto ya os digo, por no repetirme lo tenéis en capítulos anteriores de este mismo podcast.

Y por último revisad siempre que estén los permisos de los ficheros y directorios correctos, recordad que WordPress recomienda los ficheros en 644 y los directorios en 755.

Con estas sencillas normas podéis mejorar o evaluar un WordPress en cuestión de minutos, por supuesto luego podéis profundizar todo lo que deseeis.