WebBlocks Appointments

Dokumentierte Paketversion: 0.12.2. WebBlocks CMS ^1.73.0; PHP >=8.3.

A WebBlocks CMS Plugin, das es einer Website ermöglicht, Buchungen auf ihrer eigenen Domain entgegenzunehmen, anstatt Besucher an einen Planungsdienst eines Drittanbieters weiterzuleiten.

Erstellen Sie das Artefakt und installieren Sie es dann über System → Plugins im CMS-Administrator mithilfe des normalen ZIP-Upload-Ablaufs.

Das Artefakt und sein SHA-256 landen unter build/. Plugin-Installation deaktiviert; Aktivieren Sie das Plugin explizit über den Plugin-Detailbildschirm, nachdem Sie es überprüft haben.

Alles, was das Plugin besitzt, wird gemäß den CMS-Plugin-Paketkonventionsregeln durch sein Handle benannt:

Fügen Sie den Block Appointment Form zu einer Seite hinzu. Durch die Auswahl eines Dienstes oder Tages werden die verfügbaren Zeiten abgerufen, ohne dass die gesamte Seite neu geladen werden muss. Wenn JavaScript deaktiviert ist, bleibt das vom Server gerenderte GET-Formular verfügbar. Jede Buchung wird an den Server übermittelt, der die Verfügbarkeit erneut prüft.

Der Titel, das Intro und das Submit-Label können pro Blockplatzierung übersetzt werden. Nur die Kopie des Blocks erfolgt pro Block. Dienstleistungen, Personal und Öffnungszeiten gelten für die gesamte Website, da die Duplizierung pro Block dazu führt, dass sich zwei Buchungsseiten im Stillen über die Öffnungszeiten nicht einig sind.

Zwei Schutzfunktionen, über die es sich zu informieren lohnt, da keiner von beiden im Markup sichtbar ist:

• Eingereichte Slots werden neu abgeleitet und sind nicht vertrauenswürdig. Der Bucher erzwingt Konflikte, aber nicht die Regeln, die entscheiden, was hätte angeboten werden sollen – Öffnungszeiten, Vorlaufzeit, der Horizont. Ohne die erneute Prüfung könnte ein gestalteter Beitrag 03:00 Uhr an einem geschlossenen Sonntag buchen, da nichts davon mit einem bestehenden Termin kollidiert.
• source_url wird nur als Pfad zur gleichen Site berücksichtigt. Eine absolute URL würde das Formular zu einer offenen Weiterleitung machen.

Wenn eine Buchung eingeht, erhält das Unternehmen eine Ankündigung und der Besucher erhält eine Bestätigung mit dem Termin als .ics-Anhang – wodurch er in seinen eigenen Kalender eingefügt wird, ohne Konto, ohne OAuth und ohne externen Service. Die Geschäftskopie legt den Kunden als Antwortempfänger fest, sodass eine Buchung durch Beantwortung beantwortet werden kann; Die Absenderadresse bleibt der konfigurierte Absender, da die Weiterleitung des Besuchers dorthin fehlschlägt SPF.

Drei Regeln sind wissenswert:

• Die Benachrichtigung erfolgt nach der Bestätigung der Buchung, niemals innerhalb der Transaktion.Ein Send, der auslöst, darf keinen Slot zurücksetzen, von dem dem Besucher bereits mitgeteilt wurde, dass er ihm gehört.
• Die beiden Seiten werden unabhängig voneinander ausprobiert und aufgezeichnet.Ein falsch eingegebener Geschäftsempfänger darf die Bestätigung des Besuchers nicht unterdrücken, und ein kombinierter Status würde dazu führen, dass der Admin-Bildschirm genau dort angezeigt wird, wo ein Betreiber ihn ehrlich gesagt benötigt.
• sentDas heißt, der Transport hat es angenommen, nicht, dass es angekommen ist.Derlog,arrayUndnullMailer werden als gemeldetnicht konfiguriertund nicht als gesendet, denn die Meldung als gesendet ist eine Lüge, die ein Betreiber nicht durchschauen kann.

Gespeicherte Fehlerdetails werden bereinigt: Verbindungszeichenfolgen und gekennzeichnete Geheimnisse werden geschwärzt und die Nachricht wird begrenzt, da sie den Bedienern angezeigt wird und eine rohe SMTP-Ausnahme routinemäßig Anmeldeinformationen überträgt.

Der geschäftliche Empfänger wird anhand der Plugin-Einstellung aufgelöst, dann die Kontaktadresse der Site und dann der konfigurierte Absender.

Reminders werden von einem Artisan-Befehl gesendet, nicht von einer Warteschlange – der CMS-Kern liefert keine Jobs in der Warteschlange, und die Einführung einer Warteschlangenabhängigkeit ist eine Kernentscheidung, die dieses Plugin nicht trifft. Fügen Sie es dem Cron des Hosts hinzu:

