WebBlocks Appointments

Versione pacchetto documentato: 0.12.2. WebBlocks CMS ^1.73.0; PHP >=8.3.

A WebBlocks CMS Plug-in che consente a un sito di accettare prenotazioni sul proprio dominio, invece di collegare i visitatori a un servizio di pianificazione di terze parti.

Crea l'artefatto, quindi installalo tramite System → Plugins nell'amministrazione CMS utilizzando il normale flusso di caricamento ZIP.

L'artefatto e il suo SHA-256 atterrano sotto build/. Installazione dei plugin disabilitata; abilitare esplicitamente il plugin dalla schermata dei dettagli del plugin dopo averlo esaminato.

Tutto ciò che possiede il plugin ha lo spazio dei nomi in base al suo handle, secondo le regole della convenzione del pacchetto plugin CMS:

Aggiungere il blocco Modulo di appuntamento a una pagina. Scegliendo un servizio o un giorno vengono recuperati gli orari disponibili senza ricaricare l'intera pagina. Con JavaScript disabilitato, il modulo GET reso dal server rimane disponibile. Ogni prenotazione viene inviata al server, che ricontrolla la disponibilità.

Il titolo, l'introduzione e l'etichetta di invio possono essere tradotti per posizionamento di blocco. Solo la copia del blocco è per blocco. Servizi, personale e orari di apertura sono presenti in tutto il sito, perché duplicarli per blocco è il modo in cui due pagine di prenotazione finiscono per essere in disaccordo silenziosamente sugli orari di apertura.

Due protezioni che vale la pena conoscere, perché nessuna delle due è visibile nel markup:

• Gli slot inviati sono derivati nuovamente, non attendibili. Il booker applica i conflitti ma non le regole che decidono cosa avrebbe dovuto essere offerto: orari di apertura, tempi di consegna, orizzonte. Senza il ricontrollo, un post creato potrebbe essere prenotato alle 03:00 di una domenica chiusa, poiché nulla di ciò è in conflitto con un appuntamento esistente.
• source_url viene considerato solo come percorso dello stesso sito. Un URL assoluto renderebbe il modulo un reindirizzamento aperto.

Quando arriva una prenotazione, l'azienda riceve un annuncio e il visitatore riceve una conferma che riporta l'appuntamento come allegato .ics, che lo inserisce nel proprio calendario senza account, senza OAuth e senza servizio esterno. La copia aziendale imposta il cliente come destinatario della risposta, pertanto è possibile rispondere a una prenotazione rispondendo ad essa; l'indirizzo del mittente rimane quello del mittente configurato, poiché l'inserimento del visitatore lì non riesce SPF.

Tre regole che vale la pena conoscere:

• La notifica avviene dopo il commit della prenotazione, mai all'interno della transazione. Un invio che lancia non deve ripristinare uno slot a cui è già stato detto che il visitatore è suo.
• Le due parti vengono tentate e registrate in modo indipendente. Un destinatario aziendale digitato in modo errato non deve eliminare la conferma del visitatore e, a dire il vero, uno stato combinato farebbe sì che la schermata di amministrazione si trovi esattamente nel caso in cui un operatore ne abbia bisogno.
• sent significa che il trasporto lo ha accettato, non che è arrivato. I mailer log, array e null sono segnalati come not configurati anziché come inviati, perché segnalarli come inviati è una menzogna che l'operatore non riesce a capire.

I dettagli dell'errore archiviati vengono ripuliti: le stringhe di connessione e i segreti etichettati vengono oscurati e il messaggio viene limitato, poiché viene visualizzato agli operatori e un'eccezione SMTP non elaborata trasporta regolarmente le credenziali.

Il destinatario aziendale risolve dall'impostazione del plug-in, quindi dall'indirizzo di contatto del sito, quindi dal mittente configurato.

I promemoria vengono inviati da un comando Artisan, non da una coda: il core CMS non fornisce lavori in coda e l'introduzione di una dipendenza dalla coda è una decisione fondamentale che questo plugin non può prendere. Aggiungilo al cron dell'host:

