Formularios con scripts CGI. correo.pl

(Es recomendable haber leído la entrada anterior respecto a FormMail, pues algunas cosas quedan explicadas allí).
Bien, es muy probable que aunque haya seguido los pasos para configurar FormMail este siga sin funcionar, que puede ser debido a múltiples causas, dado que hay muchas versiones y revisiones de este script y además puede haber errores de sintaxis que sean inalcanzables para alguien que no pertenece al mundillo de la informática.
En particular, yo prefiero una variante de este script, desarrollado por Americandominios. Se llama correo.pl y funciona a las mil maravillas. Es más sencillo de analizar. Puede descargarse una versión desde la sección documentos de la web de la escuela de arte de Talavera.
Viene como un fichero comprimido, con el script, con un formulario de ejemplo y con un PDF de ayuda para la configuración.
Esencialmente es parecido a FormMail, ya que está basado en él. Está también escrito en Perl y hay que modificar un par de líneas, como indica la ayuda. Tras subir el script a la carpeta cgi-bin, establecer los permisos y poner la línea en el formulario correspondiente a la acción, es de esperar que todo funcione correctamente.

Así, pues, las líneas modificadas en el fichero correo.pl quedan así:

@referers = qw(escueladeartetalavera.com 137.213.100.76 localhost);
@allow_mail_to = qw(info@escueladeartetalavera.com localhost);

(la ip en este caso es ficticia, debe reemplazarse por la suya como ya se explicó en el artículo anterior)

Y en el formulario, la etiqueta correspondiente quedaría:

[form action="http://www.escueladeartetalavera.com/cgi-bin/correo.pl" method="POST"]

(no olvide sustituir los corchetes si hace copia y pega).

Puede comprobar que funciona magníficamente.

Algunas precisiones respecto al formulario de ejemplo, que puede alterar según su gusto (fíjese al final del código):

