Los SSI (server-side includes, que se podría traducir como “inclusiones del lado del servidor” o algo así), se utilizan para introducir contenido dinámico en las páginas. Una breve línea inscrita en el código html, con una sintaxis especial, ordenará al servidor que ejecute una acción que modificará el contenido de la página.

Por regla general, los SSI sólo se pueden incluir en páginas que acaben con la extensión .shtml, a menos que el servidor esté configurado para aceptarlos también en páginas .html. De cualquier modo, infórmate sobre si tu servidor admite SSI, pues no todos (en particular los gratuitos) lo hacen.

Los tipos de comandos más utilizados son “include virtual” , “exec cgi” y “echo var”. Los del primer tipo se utilizan para incluir un contenido situado en otra página. “Exec cgi” sirve para ejecutar un script. “Echo var”, para mostrar informaciones procedentes del servidor, como la hora o el navegador utilizado por el visitante.

El código consta siempre de dos partes. La primera representa el tipo de acción a realizar, y la segunda el objeto de esa acción. Se sitúa entre , que indican el comienzo y el fin del código, similarmente a los comentarios.

Aquí sólo explicaremos el funcionamiento de “include virtual” y “exec cgi”, que son con mucho los más interesantes. Para “echo var” y otros tipos de SSI, puedes consultar (en inglés) esta página.

1. Comandos “include virtual”.- La primera parte del código es #include virtual, y la segunda, la ruta a un archivo entrecomillada. Por ejemplo, . Aquí le estamos diciendo al servidor que en el punto donde se encuentra este código nos incluya el contenido del documento “header.txt”, que se encuentra en el mismo nivel (en la misma carpeta) que la página actual. Si escribiéramos le ordenaríamos que incluyera el contenido de “header.txt”, que está en la carpeta “cabeceras”, situada en el mismo nivel de la página actual. Añadiendo ../ al comienzo de la ruta del archivo, le indicamos al servidor que suba un nivel desde la página actual para encontrar la carpeta y/o documento referenciados. La ruta puede ser relativa al directorio raíz, por ejemplo, . En este caso le estamos pidiendo al servidor que incluya en la página actual -hállese ésta en el nivel en que se halle- el contenido de “header.txt”, documento que se halla en la carpeta “cabeceras”, la cual se encuentra a su vez en el primer nivel del directorio raíz. Es el método más práctico.

Este tipo de comandos es útil, por ejemplo, para introducir en todas las páginas de un sitio web la misma cabecera y el mismo pie, que sólo tendríamos que escribir una vez. Y, de la misma manera, cuando quisiéramos modificarlos, sería suficiente con cambiar el código en esas dos páginas de cabecera y pie para que los cambios se aplicaran a todo el sitio.

También se puede emplear el comando “include” para mostrar los contenidos generados por un script, lo que nos evita tener que modificar el contenido html del script para adaptarlo al aspecto de nuestras páginas.

Supongamos que tenemos un script llamado weather.cgi, situado en la carpeta cgi-bin, cuya función es mostrar los datos meteorológicos de los aeropuertos. Supongamos igualmente que para activar el script necesitamos llamarlo con el navegador añadiendo el código del aeropuerto, de esta manera: http://www.misitio.com/cgi-bin/weather.cgi?clave=LTCC. Si el autor del script no ha previsto ningún código html específico, al introducir esa url nos aparecerán los datos “pelados”, en el cuerpo y el tipo de letra por defecto de nuestro navegador, sobre un fondo blanco. Para modificar su aspecto deberíamos incorporar al script el código html necesario, lo que puede ser un lío considerable.

Pero también podemos introducir en una página ya construida la línea . Veremos entonces que en ella aparecen los datos meteorológicos del aeropuerto LTCC, “envueltos” en el código html de la página y en las etiquetas específicas con que queramos “vestir” al SSI, por ejemplo, y , y , etc.

2. Comandos “exec cgi”.- La sintaxis es igual que en el caso anterior, pero sustituyendo “#include virtual” por “#exec cgi”. Este comando ordena al servidor que ejecute un script y que incluya los resultados de esa ejecución en el punto en que se halla el código. A diferencia del caso anterior, la variable no hay que añadirla a la ruta del script en la línea de código, sino a la url de la página .shtml. De esta manera, la misma página se mantiene “envolviendo” los resultados de cada ejecución del script.

Retomemos el ejemplo anterior para mostrar el funcionamiento de esta directiva. El comando “include virtual” requiere la ruta completa del script, más la variable que queramos activar. Para mostrar el tiempo en diez aeropuertos, deberemos, pues, incluir diez SSI, cada uno con la variable correspondiente. Utilizando “exec cgi”, sin embargo, nos bastará introducir sólo una vez el SSI.