Alle paar Minuten sind in Ordnung. Jeder Termin wird genau einmal berücksichtigt: Das Ergebnis wird unabhängig davon aufgezeichnet, sodass ein Lauf nichts kostet, wenn nichts fällig ist, und eine nicht erreichbare Adresse nicht bei jedem Tick erneut versucht wird. --dry-run meldet, was ausgehen würde. Der Lead gilt pro Standort und Null schaltet Erinnerungen aus.

Die Bestätigungs- und Erinnerungs-E-Mails enthalten einen Stornierungslink. Es gibt kein Konto und keine Anmeldung – der Termin-cancel_token ist der Berechtigungsnachweis, was das einzig praktikable Design in einem CMS ohne öffentliches Benutzersystem ist.

Drei Regeln sorgen für Sicherheit und Ehrlichkeit:

• GET zeigt nur eine Bestätigungsseite; DELETE storniert. Mailprogramme, Linkscanner und Unternehmenssicherheitssysteme öffnen E-Mail-Links ohne Benutzerauftrag. Eine Stornierung bei GET würde daher Buchungen durch Spamfilter stornieren lassen.
• Ein unbekanntes Token und ein fehlender Termin sehen gleich aus. Eine Unterscheidung würde das Prüfen erratener Tokens ermöglichen.
• Ein bereits begonnener Termin lässt sich hier nicht stornieren. Andernfalls würde ein Nichterscheinen nachträglich in eine Stornierung umgeschrieben.

Wenn ein Besucher absagt, wird das Unternehmen benachrichtigt und cancelled_by zeichnet auf, dass es sich um den Besucher und nicht um einen Betreiber handelt. Wenn diese Benachrichtigung fehlschlägt, sieht der Besucher sie nie – die Stornierung ist bereits erfolgt und das Ergebnis wird weiterhin für den Betreiber aufgezeichnet.

ATerminzeitpunkte werden in UTC gespeichert. Öffnungszeiten und deren datierte Ausnahmen werden als lokale Wanduhr gespeichert, da „wir öffnen um 09:00 Uhr“ auf beiden Seiten eines Sommer-/Winterübergangs 09:00 Uhr bedeuten muss. Die Uhr der Site stammt von Site::resolvedTimezone(), niemals von config('app.timezone').

Der Slot-Generator orientiert sich an der lokalen Uhrzeit, sodass die Slots auf den Markierungen landen, die ein Besucher erwartet. Daraus ergeben sich zwei Übergangsfälle, die beide gewollt sind:

• Spring vorwärts. Wanduhrzeiten innerhalb der Lücke sind nicht vorhanden und werden nicht angeboten.
• Fall back. Wanduhrzeiten in der wiederholten Stunde existieren zweimal; Der Generator wählt den früheren Zeitpunkt. Der eigene Standardwert von PHP ist der spätere, es handelt sich also um eine explizite Auswahl und nicht um geerbtes Verhalten.

Doppelte Buchung wird auf drei Arten verhindert: durch eine Transaktion mit einem Sperrüberlappungs-Lesen (der eigentliche Wächter und der einzige, der Puffer und unterschiedliche Dauer versteht), einen eindeutigen (resource_id, slot_lock)-Index als Datenbank-Backstop, der dennoch die Umbuchung eines stornierten Slots ermöglicht, und die Übersetzung der resultierenden Integritätsverletzung in eine Antwort auf einen nicht verfügbaren Slot statt einer 500.

AppointmentsZeigt einen Tag nach dem anderen in der eigenen Uhr der Site an, mit Statusänderungen und manueller Eingabe.Services,Staff & RoomsUndOpening HoursDefinieren Sie, was wann gebucht werden kann.Appointment settingshält die Buchungsregeln, und das sind sie auchpro Standort— Zwei Standorte in einer Installation müssen sich nicht über die Vorlaufzeit oder den Bestätigungsmodus einigen.

A-Service oder -Ressource, die bereits Termine hat, wird deaktiviert und nicht gelöscht, sodass frühere Buchungen ihren Verlauf behalten, während keine neuen Buchungen dafür vorgenommen werden können. Die manuelle Eingabe erfolgt über denselben Bucher wie das öffentliche Formular, sodass keine Doppelbuchung möglich ist. Die erneute Überprüfung der Verfügbarkeit wird jedoch absichtlich übersprungen, da ein Betreiber, der außerhalb der Öffnungszeiten bucht, eine Entscheidung trifft und keine Regel umgeht.

Die Bearer-Token-API stellt Dienste, Personal und Räume, wöchentliche Verfügbarkeit, datierte Ausnahmen, Einstellungen und schreibgeschützte Termine unter /webadmin/api/plugins/webblocks-appointments bereit. Entdecken Sie die aktivierten Endpunkte und erforderlichen Funktionen mithilfe der CMS-API-Erkennung und des OpenAPI-Schemas.

Plugin Health prüft Datenbankeinrichtung, aktive Dienste und Ressourcen, Dienstzuweisungen, Öffnungszeiten, Benachrichtigungsempfänger, ausgehende E-Mails und Erinnerungsplanung.