01È il tuo server a decidere il prezzo, mai il browser
Il configuratore mostra un totale mentre il cliente sceglie, ma il numero con cui l’ordine viene scritto viene ricalcolato sul server dalla sola selezione. Un totale inviato dal browser viene semplicemente ignorato. Il denaro è tenuto in unità minori intere, così un ordine lungo non si scosta mai di un centesimo tra la fattura e l’ordine.
02Le foto caricate non sono allegati della libreria media
Finiscono in una cartella dal nome non indovinabile, protetta in quattro modi contemporaneamente: una regola .htaccess, un web.config per IIS, un index.php e permessi di file che lasciano leggere solo al sito. Un file viene accettato per ciò che sono i suoi byte, non per ciò che pretende il suo nome: un eseguibile rinominato in .jpg viene respinto alla porta. Non ricevono mai un URL pubblico.
03Una sola porta d’uscita, e controlla chi bussa
Ogni foto e ogni anteprima passa da un unico varco. Il tuo team passa grazie al permesso sugli ordini di WooCommerce; il cliente grazie a un link firmato verificato contro quell’ordine e nessun altro. Un link creato per un ordine non può aprire il file di un altro, e un link manomesso non apre nulla.
04Il cliente approva senza creare un account
La pagina di approvazione si apre direttamente dall’e-mail: niente accesso, niente password, niente carrello. Chiedere a qualcuno di registrarsi prima di poter guardare la propria anteprima è il modo più sicuro di perdere l’approvazione. Il link porta con sé la propria autorizzazione, è firmato e scade; la pagina non viene mai messa in cache, così l’anteprima di un cliente non può essere servita a nessun altro.
05Revisioni fino al sì, poi produzione e nessun’altra modifica
Prima dell’approvazione il cliente può chiedere una correzione tutte le volte che serve, e ogni richiesta viene registrata sull’ordine. Dopo l’approvazione il modulo di revisione sparisce — e anche il server rifiuta la richiesta, non solo la schermata. Secondo la normativa turca sulle vendite a distanza un articolo personalizzato non dà diritto di recesso una volta realizzato, perciò il momento in cui il cliente lo accetta viene annotato insieme all’approvazione.
06Quattro stati d’ordine che avanzano soltanto
Modellazione, in attesa di approvazione, in stampa, completato. Che cosa può seguire che cosa è scritto come elenco di transizioni permesse, non di transizioni vietate: un passaggio a cui nessuno ha pensato viene rifiutato per impostazione predefinita anziché consentito in silenzio. Gli stati sono veri stati d’ordine di WooCommerce, quindi compaiono nell’elenco ordini, nei report e nei filtri che già usi.
07Una coda che dice cosa è in ritardo, non solo cosa è aperto
La schermata del laboratorio ordina gli ordini aperti per quanto tempo hanno atteso e segna in rosso quelli oltre il termine promesso: ventiquattro ore di norma, sei per un ordine urgente. L’operatore carica l’anteprima dalla stessa schermata e il cliente riceve l’e-mail nella stessa azione; non c’è un secondo posto da ricordarsi di cliccare.
08Quattro e-mail, inviate da WooCommerce stesso
Ordine ricevuto, anteprima pronta, approvazione registrata, spedito. Passano attraverso il template e-mail del tuo negozio, quindi assomigliano al resto della tua posta e non a un’aggiunta posticcia. Il link di approvazione compare due volte nel messaggio, come pulsante e come testo semplice, perché alcuni client di posta non disegnano il pulsante.
09Le fotografie non restano per sempre
Un processo giornaliero cancella i caricamenti e le anteprime degli ordini completati dopo un periodo di conservazione che imposti tu: sessanta giorni di serie. L’ordine, il suo importo e la registrazione dell’approvazione restano; la fotografia del cliente no. Tenere a tempo indeterminato la foto di un bambino sul server di un negozio è una responsabilità, non una funzione.
010Non litiga con la tua cache
Il configuratore e la pagina di approvazione disattivano entrambi la cache di pagina per sé stessi, nel linguaggio che LiteSpeed, WP Rocket e W3 Total Cache capiscono allo stesso modo, e inviano inoltre header no-store. Un configuratore in cache invia con un token scaduto e fallisce in silenzio; una pagina di approvazione in cache mostra l’anteprima di un cliente al visitatore successivo. Qui non può succedere né l’una né l’altra cosa.