Initial commit

2026-08-02 20:55:23 +02:00
parent 411f484b40
commit d558d18d9a
295 changed files with 9 additions and 5880 deletions
@@ -1,32 +0,0 @@
-import type { PayloadEmailAdapter } from 'payload';
-export type PanelSmtpAdapterArgs = {
-    /**
-     * Used only until the panel is filled in — Payload requires a from-address
-     * synchronously at boot, before any global can be read. Once SiteIntegrations
-     * has an address, it wins.
-     */
-    fallbackFromAddress?: string;
-    fallbackFromName?: string;
-};
-/**
- * Payload email adapter backed by the SMTP settings in the SiteIntegrations
- * global.
- *
- * Why this exists: Payload builds its email adapter once, at boot, from the
- * config — which would normally mean SMTP credentials living in env vars and a
- * redeploy to change them. This adapter instead resolves SMTP on every send, so
- * an editor can change the mailbox in the admin panel and the next email uses
- * it.
- *
- * Wiring it into the config means `payload.sendEmail` works everywhere — which
- * includes the form-builder's own submission emails (the ones an editor
- * configures per form under "Emails"). Those go out over the panel's SMTP with
- * no extra code.
- *
- * Boot-time constraints shape two details:
- * - `defaultFromAddress` / `defaultFromName` must be returned synchronously, so
- *   they're placeholders; the real from-address is applied per message below.
- * - nodemailer is imported dynamically inside sendEmail, so merely loading the
- *   Payload config (or running `generate:importmap`) doesn't pull it in.
- */
-export declare const panelSmtpAdapter: (args?: PanelSmtpAdapterArgs) => PayloadEmailAdapter;