Digamos que hemos llamado a la página donde tenemos el SSI “tiempo.shtml”. El código del SSI será simplemente . Para activar la ejecución, añadamos la variable antes mencionada a la url de la página, de esta manera: http://www.misitio.com/tiempo.shtml?clave=LTCC. Aparecerán los datos meteorológicos del aeropuerto LTCC. Si luego llamamos a la url http://www.misitio.com/tiempo.shtml?clave=RTSB, tendremos el tiempo correspondiente al aeropuerto RTSB. Para activar las diferentes urls podemos utilizar una serie de enlaces o emplear un formulario javascript que nos pida introducir el código del aeropuerto.

Si el script es de un tipo que se activa simplemente introduciendo en el navegador su url, sin necesidad de variables añadidas, muy posiblemente (dependiendo de las configuraciones del servidor) será lo mismo llamarlo con un comando del tipo “include virtual” que “exec cgi”.

Por último, conviene añadir que ambas directivas funcionan con cgis en Perl, pero en el caso de las páginas en PHP el caso es diferente. “Include virtual” funciona igual para mostrar el contenido de una página PHP (como de un archivo .html o .txt), pero “exec cgi” sólo activará un programa PHP si el servidor tiene instalada la versión cgi de este lenguaje. En caso contrario sólo podrás activar el programa desde otra página PHP, con las directivas correspondientes.

Mientras lleves poco tiempo con tu sitio, y el número de visitas que recibas no sea muy elevado, todo será paz y tranquilidad en tu casa. Pero espera unos meses, y comienza a alegrarte cuando los visitantes suban a 100 o 200 diarios, y las páginas servidas a 500, 1.000 o 2.000. Échale una mirada entonces a los registros (“logs”) del servidor, en concreto al de errores. De repente descubrirás que, donde antes sólo había el registro de los ocasionales errores causados por ti mismo al escribir mal un enlace o al configurar un script deficientemente, aparecen montones de mensajes que te cuentan que alguien ha intentado acceder a determinado archivo sin conseguirlo. El mensaje que verás más repetido refiere que no se ha encontrado un archivo llamado “robots.txt”. Un buen momento, pues, para crearlo.

Se trata simplemente de un archivo de texto plano cuyo objetivo es orientar a los indexadores automáticos (robots, spiders) sobre qué carpetas pueden indexar y cuáles no. El trabajo de estos robots, en principio, es positivo: nos evitan tener que andar por ahí dando manualmente de alta nuestros sitios en todos los buscadores. Google es uno de los ejemplos más conocidos. Pero no sólo indexan las páginas principales (“index”), sino todas las del sitio y, si nos descuidamos, hasta los listados de usuarios de los foros o de las listas de correo y las bases de datos vinculadas a nuestros scripts.

Para evitar que estos indexadores metan las narices en lo que no les importa es necesario incluir en el directorio raíz el documento robots.txt. Créalo con cualquier editor de texto simple, pero que permita guardar el archivo con los saltos de línea en formato Unix. O asegúrate, en todo caso, de que el programa FTP con que vayas a subir ese archivo al servidor hace automáticamente la correspondiente conversión. Escribe en él algo como esto:

User-agent: *
Disallow: /cgi-bin/
Disallow: /foro/
Disallow: /anuncios/

De esta manera estás diciendo a todos los robots (el * que sigue a “user-agent” indica “todos”) que no indexe tu directorio cgi-bin, ni el llamado “foro”, ni “anuncios”. Para evitar que indexe una página en concreto situada en el primer nivel del directorio público, escribe:

Disallow: paginatal.htm

Si quieres evitar el acceso de un robot en concreto, por ejemplo el de Google, escribe:

User-agent: googlebot

Y para impedir el acceso a todo tu sitio, pon simplemente:

Disallow: /

En el sitio SearchEngineWorld encontrarás un tutorial más detallado y otra información relacionada en inglés, y también un validador de archivos que te dirá si tu robots.txt está configurado correctamente. También te explicará la sintaxis de las etiquetas META destinadas a impedir que los robots indexen determinadas páginas, útiles cuando no se puede acceder al servidor para configurar un archivo robots.txt.

Pero también hay robots “malos”

Sin embargo, debemos ser conscientes de que no todos los robots van a hacer caso de esas instrucciones. En concreto, hay unas malditas “arañas” recolectoras de direcciones de email que están programadas para hacer caso omiso del contenido de robots.txt. Ellas van recogiendo todo lo que lleve en medio una @, y luego sus amos elaboran unas enormes listas de emails que venden a los spameros.

Quizás no podremos evitar que sigan buceando en nuestros servidores, pero cuando menos tenemos a nuestro alcance una pequeña venganza: regalarles con miles de direcciones falsas. Si sus bases de datos se contaminan, perderán valor ante los eventuales compradores y, al ocasionar aludes de rebotes en los servidores de emails anónimos (los que mayoritariamente utilizan los spameros), contribuiremos a combatir estas prácticas. Hay algunos cgis gratuitos que realizan esto, como Killspam, que hemos traducido y ofrecemos en la sección “Scripts”. Allí encontrarás información completa al respecto.