Ogni pochi minuti va bene. Ogni appuntamento viene considerato esattamente una volta: l'esito viene registrato qualunque esso sia, quindi una corsa non costa nulla quando non c'è nulla in scadenza, e un indirizzo irraggiungibile non viene ritentato ad ogni tick. --dry-run segnala cosa sarebbe successo. Il lead è per sito e zero disattiva i promemoria.

Le e-mail di conferma e promemoria contengono un collegamento per la cancellazione. Non esiste alcun account né accesso: la credenziale è la cancel_token dell'appuntamento, che è l'unico progetto realizzabile in un CMS senza sistema utente pubblico.

Tre regole garantiscono sicurezza e onestà:

• GET mostra solo una pagina di conferma; DELETE annulla. Client email, scanner di link e sistemi di sicurezza aziendali seguono i link senza richiesta dell’utente. Annullare tramite GET permetterebbe ai filtri antispam di annullare prenotazioni.
• Un token sconosciuto e un appuntamento inesistente appaiono identici. Distinguerli permetterebbe di verificare i token indovinati.
• Un appuntamento già iniziato non può essere annullato qui. Permetterlo trasformerebbe retroattivamente una mancata presenza in un annullamento.

Quando un visitatore annulla, l'azienda riceve una notifica e cancelled_by registra che si trattava del visitatore e non di un operatore. Se la notifica fallisce, il visitatore non la vedrà mai: la sua cancellazione è già stata confermata e il risultato è ancora registrato per l'operatore.

Gli istanti dell'appuntamento vengono archiviati in UTC. Gli orari di apertura e le relative eccezioni con data vengono memorizzati come orologio locale, poiché "apriamo alle 09:00" deve significare le 09:00 su entrambi i lati del passaggio all'ora legale. L'orologio del sito proviene da Site::resolvedTimezone(), mai config('app.timezone').

Il generatore di slot segue l'ora locale in modo che gli slot arrivino ai segni che un visitatore si aspetta. Da ciò derivano due casi di transizione, entrambi intenzionali:

• Molla in avanti. Gli orari degli orologi da parete all'interno dello spazio non esistono e non vengono offerti.
• Fall back. Gli orari dell'orologio da parete nell'ora ripetuta esistono due volte; il generatore sceglie l'istante precedente. L'impostazione predefinita di PHP è quella successiva, quindi si tratta di una scelta esplicita piuttosto che di un comportamento ereditato.

La doppia prenotazione viene impedita in tre modi: una transazione con una lettura sovrapposta di blocco (la guardia reale e l'unica che comprende buffer e durate diverse), un indice univoco (resource_id, slot_lock) come backstop del database che consente comunque di riprenotare uno slot annullato e la traduzione della violazione di integrità risultante in una risposta di slot non disponibile anziché in una 500.

Appointments mostra un giorno alla volta, nell'orologio del sito, con modifiche di stato e inserimento manuale. Services, Staff & Rooms e Opening Hours definiscono cosa può essere prenotato e quando. Appointment settings detiene le regole di prenotazione e sono per sito: due siti in un'unica installazione non devono concordare tempi di consegna o modalità di conferma.

A il servizio o la risorsa che ha già appuntamenti viene disattivato anziché eliminato, quindi le prenotazioni passate mantengono la cronologia mentre non è possibile crearne di nuove. L'inserimento manuale passa attraverso lo stesso booker del modulo pubblico, quindi non può effettuare una doppia prenotazione, ma salta deliberatamente il ricontrollo della disponibilità, perché un operatore che prenota al di fuori degli orari di apertura sta prendendo una decisione, non eludendo una regola.

L'API bearer-token espone servizi, personale e sale, disponibilità settimanale, eccezioni con data, impostazioni e appuntamenti di sola lettura in /webadmin/api/plugins/webblocks-appointments. Scopri gli endpoint abilitati e le funzionalità richieste tramite il rilevamento dell'API CMS e lo schema OpenAPI.

Plugin Controlla la configurazione del database, i servizi e le risorse attivi, le assegnazioni dei servizi, gli orari di apertura, i destinatari delle notifiche, la posta in uscita e la pianificazione dei promemoria.