Radio Wordpress

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.

Hoy toca hotlinking y bloquear el spam no referido en nuestro WordPress. Disculpad, pero en el audio digo capítulo 22, ya pierdo la cuenta

Código para evitar el hotlinking no sirviendo nada

Código para evitar el hotlinking sirviendo la imagen norobar.jpg

Para bloquear el spam no referido podremos usar este código en el .htaccess

Comprobación de http requests: https://www.hurl.it/

Vamos a empezar por ver cómo bloquar el hotlinking, para el que no lo sepa el hotlinking es el robo de ancho de banda.

El hotlinking consiste en cargar elementos en una web cuando el elemento en sí está en otro lugar diferente, al hacer esto el ancho de banda del objeto cargado se contabilizará en el servidor remoto pues se carga desde ahí.

¿Esto en qué nos afecta? pues en que si lo permitimos puede haber otras webs por ahí que utilicen nuestros ficheros y por tanto nuestro ancho de banda para mostrar imagenes o cualquier cosa en su web y al final eso repercute en que nosotros tendremos que pagar esa factura de transferencia excedida.

Por ejemplo, si alguien quiere insertar una imagen en su web y ve que nosotros ya la tenemos en nuestro WordPress, pueden simplemente copiar la ubicación de nuestra foto e insertarla en sun web, de esta forma cuando carguen su web se cargará la imagen desde nuestro servidor haciendo que se consuma nuestro ancho de banda y nuestros recursos del servidor donde estemos.

Que no cuanda el pánico porque podemos prevenirnos y evitar el hotlinking, simpelemente modificando nuestro fichero .htaccess. Tenemos dos opciones, la primera consiste en evitar que cargue la foto en cualquier web que no sea la nuestra y la segunda es muchísimo más poética y lo que vamos a hacer es cargarles una imagen específica, por ejemplo una imagen que salga Bart Simpson copiando en la pizarra «Robar ancho de banda de otras webs está mal», esto no evitará que se consuma nuestro ancho de banda, pero sí el que lo intente hará lo posible para que no salga esa imagen.

El primer código de htaccess lo que hará será que cada vez que se intente cargar un gif, un png o un jpg, en cualquiera de sus posibilidades, no mostrará nada, no cargará ninguna imagen si el referer es algo que no sea nuestro dominio

La segunda opción lo que hará será mostrar la imagen norobar.jpg cuando se intente cargar un gif, un png o un jpg, en cualquiera de sus posibilidades, obviamente permitiremos cargar la imagen norobar.jpg, sólo permitiremos cargar esa si el referer es algo que no sea nuestro dominio

Ahora vamos a pasar a otro tema, a protegernos del spam no referido.

El spam no referido son todos aquellos comentarios que comentan directamente sin pasar por el post asociado, eso se hace llamando directamente al fichero de comentarios.

La opción más sencilla para evitar el spam no referido es el fichero .htaccess, el cual como estáis vioendo es como una navaja suiza, es fantástico porque hace de todo.

La forma sería bloquear el acceso a wp-commetns-post.php desde cualquier sitio que no sea la propia URL, en mi caso el trozo de código del htaccess que hace esa función os la dejo en las notas del programa.

Resulta extremadamente molesto el ver comentarios por todas partes, aunque sean de spam, porque al final por mucho Akismet que tengamos esos comentarios son procesados por php y por tanto consumen recursos del servidor, y lo que queremos es reducir el consumo del servidor en todo lo posible.

Vosotros pensar que cuanto más optimizadas tengáis las webs menos vais a pagar en vuestro hosting pues estaréis usando menos recursos y cuanto más seguras las tengáis menos problemas vais a tener, menos incidencias, menos de todo y vuestra web estará siempre perfecta.

Hoy os traigo unos plugins de seguridad, que no se diga que soy un antiplugins, nada más lejos de la realidad.

Los plugins miradlos con cariño y no instaléis todos por instalar, mirad lo que hacen e instalar sólo si veis que os aportan y que os dan la confianza que vosotros queréis.

Si escucháis un poco raro el audio es porque he cambiado la forma de grabarlo para probar a ver qué tal queda, lo he grabado directamente con una mesa de mezclas y de un tirón, no está editado, después de oírlo no estoy totalmente convencido, pero bueno, ya me diréis qué os parece.

Plugins:

Hola a todos, esto es RadioWordpress, es el capítulo 22, mi nombre es Eduardo y este audio podéis encontrarlo en eduardocollado.com.

El lunes os contaba que había que ir con cuidado con los plugins ya que a veces tienen un coste, bueno, no quiero se entienda que estoy totalmente en contra de los plugins o que tengo algún tipo de fobia a los plugins, es como todo, tenemos que saber qué estamos haciendo.

Hoy os traigo una colección de plugins que funcionan bien para casos concretos, en el caso de hoy están enfocados a la seguridad de vuestros WordPress, pero es como todo, tenéis que ver qué os aportan y si realmente os interesan.

El primero es el Akismet, en mi caso he tenido que volver a usarlo porque Disqus dejó de funcionar, parece ser que por un problema de compatibilidad con el plugin de cache que uso, así que mientras solucionan ese tema he vuelto a activar los comentarios normales de WordPress con el plugin de Akismet.

Akismet es un antispam para los comentarios escrito por la misma gente que hace WordPress, funciona bastante bien y aún sin ser mi opción favorita funciona bastante bien, este sería el primer plugin de seguridad porque creo que lo podemos englobar en esa categoría y como ya hemos hablado de él creo que no es necesario que nos explayemos más en él.

BBQ, ojo, no tiene nada que ver con una barbacoa, realmente se llama BBQ: Block Bad Queries. La versión gratuita no requiere ningún tipo de configuración, no hay que hacer nada, se instala y funciona, así de fácil.

Este plugin se encarga bloquear peticiones malas, entendiendo como malas aquellas que tengan base64_, eval(, .exec( y cosas así. Se trata de una protección bastante interesante para nuestras webs, pensad que un porcentaje enorme de las infecciones de WordPress viene dado precisamente por este tipo de cosas y bloquear esas peticiones puede ser buena idea.

El plugin es bastante ligerito para lo que hace y ahí lo tenéis para probarlo.

Para evitar ataques de fuerza bruta contra el login de WordPress tenéis varios plugins, pero el wp-fail2ban, este plugin lo que hace es escribir en el syslog del servidor los intentos de login desautorizados y es el propio servidor el que introduce esa dirección IP en el firewall del servidor.

Para que wp-fail2ban os funcione tenéis que tener un servidor que soporte esta funcionalidad, si no lo tenéis poneros en contacto conmigo y ya vermos qué podemos hacer para que os vengáis a Neodigit que eso está integrado y además tenéis muchas más cosas para que al menos os penséis el migrar.

Y si además queréis una doble autenticación siempre podéis usar el Google Authenticator para utilizar la autenticación extra Google, con su aplicación, ya sabéis como funciona, esto último de todos modos a mi no me gusta depender de Google para entrar en Worpdress ya me parece increíble, pero oye, hay gente para todo, así que os lo dejo como opción.

¿Queréis más plugins?, venga, pues sigamos, si queréis bloquear una dirección IP por la razón que queráis siempre podéis usar el WP Ban, este plugin lo que hará será filtrar por IP.

Este tipo de plugins que lo que hacen es bloquear el tráfico desde ciertas IP no me acaban de gustar porque realmente estáis delegando al php algo que tiene que hacer el firewall del servidor, así que estáis dando una carga a la web que debería de no tenerla, para eso lo mejor es meter la IP en el firewall del equipo, pero bueno, es una opción.

Si algo me gusta del wp-fail2ban que hemos comentado antes es justo eso que no bloquea el php sino el firewall del servidor, el rendimiento de la web no se ve afectado, sin embargo con este tipo de plugins el rendimiento del servidor sí se ve afectado.

Y ahora un par de plugins para aquellos que queréis estar bien seguros de tenerlo todo controlado.

El Activity Log nos va a dar un log de lo que hagan nuestros usuarios dentro del WordPress, podremos saber qué ha hecho todo el Mundo, así se acabó eso de «yo no he sido». Ya sabéis que lo importante no es buscar culpables, pero en este caso si sabemos quien ha sido podremos preguntar directamente y saber exactamente qué ha pasado ahorrándonos mucho tiempo de navegar e interpretar logs.

Y tenemos un plugin llamado Exploit Scanner, este no se lo recomiendo a los inseguros, en serio, os vais a volver locos, este plugin nos da información de todos aquellos ficheros que podrían haber sido manipulados. Realmente busca la cadena eval y cosas similares, el problema es que si usáis plugins como el Autoptimize os vais a volver loco porque en la cache vais a encontrar esa cadena muchísimas veces, así que este plugin hay que tomarlo con pinzas y con mucho cuidado.

Hoy os he traído 7 plugins que pueden ayudarnos con la seguridad, y fijaros que no he nombrado al WordFence porque a él se le atribuyen cualidades casi mágicas y a mi personalmente no me gusta mucho, pero es muy utilizado últimamente y está muy de moda, pero como os comenté el Lunes hay que usar la herramienta correcta para cada tarea.

Bueno, espero que mi fama de antiplugins haya quedado solventada con este audio y la semana que viene os traigo más contenido sobre WordPress.

Un placer como siempre y ya sabéis que os podéis suscribir con el rss, en ivoox, en itunes o donde queráis y recordad que podéis puntuar positivamente o votar el podcast si os ha gustado y también podéis comentar.

En las notas del programa recordad que os dejo los enlaces a todos los plugins de los que hemos hablado en este audio en eduardocollado.com

WordPress es un gran software, hasta aquí estamos todo de acuerdo, pero parece fácil y eso hace que todo el Mundo quiera tocarlo, además parece que todo lo podemos solucionar con un plugin, para todo hay plugins, pero no, no es así.

A veces la forma de trabajar que pareciera por defecto de WordPress no es la más óptima y nos ata, nos encadena a soluciones prefritas y al final puede afectar a la calidad de nuestro producto.

Hola a todos, esto es Radio WordPress, un podcast dedicado a todos aquellos que de una manera u otra convivimos con WordPress. Mi nombre es Eduardo y podéis encontrar el podcast con sus notas en eduardocollado.com

Hoy vamos a hablar del WordPress’ style, de cómo WordPress nos ha cambiado la forma de pensar en hacer las cosas.

Hoy iba a hablar de otras cosas, pero al escuchar a Javier Archeni hablaba en el último capítulo de su podcast República Web del uso de WordPress y me ha hecho reflexionar un poco sobre el modo de trabajar al que nos puede llevar WordPress y contra el que hay que luchar.

WordPress tiene un problema y es que parece muy fácil de usar, y me gustaría enfatizar en el verbo parecer, digo parece porque realmente no es fácil, cualquier puede conducir un coche con un pequeño aprendizaje, pero pocos acabarán corriendo rallies como Carlos Sainz, pues WordPress es un poco así.

Escribir un post, una página o instalar un tema por defecto es fácil, luego existe una pensamiento generalizado en el que todo se arregla instalando plugins, existen plugins para todo y la gente usa plugins para todo, sin discriminar absolutamente nada, todo en esta vida parece que son plugins.

¿Quieres mejorar tu posicionamiento en Google?, pues instalas el Yoast, ¿Quieres que tu web vaya más rápida?, pues instalas el WP-SuperCache, ¿Quieres insertar el código de Analitics?, pues instalas otro plugin, y así la lista es infinita, para cualquier cosa que se pueda pensar seguro que existe un plugin.

El problema es que los plugins muchas veces tienen un coste muy alto, nos ofrecen unas funcionalidades a cambio de rendimiento o de otras funcionalidades, además cada plugin que sea indispensable se convierte en una cadena, pues vamos a depender de ese plugin de por vida a no ser que encontremos otro que haga algo parecido.

No me mal interpretéis, los plugins no tiene por qué ser malos, de hecho hay veces que a nosotros mismos nos interesa crear un plugin para hacer algo concreto, el problema principal estriba en poner plugins que hacen vete a saber qué por detrás para hacer algo que podríamos hacer de una forma sencilla o no tan sencilla, pero haciendo que sea todo mucho más óptimo.

Pero también tenemos el caso de los clientes que tocan porque creen que saben mucho. Aprender es bueno, tocar es bueno, pero yo siempre digo que los experimentos con gaseosa. No hay nada peor que un cliente que toque, rompa algo sin ser consciente y luego te diga que algo habrás hecho mal tú como desarrollador porque eso no funciona, este tipo de clientes son lo peor con mucha diferencia, ya que no aprecian tu trabajo porque creen que lo único que hacemos es instalar plugins y encima están convencidos que saben más que nosotros y todos tenemos o hemos tenido clientes de estos.

Ahí tenemos un trabajo enorme con los clientes de explicarles que hay cosas que es mejor hacer de otra manera y ser capaces de explicarles el porqué.

El control del código es algo muy importante y es importante mantenerlo, conocer qué hace nuestra aplicación o nuestra web en este caso.

El sábado publiqué un post en mi blog en el que hablaba un poco de esto, necesitaba en la página principal dos columnas para poner los dos reproductores de los dos podcasts que tengo. Tenía dos opciones, buscar un plugin que lo hiciera o modificar el CSS, la comodidad y la inercia de WordPress puede llevarnos a la búsqueda de ese plugin, y haberlos haylos, de hecho cualquier plugin de edición de plantillas lo hace, el Site Origin por ejemplo, pero perderíamos el control del código y nos ataríamos a otro plugin, así que lo que hice fue un tema hijo y modificar el CSS, mucho más fácil, pero por desgracia la inercia del funcionamiento de WordPress puede no llevarnos a eso.

Esta es una de las razones por las que en el podcast intento ofrecer visiones de cómo hacer cosas de la forma correcta, o al menos de la forma que a mi me parece más óptima, por ejemplo proteger el WordPress se puede hacer de muchas formas, pero a veces lo más fácil es utilizar el fichero .htaccess, a eso me refiero cuando hablo de este tipo de cosas.

Así que procurad  no caer en lo que yo llamo el WordPress’ Style, que básicamente consiste en hacer esto que hemos estado comentando hoy y procurad trasladar a vuestros clientes este pensamiento, porque instalar plugins y temas lo hace cualquiera, pero gestionar un wordpress adecuadamente no, y esa es la diferencia y yo creo que aquí nadie quiere limitarse a instalar plugins, lo que quiere es un producto de calidad y aquí lo que buscamos es ese producto de calidad.

El capítulo de hoy no ha sido muy técnico, sino más bien una recomendación de forma de trabajar, que a veces es tan importante o más que saber hacer las cosas en si.

Como siempre muchas gracias por estar ahí en cada capítulo y recordad que os podéis suscribir al podcast tanto con el RSS o por cualquiera de las plataformas que distribuyen este podcast como Ivoox, iTunes, etc…

Un placer y hasta el Jueves en el siguiente capítulo de RadioWordpress

Enlaces:

Cabecera del fichero de la plantilla:

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos y bienvenidos a RadioWordpress, un podcast dedicado a todos aquellos que de una manera o de otra convivimos a diario con WordPress.

Mi nombre es Eduardo y hoy os traigo el capítulo 20. La verdad es que estoy muy contento pues es una barrera psicológica muy interesante, capítulo 20, la verdad es que suena muy bien.

En estos 20 primeros capítulos hemos hablado desde cosas muy sencillitas como cómo instalar WordPress correctamente y con un mínimo de dignidad hasta hoy por ejemplo que os voy a contar como crear plantillas específicas para vuestras páginas en WordPress.

Ya llevamos poco más de dos meses juntos y yo creo que ya tenemos diferenciado este podcast de otros que hay sobre WordPress, la idea era crear un podcast para usuarios avanzados de WordPress y creo que poco a poco la cosas se va situando ahí.

Veréis, cuando empecé a publicar audios, el pasado 29 de Noviembre de 2016 lo hice porque no encontré podcasts sobre WordPress que cubrieran aspectos muy técnicos, aunque tengo que decir que hay podcasts de WordPress muy buenos y en Español que yo mismo sigo como son WordPress Semanal, WordPress Radio, Dinamización Tecnológica y WordPress y WordPress Diario, al menos estos son los que yo sigo en español y cada uno de ellos ofrece una visión muy buena, pero diferente del Mundo de WordPress y personalmente creo que todos son necesarios ya que cada uno aporta un angulo distinto que nos enriquece a todos, desde luego.

Pues eso que muchísimas gracias por haber estado aquí durante estos capítulos. No voy a marear más la perdiz y vamos a empezar con el capítulo de hoy que lo he llamado «Crear nuevas plantillas de página», en WordPress obivamente, así que vamos allá.

—MUSICA—

Seguramente os hayáis fijado todos que cuando le dais a crear o editar una página en vuestro WordPress en la columna de la derecha hay un cuadrado que pone atributos de página y dentro pone Plantilla con un desplegable, si es que tenéis más de una plantilla.

¿Qué es eso?, pues no es más que la selección de la plantilla para las páginas de vuestro WordPress. Por defecto en muchos temas tenemos plantillas para eliminar la barra lateral, o para cambiar la barra lateral de lado, eso es lo más común, pero podemos tener una plantilla específica para algún tipo de página.

En el último capítulo, el 19, hablamos de la jerarquía de las plantillas, pero ojo, eso sirve para los posts, las páginas de archivo, de autores, etc…, en definiva para los posts y todas aquellas páginas que se generan de forma automática, pero para modificar una plantilla de una página generada manualmente lo que podemos hacer es crear una plantilla y seleccionarla en el momento de crear la página.

—MUSICA—

Para crear estas plantillas tenemos que crear un directorio llamado page-templates dentro del directorio del tema, o del child theme, es en ese directorio donde crearemos las plantillas para nuestras páginas.

Ahora que ya tenemos creado el directorio ¿cómo creamos las plantillas? ¿qué hacemos?. Pues bien, lo primero que tenemos que hacer es crear el fichero del la plantilla, para ello iremos al directorio page-templates y crearemos el fichero, por ejemplo plantilla-pagina-audio.php y dentro del fichero abriremos la etiqueta de php y abriremos cometario multilinea, en la segunda línea pondremos Template Name: y el nombre de la plantilla, luego cerraremos el comentario multilínea.

Genial, pero claro, tendremos que poner algo más, así que tendremos que copiar el contenido de la plantilla que se esté usando en ese momento para hacer ahí las modificaciones, lo habitual será que tengamos que modificar page.php, pero si no estamos totalmente seguros de eso lo que podemos hacer es instalarnos un plugin que nos indique qué plantilla usa la página y abrirla, el plugin nos dirá qué plantilla es.

Los plugins que hacen esto son Show Current Template, Current Template File y Reveal Template, en las notas del programa tenéis los enlaces correspondientes, como siempre.

Una vez tengamos localizada la plantilla que estemos usando abriremos ese fichero con un editor de textos y copiaremos desde el final del comentario de la cabecera hasta el final y pondremos ese contenido en el fichero que acabamos de crear, con eso ya tendríamos exactamente lo mismo que teníamos, pero en una plantilla diferente.

Ahora podemos editar esa plantilla y ya lo tendríamos

—MUSICA—

Ya veis, además de modificarse el css también se pueden modificar las plantillas tanto de los posts como de las páginas, por supuesto también las automáticas, una maravilla, WordPress nos permite hacer todo esto sin sufrir, pero como siempre os digo, hay que ser muy ordenado, sobre todo mentalmente para que todo esto funcione correctamente.

Hoy vemos un poco las tripas a las plantillas de WordPress. En el desarrollo de plantillas en WordPress tenemos que tener en cuenta la jerarquía en los ficheros de las plantillas.

Las plantillas no están compuestas de ficheros aleatorios, cada fichero tiene su propia utilidad y en cada fichero podemos personalizar cosas diferentes.

Siguiendo esto todo será muchísimo más fácil.

Documentación oficial: https://developer.wordpress.org/themes/basics/template-hierarchy/

Esquema interactivo: https://wphierarchy.com/

Os dejo aquí el esquema hablado en el podcast de hoy.

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos, mi nombre es Eduardo, esto es el podcast RadioWordpress que podéis encontrar en eduardocollado.com y hoy vamos a hablar de la jerarquía de plantillas en WordPress. Vamos a hablar de las tripas de los temas, los themes, porque los ficheros de los temas en WordPress no se situan al azar, cada uno de ellos está meticulosamente pensado y ocupa un lugar perfectamente definido, mucha gente no lo sabe, pero gran parte del éxito de WordPress recae en el desarrollo de plantillas, y se nota que WordPress cuida mucho de ello, pues la definición de lo que hace cada fichero está meticulosamente definido.

Si tenéis curiosidad de conocer como se estructuran los ficheros de las plantillas en WordPress para entender mejor como funciona, o porque queréis desarrollar vuestra propia plantilla o tema, quedaros un ratito conmigo que vamos a haber justamente de eso.

—MUSICA—

Existe una jerarquía claramente definida para los ficheros de las plantillas en WordPress, la cual viene definida en wphierarchy.com.

En esa jerarquía se definen los ficheros que tienen que responder ante cualquier tipo de página, por ejemplo, entramos en una página de un wordpress, lo primero que veremos es qué es una página de archivo, seguiremos a la derecha y veremos que se trata de una página de archivo de categoría, y veremos si tenemos un category.php, si no lo tenemos entonces miraremos si tenemos un archive.php, si lo tenemos mostraremos ese archivo.

Ahora imaginemos que queremos que en el caso que se muestre una categoría específica la plantilla sea diferente, entonces podremos usar una página intermedia llamada category-$id.php, así pues si tenemos la categoría con ID 104 que tiene que tener otra plantilla o que hay que modificar esa página en concreto podemos crear una página específica para ella, a esa plantilla la llamaremos category-104.php.

En el caso en el que no exista ninguna de las plantillas por defecto se devolverá el index, de esta manera siempre se devuelve algo.

Pues bien, esta jerarquía es la que viene definida en el wphierarchy.com.

—MUSICA—

En las notas del programa en eduardocollado.com os dejo los enlaces para que os podáis bajar el esquema, el cual os recomiendo imprimir y tener siempre delante de vuestro puesto de trabajo si es que trabajáis con WordPress ya que os va a ahorrar muchísimas horas de trabajo.

Modificar el aspecto de un WordPress es bastante fácil si seguimos las recomendaciones y si conocemos este tipo de cosas ya que no nos dedicamos a modificar ficheros a lo loco, sino que sabemos exactamente qué modificar.

Por ejemplo, vamos a suponer que queremos que cuando se pinche en la categoría podcast de un wordpress salga el reproductor de audio del podcast arriba, cosa que os tengo que decir que he probado, pero que no me ha gustado como queda, pero como ejercicio es bueno, así que creamos el fichero category-podcast.php, donde podcast es el slug de la categoría (el slug es la abreviatura que ponemos al crear la categoría) y le ponemos en la parte superior el player.

Esto va a hacer que cada vez que se cargue la página de esa categoría salga el player, pero sólo y exclusivamente en esa categoría y no en las demás.

Esto nos permite un nivel de personalización enorme de una forma muy sencilla. Por supuesto para hacer esto es muy importante estar haciéndolo o en un tema nuestro o en un child theme porque si no vamos a perder muchísimas horas de trabajo si hay una actualización.

—MUSICA—

De esta manera los child themes se pueden complicar hasta el infinito, es lo que tiene poder personalizarlos también hasta el infinito.

[/showhide]

Hoy vamos a hablar de cómo modificar el CSS de un child-theme, realmente es algo bastante fácil que nos va a permitir cambiar la apariencia de nuestra web en pasos sencillos.

En nuestro ejemplo nos vamos a basar en el inspector de Chrome y vamos a utilizar la plantilla de child-theme creada el lunes.

Recordad que os dejo la transcipción completo del audio por si queréis revisarla, para ello pinchar abajo donde pone «Ver transcripción».

Pantallazo de edición de CSS con el inspector de Chrome

Fichero style.css del child-theme

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos, yo soy Eduardo, esto es RadioWorpdress y ya no estamos en radiowordpress.com, hemos cambiado de dominio a eduardocollado.com, os cuento.

El otro día Jorge, un oyente del podcast me mandó un correo en el que me comentó que parece ser que WordPress tiene unas restricciones en cuanto al nombre de dominio a utilizar, y te sugieren no usar la palabra wordpress en el dominio porque tienen la marca reservada y bueno, no te dicen que te vayan a denunciar, pero a buen entendedor pocas palabras.

No se qué validez tendrá eso en España, intuyo que poca, pero el dominio es un .com, con lo cual es un dominio americano y he optado por hacer una transición ordenada de dominio antes de que a alguien se le ocurra decirle al ICANN alguna cosa extraña y me pudieran bloquear.

Realmente este podcast no me da un duro, por lo que no me merece la pena dedicar esfuerzos a algo que no sea generar contenido que creo que es lo que tengo que hacer.

Y no lo he dicho, pero el podcast ahora estará en eduardocollado.com, donde podréis ver el reproductor directamente en la página principal y además en la barra lateral, la que está en la izquierda si pincháis en RadioWordpress tendréis ahí los programas.

Bueno, vamos a lo que nos ocupa hoy que es la modificación del css en un Child Theme, un tema muy chulo y bastante rápido, así que vamos a ello.

—MUSICA—

Para editar el CSS de un child theme lo primero que vamos a necesitar es un navegador que tenga la opción de inspeccionar código, en mi caso uso para este fin Chrome.

Por supuesto tenemos que tener un child theme, podéis probar crearlo a partir de twentyseventeen. Para ello recordad que simplemente es crear un directorio nuevo en el directorio wp-content/themes con el nombre que queráis, por ejemplo twentyseventeen-child.

En ese nuevo directorio lo único que tenéis que hacer es crear el style.css con las instrucciones que os di en el programa del Lunes, con las líneas de comentarios que daban información sobre el child theme. Y luego hacer el import del style.css original o copiarlo, como prefiráis.

Bien, con esto tenemos ya el child-theme creado y podemos empezar

—MUSICA—

Vamos a abrir nuestro WordPress con el tema twentyseventeen y vamos cofigurarlo sin imágenes de cabecera.

Ahora lo que vamos a hacer es con el botón derecho del chrome seleccionar en la parte superior de la columna de la derecha, la estrecha y le daremos a inspeccionar, con el botón derecho.

Aquí chrome nos va a abrir la ventana de inspección, es difícil explicarlo con un audio, pero lo notaréis porque os abrirá la pantalla de inspección, os dejo un pantallazo en las notas del programa en eduardocollado.com en el capítulo titulado «RadioWordpress #18: Modificar CSS en un Child Theme»

Ahí tenéis que buscar width: 36%, ese es el valor que queremos modificar y vamos a modificarlo por 21% para hacer esa columna más estrecha, luego haremos la de la izquierda más ancha.

Ahora tendréis que copiar el contenido del bloque completo en vuestro style.css,

Fijaros que Chrome no pone las llaves necesarias, así que tendréis que añadir las llaves del @media, tanto la de abrir como la de cerrar.

En las notas del programa os dejo el ejemplo concreto para que podáis verlo.

En el caso de la columna de la izquierda haremos lo propio y cambiaremos el tamaño a 73%, de esta manera conseguiremos que nuestra columna de la izquierda sea más ancha.

—MUSICA—

En definitiva, aquí lo importante a entender es que podemos sobreescribir el CSS inicial con las modificaciones del CSS nuevo que estamos escribiendo.

Si este código lo hubiéramos escrito en el personalizador del tema habría funcionado igual, pero el código en vez de estar en un style.css estaría en base de datos, lo cual es un poco asquerosito, la verdad.

Mirar en las notas del programa en eduardocollado.com en el capítulo titulado «RadioWordpress #18: Modificar CSS en un Child Theme» que tenéis el ejemplo escrito y es muy visual.

Hoy vamos a descansar un poco de seguridad y vamos a empezar a ver los Child Themes.

Hay veces en las que queremos hacer un cambio en un tema, ya sea un css o en el functions.php o donde sea, pero hacer ese cambio directamente en la plantilla implica que en la próxima actualización del tema vamos a perder esos cambios, lo cual hace muy compleja la gestión de cambios.

Para evitar eso se han inventado los child themes, que son temas dependientes de otros, los padres o parent, y que añaden funcionalidades o hacen modificaciones sobre el tema padre, de forma que nos cubrimos ante posibles actualizaciones del tema padre.

Cabecera fichero style.css (en negrita campos obligatorios)

Opción para incluir el contenido del style.css del tema padre en el child theme

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos, esto es Radio WordPress.com, un podcast dedicado a todos aquellos que de una manera u otra convivimos con WordPress.

Hoy vamos a descansar un poco de seguridad y vamos a introducir a los child themes, ¿qué son? ¿para qué sirven? ¿qué nos hace falta? ¿cómo se montan? etc

A modo de introducción os diré que cualquier cambio que hagáis en una plantilla en el momento en el que se actualice lo perderéis y obviamente no es la idea, esa esa una de las ventajas que nos ofrecen los child themes, el modificar temas con la seguridad que una actualización no lo machacará.

Pero no os caliento más la cabeza y vamos a empezar con los child themes.

—MUSICA—

Lo primero que tenéis que saber si queréis trabajar con child themes es que es necesario que tengáis una buen manejo de WordPress, así como un html y css básico, no hace falta ser gurús, pero sí saber qué es y como funciona, eso es fundamental.

Otra cosa que vais a necesitar, es un editor de texto, a ver, es muy obvio esto, pero no uséis un bloc de notas, tenéis opciones mucho más inteligentes como Sublime Text o Atom que os van a ayudar muchísimo en vuestros desarrollos

Y por supuesto que tengamos un entorno de desarollo, de pruebas, es decir, otro worpdress donde podamos probar los cambios antes de aplicarlos en el site definitivo, no es necesario que esté en un servidor, podéis tenerlo en vuestro propio PC, no hay problema, ya os lo he comentado varias veces, pero los experimentos con gaseosa.

El entorno de desarrollo obviamente debe de tener contenido, así que lo más fácil es exportar el contenido de la web principal a la de desarrollo para que sean exactamente iguales.

—MUSICA—

Cuando tenemos un tema que realmente nos gusta, pero que requiere alguna modificación, para adaptar algún CSS o para cambiar alguna plantilla tenemos la opción de clonar el tema completo, o crear child themes.

Clonar el tema completo nos va a obligar a actualizar los cambios que se vayan realizando y a mantenerlo totalmente, lo cual al final es un trabajo innecesario por completo.

Sin embargo los child themes son algo maravilloso, porque se ejecutan sobre el tema que nos gusta y es ahí donde se aplican los cambios que necesesitamos, por ejemplo si el tema dice que el título H3 es azul, pero nosotros lo queremos marrón modificaremos el css del child theme dicen que ahora es marrón. En el tema original seguirá siendo azul, pero como el child theme se ejecutará al final se sobreescribirá el marrón y a los efectos de nuestra web habremos cambiado el color del H3.

Realmente se puede hacer un child theme de cualquier tema en WordPress, lo que pasa es que con unos va a ser más facil y con otros más difícil, si vais a crear vuestro primer child theme os recomiendo usar los temas que vienen por defecto en wordpress, aunque ya os digo, si ya tenéis elegido el tema que queréis lo único es que a lo mejor os va a costar un poquito más, pero adelante, sin miedo.

—MUSICA—

Bien, vamos a empezar a crear nuestro Child Theme, para ello iremos a nuestro directorio de temas en wordpress, recordad que es el wp-content/themes y ahí crearemos un directorio donde pondremos nuestro child theme.

Si seguimos las recomendaciones el directorio se llamará igual que el directorio que contenga el directorio padre, pero terminado en guión child.

Por ejemplo si vamos a crear un child theme del tema twentyseventeen el directorio se puede llamar twentyseventeen-child, así de fácil.

Ahora una vez creado para empezar sólo tenemos que crear un fichero, el style.css, en singular y en ese fichero pondremos uno comentarios que van a decir lo siguiente:

En las notas del programa os dejo la cabecera, pero os comento, realmente tenemos dos líneas obligatorias, que son el

Theme Name: nombre del tema

que nos va decir el nombre del child theme, el nombre que nos va a aparecer en Wordspress en la sección de temas

El otro parámetro obligatorio es

Templante: nombre del directorio que contiene el parent theme, el tema padre

Eso hará que en nuestra sección de temas nos diga que el tema este es hijo del que está en el otro directorio.

Estas dos líneas van comentadas, es decir entre dos líneas, la primera /* y la última */

—MUSICA—

Pero hay otros campos que son opcionales y que es interesante ponerlos y que son

Este nos dice cual es la URL del tema, desde donde se puede bajar básicamente

Description: Un tema hizo de twentyseventeen

Una descripción para que se pueda saber más sobre el tema, es un campo libre

Author: Eduardo Collado

El nombre del autor

Author URI: https://www.eduardocollado.com

La URL del autor, donde se le puede localizar.

Y si ya queréis dejarlo niquelado os recomiendo que subáis un pantallazo del tema llamado screenshot.png para que podáis mostrar el tema de forma visual en vuestra sección de temas de WordPress.

Una vez tengáis todo esto ya tenéis creado el tema hijo, el child theme, pero si váis al tema y lo activáis veréis que sale como si no tuviera CSS alguno, es normal, para solucionar eso lo único que tenéis que hacer es ir al fichero style.css original y copiar todo lo que esté debajo de la cabecera, es decir, después del */ y ya lo tendréis funcionando, cualquier cambio que queráis hacer ya lo podéis hacer aquí sin miedo a que pase nada ni a que se pierdan los cambios.

Otra opción es simpelmente importar el fichero css del tema padre con

@import url(«../tema_padre/style.css»)

Lo recomendable es copiar el fichero entero en vez de hacer el import, pero a mi personalmente me resulta mucho más cómodo hacer el import, aunque si hay alguna actualización pierdo el control, ahí cada uno tiene que evalutar qué prefiere.

[/showhide]

La seguridad de WordPress es mucho más que WordPress, a veces es necesario tocar cosas que no se pueden tocar desde nuestro panel del WordPress.

Plugin Akismet: https://akismet.com/wordpress/

Plugin WordPress Zero Spam: https://es.wordpress.org/plugins/zero-spam/

Plugin Stop Spammers Spam Prevention: https://es.wordpress.org/plugins/stop-spammer-registrations-plugin/

Plugin Disqus Comment System: https://es.wordpress.org/plugins/disqus-comment-system/

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos, esto es Radio WordPress.com, un podcast dedicado a todos aquellos que de una manera u otra convivimos con WordPress.

Mi nombre es Eduardo Collado, este es el capítulo 16 y hoy vamos a tratar un tema cotidiano que todos conocemos y odiamos, el spam en nuestro WordPress .

El spam de comentarios puede llegar a ser un infierno, bueno, realmente hubo un momento en el que era un infierno, pero los tiempos han avanzado y hoy en día el que tiene problemas con el spam es básicamente por que quiere porque a día de hoy tenemos varias opciones muy buenas todas.

Así que vamos a pasar a hablar del spam en WordPress de la mano de los Monty Python, ¿habéis visto el vídeo?, bueno, os dejo unos segundos del audio y empezamos.

—MÚSICA SPAM—

Hay pocas cosas más frutrantes que los comentarios de spam en los WordPress, pero por suerte hay forma de evitarlos, de bloquearlos.

La forma más primitiva sería la de decirle a WordPress que sólo se van a publicar los comentarios aprobados previamente, realmente era así al principio, era la única forma y era un infierno porque teníamos cientos de comentarios para moderar de forma diaria, ya os digo un infierno.

Pero no vamos a centrarnos en temas históricos y vamos a ir al día de hoy. Para solucionar el tema del spam tenemos que para por plugins, no hay otra, o eso o deshabilitar los comentarios en Worpdress, que es otra opción, la abstinencia de comentarios también hace que no tengamos spam en nuestros WordPress.

El plugin más famoso y conocido mundialmente es Akismet, un plugin desarrollado por Automattic, que es la empresa de WordPress.com, así que se le presupone una calidad espasmosa, yo mismo lo he estado usando muchísimo tiempo.

El funcionamiento es simple, pero antes de ponerlo a funcionar tienes que darte de alta en la web del plugin, en https://akismet.com/wordpress, el enlace ya sabéis, como siempre os lo dejo en las notas del programa en radiowordpress.com, como este es el capítulo 16 lo único que tenéis que hacer es escribir en el buscador #16 y os saldrá el capítulo.

En la web del plugin lo que tenéis que hacer es daros de alta con vuestra contraseña de WordPress.com y conseguir la clave de api para vuestro WordPress, por supuesto tenéis la opción gratuita y luego otras más avanzadas, pero lo normal es que con la opción gratuita tengáis suficiente, de hecho no conozco a nadie que utilice una de las opciones de pago.

Una vez tengáis el api y hayáis registrado vuestro WordPress en la web de Akismet y apodéis empezar a utilizar el antispam en vuestro WordPress, no tiene más complicación.

Este plugin nos sacará unas estadísticas de los comentarios bloqueados, etc, realmente es el más utilizado y es por algo.

—MUSICA—

Pero puede ser que por alguna razón no queráis utilizar el plugin Akismet, tal vez no queráis que Automattic tenga más datos vuestros o simplemente porque no os guste por culquier otro motivo.

En ese caso tenemos más plugins, claro que sí, en concreto tenéis dos más y el último que me lo reservo para el final.

En cuanto a plugins como tales tenemos WordPress Zero Spam y Stop Spammers Spam Prevention, ambos plugins gozan de una buena reputación dentro de la comunidad Worpdress, sin embargo el primero según sus notas es funcional hasta la versión 4.6.2 y el segundo hasta la versión 4.5-alpha, en mi caso tengo la versión 4.7.1 funcionando en el momento de la grabación del audio, en principio no debería de haber problema, pero como ya comentamos en capítulos anteriores es importante ver las actualizaciones. De todos modos no tengáis demasiados reparos en utilizar cualquier de estos dos si no queréis o podéis usar la solución de Automattic. En las notas del programa os dejo los enlaces.

—MUSICA—

Sin embargo mi opción favorita a modo personal no es ninguna de estas tres aquí propuestas sino utilizar un gestor de comentarios externos, en mi caso disqus, el cual se integra de maravilla con Worpdress y tiene un panel centralizado donde podréis gestionar todos los comentarios de vuestros sitios, a mi me resulta muy cómodo, además es muy bonito.

Disqus deshabilita los comentarios de WordPress tradicionales y en su lugar pone su propio formulario, así que vosotros os olvidáis de eso.

La instalación de Disqus requiere que tengáis una cuenta en el servicio disqus y que instaléis el plugin de disqus llamado Disqus Comment System y seguir los pasos que nos indican.

De todos modos es interesante configurar en la web de disqus nuestro formulario en el idioma que queramos e indicar si lo queremos claro u oscuro, etc.., tiene pocas opciones de configuración y son muy intuitivas, así que no vamos a repasarlas todas aquí.

—MUSICA—

Bueno, esto es todo por hoy, como veis el problema del spam en los comentarios de WordPress es fácilmente solicionable, dos opciones principales, Akismet o Disqus, que cada uno elija la que más le guste o la que más se adapte a sus necesidades.

Nos vemos el lunes

[/showhide]

Hoy hablamos de seguridad avanzada, pero no de plugins, no, hablamos de WordPress, de cómo limitar el acceso al fichero wp-config.php, de las claves de autenticación de WordPress, del prefijo de las tablas, de cómo evitar el listado de ficheros desde apache y de cómo bloquear el debug de php y los mensajes de error.

El capítulo de hoy es bastante completo y de hecho se me ha ido de tiempo, es un poco más largo, pero os recomiendo que lo escuchéis y que pongáis en práctica lo que aquí os cuento, os va a ayudar mucho y os va a hacer la vida mucho más fácil.

CÓDIGO PARA EL .HTACCESS PARA BLOQUEAR EL LISTADO DE FICHEROS

Options -Indexes

CÓDIGO PARA EL .HTACCESS PARA BLOQUEAR EL ACCESO AL wp-config.php

COMPROBAR QUE ESTÁN DESACTIVCADOS LOS ERRORES DE PHP EN EL FICHERO .htaccess

define(‘WP_DEBUG’, false);

Generador de Claves de WordPress: https://api.wordpress.org/secret-key/1.1/salt/

[showhide type=»transcripcion» more_text=»Ver transcripción(%s más palabras)» less_text=»Esconder transcripción (%s menos palabras)»]

Hola a todos, esto es Radio WordPress.com, un podcast dedicado a todos aquellos que de una manera u otra convivimos con WordPress.

Mi nombre es Eduardo Collado, este es el capítulo 15 y hoy 16 de Enero de 2017 vamos a hablar sobre la configuración avanzada de WordPress para hacerle mucho más seguro.

La seguridad de WordPress comienza por WordPress, si no aseguramos Worpdress como debe de ser no habrá plugin que nos pueda ayudar.

En serio, no comprendo esa obsesión de mucha gente de poner plugins de seguridad, que los recomienden por todas partes pero que no recomienden asegurar el WordPress.

Realmente he estado pensado mucho en ello, no os creáis, y he llegado a la conclusión de que mucha gente simplemente no sabe cómo asegurar Worpdress mínimamente, por eso es tan importante el capítulo de hoy porque vamos a tratar ese tema, vamos a saber un poco más y vamos a poder asegurar un WordPress ya de una forma más avanzada de la que vimos el otro día.

—MÚSICA—

Vamos a empezar protegiendo nuestro fichero wp-config.php. Recordad que en este fichero guardamos cosas tan importantes como nuestro usuario y contraseña de base de datos y es sumamente importante protegerlo y no dejarlo ahí abandonado tal y como viene por defecto.

Este fichero ya sabéis que está en el raíz de nuestro WordPress.

Para proteger el acceso a este fichero podemos hacerlo de dos formas, ojo, no tienen por qué ser excluyentes sino que podemos compaginarlas.

La primera será modificando los permisos en nuestro servidor y la segunda modificando nuestro fichero .htaccess para que no sea accesible desde el exterior, lo ideal es usar las dos técnicas para protegerlo.

Los permisos de nuestros ficheros deberían de ser 644, es decir el propietario del fichero, el WordPress puede leer y escribir en el fichero y el resto sólo pueden leerlo.

Esto significa que si usáis un buen hosting cada web se ejecutará con un usuario diferente, como en Neodigit, pero cuiado, hay muchos sitios donde las webs las ejecuta el usuario de apache, y esto significará que se podría leer el fichero desde cualquier web del servidor, así que enteraros de cómo funciona el tema de permisos en vuestro hosting y si todas las webs se ejecutan con el mismo usuario salir de ahí corriendo, no perdáis el tiempo.

Los directorios tendrán permisos 755 ya que para entrar en un directorio es necesario ejecutarlo.

Ni que decir tiene que esa manía de poner a los ficheros permisos 777 es lo equivalente a pegarse un tiro en el pie, eso no lo hagáis nunca.

La protección por htaccess podemos hacerla con una directiva deny from all, os la dejo en las notas del programa, pero básicamente será:

Este código se introducirá siempre antes de cualquier línea del htaccess de WordPress.

—MÚSICA—

Otro tema interesante que se puede hacer es usar las Claves únicas de autentificación, las cuales se configuran en el wp-config.php. Estas claves se pueden configurar y cambiar tantas veces como queráis gracias al configurador de WordPress, os dejo el enlace en las notas del programa.

Es bueno que uséis esas claves, y de hecho es muy probable que ya lo tengáis configurado pues se configuran autómaticamente, pero si no lo tenéis configuerado hacerlo a mano, eso os permitirá que vuestros usuarios logados estén mucho más seguros.

—MÚSICA—

Otra de las cosas que podéis hacer es definir un prefijo en la base de datos único, tal y como comentamos ya en el tercer capítulo del podcast cuando os pedí que fuerais imaginativos en ese punto, que pusierais algo aleatorio.

Por defecto ese prefijo es wp_, pero claro, todo el Mundo sabe cual es el prefijo por defecto, así cualquiera que consiga un accceso a nuestro wordpress y puede hacer peticiones a la base de datos si pregunta por la tabla wp_options podrá ver cosas, sin embargo, si hemos usado otro prefijo se encontrará perdido y no podrá consultar pues no conocerá el nombre de la tabla.

Por supuesto el mejor sitio para configurar los prefijos es en el momento de instalar, pero si lo queréis cambiar luego ya no es tan sencillo y puede llevarnos horas y muchos momentos de frustración, así que acordaros de cambiarlo en el momento de la instalación, siempre.

Otra cosa que tenemos que comprobar es que nuestro hosting no nos permita el listado de ficheros, es decir, si ponemos dominio/wp-content que no nos muestre el listado de ficheros. Si nuestro hosting permite mostrar los ficheros de un directorio podéis simplemente indicar en el htaccess

Options -Indexes

Obviemente esto no es la solución, sino arreglarlo a nivel de servidor, pero como parche os puede servir

—MÚSICA—

WordPress tiene un par de cosas que no son necesariamente buenas, una es el mostar los mensajes de error, los cuales muestran información tal como el path absoluto dentro del servidor etc.. por defecto viene desactivado, pero no es mala idea asegurarnos que está desactivado comprobando en el wp-config.php que es así

define(‘WP_DEBUG’, false);

[/showhide]