Código Libre es un proyecto surgido de la experiencia reunida por el gabinete 4Clics.com en el aprovechamiento de los recursos gratuitos generados por la amplia red de creadores de scripts. Su actividad ha generado un ingente fondo de programas de gran utilidad para los webmasters a la hora de dotar de contenido dinámico a los sitios y facilitar su gestión. Por desgracia, el material disponible en castellano es muy escaso, ya que la absoluta mayoría han sido realizados en inglés, y las traducciones corren a cargo de voluntarios que principalmente centran su atención en programas estrella, que pueden exceder las necesidades de los sitios de tipo mediano o pequeño.

Código Libre pretende compensar este vacío de traducciones aportando sus propias versiones de otros programas de menor proyección, aunque de similar calidad y de no menor utilidad para tareas específicas. Nuestro trabajo no ha consistido tan sólo en traducir, sino también en adaptar y revisar los códigos.

Junto a ello, presentamos otros servicios de interés para los webmasters como redireccionamiento de URLs, intercambio de banners y un espacio jurídico dedicado a difundir los problemas legales vinculados a la actividad de Internet. Asimismo se incluye una sección de tutoriales sobre aspectos no suficientemente popularizados de la construcción de sitios web y un índice de sitios y libros abierto a las aportaciones de nuestros visitantes.

Los scripts disponibles se encuentran reseñados en la sección “Scripts”, de donde se pueden descargar libremente. Los códigos se presentan en dos versiones: para ordenadores Macintosh (en formato comprimido .sit) y para el sistema operativo Windows (en formato .zip). Esto se ha hecho así para evitar los problemas derivados del diferente método de codificar los retornos de carro (linebreaks) en ambos sistemas, que puede ocasionar una corrupción del código al abrir un documento de texto creado en el otro sistema, y a causa de las distintas codificaciones de los caracteres especiales como los acentos y las “ñ”.

Requerimientos mínimos.– Para instalar y trabajar con scripts necesitas:

  1. Poder acceder a tu servidor vía FTP, y por tanto, una cierta familiaridad con las entretelas de los servidores y con los programas de este tipo: cómo otorgar permisiones (CHMOD), cómo subir archivos en formato ASCII/texto o binario, cómo se organizan los directorios de tu servidor, qué son las rutas del servidor y cómo conocerlas.
  2. Un servidor que admita el lenguaje PHP y el Perl. Asimismo, es muy recomendable que accepte SSI (server side includes).
  3. Disponer de un programa de edición de texto (no Word o cualquier otro que trabaje con texto formateado, sino SimpleText o BBEdit para Mac, y NotePad para Windows) por si te conviene echar una mirada a los códigos y cambiar alguna cosa.
  4. Dominar el inglés a un nivel elemental. Nuestras traducciones cubren todos los textos que se muestran al visitante de una web, los de administración y lo fundamental de las instrucciones para instalar los scripts, pero no obligatoriamente el contenido completo de éstas.
  5. Y por supuesto, dominar los elementos básicos del lenguaje HTML.

Condiciones de utilización.– Las exigencias de los creadores en cuanto a la utilización de sus scripts se ajustan aproximadamente a los principios de la OSI (Open Source Initiative, iniciativa del código abierto, cuyas características puedes consultar aquí, en inglés) o de la GNU General Public License (que puedes consultar aquí, en inglés).

Se trata en esencia de garantizar el uso, la redistribución y la modificación libres del software. El creador o creadores de un programa acostumbran a pedir que se respeten sus copyrights manteniendo los créditos situados al comienzo o al final de los códigos. Pueden solicitar también la inclusión de una referencia a su autoría en la página web que utiliza el script, junto a un enlace a su propio sitio. El uso gratuito del software se permite en unos casos con carácter general, y en otros sólo cuando la web que los emplea no tiene finalidades comerciales. Para todos estos detalles debes consultar las instrucciones de instalación o el encabezamiento de los scripts.

Por nuestra parte, sólo pedimos el mantenimiento de las referencias a nuestro trabajo de traductores y adaptadores en los encabezamientos de los códigos, aunque agradeceremos también un enlace a este sitio.

Aviso.– Dado el carácter gratuito de estos programas, ni sus creadores ni Código Libre se hacen responsables de las disfunciones o la ocasional pérdida de información provocada por su uso. Código Libre, por su parte, y aunque ha verificado el uso de los scripts reseñados, tampoco garantiza la absoluta inexistencia de errores ni en el código original ni en sus propias adaptaciones, cuya notificación, en todo caso, agradecerá vivamente.