Para empezar, un shell-script no es más que un pequeño programa a base de los propios “comandos” de linux y algún recurso más típico de programación como los bucles, o las sentencias de comparación. Es algo parecido a los batch de Microsoft pero muchísimo más potente.

Para empezar, al igual que en Windows o MS-DOS los ficheros batch tenían la extensión “.bat”, en Linux, aunque esto es absolutamente prescindible, se suele asociar la extensión “.sh” a los bash-script.

Estos archivos son simplemente ficheros de texto con todos los comandos que vayamos a ejecutar. Por lo tanto usaremos un editor de textos para crearlo. En este ejemplo usaremos nano, ya que lo hemos utilizado en otros ejemplos por su sencillez.

Crearemos un archivo llamado backup.sh. Para ello tecleamos

nano backup.sh

y ya estaremos en condición de empezar nuestro primer y muy simple bash-script.

Todos empiezan indicando donde se encuentra el ejecutable de nuestro tipo de shell. Como queremos que este pequeño script sirva para poder hacer el backup en el servidor de nuestro proveedor de internet, habrá que saber que tipo de shell están usando allí. Esto solo será posible si tenemos acceso por SSH, como es mi caso. Una vez que hayamos entrado en nuestro servidor tecleamos:

echo $SHELL

Y nos responderá dónde se encuentra, y por ende el tipo. En mi caso la salida a ese comando es:

/bin/bash

Esto me dice que estoy usando bash como shell, porque el ejecutable se encuentra en /bin/bash. Como ya sabemos donde se encuentra nuestro shell escribiremos la primera línea de nuestro shell-script que será:

#!/bin/bash

A continuación copiaremos todos los archivos de WordPress a un directorio que llamaremos backup. Para hacer esto escribiremos lo siguiente en nuestro archivo

mkdir backup
cp -R wp* ./backup
cp *.php ./backup
cp .* ./backup
cp *.text ./backup
cp *.ht* ./backup

Con la primera línea creamos el directorio backup. La segunda copia todos los archivos y directorios que comienzen por “wp”. Sin embargo como existen algunos ficheros de WordPress que no comienzan por “wp” y nos interesan, con la tercera línea copiamos todos los archivos “php” a nuestro directorio de copia de seguridad.

Como aún nos interesan copiar algunos tipos de fichero que no están contemplados en las líneas anteriores, usaremos la cuarta línea para copiar todos los archivos ocultos (en linux son los que empiezan por “.”). Fundamentalmente es .htaccess, que es un archivo que se usa para configurar en cierto modo Apache, y del cual hace uso wordpress.

En la quinta y sexta línea copiamos los ficheros de texto y html que suele crear wordpress en su instalación. Son completamente prescindibles, pero no obstante los copiaremos.

Guardamos (Control + O) y salimos (Control + X). Este archivo tiene que estar al nivel en el que se encuentran el resto de los archivos principales de worpdress como el “index.php”.

Ahora habrá que hacer que este archivo sea “ejecutable”. Para ello usamos el comando chmod, haciendo “ejecutable” con la opción +x el archivo backup.sh, es decir ejecutaremos la siguiente orden.

chmod +x backup.sh

Ya tan sólo nos queda ejecutarlo. Y esto se hace de la siguiente forma:

./backup.sh

No olvidéis el “./” del comienzo, sino no os funcionará.

Obviamente esto es mejorable en múltiples aspectos, no es más que un pequeño ejemplo de un primer shell-script que además nos sirva de algo. Aún nos quedaría hacer una copia de la base de datos y controlar
múltiples aspectos de dicha copia, pero podría servir de base.

Saludos.

Pues bien, al poco de comenzar me di cuenta que mi estimado Firefox no me mostraba la última versión del blog sino forzaba un refresco de la página.

Curiosamente Internet Explorer 8 si lo hacía correctamente. Comencé una búsqueda por Google y me encontré con esta página que me dio la solución.

Resumiendo un poco, el problema está a medias entre los navegadores y los ISP. La cuestión es que ambos suelen guardar una copia de la página que estás viendo. En los navegadores hay opciones más o menos accesibles donde puedes decirle que busque siempre una versión más moderna que la que tienes almacenada, como se muestra en la siguiente imágen para el Internet Explorer:

Para Firefox la cosa es más peliaguda, y podéis buscar en Google el literal “browser.cache.check_doc_frequency” para ver como modificar este comportamiento.

Tambien hay que tener en consideración que al variar estas opciones podréis tener más tráfico de internet y, además, muchas veces innecesario.

Obviamente esto no es solución porque no puedes obligar a todos los usarios a cambiar estos parámetros. Pero aunque así fuera, no puedes obviar las proxy-cache que algunos ISP implementan y que también podrían mostrarte una versión algo anterior de tu blog.

Por lo tanto el problema hay que arreglarlo entonces en el propio WordPress para que obligue al navegador a saltarse la versión que tiene en su cache y leerla directamente de tu blog.

Hay dos formas de hacer esto, pero ambas pasan por modificar el fichero “header.php” de tu tema.

La primera es introducir las siguiente líneas inmediatemente después de la declaración de la sescción “head”:

<meta http-equiv="Expires" content="Mon, 26 Jul 1997 05:00:00 GMT" />
<meta http-equiv="Pragma" content="no-cache" />

Con la primera línea le decimos al navegador que el contenido de la página expiró hace más de 10 años.

Con la segunda le decimos que no almacene en cache nuestra página.

¿Ya está solucionado?. No, ni mucho menos. Algunos navegadores pueden maliterpretar la segunda línea y guardar la página en determinados casos.

Por otro lado si tenemos una proxy-cache por medio, ésta no analiza la página, sino que la almacena, por lo que de todas formas la meterá en cache, con lo cual le seguiría dando una versión antigua de tu página independientemente de que tu navegador no la guardara.

Como solución final, el artículo nos propone añadir además las siguientes líneas justamente al comienzo de “header.php”:

<?php
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', FALSE);
header('Pragma: no-cache');
?>

Con esto conseguimos, en teoría en la práctica, que ni el navegador ni el proxy-cache almacenen la página. Así que si mañana, que es cuando este post saldrá, me actualiza bien la página con Firefox, a continuación veréis el resultado.

Por fín me actualiza bien la página