01El precio lo decide tu servidor, nunca el navegador
El configurador muestra un total mientras el cliente elige, pero la cifra con la que se escribe el pedido se vuelve a calcular en el servidor únicamente a partir de la selección. Un total enviado por el navegador se ignora por completo. El dinero se guarda en unidades menores enteras, de modo que un pedido largo nunca se desvía un céntimo entre la factura y el pedido.
02Las fotos subidas no son adjuntos de la biblioteca de medios
Van a un directorio cuyo nombre no se puede adivinar, protegido de cuatro formas a la vez: una regla .htaccess, un web.config para IIS, un index.php y permisos de archivo que solo permiten leerlos al propio sitio. Un archivo se acepta por lo que son sus bytes, no por lo que afirma su nombre: un ejecutable renombrado a .jpg se rechaza en la puerta. Nunca reciben una URL pública.
03Una sola puerta de salida, y comprueba quién llama
Cada foto y cada vista previa se sirve por una única pasarela. A tu equipo lo deja pasar su permiso de pedidos de WooCommerce; al cliente lo deja pasar un enlace firmado que se verifica contra ese pedido y ningún otro. Un enlace creado para un pedido no puede abrir el archivo de otro, y un enlace manipulado no abre nada.
04El cliente aprueba sin crear una cuenta
La página de aprobación se abre directamente desde el correo: sin inicio de sesión, sin contraseña, sin carrito. Pedirle a alguien que se registre antes de poder ver su propia vista previa es la forma más segura de perder la aprobación. El enlace lleva su propia autoridad, está firmado y caduca; la página nunca se cachea, así que la vista previa de un cliente no puede servirse a otra persona.
05Revisiones hasta el sí, luego producción y ningún cambio más
Antes de la aprobación el cliente puede pedir una corrección tantas veces como haga falta, y cada petición queda registrada en el pedido. Tras la aprobación el formulario de revisión desaparece, y el servidor también rechaza la petición, no solo la pantalla. Según la normativa turca de venta a distancia, un artículo personalizado no da derecho de desistimiento una vez fabricado, así que el momento en que el cliente acepta eso se anota junto con la aprobación.
06Cuatro estados de pedido que solo avanzan
Modelado, esperando aprobación, imprimiendo, terminado. Qué puede seguir a qué está escrito como una lista de movimientos permitidos, no de prohibidos: un paso en el que nadie pensó se rechaza por defecto en lugar de permitirse en silencio. Los estados son estados de pedido reales de WooCommerce, así que aparecen en la lista de pedidos, en los informes y en tus filtros actuales.
07Una cola que dice qué va con retraso, no solo qué está abierto
La pantalla del taller ordena los pedidos abiertos por el tiempo que llevan esperando y marca en rojo los que han superado el plazo prometido: veinticuatro horas normalmente, seis en un pedido urgente. El operario sube la vista previa desde la misma pantalla y el cliente recibe el correo en la misma acción; no hay un segundo sitio que haya que recordar pulsar.
08Cuatro correos, enviados por la propia WooCommerce
Pedido recibido, vista previa lista, aprobación registrada, enviado. Se componen con la plantilla de correo de tu propia tienda, así que se parecen al resto de tus mensajes y no a un añadido. El enlace de aprobación aparece dos veces en el mensaje, como botón y como texto plano, porque algunos clientes de correo no dibujan el botón.
09Las fotografías no se quedan para siempre
Una tarea diaria borra las subidas y las vistas previas de los pedidos terminados tras un plazo de conservación que tú fijas: sesenta días de fábrica. El pedido, su importe y su registro de aprobación se quedan; la fotografía del cliente no. Guardar indefinidamente la foto de un niño en el servidor de una tienda es una responsabilidad, no una función.
010No pelea con tu caché
Tanto el configurador como la página de aprobación desactivan la caché de página para sí mismos, en el lenguaje que LiteSpeed, WP Rocket y W3 Total Cache entienden por igual, y además envían cabeceras no-store. Un configurador cacheado se envía con un token caducado y falla en silencio; una página de aprobación cacheada muestra la vista previa de un cliente al siguiente visitante. Aquí no puede pasar ninguna de las dos cosas.