QuarkXPress (III). Cajas

QuarkXPress (II). Esquinas. Operaciones booleanas

QuarkXPress (I). Preparar un documento.

AppServ. Instalación.

Tras haberse descargado el fichero de instalación, y proceder a ejecutarlo, en primer lugar nos encontramos con las habituales páginas de bienvenida, aceptación de uso de la licencia y la ubicación del directorio donde se procederá a instalar el producto (en este caso D:\AppServ\)






A continuación nos da la opción de instalar todo el paquete o solamente alguno de los módulos comentados. En nuestro caso los seleccionamos todos:



Posteriormente elegimos un nombre para nuestro servidor y que será el que usaremos para localizar nuestras páginas web de modo local. El universalmente usado es localhost ya que además ciertos proveedores de hospedaje lo califican así también en modo remoto para facilitarnos la tarea y no tener que referirnos con diferentes nombres al servidor local de nuestro ordenador y al remoto, lo que obligaría a cambios de código a la hora de subir nuestra web.
La dirección de correo electrónico en principio es indiferente, si vamos a usar nuestras web, de momento, en modo local. Así que sulen utilizarse nombres neutros de tipo admin@localhost root@localhost, etc.



A continuación se nos pide una contraseña y su confirmación que, dado que la instalación se hace de modo local, o bien no tenemos de momento información excesivamente sensible en nuestras bases de datos, o solo nosotros tenemos acceso a ellos o gente de nuestra confianza; de este modo para evitar líos y olvidos, podemos elegir igual contraseña que el nombre de usuario que automáticamente se nos ha creado root. Así que tendremos un superusuario, que administrará localmente las bases de datos de nombre y contraseña root. Evidentemente esta no puede ser la contraseña aconsejable en bases de datos remotas. Unas veces el nombre de usuario nos lo proporciona el proveedor de servicios, otras veces los creamos nosotros como superusuarios que seremos.



Las restantes pantallas muestran el progreso de la instalación y la notificación de que al finalizar se arrancarán automáticamente tanto el servidor Apache en nuestro ordenador, como el soporte para tratar con bases de datos MySQL.
Posteriormente habrá que hacer ciertos ajustes en ciertos archivos de configuración, de lo que trataremos en artículos siguientes.





Artículos relacionados
Appserv. Apache. PHP. MySQL. phpMyAdmin

Appserv. PHP. Apache. MySQL. phpMyAdmin.

El sistema más extendido de gestión de contenidos dinámicos en la web está basado en tener un servidor de aplicaciones como Apache, el intérprete para un lenguaje capaz de generar comportamientos de servidor como PHP y el uso de un tipo de bases de datos. El más usado para esto es MySQL.
Sobre todo porque son recursos gratuitos, de código abierto, con soporte actualizado y ser el sistema más usado por desarrolladores de todo el mundo, tanto para generar productos web básicos hasta los más exigentes.
Pueden instalarse independientemente cada uno de estos módulos y para ello pueden consultarse las páginas web oficiales tanto de Apache, como de PHP, como de MySQL, para estar al tanto de todas las sofisticaciones, últimas novedades y revisiones, así como para descargarse las últimas versiones.
Pero el camino que solemos seguir muchos que usamos la informática pero no somos informáticos y que es más cómodo (aunque no exento de ciertos inconvenientes), es el de instalar un paquete que automatiza lo suficientemente todas estas instalaciones que habríamos de hacer por separado.
Comentaremos la instalación de uno de estos múltiples paquetes que se encuentran en internet: Appserv, aunque es completamente semejante a como se haría con cualquier otro.
Puede visitar el sitio de Appserv para descargar la última versión estable, pero hay el problema de que no siempre los servidores que vamos a utilizar para publicar y gestionar nuestros sitios webs están a la última y si, por ejemplo, se va imponiendo la versión 5 de PHP, hay múltiples servidores que solo dan soporte para PHP4. Por eso, de nada nos sirve usar versiones de última hora si luego nuestro servidor no va a ser capaz de interpretarlos o procesarlos en toda su capacidad. Lo mismo ocurre con Apache o con MySQL.
Por eso describiremos la instalación de una versión concreta de Appserv: la 2.5.7.
Antes de pasar al siguiente artículo tenga claro que lo que al final tendremos instalado será lo siguiente:

Servidor: Apache
Lenguaje: PHP5
Tipo de Base de datos: MySQL.
Administrador de base de datos: phpMyAdmin

La instalación (para Windows) se trata en el siguiente artículo. Los usuarios de Mac deben encontrar las peculiaridades de la instalación para su sistema.

Artículos relacionados
Appserv. Instalación

FormMail compat

Y si aún después de todo, tiene problemas en la configuración manual de FormMail y no tiene acceso a usar el script residente en su proveedor de hospedaje, aún puede usar una variación de FormMail, llamado FormMail compat, menos farragoso y más claro que el original. Curiosamente usa la misma sintaxis que correo.pl del que ya hablamos anteriormente y cuyas líneas significativas quedan modificadas de la siguiente forma:

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

y que usted puede modificar con sus datos de dominio, IP y receptores de correo permitidos (pueden habilitarse varios). Observará que las modificaciones son idénticas a lo hecho con el script correo.pl.

Se sube el script, se modifican los permisos a 755, como ya se ha explicado, se modifica ACTION del formulario de forma: http://sudominio.com/cgi-bin/FormMail.pl, (el formulario ha de contener el campo oculto del receptor como ya se explicó anteriormente) y este script no falla.

Puede descargárselo en formato comprimido de la web de la escuela de arte de Talavera en la sección documentos.

Y también puede ver los ejemplos acerca de como usarlo para mandarlo a diferentes destinatarios y redirigirlo a otras cuentas de correo no asociadas al dominio en los documentos de texto adjuntos.

Artículos relacionados:

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

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