[INPUT TYPE=hidden name="env_report" value="HTTP_USER_AGENT,REMOTE_ADDR">
[INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"]
[INPUT TYPE="hidden" NAME="subject" VALUE="Formulario enviado desde escueladeartetalavera.com "]
[INPUT TYPE="hidden" NAME="redirect" VALUE="http://www.escueladeartetalavera.com/confirmacion.htm"]


Fíjese en estos cuatro campos ocultos del formulario: en uno de ellos se establece el informe (report) del formulario. Entre esos datos está el navegador usado para gestionar el correo, así como la IP del que le rellenó el formulario (yo he eliminado el valor REMOTE_HOST, que hace referencia a la página principal de Americandominios).

El campo oculto [INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"] es imprescindible, al igual que en los formularios gestionados por FormMail, para que el formulario sepa donde dirigir el correo. Su contenido debe coincidir con la dirección de correo que se configuró en el script en el apartado @allow_mail_to.

El campo de nombre "subject" hace posible que establezca el asunto del correo. Yo he puesto uno genérico, "Formulario enviado desde ....", si bien puede gestionarse uno distinto con un campo de texto de entrada en el formulario, que se llame "subject" y donde el usuario pueda establecer su Asunto personalizado.
Y por último, se establece en el campo "redirect" dónde debe acabar el usuario tras haber mandado el formulario. Yo lo configuro a una página donde se confirma que se ha recibido el formulario correctamente pero que tiene el mismo aspecto de la página donde se rellenó, para que el usuario pueda seguir navegando desde el punto en que decidió mandar su consulta.

Todo esto puede verlo en acción desde la página contacto de la web de la escuela de arte de Talavera, donde además puede apreciar el diseño de campos y botones personalizados aplicando hojas de estilo CSS corrientes y molientes.

Por cierto, si observa, puede acceder a otro formulario de contactar con el webmaster. Sepa que el formulario de la consulta genérica está gestionado por el script correo.pl configurado manualmente y que el formulario de contacto con el webmaster usa el script FormMail. Puede comprobar que ambos funcionan sin problemas.

Artículos relacionados:

Gestionar formularios
Formulario básico de correo
scripts CGI. FormMail
FormMail compat

Formularios con scripts CGI. FormMail

Si lo que desea es un formulario que funcione de forma transparente al usuario, puede usar el método clásico de utilizar los scripts CGI. Con ellos, el usuario de su formulario, no tiene más que rellenarlos, pulsar el botón "Enviar" y nada más. Usted recibirá en su correo los datos que hayan sido completados.
Los scripts CGI son archivos escritos normalmente en lenguaje Perl y de los que gestionan el uso de formularios el más famoso es FormMail. Es un recurso tipo Open Source, desarrollado por Matt Wright, gratuito y de código abierto. Es el más usado universalmente.
Puede descargarlo de las múltiples páginas que lo ofrecen en internet, o bien desde el enlace en la escuela de arte de Talavera, en la sección documentos. Se ofrece como archivo comprimido, con un fichero de texto adicional de instrucciones (en inglés).
También se ha de comprobar con el servidor si éste da soporte para scripts CGI (los gratuitos no suelen). Con los servicios de hospedaje de pago es habitual que sí lo hagan. Si no lo hacen, ya sabe el camino que debe tomar cuando toque renovar el servicio.
Por lo general, si no quiere complicarse la vida configurando el FormMail, diríjase a su proveedor de servicios de hospedaje y hágale la consulta directamente, de cuál es la dirección en donde reside FormMail en su servidor. Le dirán qué debe poner en el campo Acción de su formulario y ya está. Suelen funcionar sin problemas.
Por el contrario, si su servicio de hospedaje no tiene un script tipo FormMail configurado para sus clientes, debe realizar sus operaciones a mano del modo en que se describe a continuación.
A través de su programa de FTP (yo recomiendo fervientemente no usar uno de terceros si edita con Dreamweaver, use directamente el propio DW para comprobar el estado de su sitio y su sincronización con los datos remotos), compruebe si hay una carpeta llamada cgi-bin en su servidor. Si no la tiene, puede crearla usted mismo y aquí es donde hay un punto de discordia entre los diferentes proveedores de servicio: ¿dónde crear la carpeta?
Habitualmente las páginas se publican en una carpeta llamada html_public o httpdocs o algo por el estilo. Pues bien, dependiendo de como traten los contenidos de su web, habitualmente la carpeta cgi-bin está por encima de la mencionada. Ahí es donde debe alojar el script o mirar si ya se la proporciona el proveedor, fuera de la pública. Si no tiene asignada una estructura de carpetas por el proveedor, puede probar a crearla dentro de la que aloja su sitio web completo. Esto afecta a la ruta que debe indicar en su formulario para ser procesado.
Debe modificar el FormMail con un editor de texto tipo Bloc de Notas (Notepad) o WordPad, desaconsejándose que se use un procesador de textos de los que guardan el texto con formato, pues no funcionará. El fichero ha de ser ASCII y el resultado de guardado posterior ha de ser FormMail.pl, aunque puede usarse otro nombre siempre que después lo indique en la acción de su formulario.

Las modificaciones esenciales de FormMail son las siguientes:

@referers = ('midominio.com','ip del servidor');

en su domino, debe poner el propio, por ejemplo 'escueladeartetalavera.com' y después la ip del servidor donde está alojada su web. Esta información puede obtenerla de los detalles del contrato con su proveedor de servicios, o del panel de control que suele asignarse a los clientes y donde se encuentran los datos referentes a su cuenta. Si no lo encuentra, puede dirigirse al proveedor de hospedaje para que se lo proporcione.

@recipients = ('midominio.com','usuario@midominio.com');

Aquí se indica el destinatario del correo que recibe los datos del formulario. Tiene la restricción que debe ser una cuenta de correo asociada a su dominio, no una dirección de correo cualquiera, porque FormMail hace referencia a los servidores de correo asociados con midominio.com. Cuestión distinta es si usted puede y quiere redirigir los mensajes que reciba en esa dirección a otra de su conveniencia, aunque en cuestiones de correo, yo prefiero no mezclar unos asuntos con otros. Razón de más para usar varias cuentas de correo y gestionarlas todas separadas, pero al mismo tiempo, con un programa como Outlook, pero esa es otra cuestión.

Para la web de la escuela de arte sería algo así:

@referers = ('escueladeartetalavera.com','192.43.132.56');
@recipients = ('escueladeartetalavera.com','info@escueladeartetalavera.com');

(la ip es ficticia)

Con estas modificaciones básicas, por el momento basta. No se abrume con el contenido del resto del script.

Una vez modificado, súbalo a su servidor por el método habitual, a la carpeta cgi-bin anterior.
Ahora hay que darle permisos al script, los llamados permisos CHMOD de lectura/escritura. Puede hacerlo directamente con Dreamweaver (¿no es maravilloso?), pulsando con el botón derecho sobre el fichero remoto alojado en el servidor (debe estar conectado) y en el menú contextual "Establecer permisos". Básicamente se permite al autor poder leer/escribir/ejecutar el script y a los usuarios, permitirles ejecutarlo solamente. Las diferentes opciones escogidas producen un valor total del permiso, pero usted puede limitarse a escribir 755 en el valor total.
No olvide comprobar que el valor total es 755 tanto para el script como para la carpeta donde se aloja.

Y, en el formulario, en la Acción, desde el inspector de propiedades de DW se pondría:

http://www.escueladeartetalavera.com/cgi-bin/FormMail.pl
El formulario ha de contener de modo imprescindible un campo oculto de tipo
[INPUT TYPE="hidden" NAME="recipient" VALUE="info@escueladeartetalavera.com"] donde el valor recipient ha de coincidir con la dirección de correo definida en el script.
Puede también probar a usar otros nombres del formmail si tiene problemas con las mayúsculas, siempre que lo indique en la acción del formulario.

El método como en el caso anterior, es POST.

El resultado es que cuando el usuario pulsa el botón enviar, el formulario se remite al archivo FormMail, que se encuentra ubicado en la carpeta cgi-bin. Este procesa la información y manda el resultado a la dirección de correo que se encuentra en el @recipient.

Pueden hacerse más modificaciones en el script, pero para lo que nos proponíamos, esto basta.

Puede consultar también otros tutoriales de internet, como éste, por si se entera mejor.

Pero desde este momento le indicamos que hay más consultas en internet respecto a como se configura y problemas insolubles, que a consejos útiles para que funcione debidamente. Creo que es por causa de que hay varias revisiones de FormMail funcionando y hay que leerse el manual adjunto (en inglés), lo que no siempre es fácil. Mi experiencia me dice que la mayor parte de problemas provienen de detalles absurdos, como el establecimiento de permisos o de la sintaxis empleada en el campo @recipients.
Si no ha sido capaz de hacer que funcionen de ninguna de las dos maneras, no desespere, porque le propongo dos métodos más: lea los artículos de correo.pl y FormMail compat.

Artículos relacionados:

Gestionar formularios
Formulario básico de correo
scripts CGI. correo.pl
FormMail compat

Formulario básico de correo

Daremos por sentado que se saben hacer formularios. Lo que es un campo de texto y demás. Aquí nos ocupamos de que funcionen.
La primera opción y más económica es recibir un correo en texto sin formato lo que se logra haciendo que la línea correspondiente a la "Acción" del formulario sea eso, enviar un correo. Por ejemplo: (sustituya los corchetes por <>)
[form action="mailto:javieranquela@gmail.com" method="POST"]
Si usa un editor de páginas tipo Dreamweaver, puede hacerlo en el inspector de propiedades. Seleccione el formulario (o su etiqueta form) y en el campo Acción escriba como si fuera un vínculo de correo electrónico mailto: sudirección@decorreo.com, donde ha de escribirse en esta dirección aquella en la que queremos recibir el contenido del dichoso formulario.

Habrá observado que el método elegido es POST y no GET, usándose este otro método, por ejemplo, en otras operaciones distintas, como es el de envío de valores de variables PHP con las direcciones de las páginas en sus URL, pero eso es harina de otro costal. Usted limítese al método POST.

Pero así solo no funcionará, por el tipo de codificación. En el método de codificación hay que escribir, (porque Dreamweaver por ejemplo no lo tiene entre sus opciones), text/plain y no otros tipos como el multipart/form-data o el application. Este es el punto clave para hacer que el correo funcione.
El usuario de su web que rellene el formulario, cuando le de al botón de enviar, verá, con sorpresa para muchos, que se confirma que se está enviando información desde el equipo y le pedirá que confirme el envío del contenido del formulario.
Este es el verdadero problema de este método y es que no está generalizado el uso de programas clientes de correo del tipo Outlook entre los usuarios de internet.

Si un usuario no tiene una cuenta de correo configurada en su Outlook, no podrá mandar el correo y si no sabe que habitualmente el mandar los correos no se hace de forma inmediata, sino que tiene que revisar si el correo ha salido de su Bandeja de Salida, peor que peor. Los más avispados podrán al menos abrir el correo y copiar la dirección del destinatario y mandar un correo vía web a mano. Pero para ese viaje no necesitábamos alforjas.

Supongamos que damos con alguien un poco espabilado, que tiene una cuenta de correo configurada en su Outlook. Lo que usted, como receptor del correo, recibirá será el nombre de los campos del formulario, se hayan rellenado o no, el contenido que haya puesto el usuario (incluso recibirá hasta los botones tipo "Submit") y por supuesto, si sabe manejarse con campos ocultos de formulario, el contenido de estos campos.
Todo ello como un mensaje legible de correo en texto sin formato, no como datos adjuntos. Como vendrá como un correo del usuario, tendrá también a disposición la dirección de email del que se lo mandó con lo que podrá responderle.
Y con esos datos puede hacer lo que quiera, eso sí, a mano.

Artículos relacionados:

Gestionar formularios
scripts CGI. FormMail
scripts CGI. correo.pl
FormMail compat

Gestionar formularios

Una de las frustraciones habituales con las que se encuentra un diseñador es cuando se enfrenta con un formulario y se las promete tan felices al respecto, de cómo recibirá comentarios, mensajes y sugerencias a través de la web. Y de pronto se encuentra con que los manuales de los programas de diseño (algunos no muy al día), en el mejor de los casos te enseñan a diseñarlos. Para la gestión, recurren a la consabida coletilla: "No es el objeto de esta obra el explicar como se gestiona un formulario; para más información, acuda a obras especializadas".
Que es tanto como decir que un diseñador debe limitarse a eso, a diseñar y que las tareas de gestión de formularios (y no digamos ya de bases de datos) es propia de otro departamento, el de informática.
¿Y si en mi empresa el que más sabe de informática soy yo (entre otras cosas porque soy el único dueño y empleado, por ejemplo)?
Con lo fácil que sería dar algunas pequeñas indicaciones. Tampoco es que el manejo de formularios para que funcionen, se rellenen, vayan y confirmen sea para mentes privilegiadas. Es, como todo, simplemente saberlo hacer.
Dedicaremos unos cuantos artículos a este tema.
En primer lugar, debe decidir qué pretende hacer con su formulario. Porque una cosa es recibir una sugerencia, una petición de contacto, etc. Y otra muy distinta recibir por la vía de un formulario una cantidad de datos con la finalidad de dar de alta a un usuario en un servicio o una petición de comercio en línea, como los de carritos de la compra.
En el primer caso, un mensaje de correo basta. Es decir, si queremos recibir una petición de información respecto a nuestros productos, una solicitud de contacto, una sugerencia, probablemente nos conformemos con recibir un correo electrónico donde el nombre del remitente, su email y su mensaje sean suficientes.
En el segundo caso, si queremos inscribir a un nuevo usuario en nuestro portal, aceptarle una contraseña, darle un servicio de correo, un catálogo en línea, cobrar un pedido a través de una pasarela, o mostrar unos movimientos bancarios, eso ya son palabras mayores: el destino del formulario no puede ser un simple correo, ha de ser una base de datos en la que se ingresen los datos rellenados.
Para el primer caso (destino correo), pueden usarse varios métodos, algunos realmente sencillos, bien directamente o bien a través de los scripts CGI (el más famoso, FormMail). En el segundo caso, se requiere habitualmente un lenguaje de comportamientos de servidor, tipo PHP, ASP, JSP o Cold Fusion, además de destreza en el uso y manejo de bases de datos tipo MySQL. Lo que no quiere decir que con PHP por ejemplo no se puedan solucionar formularios cuyo destino es un fichero de texto cualquiera, que también para eso sirve.
Quizás más adelante dediquemos unos artículos a estos y la integración con bases de datos. Pero por el momento nos centraremos en la cuestión más básica, aquella en la que un usuario se dice: soy usuario de HTML de toda la vida, ni sé PHP ni usar un servidor de correo, ni ganas; sé hacer un formulario y sólo quiero hacer que funcione, que alguien pueda escribir un mensaje, le de al botón "Enviar" y pueda recibirlo claramente.
De eso nos ocuparemos a continuación.

Artículos relacionados:

Formulario básico de correo
scripts CGI. FormMail
scripts CGI. correo.pl
FormMail compat

Video embebido

Podemos hacer un "embebido" del video directamente, de un video que se encuentra en una determinada dirección, con la etiqueta embed , que es la forma más económica de hacerlo. Este video ha de estar en línea y puede encontrarse en cualquier dirección de internet, solo hay que conocer su ubicación. Por ejemplo, en el caso de abajo, el código sería:

[embed src="http://video.google.com/googleplayer.swf?docId=9140752344761227618&hl=es"][/embed]

Desde Google Video

Desde el servicio de Google Video es semejante a Youtube. A ambos servicios puede accederse con una cuenta de Google-Gmail y su uso es semejante.
Se suben los videos a la cuenta respectiva en los formatos admitidos: *.mov, *.avi, *.mpg, etc. y tras el procesamiento, se busca el código HTML para ser insertado en la entrada del Blog.

Nótese en el caso de abajo una variante y es que la reproducción de video se logra automáticamente al cargar la página sin necesidad de pulsar el botón de "Play", simplemente añadiendo en el código el parámetro flashvars="autoPlay=true".

En todos estos casos, el vídeo va incrustado en un reproductor Flash que es generado por Youtube o Google Video.

Por ejemplo:

Subir video directo

Por el contrario, puede subirse directamente un video a Blogger con el botón "Añadir video" en la edición de entradas. En este caso, el resultado es distinto, así como el código generado. En cualquier caso, ya sea con Youtube (o para usuarios de Google Video), se ha de esperar un cierto tiempo entre la subida de video y su visualización, tiempo durante el cual el servicio correspondiente se dedica a procesar el mencionado clip.

Poner video desde Youtube

El vídeo que se reproduce a continuación se descarga directamente desde Youtube, que lo inserta en un reproductor Flash. Se copia el código y se pega en la entrada directamente. Puede personalizarse la apariencia del reproductor y también su tamaño como puede verse en el ejemplo siguiente, manipulando los atributos width y height. Es conveniente mantener la relación de aspecto.

Algunas mejoras sobre los feeds

Creo que ya expliqué que una de las tareas imprescindibles respecto a los feeds RSS es la de validarlos, ya que es muy frecuente que estos tengan algún error. Hay muchos servicios que pueden usarse para ello, pero yo uso Feed Validator, que te da indicaciones acerca de errores de código y sugerencias para mejorar.
Una de las mejoras sugeridas en uno de mis antiguos feeds es la inclusión de líneas que hacen del Feed compatible con XML y con Atom.
De igual forma, sugiere que haya una línea que haga referencia al propio feed dentro de la etiqueta channel.
A modo de ejemplo, el comienzo de uno de mis antiguos feeds (ya validado y probado su uso) queda de la siguiente forma (solo se muestra un item):

[?xml version="1.0" encoding="utf-8"?]

[rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"]
[channel]
[title]Escuela de Arte de Talavera[/title]
[link]http://www.escueladeartetalavera.com/[/link]
[description]Sitio oficial de la escuela de arte de Talavera[/description]
[language]es[/language]
[lastBuildDate]Mon, 19 Nov 2007 00:00:00 GMT[/lastBuildDate]
[atom:link href="http://www.escueladeartetalavera.com/rss.xml" rel="self" type="application/rss+xml" /]

[item]
[title]Premios II Maratón fotográfico Ciudad de Talavera[/title]
[pubDate]Mon, 19 Nov 2007 00:00:00 GMT[/pubDate]
[guid]http://www.escueladeartetalavera.com/maraton_2007/galeriamaraton2007.htm[/guid]
[description]Premios de la II edición del maratón fotográfico Ciudad de Talavera, organizado por la asociación cultural Taboracrom y patrocinado por el Ayuntamiento de Talavera de la Reina.[/description]
[/item]
[/channel]
[/rss]


Obsérvense las líneas resaltadas, donde no solo se hace mención a la ubicación del feed propio (en mi caso, se llama rss.xml) sino también a la fecha de última creación del feed y la de publicación de los items, información también útil.
Se sigue el convencionalismo habitual en este blog de que hay que sustituir los corchetes por los símbolos <>.

Premios Taboracrom

Se han fallado los premios de Taboracrom de fotografía y la obra se encuentra expuesta en la escuela de arte de Talavera durante este mes de noviembre y diciembre. Se cumplen así 11 años ya de estos premios y además se presenta por segunda vez una edición del Maratón fotográfico "Ciudad de Talavera", celebrado durante el pasado 12 de octubre y en el que se puede participar con cámara fotográfica o bien con el mismísimo teléfono móvil, con lo que la participación juvenil está asegurada.
Puede ampliarse esta informaciónaquí

Algunas muestras de las obras premiadas: